System Test with Boundary Scan (JTAG)

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

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:

1. The JTAG connector on each board must be accessible when the boards are installed in a system.
2. 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.)
3. The boundary scan tool must be capable of managing several scan paths and generating tests for the connections between the boards.
4. 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.

1. 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.
2. 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.

Previous : Next                    Page 4 of 4          Back to Page 1