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

Philipp Wagner philipp.wagner at tum.de
Mon Mar 6 19:12:43 CET 2017


Hi Tim,

On 03/04/2017 04:19 AM, Tim Ansell wrote:
>     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?

Yes, the transport layer is not part of the OSD Specification. For our 
reference implementation, we use GLIP (http://www.glip.io/). GLIP is 
conceptually similar to your Wb2Host approach, it's just even a bit more 
low-level: the data transfer is abstracted as FIFO reads and writes, and 
a bus protocol such as wishbone could be implemented on top of it.

Now, I see a couple of options using OSD in your setup. I've tried 
drawing the most significant ones here: 
https://docs.google.com/drawings/d/1AmjG0FFkTv_wLnw1iKEqU-Do72TsChtH6hlmAS98At8/edit?usp=sharing 
(apologize my quick drawing)

- Option 1 is the easiest: Use OSD with GLIP as-is, meaning you have now 
two off-chip interfaces in your system: wb2host and GLIP, using 
different physical transports (e.g. ethernet for wb2host and UART for GLIP)

- Option 1a is compromise: integrate WB2HOST into GLIP as a "backend" in 
glip speech: this would make wb2host stand next to UART, JTAG, and USB a 
way to communicate from the FPGA with the host).  The benefit is that 
you need no changes to the opensocdebug software implementation, just 
the GLIP library to which the OSD software is linked must be changed.

- Option 2 is integrating in the tightest way, but probably requires 
most modifications. You take the data from the OSD system, which would 
normally go to GLIP, and feed them back into your main wishbone bus. 
This way you don't need to change wb2host, but need to change the 
libopensocdebug library of the reference implementation.

In any option, nothing beyond the connection infrastructure needs to be 
changed. You can use the gdbserver implementation of osd, and you can 
use the OSD-provided module to interface the OSD with a or1k (mor1kx). 
Note that we don't have a lm32 interface at this moment, and the RISC-V 
one is stalled until the spec of how to actually do run-control 
debugging in RISC-V is more stable.

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

Note that OSD also has components to do memory loading. It's useful to 
integrate them into the debug system, as they can then be used from GDB.

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

I don't really understand what you mean here. TCP would be on the host, 
while the WB interface is on the FPGA.



Since I see a lot of confusion going on here, which is hard to express 
in written form, I'm proposing a audio/video call to reach a common 
understanding more quickly. I'm on central European (CET) time, and 
available during most sane hours this week :-) (usually in the morning 
hours in Australia) Let me know if you're interested and we can schedule 
a call.

Philipp


More information about the OpenSoCDebug mailing list