http://debugmo.de/2012/02/xvcd-the-xilinx-virtual-cable-daemon/
I recently discovered an almost undocumented function in Xilinx ISE: the Xilinx virtual cable driver. It’s basically “a platform cable without a platform cable” (as marcan said so nicely) – it allows you use Impact (and Chipscope, and all other tools) over TCP/IP.
Avnet Spartan-6 LX9 MicroBoard (an, excuse me, terrible board – but that aside) don’t have the clumsy and expensive FX2+CPLD combination anymore. Instead, they come with a cheaper solution and a corresponding plugin for the Xilinx tools. However, the plugin SDK is not available publicly, so it’s not easily possible to write a plugin for arbitrary JTAG dongles (like a generic FTDI 2232 board) without either licensing the SDK or reversing the API.
For OpenVizsla I wanted to get programming working from Impact. Programming the CPLD and FPGA is supported via an on-board FTDI chip, and usually done with urjtag. However, you can’t use – for example – Chipscope.
There are solutions like this neat hack, which basically LD_PRELOADs into ISE, pretends to be libusb, provides a virtualized platform cable, and then talks to some different back end.
But it turns out – there’s a much easier, albeit undocumented, solution. It’s called xilinx_xvc, or “Xilinx Virtual Cable”. It’s a plugin – the only one next to the Digilent plugin – that can be used as a cable. It opens a TCP connection to a specific host, and sends JTAG “shift” instructions over TCP. The protocol is really, really simple: There’s only one command that I ever saw being used, calledshift:. After that, a 32-bit little endian word specifies the number of bits, and after that, two byte-padded strings are the bits to be shifted out on TMS and TDI (in that order). The response is a byte-padded string of the bits shifted out on TDO. That’s all – a nice, abstracted JTAG PHY.
I implemented a client for this for the awesome NeTV here (requires some hardware hacking though to get the JTAG pins connected), and a generic FTDI version (based on libftdi) here (feel free to merge and send me a pull request!).
The xvcd is a daemon that listens on port 2542, and allows multiple programs to access the JTAG chain at the same point (it switches between them only when it’s “safe”; it relies on the programs to idle the chain every once in a while by going through TLR and then staying in RTI). It also works around a weirdness where Impact, whenever an IR or DR is written, goes back to the Capture-IR/DR state before exiting back to RTI (which almost always screws up the register). xvcd follow the JTAG state machine and just ignores this these instructions.