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

Stefan Wallentowitz stefan at wallentowitz.de
Thu Mar 2 17:44:14 CET 2017

Hi Tim, Hi Paul,

On 01.03.2017 06:33, Tim Ansell wrote:
> Adding Paul Fertser to the CC list to keep him in the loop.
> On 1 March 2017 at 16:21, Tim Ansell <mithro at mithis.com
> <mailto:mithro at mithis.com>> wrote:
>     Hi!
>     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.

Congrats! We will also link to your ideas page again this year from

>     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 (sh2).
>         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
>         <http://Linux.conf.au> 2017 which includes more details, see the
>         recording at https://www.youtube.com/watch?v=MkVX_mh5dOU
>         <https://www.youtube.com/watch?v=MkVX_mh5dOU> (which was
>         recorded using a LiteX based firmware!) or the slides at
>         https://j.mp/pyhw-lca2017.
>     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
>     <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].
>      [1]:
>     https://docs.google.com/drawings/d/1kdtJHC2L5_Igf3RvxbLr_FVFMLJGzxB7_gkHhOyp03k/edit
>     <https://docs.google.com/drawings/d/1kdtJHC2L5_Igf3RvxbLr_FVFMLJGzxB7_gkHhOyp03k/edit>
>      [2]:
>     https://docs.google.com/drawings/d/1zsrwQyKDoafqOwN0p8du1d40rqRFVA64SD53WiYx4Q4/edit
>     <https://docs.google.com/drawings/d/1zsrwQyKDoafqOwN0p8du1d40rqRFVA64SD53WiYx4Q4/edit>
>     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].
>      [3]:
>     https://docs.google.com/drawings/d/15GJshJgaVPx8uu5QUm_IdZ8sztiG_cqzl-16z7XdBbA/edit
>     <https://docs.google.com/drawings/d/15GJshJgaVPx8uu5QUm_IdZ8sztiG_cqzl-16z7XdBbA/edit>

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

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 questions I have are;
>      * What do the things in the blue boxes actually do in the diagram [3]?

On the host: We have our own daemon and a gdb rsp server. OpenOCD only
plays a role if the transport is JTAG. The reason we so far do not
support OpenOCD as the actual debug tool is that we started with it for
the OpenRISC architecture, but I pretty fast realized that the transport
is deeply coded into OpenOCD. So replacing it with a generic transport
seems a larger task.

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

Yes, that is also the plan. We have the mor1kx setup ready in
prototyping state (a student project). We delayed run-control debug for
RISC-V mainly because the spec is not finished. Anyhow the setup will be
quite simple.

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

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

This is supported by glip already. We actually implement a high-speed
protocol on top of JTAG to provide a FIFO-style interface on the
software and hardware side at decent throughput. This is configurable
with the size of the JTAG shift register.

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

We support verilator already (emulate via a socket).

Sorry for the delay, I am a bit snowed currently..


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.librecores.org/pipermail/opensocdebug/attachments/20170302/e183d6d2/attachment.sig>

More information about the OpenSoCDebug mailing list