[Open SoC Debug] CDM-OR1K implementation

Philipp Wagner philipp.wagner at tum.de
Fri May 18 18:01:32 CEST 2018

Hi Shivam,

On 05/17/2018 03:37 PM, SHIVAM AGGARWAL wrote:
> Hi,
> Thanks for the detailed and informative response for the CDM-OR1K 
> specification
> I think it is the perfect time to work on the implementation of Core 
> Debug Module.

absolutely. And thanks for your patience while we iterated over the spec 

I've now merged the spec and you can find it online here: 

> Few attributes of CDM-OR1K from the spec:
>   * Provides a register map for OR1K debug registers: Something similar
>     to one in MAM but less complicated (We have already mapped them in
>     specification)
>     https://github.com/opensocdebug/osd-hw/blob/cc01967f5c685645f4f83510f9710658643b3263/modules/mam/common/osd_mam.sv#L134
>   * To allow GDB access to these mapped registers using
>     osd_regaccess_layer: Similar to this implementation
>     https://github.com/opensocdebug/osd-hw/blob/cc01967f5c685645f4f83510f9710658643b3263/modules/mam/common/osd_mam.sv#L100
>     <https://github.com/opensocdebug/osd-hw/blob/cc01967f5c685645f4f83510f9710658643b3263/modules/mam/common/osd_mam.sv#L100>
>   * How are the input/output values (input dii_flit debug_in, output
>     logic debug_in_ready, output dii_flit debug_out, input
>     debug_out_ready) determined? Are these values similar to enable signals?

I don't understand that question. These are the NoC signals as described 

>   * Next we need to ensure that we can interact (i.e., read/write
>     operation) with the or1k debug unit effectively. For write, we
>     already have an update write register.

This means you have to introduce a 32 bit wide register stage between 
the registers as they are provided by osd_regaccess_layer and the actual 
or1k registers.

>   * Debug stall event packetization. Do we need something similar to
>     osd_trace_packetization
>     <https://github.com/opensocdebug/osd-hw/blob/master/blocks/tracepacket/common/osd_trace_packetization.sv>?

You can use that module as inspiration on how to send an event packet, yes.

>   * In the attached or1200 architecture
>     <https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=4&cad=rja&uact=8&ved=0ahUKEwjloOWE7IzbAhXafX0KHb82B9MQFghGMAM&url=http%3A%2F%2Fwww.cl.cam.ac.uk%2Fresearch%2Fsrg%2Fhan%2FACS-P35%2Fdocuments%2Fopenrisc1200_spec.pdf&usg=AOvVaw1Hk6hwaTdFSBQT_tpihEPW>,
>     there is quite a good explanation for debug development interface
>     (Page 48 onwards). In or1200, there is dbg_op_i[2:0] to choose
>     between different operations. But, I couldn't find the one in mor1kx
>     code. I need a little more help in that part.

You only need the signals starting with du_* as shown in 
Note that the or1200 implementation is older and not the one we're using 
(although it's similar in many ways).

>   * Do we need to make changes to the mor1kx code?

> All the stuff related to CDM-OR1K will be in this 
> repository:https://github.com/opensocdebug/osd-hw/tree/osd-next
> There is already an issue related to CDM for mor1kx 
> https://github.com/opensocdebug/osd-hw/issues/22

You can go ahead and start implementing the hardware part. Please open a 
PR once you have initial code ready.

Unfortunately, the cocotb-based unit tests used in OSD currently require 
Synopsys VCS to run, there's no free alternative which can be used. If 
you don't have access to VCS (which I doubt you do) development will be 
a bit more tricky.

As a rough idea, I'd propose to
1. Start with an existing compute_tile_dm system in OpTiMSoC and run 
that in Verilator. Do all subsequent hardware modifications on OSD also 
in an optimsoc source tree (which contains copies of osd-sw and osd-hw). 
Once you have the system working there we can take out the changes from 
optimsoc and merge them into the right osd-sw and osd-hw repositories).

2. Create the initial structure of the CDM module by taking code from 
one of the other existing debug modules. Make sure you roughly 
understand what you're copying!

3. Add the new CDM debug module to the OpTiMSoC system. Look how it's 
done e.g. for the STM module and do it the same way.

4. Now you can make use the existing software and their python bindings 
to write and read registers, and observe how they are forwarded to the 
mor1kx module by looking at the waveforms that Verilator generates.

I know that getting started here is tricky and is much easier with a bit 
of experience in this domain. I therefore propose you get started with 
step 1 and 2 and try step 3. If you hit a roadblock there please make 
your code available in a repository and I (or Max) can have a look at it.


More information about the OpenSoCDebug mailing list