[Open SoC Debug] GSoC Proposal | To improve soft-CPU debugging in LiteX + MiSoC
shivam16195 at iiitd.ac.in
Mon Mar 26 14:46:39 CEST 2018
I think now I have a firm understanding of CDM module.
On Mon, Mar 26, 2018 at 5:39 PM, Philipp Wagner <philipp.wagner at tum.de>
> Please keep all project-related discussion on the public mailing list so
> that others can profit from the answers as well. Thank you!
> On 03/26/2018 01:50 PM, SHIVAM AGGARWAL wrote:
>> I have a few doubts regarding the implementation of CDM module.
>> As far as I understand, CDM is responsible for translating requests made
>> by OSD interconnect to CPU core.
> Requests are not made by the interconnect, but by the software on the host.
> These request are in OSD specific
>> registers packets and need to be transferred to CPU core such that it can
>> understand the request and respond accordingly. Similarly, all response
>> actions and events triggered by CPU core will be translated back into OSD
> You cannot translate something into a specification. Responses are
> packaged into Debug Interconnect packets, i.e. the "data format" used for
> all communication in OSD.
> > and transferred back to the host. So, CDM
>> module is basically a memory mapped interface between CPU core and OSD
>> interconnect. Is that correct?
> The wording is rather unusual, but not completely wrong.
>> I mapped debug registers given in the OR1K CPU VERILOG module into OSD
>> specific registers. But, I believe that's not what I was supposed to do.
> It's expected to map the debug registers of the CPU. But what you did is
> one layer below that, you mapped individual ports in the Verilog
> Please help a bit for this part. I looked at the documentation of debug
>> packets in OSD. Basically, OSD packets have following register types:
> That's not a "register type" of a packet (there is no such thing), that
> are fields inside a Debug Interconnect Packet. These fields describe the
> general structure of a communication packet. The semantics come from the
> higher layer, i.e. how these fields are used. That is what is described in
> dataformats.html#register-read-request-type-sub-req-read-reg for example.
What we're looking for is a mapping between CPU debug registers, as
> specified in the OR1k ISA Chapter 11 (Debug Unit) to registers in the
> to-be-developed OSD Core Debug Module (CDM).
> For example, the register DVR0 of an OR1k CPU (Debug Value Register 0,
> could be a breakpoint or watchpoint address) could be mapped to register
> address 0x300 of the CDM module. When you write (from the host software)
> the register 0x300 of the CDM module, this register write is forwarded to
> the CPU's DVR0 register over the debug bus (the one with the du_* signal
> names in the mor1kx implementation).
Thanks a lot for this explanation. Now, I have a firm understanding of the
CDM module. Those debug registers which I mentioned in the proposal are
actually the carriers of information.
> Reads happen in the same way. All of that discussion doesn't touch the
> internal structure of the Debug Interconnect Packet that you showed, it's
> semantics on top of that.
> Here, each register is 16 bits long. So, according to the documentation.
>> So, debug registers in CPU core need to be translated into these
>> specifications, right?
> What do you mean by "here"?
Now, I am clear with this part. So, we can safely ignore the above lines.
> Now, you mentioned in the last mail, regarding osdacceess register
> There is no module with that name.
Sorry for the mistake. I actually meant osd_regaccess verilog
module. Using osd_regaccess module, I can forward the register access
requests to the debug ports of the mor1kx core (the one with the du_*
signal names in the mor1kx implementation), right?
The only inputs to regaccess module are clk, rst, debug_in and
debug_out_ready. So, if debug_in = 1, the module is ready to accept debug
access request and if debug_out_ready = 1, then the request made by the
module is asserted.
> VERILOG module. I tried looking for the documentation of the module but
>> couldn't find a lot of details. I mentioned some points in the proposal
>> regarding the module. Please throw some more light on this part as how it
>> will be used.
Thanks a lot for bearing with me. I believe I have a good understanding of
the project by now. I will update the proposal in an hour and share the
same with you for further feedback.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenSoCDebug