An Update on Using Boundary Scan for System-Level Test Integration

Boundary scan and other design-for-testability techniques play an increasingly important role in today’s system-level test integration. Since the availability of components and tools has grown over the past year, these techniques are becoming more popular. The feasibility of a hardware infrastructure consisting of boundary scan has fueled the system-level test capability that promises to bring advantages to both the system designer and the end user.

The fundamental requirements for building this infrastructure consist of three elements:

A mechanism for deploying the IEEE 1149.1 communications protocol throughout the system.

A means of re-using test vectors.

A means of deploying and manipulating these vectors in the system itself.

System Infrastructure

Building the system infrastructure involves creating both a means of controlling and executing the system-level tests in hardware and a communications infrastructure to deploy the tests throughout the system. Figure 1 shows the basic elements required to assemble such a system.

The test master or controller consists of intelligence and conversion functions. A microprocessor and memory for storing both the executable code and vectors serve as the intelligence function. The conversion function consists of a device intended to convert the parallel data from the processor into the serial protocol of IEEE 1149.1.

The microprocessor is the central control location for execution and result reporting of the testing process. It contains knowledge of the system configuration, the desired test plan and the expected results.

The conversion function is easily handled by several devices currently on the market. These devices usually can convert parallel commands from the processor into the serial string of commands understood by the test access port (TAP) controller in IEEE 1149.1.

Building the communications infrastructure requires a means of transporting IEEE 1149.1 in either a multidrop or a hierarchical fashion. Some methods have been tried, including long serial chains and multiplexed architecture, but they have limitations that make them undesirable for system-level implementation. A system-level implementation should allow the user to test several boards simultaneously or execute built-in self-test (BIST) on one board while reading test results from another.

A serial chain can be built by connecting the Test Data Out (TDO) pin of one board across a backplane to the Test Data In (TDI) pin of the next board. While this configuration can work, it has severe limitations.

One problem is the length of the resulting chain. Long chains slow down the testing process and can make diagnosis a cumbersome process. It may be necessary to repeat a test several times over many clock cycles to diagnose an error at the end of a long serial chain.

Perhaps the more severe limitation is removing boards from the system. This renders the test bus useless by breaking the serial connection.

A multiplexed scheme may also be used where the TDI and TDO pins are multiplexed to each board and the Test Mode Select and Test Clock pins are run in parallel. This scheme is really nothing more than a switch that allows the user to test a single board while it is in a system. It provides none of the benefits of parallel testing that should be expected from a system-level implementation. Also, the number of backplane pins required to implement this grows linearly with the number of boards in the system.

Another scheme consists of placing an addressable 1149.1 device, such as the National SCAN PSC110 Bridge, on each board. With this type of component on each board in the system, a simple mechanism is available for accessing multiple boards. When selecting or designing this type of component, it is important to consider its compatibility with the 1149.1 standard, its ability to multitask the test process, and its ability to off-load some of the sequencing operation from the processor.

The hierarchical aspect of this configuration is useful when you build systems that require multiple levels of integration. A good example is when a board is assembled into a subsystem and then multiple subsystems are combined to form a complete unit. In this scenario, the integration process can be simplified if tests generated at each manufacturing stage can be re-used at subsequent integration stages without regeneration. This is possible if hierarchical 1149.1 test structures are built that can communicate at different levels without additional software translation.

This hardware infrastructure, in conjunction with a growing list of components that support boundary scan, will enable new applications of this standard. In addition to testing, some of the standard’s most useful applications include design emulation, design debug and field service remote access. Embedded SoftwareSoftware has several roles in the system integration of boundary scan test. Figure 2 shows the process. Ideally, this software should be purchased rather than customer-written. Purchasing the software allows the manufacturer to focus on critical functional aspects of the system rather than the standardized embedded test-control software.

The first role of the software is to compress and configure tests generated by board-level automatic test-program generation (ATPG) tools into something that can be stored efficiently in memory. This process is required because vectors generated by board-level ATPG are lengthy due to their ASCII format and pin-level rather than command-level descriptions.

The process begins with patterns generated from standard ATPG tools. Most of these tools code their vectors in a proprietary format, making conversion to other tools and applications difficult.

Serial Vector Format (SVF) has been offered as an industry standard by Texas Instruments and Teradyne. SVF can be used to transfer vectors between a variety of test platforms. Most test systems use a proprietary means of encoding test vectors, making it difficult to share vectors created in one system with another.

The SVF makes it possible to create the patterns in one environment and re-use them in others. It is finding common use and is supported by most test tools as a common input and output point.

From either of these entry points, software is required to strip out the unnecessary information included in the ATPG vectors and compress the vectors for storage in memory. Embedded Vector Format (EVF) developed by National Semiconductor compresses test vectors for storage in the test master.

For the user, this is a significant development. EVF compression can reduce the size of test vectors in vendor-specific format or SVF by up to 80%, making it feasible to store and execute those vectors from the system test master.

EVF also allows the test engineer to define specific system configurations that should be tested by the embedded test controller. Some common configurations could include backplane interconnect testing, parallel testing of redundant boards, or execution of BIST on multiple boards.

After the vectors are compressed and stored, a test plan must be developed and executed from the test master. In this process, the test engineer will determine how the tests should be configured and create a final set of embedded vectors to deal with the desired hardware configurations.

Different tests will be developed for different configurations of the hardware. For example, one test set may execute tests for the backplane while another may execute simultaneous parallel testing of similar boards.

Once the configurations have been determined and the test executed, some additional action may be needed. In most situations, simple go, no-go testing is adequate to determine system integrity. If a problem is found, more extensive testing may be required.

New test plans can be remotely loaded into the test-master’s local vector storage for more exhaustive testing. If the hardware is reconfigured in the field, then new test plans can be loaded from a remote communications link.

Future Considerations

Several other developments may be on the horizon to take this technology even further. The first is the use of in-system programming techniques to configure programmable devices after they have been placed on the board. This provides several advantages.

In manufacturing, significant cost savings can be found. Today, products must be programmed and placed in inventory before being soldered onto the board. This is costly since the inventory is difficult to manage.

It is quite easy to place the wrong component in a socket. In-system programming via the Joint Test Action Group (JTAG) port promises to eliminate the trouble by delivering the programming algorithm through a standard port after the part has been soldered on the board.

In-system programming will also enable new design-related benefits. By connecting the in-system programming products to the system-level embedded structure, access to system reconfiguration from remote locations is possible. This will allow simple system changes to be installed quickly and easily.

This system infrastructure also becomes an integral part of the system. The architecture described in this article presumes that a resident test master exists somewhere in the system.

In the future, the test master will likely come under greater control of the central processor. The issue will then revolve around how the central processor communicates with the test processor.

Some alternatives for this communication include the 1149.5 standard and other standard communications protocols such as Ethernet. Time and experience will tell which of these alternatives finds widespread use.

About the Author

Gary O’Donnell is the Market Development Manager for National Semiconductor. He joined the company in 1982 as a Test Engineer, and later worked in Quality Assurance. Mr. O’Donnell has a B.S.E.E. degree from Purdue University and an M.B.A. degree from the University of Southern Maine. National Semiconductor, 333 Western Ave., South Portland, ME 04106, (207) 775-8707.

September 1996