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 is defined in IEEE Std. 1149.1.
Boundary scan was developed to test IC interconnects on PWBs 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 which 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 irregardless of the cost/benefit trade-off.
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 which 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 systems designs ranged from less than 30% for a thru-hole board to over 90% boundary scan for a parallel processing multi-chip 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.
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 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, multi-chip modules, etc. Some functions may only be testable or isolatable 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, making troubleshooting and repair unrealistically expensive.
Finally, adding boundary scan to select areas is justified in order to test complex or critical functions which are "pattern expensive". This includes functions which are difficult to test because of physical or structural inaccessability. 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 scannable components can be substituted to directly control the nets surrounding the decoder, therefore providing a more direct test with better fault isolation.
Boundary scan based tests, while providing many internal "virtual" test points, requires 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 serial 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 which 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 which 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 which 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 which are testable by different boundary scan tests.
Figure 1. Nets Testable via Boundary Scan Tests
The ideal way to increase boundary scan test fault detection is to add or substitute more boundary scan components so the percentage of boundary scannable 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 you have.
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 which 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 which 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 had to be completed. First, the original boundary scan tests must be translated into a format which would 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. Boundary Scan Test Enhancement
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, using the same boundary scan ATPG stimulus, after the logic simulator predicted new response data, resulted in 81% fault detection; an 11% improvement. The 11% improvement represented non-boundary scan active and passive components which 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 scan tool. 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, design verification, and ATPG boundary scan tests.
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 which boundary scan has provided.
TI Home
Search
Semiconductor Home