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

Tim Ansell mithro at mithis.com
Fri Mar 17 00:26:15 CET 2017


Hi!

Sorry about the slow response.

What is the current status of OpenSoCDebug? How much is currently
implemented? Can you use it to debug a mor1k running on a FPGA board?


On 7 March 2017 at 05:12, Philipp Wagner <philipp.wagner at tum.de> wrote:

> 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/drawin
> gs/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.
>
>
Based on your diagram - I remade mine as follows ->
https://docs.google.com/drawings/d/1l_UlgCmy-WSJq3wA0gkDroZD19vauavK-Srg9hLeXK4/edit?usp=sharing

>From looking at your diagram I think I see a couple of things now;

 * There is a "OSD Bus" which connects together the various OSD modules.
 * There is an "OSD HIM" module which connects the OSD Bus to another
system.
 * GLIP is an FIFO abstraction independent of OSD.

The HIM currently just translates from the GLIP FIFO interface into the OSD
Bus format. The GLIP FIFO interface is defined as two FIFOs (one in and one
out) of the form (data, valid, ready).

The current stuff seems to be concentrating on the Host being a different
entity to the device under debug, there seems not much consideration for
"self debugging"? At the moment, GLIP doesn't seem to have any backends
designed for when the FIFO is actually local on the system (rather than a
remote via some extra transport system)? There is mention of a PCIe backend
but I can't see any documentation on that?



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

Are you on IRC at all? I go via 'mithro' on there.

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


More information about the OpenSoCDebug mailing list