The Xilinx chips are programmed via a JTAG interface. JTAG is a standardization of a serial interface used for programming and accessing all sorts of logic devices and CPUs. The intent seemed to be to add some standardized intelligence around a variable-length shift register, similar to SPI, in order to add some common sense to testing of gigantic digital devices. A “JTAG” consists of the standardized state machine called the TAP controller (Test Access Port) and a quasi-standardized set of shift registers. We say quasi-standardized because the standard says there are two shift registers: Instruction and Data. After that, you’re on your own and the manufacturer has free reign to implement whatever sort of bizarre command/data structure they’d like. And they do. So other than controlling the TAP, the interactions are often quite different between manufacturers and you should not expect JTAGging one device to use the same instructions and/or data structures as another. YMMV.
JTAG uses a 4-pin (5 if you count a reset pin) interface that boils down to serial shift registers and a TMS line for controlling the TAP. The pins are:
- TCK – Test Clock. The clock signal for both SPI-style data shifting, as well as latching TMS commands into the TAP. You feed it rising edges to send data in, and the part sends data out on falling edges, of which you look at on the next rising edge. So you can consider the rising edge of TCK to be the important edge. Stuff data, raise TCK to latch it.
- TMS – Test Mode Select. Used to control the TAP state machine, directing it through various modes of operation. Always evaulated on every rising edge of TCK, although there are certain states in which you can sit and clock data forever by simply leaving TMS either high or low.
- TDI – Test Data Input. Data input from the perspective of the device under test, you’d call it the MOSI line if it were SPI. The programmer sends data to the chip by putting it on TDI and raising TCK.
- TDO – Test Data Output. Again, this is data out of the chip being programmed or tested. It is updated on the falling edge of TCK, so to read out some data you usually clock in junk (00′s or FF’s) on TDI and watch the data coming out of TDO.
OK, looks like a pretty standard serial interface. Can we just read in a .jed bitstream and start churning data into the device? Hardly. Each manufacturer’s device uses quite different command structures, as well as very different data lengths for each of those commands. We could implement a software programmer for one single device by reading and implementing it’s programming spec, but the beauty of JTAG is that one generic programmer should be (theoretically) able to program a wide range of devices WITHOUT knowing much about the device specifics. Enter the SVF (Serial Vector Format) file. This is a programmer-independent text file containing all the customized commands required to program a certain device on a generic programmer.
SVF is kind of fantastic- Xilinx did the world a big favor by developing the SVF file format, which takes all the work away from the JTAG programmer by pretending that the Impact software is itself a generic programmer, and dumping out a step-by-step list of all the operations needed to program a Xilinx device. Go download the SVF file format white paper from Xilinx if you’d like to learn the details. Great Stuff!
To generate SVF files from .jed bitstreams, you’ll need the “Impact” software, and the bdsl files for your device. Impact is a free tool installed with the Xilinx ISE development platform – dunno if you can get it standalone, but if you plan to do any development you’ll need the ISE. The bdsl files for this devices are included in a zip file called xc2c.zip. The web page wants you to register (annoying!), but if you just search the filename then Google will find you a backdoor: Direct link to the Xilinx FTP for BDSL Files. Open impact, select device, load jed and export SVF. Yawn.
Are we ready to flash? Not quite yet. We need to study how to work this stinkin’ TAP a little.