System Design

Optimizing Fault Detection for Boundary-Scan Testing

Integrating with the automatic test generation tools can improve test coverage.

by Wayne Daniel

Introduction By now, many engineers have used or are aware of boundary scan. If not, they probably will become aware of boundary scan because most new processors and, according to one ASIC vendor, about 60% of new ASIC starts incorporate boundary scan. Boundary scan is a structured test technique where a shift register and latch are placed at the functional I/Os of an IC. Each I/O pin can be driven to a known state or the current logic level can be captured and scanned out via a four-wire serial bus. The test bus and protocol as well as the behavior of the boundary cells are defined in IEEE Std. 1149.1.

Boundary scan was developed to test IC interconnects on PWBs (printed wire board) when physical access is impossible, difficult, or impractical. As IC pin counts increase, pin spacing decreases, and pin accessibility disappears. Boundary scan is playing an increasing role in design verification, manufacturing, and the testing of new products. Studies have shown that, for surface-mount boards, 75% to 95% of manufacturing faults are caused by solder opens or shorts. Of course, to maximize the benefits of boundary scan, it must be optimally designed into the product. There are usually two factors that determine the required amount of boundary scan designed into a product: 1) test equipment costs, test development costs, test execution time, and fault isolation requirements justify the cost of adding boundary scan; and/or 2) lack of physical access may require boundary scan regardless of the cost/benefit tradeoff.

For whatever reason, if boundary scan is implemented in a product, it is paramount that planning be done at the system level because it primarily benefits PWB and system test. Most products that utilize boundary scan do not contain 100% boundary-scan ICs due to either availability, cost, or other reasons. For example, a survey of the percentage of boundary-scan nets on several TI defense system designs ranged from less than 30% for a through-hole board to over 90% boundary scan for a parallel-processing multichip module. In each case, the percentage of boundary scan implemented was driven by technology, manufacturing needs, and customer fault detection/isolation requirements. By intelligent planning, partial boundary scan can be used to test or assist in testing significant portions of non-boundary-scan logic.

Smart boundary-scan implementation Test effectiveness can be maximized by strategically selecting which functions or partitions should contain boundary scan. In addition to considering physical-access limitations, one should also determine what other test priorities are important for the product. Typically, boundary scan is added to selected areas in order to provide the most coverage vs. cost, reduce fault ambiguity, or to verify difficult-to-test functions of the PWB.

Implementing boundary scan on buses and logical partitions is practical because of the high number of devices attached to common nets. Typical candidates include processor data and address buses, memory address and data buses, I/O buses, and critical control and observation points. Not all components on a bus must have boundary scan in order to realize benefits. For example, if boundary-scan buffers and transceivers are implemented on a memory bus, then memory interconnect tests can be performed without having boundary scan on the memory devices. Don't overlook adding boundary scan to control-critical signals such as chip select, read/write, and clocks.

Another motivation for adding boundary scan to selected functions is to test or isolate expensive ICs or high ambiguity areas. Examples include processors, ASICs, daughterboards, hybrids, multichip modules, etc. Some functions can only be tested or isolated when used with other glue logic or support chips. While it may be possible to create a test to provide adequate fault detection, a large fault ambiguity group may result, thus making troubleshooting and repair unrealistically expensive.

Finally, adding boundary scan to select areas is justified in order to test complex or critical functions that are "pattern expensive". This includes functions that are difficult to test because of physical or structural inaccessibility. For example, the interconnects of an embedded decoder IC may be testable by propagating thousands of test vectors through other logic partitions, but the test patterns may require several man-weeks to develop and significantly increase the PWB test time, resulting in a large ambiguity group. However, boundary-scan components can be substituted to directly control the nets surrounding the decoder, therefore providing a more direct test with better fault isolation.

Developing boundary scan-based tests Boundary scan-based tests, while providing many internal "virtual" test points, require data to be formatted in serial form in order to shift in stimulus and shift out response data. This can be tedious if an engineer must write more than a few serial test vectors by hand. Fortunately, there are automated tools to handle this tedious task. Tools are available to automatically generate a boundary scan-based PWB interconnect test, serialize and apply parallel vectors to an embedded logic cluster via boundary scan, and allow serial boundary-scan test development using a parallel test paradigm.

The easiest, and probably the most cost-effective, method of generating boundary-scan tests is by using a boundary-scan interconnect Automatic Test Pattern Generation (ATPG) tool. These tools read in a PWB netlist, the IC Boundary Scan Description Language (BSDL) files, and device characterization files to automatically generate test vectors that detect and, in some tools, isolate faults between boundary-scan ICs. Typically, the test vectors are very compact (<30 boundary register scans) and very effective (100% of boundary scan-to-boundary scan nets).

