JTAG introduction

JTAG is a serial protocol, similar to SPI in some respects, that is used for boundary scan testing, in circuit emulation, and flash programming. It is standardized in IEEE 1149.1-1990. In boundary scan mode, all the I/O pins on all JTAG devices on a board may be connected together in one giant shift register with one or more bits per pin. There are control registers and ways to bypass the shift register for individual devices (replacing them with a one bit register).

The picture above shows a slightly ficticious chip with a simple 8 bit D-flip flop register with clock and output enable controls with a JTAG TAP (Test Access Port) controller and 18 boundary cells, one on each I/O pin, added. The boundary cells are connected together in a big daisy chain loop. I show only the data path in that loop, there are a number of control signals as well. Individual chips are then connected together in a longer loop. I say the chip is ficticious but there are similar parts: TI SN74BCT8374A is almost identical. The amount of test logic on such a simple device far exceeds the amount of operational logic.

JTAG is not an open standard in the sense that internet RFCs and USB are and the way all standards should be, where you can download the standard documents for free. Instead, they fund the standards process by selling copies of the standards documents. It would cost you around $400 to purchase a copy of the standards plus possibly a couple hundred more for books to explain them. This is prohibitively expensive for hobbyists, open source developers, some small businesses, and lots of other people who can't justify forking over that kind of money to buy a standard that they don't know if it will help them until they have read it. Add $100-$400 or so for a USB JTAG pod or cable . And fancy commercial software can cost close to $3000 a copy. There is some free software, with limited functionality, no-frills parallel cables can be had for around $20, and there is almost enough information on the net to do some serious stuff with JTAG, though you can spend weeks finding it. This page will help you in your quest.

A long time ago, I worked for a company specializing in built-in test. I wrote the software that analyzed the reliability of synthetic aperature radar systems, software that determined in what order to perform tests, built in diagnostics software for sonar systems, and the hardware device that actually injected simulated faults into the system. (I did other things, as well: I wrote the billing software, the timecard system, the purchase order system, adminstered the network and the PBX, and reverse engineered the proprietary network stack (including the firmware on the NIC card)) so I could write network utilities. We were among those who pushed for inclusion of boundary scan in ICs and the creation of the JTAG standard in the first place and one of my coworkers was on the standards committee. Unfortunately, I didn't get to work with JTAG at the time because the standard didn't exist and there weren't actually any parts that implemented boundary scan. 25 years later, JTAG is availible on far fewer chips than it should be. It is found on most FPGAs, CPLDs, better microcontrollers and processors, and some peripherals. It still isn't available on gates and most other discrete logic parts; there are a few overpriced registers and bus transceivers with JTAG, similar to the one pictured above. But it is several times cheaper to replace those parts with a CPLD and instead of needing glue logic to drive the logic chip, you can reprogram the CPLD to be compatible with your signals and maybe suck in some extra glue logic as well. Now that some of the programable logic vendors provide free (as in beer) software, small logic parts are mostly obsolete. And to take best advantage of JTAG for testability, you will want to use programable logic and microcontrollers instead of discrete logic. And JTAG is widely used, beyond its original intended purpose, for programming those microcontrollers and programmable logic devices.

What JTAG can do?

Here are things JTAG can do or potentially do:

