[Open SoC Debug] cdm_ads memory map

Stefan Wallentowitz stefan at wallentowitz.de
Tue Nov 17 15:12:37 CET 2015

Hash: SHA1

Hi Andy,

final mail in this burst :)

Also taking up the discussion of the memory map for the actual debug
module (cdm_ads).

This was your suggestion in a mail:

> - In OpenRISC we had the 16 bit wide dbg interface, I also think 
> sticking to 16 bits makes the most sense. Since the CSR registers
> in RISC-V are already 12 bit wide, we should probably do some
> groups of 12 bits. Meaning we would have 16 groups in total

Makes sense. I generally have the feeling the 16 bit is sufficient for
addressing, do you think the same?

> - 1 group will go the CSR - 1 group we will probably spend on CPU
> internal registers like GPR, PPC, NPC and so on Although we will
> probably not fill the 12 bits, it allows us to do extensions later
> on (maybe a silly idea?)

We should mark them as reserved and can use them if we didn't come up
with a good idea until we run out of groups :)

> - 1 group we should spend on debug related stuff like Debug Mode 
> Registers (toggling single-stepping mode, trap on branch, ...),
> hardware breakpoints (if supported), basically everything that is
> related to run control for a core


> - 1 group maybe could be used for the MMIO specific things, like 
> version numbers, capabilities and so on

I was planning to put this in the lower registers, but now I came to
that my solution does not apply generally. I was planning to save the
extra access by adding stuff like version and id to the mmio_bridge.
This of course doesn't work when connecting to a bus or similar. So my
basic proposal is to pass the MMIO definition through (i.e., make it
identical to mmio_bridge). Capabilities etc. are still lacking, please
put in something whenever it comes to your mind :)

> - .... much more that I currently forget

Let's hope less than 12 groups :)

> - We should also try to keep this memory map as general as
> possible, so that it can be used directly also on the dbg interface
> to the
core > (assuming we keep the MMIO and dbg interface separate)
> This would make our lives easier later when we have to deal with
> the software part and also on the core side, since we can just pipe
> this through.

Yes, I was hoping once we have the convergence for two architectures
on the adv_debug_sys-based interfaces, we may be able to transfer it
to others, but to be honest I don't know much others. At least we
should have a layered software library with calls like read_csr(),
step() etc. that map to an MMIO driver for the debug interface that
use mmio_write() and mmio_read(). If you have some other debug
interface around it is definetely a good idea to try to unify it from
the beginning. I will have a look at lm32 or other open cores and
their interfaces the next days.

Version: GnuPG v2


More information about the OpenSoCDebug mailing list