[Open SoC Debug] CDM-OR1K implementation

Philipp Wagner philipp.wagner at tum.de
Wed May 23 14:14:58 CEST 2018


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 

> *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_dataformats.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_dataformats.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.

[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.]

> 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/a9a01c009ea2b24764973560fde4a9855f4ba95d/rtl/verilog/mor1kx_cpu.v#L157
 > OR,
 > 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/mor1kx/blob/master/rtl/verilog/mor1kx.v. The 
du_* signals can access any register, including SPRs. (That's at least 
my understanding, Stafford can confirm.)


More information about the OpenSoCDebug mailing list