The effort to develop a standardized test method that can solve test access problems caused by ever denser printed circuit designs, shrinking device geometries and new device packaging (such as BGA and CSP) started in the mid 1980s, when a group of European companies and institutions formed the Joint European Test Action Group (JETAG), which later changed its name to Joint Test Action Group (JTAG) when North American organizations joined the group.  Working hard on creating the first standardized test access technology, the group approached IEEE in the late 1980s to sponsor the effort. In 1990, the JTAG / Boundary Scan architecture was published as IEEE 1149.1 (Standard Test Access Port and Boundary Scan Architecture [1]). Since then, various improvements have been made to the original standard; the latest revision has been approved and published in 2001. The JTAG / Boundary Scan technology owes its success to its elegant way of providing test and debug access to nodes on a printed circuit board (PCB). Even though the IEEE 1149.1 standard is limited to digital circuitry, the test access achievable on today’s designs implementing this technology allows a wide variety of test and debug applications and even supports some tasks not foreseen at the time the standard was developed. Most modern board and system designs make use of Central Processing Units (CPU’s) or Micro Processors (?P’s), Digital Signal Processors (DSP’s), Programmable Logic Devices (PLD’s), and/or Field Programmable Gate Arrays (FPGA’s) – all of which are of digital nature and most of which implement JTAG / Boundary Scan capabilities as defined in IEEE 1149.1.

An overview of typical test applications utilizing JTAG/Boundary Scan features is provided below. 

Boundary Scan Infrastructure Test

Infrastructure Test is used to ensure that the right BScan components are mounted and that the test resources and the scan chain(s) are accessible and functioning. It verifies the Boundary Scan resources (register lengths and capture codes for ID-Code, Bypass, Instruction, and Boundary Scan Registers) of and the test bus connections between the various BScan devices on the UUT.  

Interconnection Test

Interconnections Test verifies the connections between Boundary Scan pins. The existence of serial resistors and pull-Resistors is verified as well as the function and connectivity of transparent clusters (e.g. buffer devices between BScan components). It includes test steps to find stuck-at-0 faults, stuck-at-1 faults, opens and shorts, and provides diagnostic information on BScan cell, pin and net level. The testability of a BScan net depends heavily on the boundary scan resources available in this net and on additional non-BScan pins connected to it. BScan nets featuring bi-directional BScan pins are tested in both directions, if possible. The number of test vectors (scan cycles) generated depends on the number of BScan nets and on the highest number of BScan drivers found in any BScan net. Several test steps are generated: first stuck-at-low and stuck-at-high tests, then up to four counter tests to find shorts and opens. For stuck-at test, the maximal number of BScan drivers in any nets is defining the number of generated test vectors. For counter tests, the number of generated test vectors can be calculated per logarithm of the number of nets to the basis two.

Memory Cluster Test

A Memory Cluster Test verifies the connections between Boundary Scan pins and the memory device (at the same time other BScan to BScan pin connections are checked as well). Existence of serial resistors and pull-Resistors is verified. The function of the memory devices and any logic between BScan device and the memory devices tested. Access to all memory control pins (direct or indirect), as well as control over clock signals on SDRAM, and similar devices, is required. 

Logic Cluster Test

A Logic Cluster Test verifies the connections from Boundary Scan pins to Cluster inputs and outputs and connections within the cluster as well as the general cluster functionality. Fault isolation is limited due to missing Boundary Scan access to all cluster-internal nodes. Keep logic clusters as small as possible. Control over non-BScan devices and clock signals (for sequential logic) is required. 

In-System Programming of PLD

Most modern programmable logic devices (PLD) provide a IEEE-1149.1 test bus interface and support in-system programming through that port. Typically, programming control is built in to the device and the control sequence and programming data is provided by means of various file types, such as SVF files, JAM files, STAPL (Jedec-Std. 71) files [10], or IEEE 1532 files [11]. If a PLD blocks data from scanning out of its TDO during In-System Programming, keep this device in a separate scan chain or put it at the end of the scan chain (no other BScan components between this device and TDO of the board) or provide the means to temporarily isolate the device for ISP.

In-System Programming of EEPROM

FLASH devices and other EEPROM (such as serial EEPROM based on I2C or SPI protocol) can be programmed via Boundary Scan devices if access is available to all memory pins required for programming (either directly or indirectly). To reduce programming time, a short scan chain and high TCK frequency are required. Separate the BScan device used to program EEPROM from other BScan devices (put it in a separate scan chain) if those devices support only a much slower TCK frequency. Try to control all EEPROM pins from the same BScan component (so that all other BScan components can be kept in HIGHZ, CLAMP, or BYPASS mode). Programming speed can be increased if frequently exercised control pins (such as /WE) are accessed with parallel I/O resources rather than Boundary Scan. Precondition for that is that the Boundary Scan pin in that net can be disabled and that access to the control pin is available via connector (preferably) or test pad.

Built-In Self Test (Device Test/Emulation)

Built-In Self Test (BIST) can be used to verify that a device is working properly after it has been assembled on a PCB. Usually, BIST is used to exercise device functions at speed. The test can be initiated via the IEEE-1149.1 test bus interface, e.g. by loading a BIST data register with stimulus applying the RUNBIST instruction. After completion, the test results (e.g. a signature pattern) can be read out via the test bus interface. In a similar way, device emulation resources can be accessed through the test bus interface to debug device functions and/or firmware programmed into a device. Keep the device to be tested in a separate scan chain if the tool used to apply BIST pattern or emulation sequences cannot handle devices other than the target component in the same scan chain.

Extended Interconnection Test

Often times, Boundary Scan alone cannot test all of the board level circuitry completely. Usually, other test methodologies, such as MDA (Manufacturing Defect Analysis), AOI (Automatic Optical Inspection), ICT (In-Circuit Test), or FT (Functional Test), are used to complement Boundary Scan to achieve satisfactory test coverage. Executing all these tests in a separate step means board handling overhead that may be reduced by combining test methods. Boundary Scan can be highly advantageous when integrated into ATE systems based on a bed-of-nails or moving probes (Flying Probe Testers). A combined solution can either reduce the number of nails required in a fixed-probe-adapter (thus dramatically reduce adapter cost), or it can improve the test time by reducing the number probing points required for an interconnect test based on moving probes.

Combined Functional Test

Combining Ad-Hoc test, such as FT (Functional Test), with Boundary Scan has the advantage, that functional test sequences become much simpler, since they don’t have to detect and locate/diagnose structural faults. Boundary Scan tests can be initiated at the beginning of the test sequence, verifying that there are no structural faults on the Unit Under Test (UUT) in the circuitry testable via Boundary Scan resources. After successful execution, functional tests can be executed to exercise the UUT at speed. Boundary Scan can be used to reconfigure certain parts of the circuitry, e.g. to aid functional test or to load the firmware. At the most integrated level, both Boundary Scan resources and functional test resources can be used in conjunction to improve testability and simplify test sequences.