ASSET InterTech provides unique tools for accessing embedded instrumentation: Boundary Scan, CPU Emulation, Intel® IBIST.

News / Resources

For Working Media

Media Contacts:
Bob Greenfield
G&A PR
(972) 254-2887
bob.greenfield@verizon.net

WHITE PAPERS

System Test with Boundary Scan (JTAG)

by Dave Bonnett, Technical Product Manager,, ASSET InterTech, Inc.

Table of Contents
Executive Summary
What is system test and why would you want to do it?
Why system test?
How is system test implemented with boundary scan?
Boundary-scan access to each system component
System Test with Multi-drop Devices
Considering System Test

Executive Summary

Boundary scan (IEEE 1149.1/JTAG) is most often thought of as a board-level test method, but new hardware and software techniques make system-level test with boundary scan not only feasible, but quite effective. In fact, system-level tests with boundary scan can save a significant amount of time and effort troubleshooting systems that have failed functional test. Ultimately, boundary-scan system tests ensure a high-quality system.

Many different types of faults can arise when systems are assembled. JTAG testing techniques are well suited to finding and diagnosing many of these problems. In addition, the usefulness of boundary scan at the system level extends well beyond what is usually thought of as test functions. Besides structural integrity tests, JTAG can also perform on-board programming of flash memory, in-system configuration of programmable logic devices (PLDs), on-board programming with I2C data and emulation-based functional testing through a processor’s JTAG debug port. Some of these functions can be very helpful to support and maintenance personnel long after a system has been assembled in a manufacturing environment and installed at a customer location.

What is system test and why would you want to do it?

The logical place to begin a discussion of boundary-scan system-level testing is to define what system test means and to distinguish it from board test, which is the more typical arena for boundary scan. A system can be defined as “a group of interrelated, interacting, or interdependent constituents forming a complex whole.” (Webster Dictionary) For the purposes of this discussion, system will mean more than one board connected together. This could be an assembly as simple as a mother/daughterboard combination or an extremely complex backplane-based computer with hundreds of boards.

So, applying this definition, it can be said that an electronic system is a group of interrelated devices and boards that function together to accomplish a task. Although the components that comprise an electronic system may be tested individually without regard to the task of the entire system, the overarching goal of system test is to verify the structural integrity and/or functionality at the level of the complex whole. At a fundamental level, testing a system’s structural integrity would involve verifying that each component is properly connected to all other components that require such connections.

Why System Test?

Most electronic products can be seen as a system. Even if all of the system’s components are fully tested individually, the system still may not function properly. Many problems can arise when systems are assembled. Boundary scan is well suited to finding and diagnosing these problems. For example, a connector may not be making good electrical contact or a connector’s pins might be damaged during assembly. Boards on a backplane may be missing, out of place or simply not functioning properly. Functional tests might identify that the system is not functioning as expected, but isolating and diagnosing the fault with functional tests would be very time consuming and often would require high-level system expertise to troubleshoot the cause.

In addition, the usefulness of boundary scan at the system level extends well beyond what is usually thought of as test functions. Besides structural integrity tests, boundary-scan can also perform on-board programming of flash memory, in-system configuration of programmable logic devices (PLDs), on-board programming with I2C data and emulation-based functional testing through a processor’s JTAG debug port. Beginning with system-level debug and production test, boundary scan provides many other system benefits when it is extended to field support. For example, boundary scan can be used for quick and easy updates of programs stored in flash memory or updates to system functionality in the field through the re-configuration of on-board PLDs.

How is system test implemented with boundary scan?

Four primary methods are available for implementing boundary-scan-based system tests. Three of these methods involve connecting an external boundary-scan test tool to the system and the fourth involves embedding boundary-scan test into the system.

The first external method connects all of the boundary scan paths on all of the boards in the system to a single scan path with one point of access for the boundary scan test system (Figure 1). This method requires that the configuration of the system must remain exactly the same in every assembled product. Also, any break in the single scan path will disable all boundary-scan test access. One very long scan path can also result in slow access times.

Figure 1 - Single Scan Path

The second external method is to link each scan path in the system to external connectors where the boundary scan tool will have access to all scan paths (Figure 2). With this method, physical access to each JTAG connector must be available when the system is operating. Additional test system hardware is also needed to connect the test system and the system under test. However, with this method, the configuration of the system can change and the test system is able to manage test access for each new or different configuration of the system. Also, systems that may not have been designed with system-level testing in mind may be tested with this method.

Figure 2 - Multiple Scan Paths/Multiple Access Points

The third method is to design a method for controlling access to the scan paths on the individual boards from one external JTAG port (Figure 3). This is most commonly accomplished with multi-drop gateway devices that control the board for the purposes of testing the system. These gateway devices typically are controlled by the test system. They can be mounted on each board or on the backplane where the boards are installed. If installed on-board, gateway devices will require board real estate. In any event, they will add to the cost of the system. Also, distinct tests must be developed for each configuration of the system.

Figure 3 - Multiple Paths/One-Access Point

The fourth method is to embed built-in-self-test (BIST) features into the system (Figure 4). This is usually the most efficient method because it can provide fast test times and high fault coverage if it is designed properly. However, BIST-based tests must be designed into a system early in the design cycle, because they can not be easily retrofitted into a system. Embedded BIST can be controlled by an on-board test manager and initiated by the normal functional user interface, or it can be initiated by a test interface such as a boundary-scan IEEE 1149.1 Test Access Port (TAP).

Figure 4 - Embedded BIST

