Back

@azonenberg @whitequark I'm all ears for stories of perverted debug interfaces if you feel like sharing

@abrasive @whitequark So the high level concept is that the debug interface was bridging datagrams in the on-chip interconnect out to a TCP socket on the client PC.

Essentially each client (unit test, logic analyzer, etc) connected to the debug server would get a virtual device ID that it could use to send and receive packets to on-chip devices as if it were a very slow on-chip IP.

The bus words were all 32 bits wide so the natural implementation over JTAG would be a single 32-bit scan register that you'd hit over and over to send multiple words.

The problem is, this is slooow especially if you're using FTDI things that run over USB 2.0 with large bulk transfers etc.

@abrasive @whitequark I loaded USER1 into IR (this was a Spartan-6 FPGA) and then entered SHIFT-DR state.

And free-ran TCK.

The debug bridge would constantly shift in idle words if you had no data to send, and check the response data from the DUT for a preamble. As soon as it saw a 55 55 55 D5 it knew the DUT was sending traffic and would parse it appropriately.

So you effectively had two independent unidirectional streams of 32-bit words sent bit serial, each synchronous to TCK but with no tight coupling to each other. This let me use large bulk transfers over the MPSSE and completely eliminated polling, which was far more efficient.

@azonenberg @abrasive technically this is 1149.1 noncompliant but it definitely works

(oooor you could be like me and implement your own debug probe, not beholden to inefficiencies of FTDI :3)

@whitequark @abrasive It was possible to implement an 1149.1 compliant client for the protocol by switching from SHIFT-DR back to RTI and into SHIFT-DR for each 32-bit word. The FPGA side didn't care. It just allowed this optimized version if your probe could handle it.

And I was already building my own MIPS-1 CPU (this predated the widespread use of RISC-V by quite a bit, it was circa 2011), gdbserver, interconnect, etc. in order to test all of the weird stuff I needed for Antikernel.

I created scopeclient (the GTK based, fully software rendered, horribly slow ancestor of glscopeclient) to interface with the custom logic analyzer IP I wrote because ChipScope for ISE was a paid block I didn't have the money for, and while gtkwave was an OK waveform viewer it had no trigger integration.

So a custom debug probe on top of that was just excessive. (I was already making custom FTDI dongles but not full custom drivers/protocols)