Connect - ASSET InterTech

Unnecessary defects, which may not show up until a system is installed and has been operating for years, can be introduced into circuit boards during the test process. And, in many cases, test and manufacturing engineers don’t even realize they are having this effect because these defects aren’t accompanied by a mushroom cloud of smoke or capacitors popping. Still, unwarranted stress placed on components during test can shorten their useful lives and reduce the long term reliability of the system. In critical, high-availability applications, this could be an expensive proposition involving emergency repairs on the system and down-time that could have been avoided.

Backdriving in ICT

Anyone who has worked in test for very long is probably aware of the concerns that were raised when ICT was introduced and “backdriving” became a common technique. Backdriving is the “technique of temporarily overdriving component outputs to force a node to its opposite logic state.”¹ During the 1990s, many studies confirmed that backdriving on in-circuit testers was safe. The general consensus from these studies asserted that backdriving was safe and did not damage components as long as certain parameters were not exceeded. Problems can occur when the current flowing through the backdriven component causes thermal damage. The voltage applied to backdriven components can also cause transistor latch-up as a result of voltage spikes. Consequently, current and voltage must be carefully controlled during the backdriving process.

ICT systems test a printed circuit board (PCB) by testing each component on the board individually, as if it were the only component on the board. The strategy is to surround each component with physical test probes that isolate the component from the rest of the PCB. The inputs are driven to specific values and the outputs are monitored to make sure each output provides the expected response. But, for example, if an input on Device A can not be isolated from an output on Device B, then the ICT system must overdrive the input to Device A to establish the input level that is required by the test. The ICT very closely controls how long the active output on Device B is overdriven, how often it is driven and the voltage the ICT tester applies to it. To ensure that ICT tests are safe, some of the ICT vendors introduced certain features. Agilent introduced SafeGuard, for example, and Teradyne introduced SafeTest. These technologies, which are quite effective, ensure that components are not damaged during ICT PCB test.

Contention in Boundary Scan

Boundary scan testing can create situations where a condition similar to backdriving occurs. With boundary scan this condition is known as “contention.” Contention occurs when there are two active drivers attempting to drive different logic states on the same net. The result is very similar to ICT backdriving and the potential for damage to the unit under test (UUT) is significant unless safeguards similar to the ICT safeguards are built into the boundary scan test generation tools.

Boundary scan testing for shorts and opens is very different from ICT testing. With boundary scan the entire PCB is tested as a single unit instead of a component at a time. Typically, there is a mixture of boundary scan and non-boundary scan devices on a board, and there are usually connections between the boundary scan and non-boundary scan devices. During boundary-scan tests, the test system often uses boundary-scan devices to control and observe nets that are also connected to non-scan devices. When this happens, the potential for contention between these devices is very high.

In Figure 1, net N1 could be tested for shorts if the boundary scan cell on the device BS1 were a self-monitoring cell, allowing it to be both driven and observed by BS1. However, N1 is also connected to a non-boundary scan device, NBS1. Only if the ATPG tool is smart enough to know that the connection to NBS1 is an input pin can N1 be tested with no possibility of contention occurring. A model of NBS1 could inform the ATPG tool that the pin in question is an input, allowing N1 to be tested. But, as straightforward as this may seem, it isn’t good enough. The output pin on NBS1 associated with the driven input pin is driving net N2, which is connected to another non-boundary scan device, NBS2, and this device is connected to N3. In turn, N3 is connected to BS2 and some other pin, the nature of which is unknown because a device model is not available. The nature of the connection to BS2 is understood by the ATPG tool and, since it is a boundary scan device, this pin can be controlled as an input. Unfortunately, because N3 has an unknown connection, it must not be tested. And since net N3 cannot be tested, then nets N1 and N2 should not be tested unless they can be isolated from net N3. However, a smart ATPG tool like ScanWorks will know that device NBS2 can be disabled by net N4, which can be driven by a boundary scan device. If the output pin on NBS2 is disabled, nets N1 and N2 can be tested, but net N3 still should not be tested.

This example points out that NBS models should not only identify the device pin types (input, output, etc.), but the model should also identify enough functionality to determine whether a value driven on an input will propagate to the output and cause contention on other nets.

This is but one relatively simple example of the conditions that must be considered by a boundary-scan interconnect ATPG tool. Increasing levels of complexity will require increasing sophistication in the ATPG tool.

ICT Backdriving vs. Boundary Scan Contention

The major differences between ICT and boundary-scan test are as follows:

The obvious conclusion to this discussion is this: contention must be avoided. The obvious question is how best to do this. The not-so-obvious answer is a model-based ATPG tool for shorts and opens testing with boundary scan. And, of course, ASSET has the most sophisticated model-based interconnect ATPG tool available.

Interconnect Automatic Test Pattern Generation

An interconnect ATPG tool must have certain information to produce safe tests. This information includes:

All of this information must be provided in a format that is understandable by the ATPG tool. The usual sources of this information are typically CAD design files, netlists, bill of materials, and both boundary scan and non-boundary scan device models. Accurate information is critical for safe boundary scan testing. The old saying, “Garbage in; garbage out” applies. In this case, “garbage in” causes the boards being tested to become the “garbage out” when they are damaged by unsafe testing.

Netlists provide the information that identifies what devices are on a board and the connections between them. However, it does not identify any functional or test capabilities of the devices. That information is provided by models. BSDL (Boundary Scan Description Language) models define the boundary scan capabilities of boundary-scan devices. Non-boundary-scan models provide information about non-boundary-scan devices.

Once this information is available, the ATPG tool must use it effectively to perform the following:

High Coverage or Safe Tests?

ScanWorks’ interconnect ATPG tool creates coverage reports with information on which nets and pins are covered for shorts and opens and which are not. For nets and pins that are not covered, an effective ATPG tool should identify the reasons why there is no coverage and, if possible, offer suggestions on how to achieve it. The ATPG tool should also offer several easy methods for adding the information that’s needed for the tool to automatically regenerate tests with better coverage. This additional information typically involves non-boundary-scan models or establishing “constraints” in the tests for a certain design which are followed by the ATPG tools.

Some interconnect ATPG tools generate tests that seem to have high coverage, but upon further examination the engineers may find that the initial test generation process has assumed that all nets and pins that can be tested are indeed safe to test. Or, the report may indicate that some nets and pins may not be safe to test and suggest that the user manually determine whether they are safe or not. It is the user’s responsibility to resolve all potential contentions before proceeding. This is not only very time consuming but highly prone to error. Consider the example illustrated by Figure 1 above. When the ATPG tool warns that N1 may not be safe to test, how many engineers would notice that NBS2 must be disabled, especially if BS1, NBS1, and NBS2 are spread over several pages of the schematics?

Interconnect ATPG will always be an iterative process. Whenever new information is added, the output will change. Sometimes coverage will improve, but coverage could decrease if a new potentially unsafe condition is brought to light by the new information. A test with the highest coverage isn’t always the best test. The best test achieves the highest possible coverage with safe test vectors.