[Open SoC Debug] Queries Regarding GSoC and Open SoC

Anant Sharma anant16129 at iiitd.ac.in
Wed Mar 21 02:11:08 CET 2018


Its been a while. I will tell you the things I have tried from my side to
try and implement a breakpoint in the mor1kx module. I will try to be as
specific as I can so that you might be able to help me out. I will also
talk about the problems I faced.

1. I understand the registers on which I have to load bits to get things
done. But, I had to do a lot of research on the repository of mor1kx to
find out which register does what. I am still uncertain but I know the path
that is being followed by each bit put in the 'du_*' registers. There are
things that I am still uncertain about like the difference between the data
and address register.

2. Any values I load on the registers on the mor1kx_module file is not
effecting the output at the gtkwave at all. One of the possible reasons
might be that I am not in Supervisor mode but I am having trouble figuring
that out.

3. In my experience with Verilog. You simply cannot load stuff into input
ports of the module. I obviously know how to write to a bus but that is not
exactly an editable bus here. I would have to deal with the 'from where'
are the bits in the register coming from so that this can be edited and
changes can be made at the source. What I am doing as of now is creating
registers of similar names and using those registers to push bits into the
next channel.

If I am able to solve this out. I will start writing my proposal.

On Mon 12 Mar, 2018, 1:56 PM Philipp Wagner, <philipp.wagner at tum.de> wrote:

> On 03/12/2018 07:07 AM, Anant Sharma wrote:
>> So here is what the problem is, the ports i mentioned above are
>> instantiated to
>> mor1kx as the parameters of the 'du_'s you mentioned and given is a
>> sceenshot
>> that tells me that I am receiving nothing in those parameters. I know the
>> changes
>> I have to make, but I need to know the current program counter to set
>> breakpoints
>> right?
>>  >> input         dbg_stall_i, // External Stall Input
>>  >> input         dbg_ewt_i, // External Watchpoint Trigger Input
>>  >> output [3:0]  dbg_lss_o, // External Load/Store Unit Status
>>  >> output [1:0]  dbg_is_o, // External Insn Fetch Status
>>  >> output [10:0] dbg_wp_o, // Watchpoints Outputs
>>  >> output        dbg_bp_o, // Breakpoint Output
>>  >> input         dbg_stb_i, // External Address/Data Strobe
>>  >> input         dbg_we_i, // External Write Enable
>>  >> input [31:0]  dbg_adr_i, // External Address Input
>>  >> input [31:0]  dbg_dat_i, // External Data Input
>>  >> output [31:0] dbg_dat_o, // External Data Output
>>  >> output        dbg_ack_o, // External Data Acknowledge (not WB
>> compatible)
>>  >
>>  >
>>  > These signals are the read/write ports for the debug registers.
>> Well as gtkwave suggests, these ports do not receive any information
>> throughout
>> the execution of the program. That is the part I was confused about in my
>> previous
>> email since I wasn't able to receive any data from anywhere.
> As long as you don't drive the bus you will not see any activity there. As
> this is a rather fundamental question, please pick up any digital design
> textbook on how to interact with a bus.
> Best,
> Philipp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.librecores.org/pipermail/opensocdebug/attachments/20180321/a1db4d13/attachment.html>

More information about the OpenSoCDebug mailing list