• Boundary scan test of connections between JTAG compliant ICs and boards.
• Test of logic connected between JTAG devices
• In system programming of flash based FPGAs, CPLDs, and other progammable logic. Parts can also be programmed while installed in a zif socket with a JTAG connector.
• Temporary configuration of ram based FPGAs and other programmable logic
• Loading FPGA or CPLD bitstreams into JTAG enabled serial configuration flash devices (such as Xilinx Platform Flash) used to configure FPGAs on reset.
• Loading code into JTAG enabled parallel flash chips (if you can find one)
• Loading code into FLASH memory devices that are not JTAG enabled by manipulating address, data, and control lines on other JTAG enabled chips (such as a micro or CPLD). This can be very inefficient and slow (possible workarounds listed below).
• In system (or Zif) programming of Microcontrollers.
• Test that internal logic of a chip conforms to specifications, provided you have a model or test vectors.
• Detailed internal chip testing with internal cells inserted to allow breaking the design into smaller, testable pieces.
• On chip debugging (hardware assisted debugger built into micro). Breakpoints, single stepping, memory examine/change, etc.
• Test of external connectors on a board, provided you have JTAG devices to connect it to such as a JTAG based test fixture, other JTAG enabled boards that normally connect to the board, loopback connections, or have connected bidirectional I/Os between two similar boards together.
• De-brick routers, motherboards, etc. after a botched firmware download.
• Communicate with logic or software inside a micro, FPGA, CPLD, or other programable logic provided that the chip provides JTAG accessable data registers.
• Check jumper settings to digital logic to check if board is jumpered to factory configuration before shipping.
• Eliminate jumpers in many applications.
• Production programming and test of assembled boards. You can test the solder connections, download Microcontroller, FPGA, and CPLD firmware, and perform basic (low frequency) testing of board logic. All in a single operation with hookup to one or two jtag connectors. You may also be able to set the real time clock by twiddling SPI or I2C pins.
• Measure supply voltages, if you have a JTAG ADC on board.
• Trim boards, if you can find a JTAG DAC or have a DAC or digital potentiometer driven from programmable logic.
• Design one board to be used for multiple functions reducing design, NRE, and inventory costs and achieving better economy of scale. Board can be personalized just in time for shipment.
• Update or reconfigure systems in the field. You can send a technician with a PDA or LAPTOP, send JTAG pod and software to customer, ship a small inexpensive device with flash memory and a microcontroller that acts as a JTAG player, or design the system to perform self upgrades.
• Build in USB JTAG for easy field upgrades.
• Do built in self test by providing a mechanism for an onboard micro to access the JTAG chain.
• Perform analog tests (limited number of devices support 1149.4, though).
• Re-purpose off the shelf devices to serve new applications the designer may not have even imagined.
• Perform basic RAM tests.
• Software developers may be able to use JTAG to produce a partial netlist sufficient to describe the connectivity information needed for software development.
• JTAG could be used to program nonvolatile "fuses" on IIC bus devices to set the node address, thereby overcoming the achiles heal of IIC.

Limitations

Attempts to use JTAG in the ways described above can be hampered by:

• Standards which aren't free
• Commercial software that is too expensive for many applications and which may be difficult to modify or extend.
• "free" software that is either too limited in function or has a copyleft license that prevents you from owning your own enhancements which may contain sensitive information or substantial value added.
• Limited part availability. Obtuse semiconductor manufacturers often omit JTAG when the marginal cost would be negligable or even negative (due to enhanced testability) or when JTAG might substantially increase part sales and/or allow one part to replace many.
• JTAG pods which lack adequate documentation.
• Software that will only work with PODs supplied by the software vendor.
• For the most part, JTAG can not be used to perform high speed functional testing although it may assist in configuration for such testing by setting mode pins to appropriate states or downloading test code to programmable devices capable of high speed signal generation and checking.
• Many pods are cable of far less than the 20Mbps allowed by the standard which limits certain applications like programming large flash devices via bit twiddling of attached chips.
• Different connectors used on different products.
• Programable logic vendors who don't provide easy ways to reconfigure parts without resynthesis which is needed to trim parts or make minor (software jumper) configuration changes.
• JTAG boundary scan was designed in the days of TTL logic which had asymetric drive. If two pins were shorted together and you drove a 0 on one and a 1 on the other, you would usually get a consistent 0 as a result. With many modern logic families the result is far less predictable. This could be improved with programmable pull-up and pull-down combined with output and I/O cells that can be operated in open drain or tristate mode and/or receivers that have multiple thresholds. A part may even have these features in normal operation but they may not be available via JTAG.
• Components such as pull-up resistors may not be adequately tested.

BSDL

A supplement to 1149.1-1990 defined the boundary scan description language (BSDL). BSDL is a subset of VHDL. IEEE 1532 extended BSDL to have information on flash/FPGA/CPLD programming. Another important improvement in 1532 is list which maps pin numbers to pin names. Note that for many programable logic devices, the BSDL files distributed by the vendor describe the device before configuration but the configuration may change circuitry between the boundary scan registers and the pins. Xilinx has a bsdlanno program to generate a BSDL file for a specific design that describes the device post-configuration. ur Xilinx has no-cost with source software, called J Drive, that reads 1532 files and programs devices. (registration required). Altera's equivalent is JAM

The PIN_MAP_STRING tends to be rather haphazardly split into lines with the string concatenation operator "&"..

BSDL parsers

BSDL was defined in an IEEE supplement and extended in IEEE STD 1532. Kenneth P. Parker and Stig Oresjo at HP (now Agilent) distributed the source to what was probably the original BSDL parser. It can also be found as a listing in an appendix of the Boundary Scan Handbook containing a copy of the paper A language for describing boundary scan devices (1991). The license is a little vague but appears permissive in intent. The language has changed since then. IEEE 1149.1-2001 lists some changes and IEEE 1532 lists some additional changes.

