Introduction to JTAG and the Test Access Port (TAP)

JTAG has become a standard in embedded systems, and it is available in nearly every microcontroller and FPGA on the market. It's named for the group which developed it: the Joint Test Action Group.

If you’ve programmed a microcontroller in the last few years, there’s a strong chance that you've used JTAG or one of the related standards. So it’s worth asking: What exactly is JTAG? How does it work? And what can you do with it?

 

What Is JTAG?

It used to be the case that testing a board with many IO paths required something like a bed of nails testbench. However, as pin density increased and as ball-grid-array (BGA) packaging became more prevalent, a new method of testing was required. A solution was needed which tested hardware interconnects between multiple ICs.

And so, in the 1980s, boundary-scan was developed, and standardized in IEEE 1149.1-1990, IEEE Standard for Test Access Port and Boundary-Scan Architecture. This standard technology became known to developers and engineers as JTAG. 

 

JTAG Boundary Scan

The standard itself provides the implementation of boundary scan: each IO pin on a device is provided with a small logic cell between the internal logic and the physical pin, and all of these logic cells are connected so that they can shift data in one direction around the chip. Pin values can be read or written, to test functionality.

In addition, it specifies a test access port (TAP) which is a logic block responsible for executing tests and managing data flow along the boundary cells. The TAP, which is essentially a state machine and several shift registers, can be made to execute commands, like data load and data read. But the framework is general enough that manufacturers have freedom to add commands and logic blocks which provide things like programming and debugging access. 

 

Why Is JTAG Popular?

So how did JTAG become synonymous with device programming? Recall that any device which has memory can be programmed by, first, addressing a word and, second, writing data to that address.

Early memory devices utilized asynchronous addressing, often without decoding, using a matrix-like address scheme. Data is provided through separate data pins, one for each bit in the memory word. Soon, binary decoding for addresses reduced the required pin count and allowed for larger memories, and later the application of serial protocols allowed a programmer to communicate with the device using only a few pins, for memories of any size.

Then, as JTAG’s flexibility allowed developers to implement custom logic, it, too, became used for programming. The data pipeline which the JTAG TAP provides is well suited to the task of microcontroller and FPGA programming, and the standardization of the interface helped create uniformity across devices (though, as we will see, there is broad variety across implementations). 

Further extensions of the standard, such as ARM’s Serial Wire Debug (SWD), as well as additional IEEE 1149.x standards, would expand the standard’s applicability and utility, allowing JTAG to become what we know today.

Though it is a standard, IEEE 1149.1 leaves a lot to the developer. There are no standard pinouts, no standard connectors, and only a few built-in commands. Beyond the basic state machine, many features are not required to be compliant; even the boundary scan functionality is optional. We’ll see more of this variety in the articles to come. 

With that history lesson over, let’s move on to the standard itself.

 

The Test Access Port (TAP)

Figure 1 shows the basic JTAG architecture. 

 

Figure 1. JTAG architecture schematic

 

Let's work from the bottom up. There are four required signals in the JTAG standard, and one optional signal. All JTAG-compliant devices must have:

• Test data input (TDI) pins
• Test data output (TDO) pins
• A test clock pin (TCK)
• A test mode select pin (TMS) for controlling the TAP state machine

The test reset pin (TRST), which forces the state machine into the reset state, is optional, because the reset state can always be obtained by holding TMS low and clocking TCK five times. 

 

The TAP Controller

The test access point (TAP) is composed of the TAP controller, an instruction register, and several test data registers, in addition to some glue-logic. The TAP controller contains the testing state machine, and is responsible for interpreting the TCK and TMS signals. The data input pin is used for loading data into the boundary cells between physical pins and the IC core, and loading data into the instruction register or one of the data registers. The data output pin is used to read data from the boundary cells, or to read data from the instruction or data registers. 

The TAP controller’s state machine is manipulated by the mode select signal, TMS, which is clocked by TCK. There are only two “paths” which the state machine takes, representing two different modes: instruction mode and data mode. The mode is selected by clocking in a TMS HIGH or TMS LOW bit. Then, when in a given mode, the state machine either progresses (TMS HIGH) or moves toward the reset state (TMS LOW). We’ll look at the state machine in detail in the next article. 

 

