[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
specs/features.
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.

Tim
-------------- 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