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

Tim Ansell mithro at mithis.com
Wed Mar 1 06:21:24 CET 2017


The TimVideos project got into Google Summer of Code and one project we are
interested in having students work on is improving the soft-CPU debugging
in our Python based FPGA SoC. While trying to put together a reasonable
specification for the idea I ended up with a bunch of questions and pointed
at OpenSoC Debug.

Firstly a bit of background;

LiteX (which is a "soft fork" of MiSoC) is a Python based system for
quickly building SoCs for FPGAs. Like all good SoC systems it has support
for a soft-CPU so you can use C firmware for any non-performance critical
stuff. One of the really cool things is that LiteX is mostly soft-CPU
architecture independent and currently supports ~4 different CPU
architectures. They are lm32, mor1k, picov32 and hopefully soon j-core

Another important thing about LiteX is that is already has a bunch of host
computer <-> wishbone bridge cores such as UART, Ethernet & PCI express.
These bridges are currently exposed on the host via a nice scriptable
Python interface which is independent of the bridge transport. The Python
code also handles providing info about things like register locations,
memory maps, etc.

If you want to find out more about LiteX and our usage, I actually gave a
talk about it at Linux.conf.au 2017 which includes more details, see the
recording at https://www.youtube.com/watch?v=MkVX_mh5dOU (which was
recorded using a LiteX based firmware!) or the slides at

One part that is currently missing from LiteX is good support for debugging
C code running on the soft-CPU and I would like that improved. I'm
currently tracking information about this idea in the following GitHub
issue [0].

 [0]: https://github.com/timvideos/getting-started/issues/39

A long while back (~12 months ago) I made my first attempt at getting
something like this working. I hacked the adv_dbg_if + JTAG wrappers into
LiteX when using the mor1k soft CPU. You can see how this was working in
the following diagram [1]. Using this I was able to use OpenOCD to talk to
the core and do basic things but this hack was very slow (our JTAG adapter
is quite slow). As I mentioned we have much higher speed Wishbone bridges
as part of LiteX (IE Gigabit Ethernet!). This lead me to the idea of
instead using a system that works like this diagram [2].


After talking with PaulFertser on #openocd and wallento on #openrisc, it
seems like it might be a good idea to try and model something after
OpenSoCDebug stuff and maybe try and be compatible. So I would like to
flesh out how this would work a bit more.

At the moment I think using OpenSoCDebug stuff might look something like
the following diagram [3].


The questions I have are;

 * What do the things in the blue boxes actually do in the diagram [3]?

 * OpenSoCDebug seems to be mainly targeting RISC-V architecture but has
some basis on the adv_debug_sys stuff originally for the OpenRISC1000
architecture. Would it be easy to adapt OpenSoCDebug to support the
multiple different soft-CPU architectures?

 * How much of existing OpenSoCDebug code can we reuse?

 * 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?

 * 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?

 * It would be nice to continue to support the "over JTAG" version in the
diagram [1] for cases where you want to only use the JTAG port for
debugging. How would you think that would work?

 * We would also like to support running under simulation using iVerilog
and verilator. I'm not sure the best way to expose

Thanks for your help!

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

More information about the OpenSoCDebug mailing list