How to Use JTAG

Working with JTAG typically works as follows:

1. First, the instruction mode is selected. One of the states within the instruction mode ‘path’ allows the user to clock in an instruction through TDI.
2. Then the state machine progresses until it resets.
3. For most instructions, the next step is to select the data mode. In this mode, data is loaded through TDI and/or read from TDO. The data paths for TDI and TDO will be configured in accordance with the instruction that has been clocked in.
4. When the read or write operation is complete, the state machine again progresses to the reset state. 

 

Test Instructions and Data Registers

There are two data registers and four instructions which the JTAG standard requires in all devices. Another six data registers and 13 instructions are also standardized, but not required.

The data registers required are:

• BSR – “Boundary-scan register”, the main register for passing data to the boundary-scan cells
• BYPASS – A single-bit pass-thru register, connecting TDI to TDO without first passing through the boundary-scan cells

Vendors can implement other data registers depending on their design needs, whether standardized or design-specific. The only instructions the JTAG standard requires to be implemented are:

• EXTEST – Perform an “external” boundary-scan test using the boundary scan cells
• SAMPLE and PRELOAD – Boundary scan while the device is functional
• BYPASS – Bypasses the boundary scan cells altogether

 

Common JTAG Instructions

Other recommended instructions include:

• IDCODE – Output an identification code stored in an identification data register
• CLAMP and HIGHZ – Used to isolate parts of the device without risk of damage. HIGHZ forces all logic outputs to high-impedance mode, while CLAMP forces logic outputs to particular values, e.g. to ensure a device doesn’t respond when other devices are being tested
• IC_RESET – Mandatory when a reset selection register is implemented, allows for control of device resets and power
• CLAMP_HOLD, CLAMP_RELEASE, and TMP_STATUS – Mandatory when Test Mode Persistence (TMP) is implemented through a TMP controller
• INIT_SETUP, INIT_SETUP_CLAMP, and INIT_RUN – Recommended when a device has programmable IO pins

Additionally, there are optional instructions which are defined in the standard but are not among the required or recommended instructions:

• RUNBIST – Built-in system tests, controlled internally
• INTEST – Internal boundary-scan test
• USERCODE – User-programmable ID code is shifted out
• ECIDCODE – Electronic chip identification code, an identifier for the silicon die itself

The instructions are assigned binary codes, and may be considered public (for the end-user/designer) or private (for device verification by the device vendor). Most instructions do not have requirements for the binary value, meaning it is the choice of the manufacturer. One exception is the BYPASS instruction, which is {1,1,…,1}, i.e. all ones. The standard does require that all possible instruction binary codes, whether valid or invalid, default to some well-defined behavior. 

Most JTAG instructions can broadly be described as connecting different data registers to the TDI/TDO path. The BYPASS instruction connects TDI directly to TDO through a 1-bit shift register, the IDCODE instruction connects the identification code register to TDO, the EXTEST, INTEST, SAMPLE, PRELOAD instructions all connect the boundary-scan register (BSR) data register to TDI and TDO, and so on. 

Now you might ask, how are we supposed to know what the instruction codes are?

As mentioned, this is vendor-specific, but generally the JTAG interface will be wrapped in a “middleware” architecture which not only includes the JTAG TAP, but also the interface and connections to the device core, such as FLASH memory, or ROM memory, or CPU registers. An example of a middleware architecture is Arm’s CoreSight architecture, and more particularly the Arm Debug Interface (ADI), which adds additional structure to the JTAG TAP in the form of a debug port, access ports, and device resources. 

 

Conclusion

We now understand broadly what JTAG is, and what it can do. We saw the JTAG TAP (test access port), and several instructions and data registers.

There is still a lot of information to cover, most important being the TAP state machine, which is the topic of the next article. With an understanding of the state machine and TAP, we can begin to move beyond the JTAG standard, looking at the Arm Debug Interface and particular JTAG interfaces such as the Seggar J-Link and the Black Magic Probe.