[Open SoC Debug] CDM-OR1K implementation

Richard Herveille richard.herveille at roalogic.com
Fri May 18 17:57:24 CEST 2018

I actually did quite some work on the adv_dbg_if and rewrote major parts. It should be much cleaner now (see https://github.com/RoaLogic/adv_dbg_if).

I also added quite a few new features.

It would be cool if you can use this port, as it’s much cleaner than the one on OpenCores.





Richard Herveille

Managing Director – Roa Logic

Phone +31 (45) 405 5681

Cell +31 (6) 5207 2230

richard.herveille at roalogic.com




On 18/05/2018, 17:42, "OpenSoCDebug on behalf of Philipp Wagner" <opensocdebug-bounces at lists.librecores.org on behalf of philipp.wagner at tum.de> wrote:




On 05/18/2018 01:31 PM, Stafford Horne wrote:

On Thu, May 17, 2018, 10:37 PM SHIVAM AGGARWAL <shivam16195 at iiitd.ac.in 

<mailto:shivam16195 at iiitd.ac.in>> wrote:


     Thanks for the detailed and informative response for the CDM-OR1K


     I think it is the perfect time to work on the implementation of Core

     Debug Module.

     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)


Is it possible to not make this specific to or1k. I figure the cdm needs 

to just provide.

   1 an interface to read/write registers with an address like memory

   2 stall / resume the CPU

   3 notify debugger of a stall

The mapping and definitions of registers sounds like something target 

specific which should be handled in software.

Taking the read/write address And converting it to the or1k register is 

done in mor1kx already.

This is also all the advanced debug interface does. See:


"The OR1ON CPU sub-module is designed to allow a software debugger to access

the internal registers of a CPU, to stall the processor, and to take 

control when a

breakpoint occurs in software."


That is actually the modified PULP version of the Advanced Debug System, 

but the general principle still applies.


Sorry if I am missing something.


You didn't miss anything, and in fact the specification (as now 

published here 


is pretty much all about forwarding registers (starting at 0x400).


Why isn't this a generic debug wrapper? Mainly to keep it simple for now 

and to gain experience with it.


Open SoC Debug (OSD) has in theory the ability to read and write 32 bit 

registers through its infrastructure, in practice that's not fully 

implemented yet. So we took the "easy path" and split each 32 bit or1k 

debug register into two 16 bit OSD registers. This is a bit "hackish" 

and requires knowledge about the semantics of the actual register (when 

do they change, when can we update safely to have "almost atomic" 

behavior, etc.). But it should enable Shivam to make easier progress and 

focus on the main task.



Once we are confident things work how we envision it, and have added the 

ability to do 32 and 64 bit register access over the debug 

infrastructure we can make the implementation generic by what will most 

likely be trivial changes.




OpenSoCDebug mailing list

OpenSoCDebug at lists.librecores.org



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.librecores.org/pipermail/opensocdebug/attachments/20180518/6d45480e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5014 bytes
Desc: not available
URL: <http://lists.librecores.org/pipermail/opensocdebug/attachments/20180518/6d45480e/attachment-0001.bin>

More information about the OpenSoCDebug mailing list