JTAG is JTAG is JTAG

[westfw]

JTAG is just a low-level communications protocol, right?  Pretty much not more than than a spec for a cascadable set of shift registers capable of running through all your JTAG-enabled devices through a single connection to your board.
What the bits communicated to various registers actually DO is beyond the specification.  So saying that JTAG sucks because you need a bunch of different devices is like saying that Ethernet sucks because a web page is ugly.

[Crazy Ape]

JTAG is just a low-level communications protocol, right?  Pretty much not more than than a spec for a cascadable set of shift registers capable of running through all your JTAG-enabled devices through a single connection to your board.
What the bits communicated to various registers actually DO is beyond the specification.

Aggreed 

So saying that JTAG sucks because you need a bunch of different devices is like saying that Ethernet sucks because a web page is ugly.

Hmmmmm, well, if you want to access my web page, you'll have to buy a $700 Ethernet card from me. Sound about right. 

[legacy]

Because the programming sequence for the 2E was slightly different from the 2. But thats ancient history now. AFAIK the Spartan2E is already obsolete.

but Spartan2E is 5V tolerant, so it is still good, while Spartan3E is not 5V tolerant 

[legacy]

anyone has used a low cost jtag cable with
- blackfin
- Atheros AR9830

in case, about blackfin's jtag, there is this incredible story 

[clifford]

There are still other options.
If you have a half reasonable micro-controller handy (and know how to wield it) take a look at Xilinx XAPP058.
http://www.xilinx.com/support/documentation/application_notes/xapp058.pdf

Unfortunately xilinx released that under the xilinx reference design licence, which only allows you to run the code on a xilinx fpga and not re-release the sourcecode.

But as even the title of the appnote says, this is meant to be run on a uC outside of the fpga. and if you want to use it from an existing framework or kernel you have to check if the "not re-releasing to source code" clause is compatible with that. I have not checked if they have fixed the issue, but at least it was like that a couple of years back. I sent them a mail back then and just got a standard reply that xilinx does not make any licencing exceptions for stuff released under the reference design licence.


So I went and wrote my own library for running SVF files from a uC: http://www.clifford.at/libxsvf/

It's used to program FPGAs in the LHC accelerator ring at CERN. So I guess this is a strong argument for releasing your code under a liberal licence..

[Crazy Ape]

Hi Clifford,

I've had a play with the gpio version of your code on an LPC1768, programing the FPGA on a gameduino (hey it was cheap) from a FAT32 SD card.

Nice code by the way.

[nctnico]

There are still other options.
If you have a half reasonable micro-controller handy (and know how to wield it) take a look at Xilinx XAPP058.
http://www.xilinx.com/support/documentation/application_notes/xapp058.pdf

Unfortunately xilinx released that under the xilinx reference design licence, which only allows you to run the code on a xilinx fpga and not re-release the sourcecode.

Last time I checked (about a decade ago) the software provided by Xilinx was immensly bloated and way too large. IIRC it compiled into 32KB on a Renesas H8.

So I went and wrote my own library for running SVF files from a uC: http://www.clifford.at/libxsvf/

It's used to program FPGAs in the LHC accelerator ring at CERN. So I guess this is a strong argument for releasing your code under a liberal licence..

I'm wondering how SVF files work when you have different configurations for several FPGAs in a chain (for example depending on a module installed on the board).

Anyway, IMHO the serial (SPI like) programming of an FPGA is much easier and you can use the SPI interface on a controller to make it extremely fast. In one project I used an SPI flash for several purposes. By connecting the SPI flash' SDO to the data in of the FPGA and gating the SPI clock to the clock input of the FPGA I could pump the configuration into two daisy chained FPGAs very fast even though the microcontroller was a simple MSP430.

[westfw]

the serial (SPI like) programming of an FPGA is much easier

