[Open SoC Debug] CDM-OR1K implementation
philipp.wagner at tum.de
Fri May 18 17:42:02 CEST 2018
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
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.
More information about the OpenSoCDebug