Unfortunately, for most products, it may not be possible to implement 100% boundary scan due to cost and/or IC availability. Therefore, boundary-scan ATPG tools may not provide 100% fault coverage of all nets. In addition, boundary-scan ATPG tools may not generate vectors to test simple non-boundary-scan components such as series resistors, connectors, switches, and in some cases pull-up resistors and pull-down resistors. Also, most boundary-scan ATPG tools will not test components such as buffers, combinatorial logic and sequential logic between boundary-scan nodes.

Some boundary-scan tools support application of parallel oriented tests to embedded logic clusters that are surrounded by boundary-scan ICs. This opens up the opportunity to apply and reuse tests generated during simulation, design verification, and manufacturing. Of course, this requires some up-front planning to ensure that boundary scan is designed in to control and observe the targeted logic clusters. Fault detection and isolation can be significantly improved using this method. Even if test vectors are not "available", test effectiveness, as well as cost effectiveness, can be greatly improved by utilizing a boundary-scan tool that allows test development and application using a parallel paradigm. These tools let you think in parallel even though the tests are actually performed serially. Figure 1 shows typical nets that are testable by different boundary-scan tests.

Figure 1. Boundry Scan can detect faults in the various sections in a system.

Increasing boundary-scan fault detection The ideal way to increase boundary-scan test fault detection is to add or substitute more boundary-scan components so the percentage of boundary-scan nets increases, thereby increasing boundary-scan ATPG coverage. However, if the product design is complete or there are no remaining options to add additional boundary scan, one must work with what one has.

If the hardware is fixed, the typical solution is to add more test vectors. Depending on the boundary-scan tools used, this can result in significant increases in boundary-scan fault detection or potentially a complete waste of time. Generating serial vectors by hand can become very inefficient and ineffective after a short while.

There are several methods to increase fault detection using existing stimulus vectors. A simple, but not always easy way is to apply the existing serial test vectors to a "golden" (known good) system and capture the response data. Then the captured response data is merged with the original stimulus to generate a new test. Depending on the test (and how it was generated), usually additional nets are covered since the hardware generates the response data (which is now the new expected data). The problem is that some (sometimes many) boundary-scan cells capture unstable or non repeatable values that must be masked in the new expected data. Depending on the target, this may involve anywhere from few bit changes to hundreds of bit changes. Also, it may take many iterations to determine all of the bits that must be masked. This method should only be attempted as a last resort or as a quick fix since it may not yield acceptable results.

A more effective method is to use logic and fault simulation to increase boundary-scan fault detection. As an experiment, we decided to perform pin-level fault simulation on the boundary-scan tests to determine their effectiveness. As a side effect of the fault simulation, we realized that the logic simulation of the circuit would predict the signal values on all nets, even those which contain non-boundary-scan components. If we then replace the original boundary-scan ATPG-predicted outputs with the logic simulator-predicted outputs, the fault coverage should increase with the same stimulus. This same technique can be applied to all boundary-scan tests.

In order to accomplish the simulation tasks, several operations have to be completed. First, the original boundary-scan tests must be translated into a format that will be accepted by the logic/fault simulator. Next, the fault simulation is performed with the original stimulus/response vectors to establish a fault coverage baseline. A logic simulation is then performed using the boundary-scan vectors as stimulus for the circuit and the logic simulator predicting the new response data. The new response data is fault simulated to determine the new fault coverage. This flow is shown in Figure 2.

Figure 2. The design flow to enhance the original boundry-scan test coverage.

A PWB test case consisted of 20 ICs ranging from 8 to 177 pins. All ICs except one used surface-mount packages. Although the PWB incorporated a significant amount of boundary-scan components, only 52% of the nets had devices with partial or full boundary scan. Boundary-scan ATPG only resulted in 70% fault coverage of all nets. However, after the logic simulator predicted new response data, using the same boundary-scan ATPG stimulus resulted in 81% fault detection; an 11% improvement. The 11% improvement represented non-boundary-scan active and passive components that were being stimulated by the boundary-scan ATPG vectors, but could not be predicted without complete models and logic simulation. The remaining 19% of faults were targeted by design verification vectors from simulation and manually generated test vectors using the Asset Boundary Scan Tool from ASSET InterTech, Inc. (Richardson, Tx.). During manufacturing, data was collected to determine the actual effectiveness of the boundary-scan tests. Results indicate that 97.5% of the actual manufacturing faults were detected by the manually generated test vectors, design verification, and ATPG boundary-scan tests.

Conclusion Simply adding some amount of boundary scan can improve the fault detection and fault isolation of a product. However, smart boundary-scan implementation and utilization of design tools, including both boundary scan-aware and traditional non-boundary scan-aware tools, can significantly improve results. More than one project has been saved by the test, debug, and troubleshooting capabilities that boundary scan has provided.

Wayne Daniel develops new products for Texas Instruments' Semiconductor Group. He has developed embedded test hardware and software for TI defense and commercial programs for over 10 years.

To voice an opinion on this or any Integrated System Design article, please e-mail your message to: michael@asic.com.

integrated system design  September 1995