BSDL files include standard packages written in VHDL, depending on the version of BSDL used: Package STD_1149_1_2001 also found in an Actel BSDL format application note , Package STD_1149_1_1994 also available as a chapter from the Boundary Scan Handbook, 2nd ed: Analog and Digital for $25, and Package STD_1149_1_1990 also in appendix B of the first edition of The Boundary Scan Handbook. Package STD_1532_2002. The license on those files is unclear. They seem to be used as if there were no restrictions on copying and the standard pretty much says though shalt use exactly this text which could be taken as an implied license.

Mentor graphics has published a paper on ABSDL, an analog extension to BSDL for mixed-signal test. Optional package declaration is "use STD_1149-4_version.all" where "version" refers to an updated version of the standard that hasn't been released yet.

HSDL

HSDL is a BSDL derived syntax for defining board level details.

Test Description Language (TDL)

SVF, XSVF, JAM, STAPL

SVF (ascii) and XSVF (binary) are files created by xilinx tools that contain JTAG instructions for how to program a particular device. "player" software source code is available (see links below). They are pretty limited, they let you do SHIFT-IR and SHIFT-DR and specify the data to be transfered and the response to expect and specify fixed bit strings to send and match before and after but they don't let you get creative with other TAP controller states which you might need in a boundary scan application. JAM evolved into STAPL which is a JEDEC standard, available from JEDEC as JESD71 (direct linking not permitted). It is an acronym for Standard Test And Programming Language and is designed for programming and testing devices over JTAG. It also supports devices with human interfaces. It was designed in such a way, though that it is not practical for devices with limited memory. There is also apparently a JEDEC standard transfer format, that isn't very popular.

STV and SRV

STV is an acronym for Sequenctial Test Vector and SRV is an acronym for Sequential Response Vector.

Standards

• IEEE 1149.1 - Digital Boundary scan
• IEEE 1532 - In-System Configuration
• IEEE 1149.6 Advanced I/O testing, AC coupled, differential, etc.
• IEEE Std 1149.4 Analog boundary scan

Links to the actual standard documents can be found in the books section, below.

IEEE STD 1149.4 Analog JTAG

There are extensions to JTAG that allow signals to be routed to and from two analog test pins. The National STA400EP is an analog mux with analog boundary scan built in but it appears it is being discontinued.

The two internal analog buses, AB1 and AB2, are connected by a 2x2 crosspoint switch to the two test pins. AT1 and AT2; switching pins is used for calibration?. Switch impedance is not necessarily low. "4 wire" measurements of an external resistor are done by taking two measurements, one on each side. 30 node limit per internal bus (typical practical limit), can be increased to 900 by two level hierarchy. Parts with incompatable voltage ranges may need a separate bus or perhaps a voltage clamp.

IJTAG

Work is afoot to provide faster TAP access to internal logic by providing a higher speed TAP based on SERDES (such as used by gigabit ethernet, PCI express, SATA, etc.). This is oriented more towards factory test rather than board level test. IEEE P1687.

JTAG Details

A JTAG Test Access Port (TAP) consists of 4 signals, with an optional fifth signal:

• TMS - Test Mode Select (input from controller) (pullup required to force entry into reset state in event of a bad connection on TMS).
• TCK - Test Clock (input from controller)
• TDI - Test Data In (input from controller)
• TDO - Test Data Out (output to controller or next chip in chain)
• TRST* - Test Reset (optional, input from controller)

Some JTAG ports have some additional non-standard signals. Microcontrollers often have a debug enable signal that switches between normal JTAG mode and OCD mode. Some ports have a RTCK signal which echos the TCK signal. In many cases TCK is tied to RTCK at the JTAG connector and this may be used to adjust for cable delay. On some ARM7TDMI based chips, this is used to synchronize TCK to the internal system clock. Thus the idea is for the JTAG pod to assert an edge on TCK and wait for the processor to return that edge on RTCK before proceeding. The philips LPC2468 microntroller has RTCK but the Ateml AT91SAM7XC256 does not, though both use the ARM7TDMI core. Many ports have a SRST signal, to reset the processor and other logic. It may also indicate to a debugger that the processor has been manually reset. Some processors have a separate reset input and reset output. Other processors will pull their reset line low when an internal reset is generated. This is a smarter design as it not only saves a pin but it allows one or more chips to hold the system reset low. On the LPC2400 family, RSTOUT is a 1.8V output while JTAG pins are 5V tolerant 3.3V signals, presenting level translation issues if one were to attempt to read this signal.