Sure.  Till you have a board with a dozen FPGAs and a microprocessor on it, and want to do that boundry-scan testing that JTAG also allows.
They way I see it, device programming (and debugging) are kuldges added to the JTAG world that was originally designed to do quite different things. (by ... shudder ... HARDWARE people.  No wonder the SW geeks don't like it.)

[clifford]

I'm wondering how SVF files work when you have different configurations for several FPGAs in a chain (for example depending on a module installed on the board).

TL;DR: JTAG is not easy, but its not hard either. When using SVF/XSVF you need extra files for all possible physical configurations of your scan chain. The more devices you have on JTAG the more benefits you will get from it over an interface like SPI.

Let me first summarize some background information so we are on the same page:

The SVF file (or XSVF, which basically is a binary version of SVF made by xilinx) only specifies what the host should send. So everything you can do over JTAG, you can do over SVF, as long as it does not require any interaction. Its a simple "send this pattern, expect that pattern" format.

So when you are using JTAG, you have all your devices in a daisy chain using the TDI and TDO pins, the TMS pin and the TCK pin are driven by the host and go to all devices in parallel.

Now each device puts an internal shift register between the TDI and TDO pins and a state machine driven by TMS can be used to select if this shift register is the "DATA REGISTER" (DR) or the "INSTRUCTION REGISTER" (IR). Each device has one IR and many DRs, and the value in IR determines with DR is in place.

There are some special values for IR and some conventions about the reset state that allow you to scan the chain and figure out with devices are on there and how large their IR register is and so on. One IR configuration that all devices must support is the BYPASS register. In this mode the chip just put one single FF in the daisy chain when in DR mode.

So when generating the SVF/XSVF file you simply tell the tool how many devices are in the chain, which size the IR registers are and which device your target device is. The SVF file generated will then simply put all other devices in BYPASS mode and add the required number of padding bits to each DR write.

Regarding the overhead: Usually the IR is set once and then hundreds of DR writes follow, each hundreds of bits wide. The IR register becomes much larger if you have many devices in the chain, but the IR is written so seldom that this does not really matter. The DR chain only increases by one additional bit per device on the chain, and the actual DR data for the device you want to program is so large, that the few extra bits do not make a huge difference.

If you have a physical configuration that can change you basically have two options.

The first question is if the socket for you extra module is just empty when the module is not installed or if you have some special connector that just shorts TDI and TDO on the connector so the chain is still intact. If you do not have such a connector, and do not want to place extra components (such as transfer gates) on the motherboard to re-route the TDI and TDO pins, then you must have two chains, one for the motherboard and one for the extra module.

With two chains you can share TDI and TCK between the chains, as long you do not want to run them simultaneously. You obviously need separate TDO pins because the JTAG output pin is not a tristate pin, so you would short out two drivers if you'd connected them together. You also need separate TMS pins. This way you can hold one chain in the JTAG reset state (just resets the jtag interface, not the device) while you talk to the other chain. Thus the chain in reset will ignore the TDI data.

If you have a special connector that shorts the TDI and TDO pins when no module is installed, then you'd normally have two programming files: one for the case where the module is installed and another one for the case where you only have this terminator connected to the port. I theory it would be possible to add the extra fill bits to all DR and IR writes on demand, but I have never seen anybody actually doing that.

If you just want to program a single FPGA, then the SPI interface certainly is much easier. The JTAG interface has a lot of other advantages:

1) You can use it to program and probe a large range of devices, not only FPGAs, and the uC doing that does not need to know anything about them. It just need to know how to play those SVF/XSVF files.

2) You can easily attach a probe to the JTAG port and use the same interface to program the devices directly from a PC, debug processors, perform boundary scans, and many other wonderful things.

3) You do not need any extra per-device pins. This is great because you might want to add an additional IC to your design late in the development process. With JTAG you can simply hang it into the scan chain and all you need are signals that can be re-routed from any nearby chip that already is in the scan chain. With SPI you would have to route an extra slave-select signal all the way from the new chip to the pint where you SPI signal originates (e.g. a uC), and then hope that you still have a free GPIO pin there.

[rsjsouza]

As westfw said, I always look at the JTAG standard as a small step above the TIA-232 (typical serial port) standard: it specifies electrical and signaling characteristics, has a minimal protocol but does not go beyond that - thus it is open to customization from each manufacturer.

Keep in mind this was devised in a time where everything was proprietary and the manufacturers were trying to solve a much greater problem of testability.

For microprocessors I also see JTAG as a debugger and not as a programmer, which contrasts with some of the serial port based ISPs.

This is how companies like Segger can get away with charging such high proces for their JTAG hardware

Hmmmmm, well, if you want to access my web page, you'll have to buy a $700 Ethernet card from me. Sound about right. 

