What is a JTAG connection test?

What is a JTAG connection test?

A JTAG connection test will check that the connections around the JTAG enabled devices on a board are the same as those specified in the design.

Where two JTAG enabled pins are meant to be connected the test will make sure one pin can be controlled by the other. Where enabled pins are not meant to be connected they are tested for short circuit faults by driving one pin and checking that these values are not read on the other pins.

Missing pull resistors and ‘stuck-at’ faults can also be found by a connection test as well as faults involving logic devices whose behaviour can be described in a truth table.

XJTAG will automatically generate the vectors required to run a connection test based on the netlist of a board and JTAG information for the enabled devices.

What about devices that are not JTAG enabled?

While the main devices, such as processors and FPGAs, are normally JTAG enabled, there will be many devices in every design that are not. DDR, SDRAM, SRAM, flash, MDIO controlled Ethernet PHYs, SPI and I2C temperature sensors, real time clocks, ADCs and DACs are just some examples of such devices.

The connection test will still provide excellent coverage for short circuit faults on the nets linking these non-JTAG devices to JTAG enabled devices; however it cannot check for open circuit faults at either the JTAG device or the non-JTAG device.

In order to add this open circuit coverage it is necessary to communicate with the peripheral device from boundary scan on the enabled device. If communication can be verified, there cannot be an open circuit fault. This type of testing can be very simple, for example lighting an LED and asking an operator to verify it has activated, or more complex, for example writing data into the memory array of a RAM and reading it back.

Is it a lot of work to create a JTAG test system?

Using the libraries for standard non-JTAG components provided by XJTAG, you can get a set of tests up and running for your board with no code development. The library files contain models for all types of non-JTAG devices from simple resistors and buffers to complex memory devices such as DDR3. Because boundary scan disconnects the control of the pins on JTAG devices from their functionality the same model can be used irrespective of the JTAG device controlling a peripheral.

Most boards already contain JTAG headers for programming or debug so there are no extra design requirements.

Where do I get information about the JTAG in my devices?

In order to run any boundary scan based testing it is necessary to have some information about the implementation of JTAG on the enabled devices on a board. This information comes from the BSDL (Boundary Scan Description Language) files for these devices. BSDL files must be made available by the silicon vendor for a device to be compliant with IEEE Std. 1149.1.

Is JTAG test just used in production?

Not at all. One of the key benefits to boundary scan testing is that the only test hardware required is a JTAG controller. Other production test technologies such as flying probe, automated optical/X-ray inspection or bed-of-nails all require specialised test equipment that will not be available on an engineer’s bench.

Using boundary scan during board bring-up can remove uncertainties – hardware engineers can test prototype boards for manufacturing defects before system testing, and even before firmware is complete. Test systems developed at this early stage of the product lifecycle can easily be reused, and extended for production.

Test Access Port (TAP) Controller

The TAP controller, a state machine whose transitions are controlled by the TMS signal, controls the behaviour of the JTAG system. Figure 2, below, shows the state-transition diagram.

TAP State machine

All states have two exits, so all transitions can be controlled by the single TMS signal sampled on TCK. The two main paths allow for setting or retrieving information from either a data register or the instruction register of the device. The data register operated on (e.g. BSR, IDCODES, BYPASS) depends on the value loaded into the instruction register.

For more detail on each state, refer to the IEEE 1149.1 Standard JTAG document.

Boundary Scan Instructions

The IEEE 1149.1 standard defines a set of instructions that must be available for a device to be considered compliant. These instructions are:

  • BYPASS – this instruction causes the TDI and TDO lines to be connected via a single-bit pass-through register (the BYPASS register). This instruction allows the testing of other devices in the JTAG chain without any unnecessary overhead.
  • EXTEST – this instruction causes the TDI and TDO to be connected to the Boundary Scan Register (BSR). The device’s pin states are sampled with the ‘capture dr’ JTAG state and new values are shifted into the BSR with the ‘shift dr’ state; these values are then applied to the pins of the device using the ‘update dr’ state.
  • SAMPLE/PRELOAD – this instruction causes the TDI and TDO to be connected to the BSR. However, the device is left in its normal functional mode. During this instruction, the BSR can be accessed by a data scan operation to take a sample of the functional data entering and leaving the device. The instruction is also used to preload test data into the BSR prior to loading an EXTEST instruction.

Other commonly available instructions include:

  • IDCODE – this instruction causes the TDI and TDO to be connected to the IDCODE register.
  • INTEST – this instruction causes the TDI and TDO lines to be connected to the Boundary Scan Register (BSR). While the EXTEST instruction allows the user to set and read pin states, the INTEST instruction relates to the core-logic signals of a device.

Obtaining the IEEE 1149.1 Standard

The IEEE 1149.1 Standard JTAG specification is available directly from IEEE: