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

Tim Ansell mithro at mithis.com
Wed Mar 1 06:33:37 CET 2017


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> 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.
>
> 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 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
> 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
>
> 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
>  [2]: https://docs.google.com/drawings/d/1zsrwQyKDoafqOwN0p8du1d40rqRFV
> A64SD53WiYx4Q4/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
>
> 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/94a03852/attachment.html>


More information about the OpenSoCDebug mailing list