This is what I don't get: if you are trying to access something that charges you a boatload of money, either there is a great reason for that or you can move away to a different webpage. There is a lot more work and money involved in creating and supporting your own JTAG debugger than using one off-the-shelf. This thread discusses Segger's prices (student version for $60 US dollars and a full commercial one for $240). Also, MrAureliusR mentioned Hercules from TI: there is the XDS100 debugger (FTDI-based with complete design files available for free) that costs $79 or $89 dollars, and is able to debug from M3s to A15s, is able to access its built-in ETB to do minimal trace and also includes support for their DSPs.

[MrAureliusR]

I'm also looking at the Dangerous Prototypes Bus Blaster, which is specifically made for JTAG. The new(ish) v3 seems to be very popular, and the (brand) new v4 (which is still kinda of beta-y) seems be high-speed. It uses a CPLD to reconfigure itself to appear as many different programmers, so it's compatible with a few different softwares. From what I've heard it's pretty configurable, basically what the defunct uniJTAG project was aiming for.

The v3 (which is more stable) goes for $34.95 on Seeed Studio, the v4 $45. I'm pretty sure they're not directly compatible with Quartus and Vivado/Xilinx ISE but I've also read it's not hard to program those parts. You just do all your work inside the ISE and then when it's time to send the code out you use a different piece of software to program. Almost like the MPLAB IDE/IPE combo. Not too much of a hassle (if it works smoothly, and its popularity seems to say it does).

Anyone have experience with the Bus Blaster?

[nctnico]

I'm wondering how SVF files work when you have different configurations for several FPGAs in a chain (for example depending on a module installed on the board).

TL;DR: JTAG is not easy, but its not hard either. When using SVF/XSVF you need extra files for all possible physical configurations of your scan chain. The more devices you have on JTAG the more benefits you will get from it over an interface like SPI.
2) You can easily attach a probe to the JTAG port and use the same interface to program the devices directly from a PC, debug processors, perform boundary scans, and many other wonderful things.

3) You do not need any extra per-device pins. This is great because you might want to add an additional IC to your design late in the development process. With JTAG you can simply hang it into the scan chain and all you need are signals that can be re-routed from any nearby chip that already is in the scan chain. With SPI you would have to route an extra slave-select signal all the way from the new chip to the pint where you SPI signal originates (e.g. a uC), and then hope that you still have a free GPIO pin there.

That point is a bit moot. Only complex chips support JTAG and adding such a chip late in a design is not very likely. Secondly, you can cascade SPI devices so you wouldn't need to route an extra select line from the MCU. Using a hardware SPI uC peripheral is way faster than bitbanging JTAG. Besides that even for an FPGA using SPI for programming has the advantage you can use the same lines to communicate with the FPGA over SPI. You need one extra line from the MCU instead of 4 (or 5 if you include a reset) for JTAG which you'd only use during programming and production testing.

Most SoCs can boot directly over USB, from SPI flash or from an SD card nowadays. If JTAG was so easy to use they would not have added those features...

[clifford]

Most SoCs can boot directly over USB, from SPI flash or from an SD card nowadays. If JTAG was so easy to use they would not have added those features...

If SPI and those other features you mentioned would be so great, they would not have JTAG on the chips.

See: It is really easy to use this kind of argument for almost anything.

You might also have noticed that I have never said that JTAG would be easier than SPI or any of the other options you mentioned. I've just said that it is easy, and gets more beneficial as you add more devices in the scan chain.

Regarding your argument that one would find JTAG only on large chips and thus it is very unlikely that you would add one of those late in the design: I'd say that this only depends on the kind of the design you are working on. Unless you use DIP or SOT packages, even a small-ish uC usually has JTAG and you might add something like a CPLD late to a design if the design is not cost sensitive. (CPLDs are often used to add additional debug functionality and flexibility to a one-off design such as a test or devel board, for example.)

[nctnico]

Most SoCs can boot directly over USB, from SPI flash or from an SD card nowadays. If JTAG was so easy to use they would not have added those features...

If SPI and those other features you mentioned would be so great, they would not have JTAG on the chips.

See: It is really easy to use this kind of argument for almost anything.

You are carefully avoiding the point I'm making  But maybe I should have put it differently: if JTAG would be sufficient (for starters: easy and convenient to use) they would not have added the other boot methods later on.