The table below provides a summary of the advantages and disadvantages of the three external and one embedded boundary-scan system test methods.

Table 1 - Advantages and Disadvantages of Various System Test Methods

Implementation Method	Advantages	Disadvantages
One path per system/one access point	Simple, single point of access	System configuration must never change. One break in the scan chain will disable all boundary scan operations. Slow access times.
Multiple paths per system/separate access to each path	Test can adapt to changes in the system's configuration. Already-designed systems can be retrofitted with boundary scan system tests	Physical access to each path needed. Additional hardware needed to connect system-under-test and test system.
Multiple paths per board/one control point per board	Test are controlled by multi-drop gateway devices. Straightforward interface with test system.	Gateway devices require board or backplane space and add to the cost of the system. Each system configuration requires its own test suite.
Designed-in embedded BIST	Fast test time and high test coverage if designed properly. Flexible deployment using boundary scan access.	Can not be retrofitted to a design.

Boundary-scan access to each system component

Many boards that are well designed for board-level boundary scan test are often easily integrated into system-level test processes that use boundary scan. However, several restrictions must be overcome to build on board-level boundary scan and achieve effective system test. These restrictions include the following:

The JTAG connector on each board must be accessible when the boards are installed in a system.
The system must be able to operate with a boundary-scan test system connected to each board. (For example, connecting each board to a boundary-scan test system may require removing the enclosure or cabinet covers and this may affect the system’s cooling.)
The boundary scan tool must be capable of managing several scan paths and generating tests for the connections between the boards.
A system-level net list is required to generate interconnect tests between boards.

ASSET InterTech’s ScanWorks boundary-scan test environment supports system-level boundary-scan operations with hardware that connects to multiple scan paths and software that manages the access to those scan paths. For example, the ScanWorks PCI-400 controller card supports access to as many as 24 scan paths. Each scan path can be accessed individually or scan paths can be concatenated together in groups of four to enable interconnect testing among the boards in a system. In addition, the ScanWorks PCI/PXI-100 controller in combination with the Four-Port Buffer/Pod theoretically supports 96 scan paths, although 32 paths is a more practical number.

System Test with Multi-drop Devices

Multi-drop gateway devices on the boards in a system can also be used for system-level tests. In this case, the multi-drop devices would control access to one or more scan paths on a board, providing access for these multiple paths to a primary source for the boundary-scan TAP signals. The boundary-scan tool connected to the primary TAP on a board sends commands to the multi-drop device, configuring it for test operations. Multi-drop devices use either of two methods for communicating with the boundary-scan tool.

The tool uses the standard IEEE 1149.1 protocol to write data to registers internal to a multi-drop device. The contents of these registers determine which of the multiple scan paths controlled by the device will be active. Each active path is included in the overall scan path along with the board’s primary scan path. If more than one multi-drop device is present on the primary scan path, the tool must be able to target each multi-drop device.
The boundary scan tool uses a proprietary protocol to place a command on the primary TAP signals. Each multi-drop device on the primary scan path examines the command to determine for which multi-drop device it is intended. These commands open or close one or more secondary scan paths, adding or removing them from the overall scan path that is connected to the boundary scan tool. The boundary scan tool must always know the exact configuration of the scan path before any scan operation can be executed.

ScanWorks supports all of the major, commercially available multi-drop gateway devices, including the following:

Texas Instruments
• Scan Path Linker (SPL) – SN54ACT8997
• Addressable Scan Port (ASP) - SN54ABT8996
• Linking Addressable Scan Port (LASP) – SN54LVT8986

National Semiconductor
• Scan Bridge (SCANSTA111, SCANSTA112)

Firecron (Alliance Semiconductor)
• Gateway (JTS03, JTS06)

Lattice Semiconductor
• BSCAN2 (Multiple Scan Port Linker)

In ScanWorks, all boundary-scan operations are based on a design description. The design description is built from the BSDL files for the devices in the design and from information describing how the devices are connected together in scan paths. Scan paths on a board can be permanent or they may be re-configured dynamically by way of commands that are sent to the multi-drop devices. ScanWorks retains the status of the scan path configuration so that it always knows the exact makeup of the scan chain or chains.

ScanWorks provides several methods for controlling multi-drop devices and the secondary scan paths associated with them. In some cases, a certain scan path configuration may be needed for several test operations. Or, the scan path may be dynamically reconfigured before an action can be applied. In either case, ScanWorks maintains a particular scan path configuration until it is explicitly changed by ScanWorks or until a JTAG Test Logic/Reset operation occurs.

As part of a ScanWorks action, a precondition can be defined that prepares the board or system for the application of the tests or programming operations that comprise the action. This precondition is applied to the board or system before the scan operations are applied. The precondition also communicates the configuration of the scan path to ScanWorks’ automatic test pattern generation tool before it generates test vectors. In this way, ScanWorks can ensure that any test vectors it creates are the required vectors for the current configuration of the scan path.

Considering System Test

Over the course of the last decade, boundary scan has established a firm foothold at the level of board test, but it also has a critical function to play at the system level. Indeed, as more board-level boundary-scan tests and programming operations are developed and deployed, the feasibility of implementing system-level boundary-scan operations increases because the developmental work done for individual boards can be leveraged against system-level objectives. Moreover, any additional effort to implement boundary scan at the system level is merely marginal when boundary scan has already been deployed at the board level. The board-level infrastructure is already in place for system-level tests. As a result, the payback for system-level boundary scan can be quite rapid because of the limited amount of development time required to implement system-level boundary-scan test as an add-on to board-level boundary-scan operations.