Beyond at-speed
A new method for creating faster-than-at-speed tests can detect small delay defects in all circuit paths of 130-nm devices.
Martin Amodeo, Cadence Design Systems, and Bruce Cory, nVidia -- Test & Measurement World, 11/1/2005
![]() |
| READ OTHER NOVEMBER ARTICLES: Table of contents, Nov. 2005 NOVEMBER FEATURES: |
As feature sizes have decreased, and as processes have changed (as exemplified by the industry-wide move to copper), the importance of structural delay test has increased greatly. Defects that cause increased delay, such as resistive opens, have become more common.
These defects are difficult to detect with single-clock (stuck-at-fault) patterns, because they don't tend to affect the overall logical results of a circuit. Some of these defects can be observed with IDDQ patterns (for example, bridging defects between power and ground), but faults detected this way are difficult to isolate and diagnose. Moreover, relatively high background leakage currents in newer designs even make IDDQ detection difficult. At-speed functional patterns offer a possible solution, but they are difficult to create and are not necessarily robust enough for high test coverage.
To detect delay defects effectively, the industry is migrating toward structural delay tests. We have found, however, that the quality of such patterns depends on the slack in the paths over which a fault is propagated and ultimately observed. Too much slack from a small physical defect to its observation point can make the defect impossible to observe, because the slack will allow extra time for the fault-induced slow transition to settle out to the expected value.
At-speed delay testsDelay-test-generation algorithms based on controllability and observability estimations tend to generate test patterns down the easiest and most accessible paths; these algorithms test for transitions at the system clock speed. The paths these algorithms select also tend to be either the shortest paths or the ones with the greatest amount of slack when running the clocks at system speed.
If a pattern generator marks off a fault effect as "tested" down one of these short paths, the generator won't attempt to evaluate that fault again to observe it down a longer path. Therefore, small defects can escape, even though they were nominally "detected" with the pattern set.
![]() |
| Figure 1. The effects of a fault at location A could be observed at location B or C. An automatic test-pattern generator would most likely choose the easier, short path to C, but slack in that path may hide the defect. |
Random fill and serendipitous fault mark-off present a similar problem, because faults are marked off with no regard to the amount of slack in the paths through which they were observed. This again leads to higher nominal coverage, but the quality of that coverage is neither determinable nor guaranteed.
To work within the constraints of existing test software (and its tendency to observe and mark off faults down short, noncritical paths) and eliminate the slack down these paths (removing the possibility of test escapes), you can use a new technique that tests chips at faster-than-system speeds.
Faster-than-at-speed delay testsA fairly straightforward way to address the problem of slack is to create patterns with as much of the slack removed as possible. Assuming you make no changes to the test-generation or fault-simulation algorithms, increasing the clocking speed of the test patterns removes slack.
In other words, this method will still test the short paths, but it will test them at higher speeds. To use this method, you must determine a range of appropriate clocking speeds that will permit a majority of the paths on the part to be measured with as little slack as possible. You can determine this range by getting a distribution of path lengths in the circuit for each clock domain.
Once you determine the frequency range, you need to generate test patterns to run at these various speeds. You must choose an interval between each frequency gradation as well. These intervals can re-introduce the problem of slack, but you can choose intervals that are small enough to keep slack to a minimum. Ideally, the test generator will automatically create tests for each transition with the minimum possible slack.
Figure 2 demonstrates that in order to create patterns at various speeds that work on real silicon on a tester, the flip-flops fed by paths that cannot operate at these faster-than-system speeds must be instructed to measure Xs (don't care states). This will harm fault coverage, but it will guarantee that your choice of frequency interval—and no other factors—will determine the maximum slack value. It will also guarantee that any serendipitous fault mark-off that occurs will be down paths with the desired amount of slack, since all others will be measuring X.

Figure 2. Faster-than-at-speed testing removes slack along the path from A to C and permits detection of a fault at A. For this testing to succeed, however, flip-flops on longer paths must be masked.
One way to automate the generation of faster-than-at-speed tests is to use circuit-timing knowledge to both generate the faster-than-at-speed tests for the shorter paths and mask off the longer paths as required. The timing information can be made available to the automatic test program generator (ATPG) engine from the Standard Delay Format (SDF) timing data from any industry-standard timing-analysis tool. The ATPG engine can internally "time" the patterns and determine which flip-flops are fed by paths that do not meet the required timing. It can then automatically mark these flip-flops to measure X in the pattern set.
The test-generation algorithm should first create the patterns that have the fastest frequencies, followed by slower frequencies. The test coverage is accumulated as the test generation progresses. In this way, faults are marked off as tested at the highest frequency at which they can be observed, and subsequent test-generation runs do not attempt to test these faults down slower paths, saving test-generation and simulation time.
Sample implementationWe conducted a study using this test method on a 130-nm graphics processor. We generated approximately 27,000 two-clock delay test patterns, achieving 85% transition fault coverage. These patterns were run at functional speed. Despite using this robust set of patterns, we still found some failures at system-level test.
![]() |
| Figure 3. The distribution of path slacks on a 130-nm device shows that about half the paths have slack in excess of 1 ns, making the device a good candidate for evaluating a faster-than-at-speed test approach. |
One (among several) of these chips was found to fail system-level test, referred to here as chip X. Chip X passed the robust set of 27,000 at-speed delay test patterns, in spite of its relatively high fault coverage. We'll refer to this as pattern set P1. An additional 1000 test patterns, pattern set P2, were timed to just over 2X the functional clock speed (detecting somewhere in the neighborhood of 13% of delay faults).
We fault-simulated pattern set P2 on top of the coverage marked off from pattern set P1, and showed no additional faults marked off. This shows that pattern set P1 had tests for all of the faults that are covered by pattern set P2, so the main difference between the two pattern sets is the speed at which the patterns can be run on the tester.
We created pattern set P2 using an SDF file generated for the worst-case corner—low voltage and high temperature. The actual tester conditions were not as poor as the conditions governing the creation of the SDF (lower temperature and higher voltage), so we scaled the delay data linearly until the test patterns began working on the real silicon at their rated speeds. This information had to be calibrated correctly so that the flip-flops that could not be measured at the rated speed could be masked. Empirically, the SDF data, created for conditions of 1.08 V and 125°C, successfully approximated the test conditions (1.1 V to 1.6 V, 110°C) when we scaled the data to 95% of its values.
Once we achieved good correlation on the timing information for a known-good part using this linear scaling, we applied the patterns with confidence to the failing part, chip X.
Implementation resultsOverall, the results from our example implementation showed that pattern set P2 was able to detect the failure mode that was detected at system-level test, but that pattern set P1 running at system speed did not detect the failure mode. The fault or faults that model the physical defect in chip X must have been marked off as tested down a short path (faster than functional speed, with enough slack to make the defect unobservable) in pattern set P1. Pattern set P2 also tests for the defect down a short path, but this pattern runs at a higher speed so the delay defect can be observed.
![]() |
| Figure 4. A delay defect on chip X caused it to begin exhibiting failures at 1.7X the clock frequency at its 1.33-V nominal operating voltage. A good chip tolerated a 2X clock even at 1.1 V. |
Pattern set P2 started detecting the failure at approximately 1.7X the functional clock speed at nominal voltage (1.33 V). The defect was determined to be a region of the chip that added approximately 500 ps of extra delay to any transition passing through it.
Figure 4 shows the difference in performance of a good chip and chip X running pattern set P2. The lines are the thresholds at which the chips begin to fail. This illustrates the relative delay that is added to a path through the defective area of the chip.
The implementation of this test method on a real device experiencing system failures has demonstrated that running faster-than-at-speed tests will detect test escapes from at-speed tests. Running only a robust set of at-speed transition test patterns is not adequate to achieve the desired product quality. In addition, our implementation demonstrates that you need test pattern timing information in addition to the test coverage percent metric to gauge how well the delay test can detect defects.
| Author Information |
| Martin Amodeo is a product engineer on Cadence's Encounter Test team, specializing in delay test applications. Prior to joining Cadence, he worked on the IBM test team as a developer for delay-test ATPG. He has a BS in computer engineering from the Rochester Institute of Technology. |
| Bruce Cory is the group manager of nVidia's design-for-test methodology group, which focuses on developing techniques to help increase chip margins and reduce the cost of manufacturing test while maintaining quality. |






















