CONNECT NEWSLETTER

asset-intertech.com

TECH TIP

What is system test and why would you want to do it?
By Dave Bonnett
Technical Marketing Manager

The logical place to begin a discussion of deploying boundary scan to perform system test is to define what system test means and to distinguish it from board test, which is the more typical arena for boundary scan. The Webster dictionary defines a system as “a group of interrelated, interacting, or interdependent constituents forming a complex whole.” 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, if the Webster definition is applied, 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 for the task of the system itself, 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 and 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 would often require system experts 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, the 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?

There are four primary methods for implementing system test with boundary scan. Three 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.

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 expected to manage test access for each configuration of the system. Also, systems that may not have been designed with system-level testing in mind still can be tested as a system with this method.

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.

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, it must be designed into a system early in the design cycle, because BIST 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).

For a summary of advantages and disadvantages of the three external and the one embedded system test methods, see the table below.

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.

ScanWorks 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 hardware 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 hardware 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 through commands to 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. Much of the infrastructure is already in place. As a result, the payback for system-level boundary scan can be quite rapid because of the limited amount of development time that might be required to implement it on top of board-level boundary scan operations.