[Open SoC Debug] GSoC project to improve soft-CPU debugging in LiteX + MiSoC
stefan at wallentowitz.de
Fri Mar 17 09:45:03 CET 2017
is the work of Nico (gdbserver<->CDM_ADS) finished and available somewhere?
On 06.03.2017 19:12, Philipp Wagner wrote:
> Hi Tim,
> On 03/04/2017 04:19 AM, Tim Ansell wrote:
>> Actually, an integral part of OpenSoCDebug is the transport layer
>> 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:
> (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.
> OpenSoCDebug mailing list
> OpenSoCDebug at lists.librecores.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 181 bytes
Desc: OpenPGP digital signature
More information about the OpenSoCDebug