Most JTAG interface connectors have a Vcc/Vdd/Vref pin that is used to adjust the level translators to the appropriate voltage level for the system. In addition, many JTAG interfaces have a system reset line; you may want to sense the state of that line to signal a debugger when a chip has been reset. You may also want to measure the presence of Vref. Since some systems use the JTAG pins for other purposes as well, you may want to tristate the outputs. The voltage level varies depending on the technology being used. Multiple chips (or even boards) with JTAG support can be chained together with the TDO of each chip connected to the TDI of the next. The remaining signals are connected in parallel. Timing is based on the TCK pin so a PC parallel port (with appropriate voltage translation if needed) can be used as a controller. TDI/TMS data is latch on the rising edge of TCK. TDI/TDO/TMS typically change on the falling edge of TCK. You could probably do a full synchronous implementation where the data changes on the rising edge but you would have to be carefull with cable skew and hold types.

Note that the idea of having a TRST line may be less so the pod can reset the TAP controller, which is unnecessary since 5 TCKs with TMS high will accomplish the same result, and more so the board design can pull TRST low through a low value pull-down resistor which the POD can override. Thus, it may be necessary to implement TRST even if you have no need to use it.

In addition, some microcontrollers have a trace port (called ETM on ARM7TDMI). Since the internal address and databus are not usually brought out to pins the trace port can be used to monitor the flow of program execution. On the ARM7TDMI, this is about 8 signals clocked out at the CPU clock rate. By decoding those signals, you can tell when the next instruction in sequence has been executed and when a branch has been taken. A debugger with access to a copy of the code loaded into the micro, a which thus knows the size of each instruction and the destination of each branch can map the flow. Interrupts, however, could complicate this. On ARM7TDMI, a low on RTCK during reset may enable the ETM port. The ETM is configured through the JTAG interface. Use of ETM involves giving up some I/O lines.

JTAG TAP Controller

Each JTAG enabled chip has a TAP controller with a state machine with 16 states. The state of the TMS pin at each TCK pulse dictates the transitions between states. These states help control whether you are shifting through the instruction register or one of the data register and control the capture of data into the shift registers and latching of data from them.

Here is a diagram of the TAP controller state machine, produced using graphviz (requires browser/plugin SVG support):

[JTAG State machine diagram]

Each ellipse denotes a state and each arrow denotes a transition from one state to another. There are two transitions from each state, one taken when TMS=0 and one taken when TMS=1. The shift IR and Shift DR states are emphasized because that is where you will spend the most time (other than when idle). These are the states where data is shifted in on TDI and out on TDO and the machine will stay in those states as long as TMS=0. The Exit* and Pause* states are not terribly interesting. For either the data or instruction registers, you usually start by passing through the Capture_* state which loads data from the chip into the register, proceed to the shift* state where the captured data is shifted out while the new data from the PC is shifted in, and then make your way through a couple minor states to the update state where the new data is latched into the chip.

Here is the TAP controller state machine as a table, which is easily converted into C, VHDL, Verilog, or other languages.

Current State

	TMS=0	TMS=1
Test-Logic-Reset	Run-Test/Idle	(no change)
Run-Test/Idle	(no change)	Select-DR-Scan
Select-DR-Scan	Capture-DR	Select-IR-Scan
Capture-DR	Shift-DR	Exit1-DR
Shift-DR	(no change)	Exit1-DR
Exit1-DR	Pause-DR	Update-DR
Pause-DR	(no change)	Exit2-DR
Exit2-DR	Shift-DR	Update-DR
Update-DR	Run-Test/Idle	Select-DR-Scan
Select-IR-Scan	Capture-IR	Test-Logic-Reset
Capture-IR	Shift-IR	Exit1-IR
Shift-IR	(no change)	Exit1-IR
Exit1-IR	Pause-IR	Update-IR
Pause-IR	(no change)	Exit2-IR
Exit2-IR	Shift-IR	Update-IR
Update-IR	Run-Test/Idle	Select-DR-Scan

Note that aside from the first two states, the remaining states are divided into two sets of 7 states which are almost identical except that one set deals with the instruction register and one deals with the data register. These two sets of states deal with three operations: capture, shift, and update. Capture loads data from the chip into the corresponding register.Data is latched on the rising edge of TCK when exiting the capture state. Shift moves the data out through TDO while new data is shifted in on the TDI pin. The update-xx states cause the data from the shift register to be transfered to the selected register. The update occurs on the falling edge of TCK while still in the update state.

The state machines main states are reset, run/idle, shift DR, and shift IR.

Data is shifted in on the rising edge of TCK and data out becomes valid on the falling edge of TCK (to be latched on the rising edge). I.E. Rising edge is the active edge for input and output and the transitions occur at the falling edge. TMS=0 to keep the controller in the shift-xx state until all the data is shifted out; TMS=1 when the last bit is shifted.