A couple of years ago I built an FPGA based JTAG gang programmer for a MIPS based SoC which only had a JTAG interface. With the gang programmer it took 20 seconds instead of 3 minutes with a parallel port JTAG adapter to progam the 150kB bootloader. That programmer cost the firm about €8000 in parts and labour. If the SoC would have been capable of booting over USB or even the serial port things would have been so much easier.

[clifford]

A couple of years ago I built an FPGA based JTAG gang programmer for a MIPS based SoC which only had a JTAG interface. With the gang programmer it took 20 seconds instead of 3 minutes with a parallel port JTAG adapter to progam the 150kB bootloader. That programmer cost the firm about €8000 in parts and labour. If the SoC would have been capable of booting over USB or even the serial port things would have been so much easier.

With an FT232H it should take well under a second to program a 150kB payload. (depending on how fast you want to clock the JTAG interface, I usually don't go faster than a couple of MHz). FTDI even sells cables with that chip with USB on one end and loose pins on the other. It can't get any easier than that. The same chip is used in the digilent probes and many others. So you can simply put a digilent-compatible probe directly on your board and have full support in many tools (such as Xilinx Impact and Xilinx ChipScope, for example).

I can't tell you what went horribly wrong in that project you mentioned, but I can assure you it did not went wrong because JTAG is an inherently complicated and hard to implement interface.

The main reason why there is SPI on FPGAs is because in many applications one wants to load the bitstream from SPI serial flash, btw.

And yes, if you only want to upload a bitstream file from a uC that already has an SPI controller, there is nothing wrong with that. But that does not make JTAG the overly complicated interface that you are trying to make it look like.

[nctnico]

A couple of years ago I built an FPGA based JTAG gang programmer for a MIPS based SoC which only had a JTAG interface. With the gang programmer it took 20 seconds instead of 3 minutes with a parallel port JTAG adapter to progam the 150kB bootloader. That programmer cost the firm about €8000 in parts and labour. If the SoC would have been capable of booting over USB or even the serial port things would have been so much easier.

With an FT232H it should take well under a second to program a 150kB payload. (depending on how fast you want to clock the JTAG interface, I usually don't go faster than a couple of MHz). FTDI even sells cables with that chip with USB on one end and loose

Not on a MIPS platform where you have to execute several instructions while emulating memory and stack thru JTAG to transfer one word. I have improved a lot on OpenOCD's MIPS support (IIRC I got it 2 or 3 times faster by optimising the instructions and data transfer) and add some extra hacks to use the buffered JTAG interface in the FPGA most efficiently.

[Crazy Ape]

Not on a MIPS platform where you have to execute several instructions while emulating memory and stack thru JTAG to transfer one word. I have improved a lot on OpenOCD's MIPS support (IIRC I got it 2 or 3 times faster by optimising the instructions and data transfer) and add some extra hacks to use the buffered JTAG interface in the FPGA most efficiently.

Right, so what you're saying is you had trouble using MIPS' EJTAG extensions in "PrAcc" mode. It's not the JTAG part of EJTAG that was causing you trouble, more the 'E' part.
That being said, I do recall tackling ETJAG on a router with BroadCom SOC. No EJTAG "DMA" mode, only "PrAcc", and yes, much fun - NOT.

The extensions that were causing you problems were not part of the JTAG standard. Do you have similar nightmare stories using actual JTAG?

[nctnico]

Oh, shifting bits through the JTAG interface is peanuts. But that gets very little done. Its the convoluted protocols which manufacturers put on top of JTAG which make it so unappealing to me. In my world I never came across a situation where I was happy to use JTAG. For starters it always means getting extra hardware before I can get started. And then there are all kinds of signal integrity issues even when connecting a dongle with short wires or flat cable. Turning on the light or plugging in an adapter can cause a large enough pulse to disturb the clock. If the download takes several minutes then something like that gets really anoying. There also was a Xilinx JTAG dongle/software which output the rising edge of the TCK together with TMS and TDO (violating / barely meeting setup timing). Try to get that to work while talking to a whole chain of devices on a board.

[abyrvalg]

ROMless SoCs were real PITA, I prefer to send just some small loader to internal RAM over JTAG, then bring up UART/USB from it and start breathing freely - no data integrity issues, no watchdogs biting while core is halted and much higher speeds usually. Happily things are changing towards ROM boots last years and JTAG is returning to it's second letter denotes - Test.