[Open SoC Debug] packet vs. memory interface

Tim Newsome tim at sifive.com
Wed Jan 27 20:42:24 CET 2016

Hi opensocdebug,

I'm working on a RISC-V debug spec, and have been e-mailing with Stefan a
little bit to try to understand better exactly what you guys are putting
together, and to maximize the amount of overlap between our debug
Stefan suggested continuing our conversation here, so other people can jump
in and so there's a record of his explanations to me. So here I am!

On Tue, Jan 26, 2016 at 12:21 PM, Stefan Wallentowitz <
stefan at wallentowitz.de> wrote:

> > Keeping that in mind, I'd like to dig a bit more into packets vs.
> > address bus. Leaving trace aside, my understanding of opensocdebug is
> > that you use glip between debugger and the platform. glip appears to be
> > based on sending data serially. I don't see any abstractions for
> > reading/writing a specific address. How does that work? (Or is it
> > documented elsewhere?)
> As an interface glip provides a parallel FIFO interface. It has one
> outgoing and on incoming FIFO of a width multiple of bytes. Beside this
> it has one extra wire logic_rst, that is used to reset a design
> remotely. This is the abstraction interface we have both in software and
> in hardware. The actual physical interface can be serial or parallel.
> Most low speed are serial (UART, JTAG). Beside that we have support for
> USB2/USB3 via the Cypress ez-usb chips. They are parallel. PCI-e is not
> yet finished, but pseudo-parallel IIRC.
> In Open SoC Debug we now build a protocol on top of the plain data
> stream that goes in and out of glip. As bit width we use 16 bit (which
> is the defined minimal width). I started with defining exactly those
> basic register accesses in the base specification:
> https://github.com/opensocdebug/documentation/blob/master/spec_base/specification.md#debug-packet-types
> There are some base registers for control and status (a picture I drew
> later today depicts it:
> https://github.com/opensocdebug/documentation/blob/master/overview/overview.md#debug-modules
> )
> and beside this a run-control debug module would now be controlled from
> the host's gdbserver by reading and writing the registers of the "debug
> unit". This is where Andreas Traber and Richard Herveille contribute
> currently to make this map similar to the one used by the adv_dbg_sys,
> which they employed in their design and that we also use in
> OpenRISC-based SoCs. So for this debug module the Open SoC debug plan is:
> gdb <-> opensocdebugd <-> glip <-> debug_ring <-> cdm <-> core
> and cdm is a module composed of two basic blocks:
> ring <-> [ mmio_bridge <-> cdm_adv ] <-> core
> The mmio_bridge supports the register reads and writes plus it generates
> a debug event when a breakpoint is hit. The cdm_adv module is just small
> wrapper that translates the core debug interface as specified in
> http://opencores.org/websvn,filedetails?repname=adv_debug_sys&path=%2Fadv_debug_sys%2Ftrunk%2FDoc%2For1k_debug_sys_manual.pdf
> to another interface. Andreas Traber is planning to use only the cdm_adv
> module to hook it up to a bus and control it from another core.

My thoughts here are that this is a lot of overhead if all you care about
is accessing memory mapped registers. It seems more straightforward to
implement a protocol that doesn't require an extra layer of packet format
on top of a memory bus. Am I overestimating the extra complexity here?

Having said that, I understand why you arrived at this design. You started
with a bus for trace, and once you have that you may as well use it for
debug as well.

I'm coming at it from the other side, which is to specify a debug interface
with minimum extra features, so I used the system bus. If proper trace is
to be added, it'll have to use a separate bus, but not everybody wants to
spend the resources required for that.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fossi-foundation.org/pipermail/opensocdebug/attachments/20160127/f73c0110/attachment.html>

More information about the OpenSoCDebug mailing list