Five TCKs with TMS high will reset the state machine to the Test-Logic-Reset state from any other state.

C implementation

   #define TAP_TEST_LOGIC_RESET 0
   #define TAP_RUN_TEST_IDLE 8
   #define TAP_SELECT_DR_SCAN 1
   #define TAP_CAPTURE_DR  2
   #define TAP_SHIFT_DR_SCAN 3
   #define TAP_EXIT1_DR 4
   #define TAP_PAUSE_DR 5
   #define TAP_EXIT2_DR 6
   #define TAP_UPDATE_DR 7
   #define TAP_SELECT_IR_SCAN 9
   #define TAP_CAPTURE_IR 10
   #define TAP_SHIFT_IR 11
   #define TAP_EXIT1_IR 12
   #define TAP_PAUSE_IR 13
   #define TAP_EXIT2_IR 14
   #define TAP_UPDATE_IR 15
   int jtag_tap_controller_state_machine(int tms)
    {
       static int state=TAP_TEST_LOGIC_RESET;
       int nextstate;
       switch(state) {
            case(TAP_TEST_LOGIC_RESET): if(!tms) {nextstate=TAP_RUN_TEST_IDLE;} else {  ; } break;
    case(TAP_RUN_TEST_IDLE): if(!tms) { ; } else {nextstate=TAP_SELECT_DR_SCAN;} break;
    case(TAP_SELECT_DR_SCAN): if(!tms) {nextstate=TAP_CAPTURE_DR;} else {nextstate=TAP_SELECT_IR_SCAN;} break;
    case(TAP_CAPTURE_DR): if(!tms) {nextstate=TAP_SHIFT_DR;} else {nextstate=TAP_EXIT1_DR;} break;
    case(TAP_SHIFT_DR): if(!tms) { ; }; else {nextstate=TAP_EXIT1_DR}; break;
    case(TAP_EXIT1_DR): if(!tms) { nextstate=TAP_PAUSE_DR;} else {nextstate=TAP_UPDATE_DR;} break;
    case(TAP_PAUSE_DR): if(!tms) { ; } else {nextstate=TAP_EXIT2_DR}; break;
    case(TAP_EXIT2_DR): if(!tms) { nextstate=TAP_SHIFT_DR; } else {nextstate=TAP_UPDATE_DR;} break;
    case(TAP_UPDATE_DR): if(!tms) {nextstate=TAP_RUN_TEST_IDLE; } else {nextstate=TAP_SELECT_DR_SCAN;}; break;
    case(TAP_SELECT_IR_SCAN): if(!tms) {nextstate=TAP_CAPTURE_IR;} else {nextstate=TAP_TEST_LOGIC_RESET;} break;
    case(TAP_CAPTURE_IR): if(!tms) {nextstate=TAP_SHIFT_IR;} else { nextstate=TAP_EXIT1_IR; } break;
    case(TAP_SHIFT_IR): if(!tms) { ; } else {nextstate=TAP_EXIT1_IR;} break;
    case(TAP_EXIT1_IR): if(!tms) { nextstate=TAP_PAUSE_IR; } else { nextstate=TAP_UPDATE_IR; } break;
            case(TAP_PAUSE_IR): if(!tms) { ; } else {nextstate=TAP_EXIT2_IR; } break;
    case(TAP_EXIT2_IR): if(!tms) { nextstate=TAP_SHIFT_IR; } else {nextstate=TAP_UPDATE_IR; } break;
            case(TAP_UPDATE_IR): if(!tms) {nextstate=TAP_RUN_TEST_IDLE; } else {nextstate=TAP_SELECT_DR_SCAN; } break;
            default: nextstate=TAP_TEST_LOGIC_RESET;    
       }
       state=nextstate;
       return(state);
    }

This code is an example, intended for illustrations, it hasn't been tested. "enum" types may be used instead of "#define". This function should be called once on the rising edge of TCK. While you probably don't want to implement a TAP controller in software on an actual hardware device (it would be very slow), simulating one is useful for keeping track of the state of a controller you are talking too, debugging, educational purposes, etc. This example can also be pretty easily converted to VHDL or Verilog for synthesis or simulation. Note that #defined values for the various states were chosen so that the similarly named instructions (which have similar state transitions) share 3 bits in common to facilitate logic minimization.

IEEE 1149 has the combinatorial form of the state machine logic expressed as a 4 sums of 17 products, each product having at most 4 inputs. Thus 21 4 input LUTs could be used to implemnt that logic (about double that when you include the sequential portion).