[Open SoC Debug] Fwd: CDM-OR1K implementation

SHIVAM AGGARWAL shivam16195 at iiitd.ac.in
Wed May 23 18:10:42 CEST 2018


On Wed, May 23, 2018 at 5:44 PM, Philipp Wagner <philipp.wagner at tum.de>
wrote:

> Hi,
>
> On 05/23/2018 10:36 AM, SHIVAM AGGARWAL wrote:
>
>>  1.
>>
>>     *Register map for SPRs and GPRs in CDM-OR1K*:
>>
>> We can easily map 32-bit wide 32 GPRs as two 16-bit OSD specific
>> registers in the module. We already have access to the debug unit for
>> setting watchpoints/breakpoints.
>>
>> In GDB, there are commands like ‘info spr’ used to show the value of a
>> SPR or group of SPRs and ‘spr’ to set the value of an individual SPR. There
>> are about 12 groups (permitted upto 32) with some groups (1, 2 and 3)
>> having 1000+ SPRs.
>>
>>
>> We can assign address spaces 0x0200-0xffff (about 65023 registers) as
>> module specific registers in CDM-OR1K. The space is enough to map each or1k
>> register into OSD address space.
>>
>
> Could you list the full register map somewhere in a document (the list can
> contain groups, but should list all relevant register addresses and their
> mapping to OSD CDM register addresses). The du_addr_i signal is a 16 bit
> signal, given that we don't have full 16 bits available for register
> address in OSD (we can only start above 0x200) we need to make sure that we
> map all relevant parts of the or1k register space to OSD registers.
>

Link:
https://drive.google.com/open?id=15EVkp6ij-7tRm2m3mgQqwUAhHUYLOkxG
The pdf contains all the information about OR1K Register Set. Section 4.3
contains the list of all the Special Purpose registers. As per my
understanding, we have to map each and every register (total 4665 SPRs + 32
GPRs) given in the description.

>
> *Alternate solution*: Can we have certain dedicated read/write registers
>> in the module?
>>
>> i.e instead of mapping each and every register, each time GDB asks for a
>> specific SPR read/write, we can store its address in one of OSD register
>> and data in two other registers. This information can be translated over
>> system interface signals to the CPU core. But, for commands like ‘info
>> spr’, we might need to store such information for all the SPRs.
>>
>
> That is possible, although very inefficient as you need multiple
> roundtrips for each access.
>
>       2. *System Interface signals*
>>
>> Currently, we have debug signals for the debug unit. The complete
>> interface should work like this:
>>
>>
>> Read operation:
>>
>>  1.
>>
>>     GDB commands Register read.
>>
>>  2.
>>
>>     OSD debug interconnect passes this request in the form of a register
>>     read request debug packet to the module.
>>     (https://opensocdebug.readthedocs.io/en/latest/02_spec/03_da
>> taformats.html#register-read-request-type-sub-req-read-reg)
>>
>>  3.
>>
>>     CDM-OR1K acknowledges that request. du_we_i port goes low. (read
>>     operation)
>>
>>  4.
>>
>>     OR1K reads data from that address into OSD registers. (du_dat_o port)
>>
>>  5.
>>
>>     Now CDM-OR1K passes this information to OSD debug interconnect in
>>     the form of two reg read response packets.
>>     (https://opensocdebug.readthedocs.io/en/latest/02_spec/03_da
>> taformats.html#register-read-response-type-sub-resp-read-reg-success)
>>
>
> What do you mean by "two reg read response packets"? Every REQ_READ_REG_16
> is answered by a single RESP_READ_REG_SUCCESS_16.
>
> If you want to split a 32 bit register into two 16 bit registers over OSD
> you need to have two REQ_READ_REG_16 and two RESP_READ_REG_SUCCESS_16
> packets, i.e. two fully independent requests.


Okay understood. So when GDB asks for a read operation from (let's say) SPR
at address 0x423 in the CPU core, internally we need to have two
REQ_READ_REG_16 for the mapped OSD specific register. And then, there will
be two RESP_READ_REG_SUCCESS_16 packets, i.e. two fully independent
requests.
Currently, this is accomplished using osd_regaccess_layer.

[Given that we seem to need a significant number of registers to be mapped,
> and the trouble of implementing the split of 32 bit registers into two 16
> bit registers seems to be significant, I'm slowly thinking we should invest
> the time to finish the implementation of 32 bit register accesses through
> OSD. Let's revisit that topic once we have a clear understanding of the
> required register map, as discussed above.]
>

I think that might be a good option. As per my understanding, we have to
change Host Interface Module and osd_regaccess_layer on the hardware side.
Please correct me if I am wrong.

>
> 1. I looked in the description of mor1kx to figure out the system
>> interface for SPRs and GPRs. Can these signals be used for the system
>> interface?
>>
>> https://github.com/openrisc/mor1kx/blob/a9a01c009ea2b2476497
>> 3560fde4a9855f4ba95d/rtl/verilog/mor1kx_cpu.v#L157
>>
> >
> > OR,
> > https://github.com/openrisc/mor1kx/blob/a9a01c009ea2b2476497
> 3560fde4a9855f4ba95d/rtl/verilog/mor1kx_bus_if_wb32.v#L28
> >
> > 2. Also since the system interface for SPRs will be different from that
> > of Debug unit, CDM-OR1K must also know a way to differentiate between
> > the two, right?
>
> No, you can (and should) only use signals which are available in the
> toplevel, i.e. here: https://github.com/openrisc/mo
> r1kx/blob/master/rtl/verilog/mor1kx.v. The du_* signals can access any
> register, including SPRs. (That's at least my understanding, Stafford can
> confirm.)
>
> Okay.

>
> Philipp
>

- Shivam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.librecores.org/pipermail/opensocdebug/attachments/20180523/beae51fb/attachment.html>


More information about the OpenSoCDebug mailing list