[Libre-soc-bugs] [Bug 499] Create experimental gdb protocol implementation in nmigen for debugging

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=499

--- Comment #5 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #4)
> (In reply to Luke Kenneth Casson Leighton from comment #3)
> > the other thing that occurred to me jacob is that Staf would like to
> > do scans of IO ports as part of the ASIC test.
> 
> This is possible with gdb's debugger protocol, you just send a custom
> interpreter command using gdb's `monitor` command (made up syntax):
> (gdb) monitor set port 1AE 0
> 
> this is how you can access openocd's command prompt from gdb.

my point is not so much "is it possible" it was "Staf's already provided it,
and his work has full unit tests, and it us FPGA proven and silicon proven as
well i think"

to do a uart version of the exact same thing, why would we do that, but even if
we did it is getting more and more complex.

throwing away Staf's JTAG io work, and the fact that he has SVF scan files
already done, which can be run against the simulator, verilator, FPGA *and the
ASIC* this is a huge saving all of which we throw away and have to do ourselves
to replicate it in gdb serial?

honestly why would we do that? it makes no sense.

basically we need to focus and this proposal is increasing more and more in
scope and cost as we go through its full implications.



> Alternatively, you could write to the GPIO ports' memory using a memory
> write command.

which is far more complex and defeats the object of testing the IO pads
directly.  remember: Staf needs to be able to test the IO pads in as direct and
simple a fashion as possible.

a memory bus is much more HDL that could go wrong.

as the memory bus is litex which uses migen which has zero checking on it, it
is already quite risky.


> One of the nice features of GDB's protocol is it supports debugging
> multi-threaded programs (we would interpret gdb's threads as processor
> cores). I don't know if the jtag protocol supports that.

both serial and JTAG are single resource and immediate response.  any multi
threading is done at the software level (as part of gdb)

neither the gdb serial nor jtag RTL will have any kind of "thread state",
except if the actual core is hyperthreaded but even there the requests will
contain the core number over the serial/JTAG link.

-- 
You are receiving this mail because:
You are on the CC list for the bug.