[Libre-soc-dev] [Libre-soc-bugs] [Bug 503] New: Create new repo for gdb-adaptor program

[Luke Kenneth Casson Leighton]

On 9/25/20, Staf Verhaegen <staf at fibraservi.eu> wrote:

> I am not sure how jtagremote comes in the picture here. The cocotb code
> reads the SVF and then drives the TCK, TMS and TDI input pins of the
> JTAG TAP. It also checks if TDO gives the right output. I don't know
> where a client-server connection would be needed. The code should be
> able to just be translated in pysim/cxxsim code.

"translated" i am interpreting to be a client-server architecture
involving the openocd protocol which can be implemented in about 25
lines of python.

context:

a couple of days ago i managed to connect openocd to the litex sim.py
simply by enabling the litex jtagremote module and writing an
openocd.cfg that connected to that port.

by taking the c4m svf cocotb code and removing the cocotb part and
putting a module in place that connects to the openocd server instead
of directly driving cocotb signals we can use the svf parser to
connect to the litex sim.py and test it directly.

the svf code thus becomes *completely* independent of nmigen, cocotb,
everything.

by also writing a small cocotb server that *also* conforms to the
openocd jtagremote protocol it is possible to use the exact same svf
parser-reader to connect to the current code in c4m.

then we can *also* write nmigen unit tests again using the jtagremote
server protocol and use the exact same svf parser reader to connect to
that nmigen unit test over a TCP socket.

it would actually be a really valuable standalone project that allowed
low-level debugging that complemented openocd, being useful in
conjunction with openocd in far more projects than just ours.

as long as c4m jtag remains tied to cocotb its usefulness remains limited.

l.