[Open SoC Debug] GSoC project to improve soft-CPU debugging in LiteX + MiSoC

Tim Ansell mithro at mithis.com
Sat Mar 4 04:19:26 CET 2017

> Actually, an integral part of OpenSoCDebug is the transport layer where
> we use (our own) "Generic Logic Interface Project" (http://glip.io).

I was thinking that the transport layer would have been independent of the
debug definition?

> The
> mainline transports we use are UART, JTAG and the EZ-USB stuff of
> Cypress. Something around Ethernet was started a few times, currently I
> think the lowRISC guys are most advanced here, let me double check.

A number of our FPGA boards have a Cypress FX2 on them which is probably
compatible with the ZTEX EZ-USB firmware. This might be useful for some
initial testing, but in many cases we are using the FX2 in a "usb device
emulation mode" (IE it appears as a webcam + serial port or similar), so
probably wouldn't want to use their firmware in that case.

> What that means to your diagram: OpenSoCDebug's "intended" mode of
> operation is orthogonal to the actual SoC. Anyhow, we could certainly be
> able to integrate in the sketch, but I would suggest we re-iterate the
> bridges in there. If the WB2Host Bridge is planned exclusively for
> debug-related feature, than it may be replaced with the OpenSoCDebug
> host interface and transport.

The WB2Host bridge is used in a number of ways;

 * When developing a core it is useful to have *just* the bridge and the
thing you are working on. This makes the development cycle much faster as,
     - the FPGA is mostly empty which speeds up the gateware generation,
     - stuff running on the host can manipulate & state in a high level

 * When using litescope (our equivalent to ChipScope) it allows controlling
the set up and reading back the captured data.

 * With a full system SoC it is often used as a quick way to load stuff
into memory (this could be firmware, but we have used it as a hacky way to
load test pattern graphics and similar).

I actually tried to explain some of this in my talk at Linux.conf.au. You
can find a recording at https://www.youtube.com/watch?v=MkVX_mh5dOU with
slides at https://j.mp/pyhw-lca2017


If I'm understanding GLIP, maybe it makes sense to define a "GLIP WishBone
Transport"? This transport would be pretty minimal -- is this the "memory
mapped access" that you are talking about below?

Having this transport you could actually have a CPU "debug itself" via the
WishBone bus? Or if you have a multi-core system, you could also have one
CPU debug another one?

Could we just then expose GLIP on a TCP socket and map it to the WishBone
interface directly then?

>      * How much of existing OpenSoCDebug code can we reuse?
> Ideally the most of it :) I would allocate some time from my side to
> make it fit your problems if it makes sense.
> >      * How might we use OpenSoCDebug over our existing wishbone bridges?
> >     I assume we want to expose something like the OpenSoCDebug registers
> >     onto either our wishbone or CSR bus?
> There are multiple interfaces. The most generic is the debug packet
> interface, which would require some (de-)packetization. The run control
> debug module would in most cases just convert debug packets back to
> memory-mapped accesses (also in the upcoming RISC-V debug), so that I
> would tend to say there is only much reuse when the wishbone part is not
> there. With it I think it is simpler to hook up the memory mapped
> interface directly.
> >      * Currently the Python interactive console and scripts talk to the
> >     WB bridge over UDP/IP (with the Etherbone protocol I believe?).
> >     There is a small Python adapter server which converts the
> >     non-Ethernet bridges into UDP/IP on the host. Does this mean OpenOCD
> >     should learn the EtherBone UDP/IP protocol?
> I didn't have a look at EtherBone. We would need to add it to glip. I
> think that makes a lot of sense to do that.

I don't actually know much about EtherBone (or if we are actually using
Etherbone). From the Python side I just get wb.write() / wb.read() like
functions and haven't really looked under the hood that much.

Tim 'mithro' Ansell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.librecores.org/pipermail/opensocdebug/attachments/20170304/4ed43df6/attachment.html>

More information about the OpenSoCDebug mailing list