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

Philipp Wagner philipp.wagner at tum.de
Tue Mar 20 21:57:34 CET 2018


Hi Shivam,

Am 19.03.2018 um 16:09 schrieb SHIVAM AGGARWAL:
> Currently, I am working with Timvideos.us and researching about this
> issue #issue 39 <https://github.com/timvideos/getting-started/issues/39>
> to create a generic debug system for soft CPU cores(or1k, lm32, risc-v)
> and a GDB server as a part of GSOC project. 

Sounds good!
> I looked at some emails from
> the last year's archives at OpenSOC. Tim introduced the project on the
> mailing list
> <https://lists.librecores.org/pipermail/opensocdebug/2017-March/000024.html>
> and some constructive discussion was carried out. A rough outline of how
> the project could be implemented was also discussed:
> https://docs.google.com/drawings/d/1AmjG0FFkTv_wLnw1iKEqU-Do72TsChtH6hlmAS98At8/edit
> <https://docs.google.com/drawings/d/1AmjG0FFkTv_wLnw1iKEqU-Do72TsChtH6hlmAS98At8/edit>

That's a good drawing. It's not fully correct any more w.r.t. the
changes we've recently made in OSD, but the general idea holds. (If the
time comes we can discuss in more detail how a fully accurate picture
would look like.)

> My current progress:
> 
> 1. I have thoroughly read about JTAG, OpenOCD, adv_dbg_sys implemented
> by opencores.
> 
> 2. I also read the documentation of OpenSOC and in the process of
> setting up the development environment for the same.
> 
> 3. Initially, I propose to tackle the project using the architecture
> implementation of adv_dbg_sys but OpenSOC seems to be a better alternative.
> 
> 
> I am quite interested in the project and would like to implement the
> project as a part of this year's GSOC. I believe a lot of things are
> already implemented as a part of OpenSOC project and can be used in this
> project. It would be great if someone could provide a rough outline of
> the project and guide me for the same.
> 
> 
> Looking forward to your valuable suggestions for the project.

The picture you've shared already shows some of the main areas which
need work to integrate OSD with LiteX/MiSoC. Please bear in mind that
I'm not overly familiar with LiteX/MiSoC, please make sure to
double-check with someone more knowledgable for these things before
taking things for granted :-)

- The main work will most likely be the work on adding run-control
debugging to OSD. This means on the hardware side the CDM module, and on
the software side the GDB server bridge. For some of these modules, we
have (outdated) drafts laying around, but essentially it's a start from
scratch -- which shouldn't be too frightening, as all accesses done by
GDB are register reads/writes. Depending on the CPU you're targeting the
hardware and software implementations will look different, and also the
existing code you can re-use. My experience is mainly with the mor1kx
cores, I haven't looked to closely at the lm32 cores. RISC-V has a
rather recently standardized run-control debug interface, which is,
however significantly different from what mor1kx has.

- The second area of work is the off-chip transport. In OSD we typically
use GLIP, a FIFO-based off-chip transport. That's the easiest way
forward, sine it's known to work. If you want to re-use existing
off-chip communication infrastructure of LiteX/MiSoC you'd need to put a
bit of work into that as well. On the hardware side, you'd need to
provide anything which acts like a FIFO. On the host (software) side you
can either extend write a new gateway implementation which feeds the
received data into the system. Or you can extend GLIP, as the picture
shows. (Note that we've changed the structure of the host software a bit
recently and GLIP is not encapsulated inside the opensocdebug daemon any
more, but living side by side. This makes it easier to write new
host-device gateways.)


To summarize, the easiest path forward would be:

- Target mor1kx CPU cores.
- Use the existing GLIP off-chip interface unchanged.
- Focus on the run-control hardware and software parts.

Depending on the time budget you can either have a look at re-using
existing off-chip communication infrastructure, or at supporting more
CPU types.


For GSoC, I'm willing to co-mentor this project with someone from
timvideos/LiteX/MiSoC. If all of that sounds reasonable to you, please
start by drafting a proposal. It probably will help to have a video call
when you're done with a first draft to see where misunderstandings
happened and what can be improved.

Please let me know how you want to proceed.

Best,

Philipp


More information about the OpenSoCDebug mailing list