Global TMW:
Login  |  Register          Free Newsletter Subscription
Subscribe
Email
Print
Reprint
Learn RSS

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:
Bringing home the data
Beyond at-speed
Protecting the tester
VoIP complicates test
Sometimes, analog is better

Traditional scan-based at-speed delay tests attempt to check for transitions at the system clock speed. For chips designed at 130-nm nodes and below, at-speed tests are no longer sufficient for detecting small delay defects in many of a design's paths. You can, however, employ a new method for creating faster-than-at-speed delay tests that are able to detect small delay defects in all circuit paths, as evidenced by the results we obtained by applying the technique on an nVidia 130-nm chip.

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 tests

Delay-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. 
For example, in Figure 1, assume there is a defect at location A. A typical test-generation algorithm will test for this defect down the shorter path on the bottom because it is far easier. Yet, a small defect would have a much higher chance of detection down the longer path on the top.

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 tests

A 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.  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. 
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.

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 implementation

We 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. 
We ran a static delay analysis to determine the slack (assuming a clock running at system speed) per unique path on this chip, within the main clock domain; the results are shown in Figure 3. Note that about half of the paths have a slack in excess of 1 ns. This chip made a particularly good candidate for these experiments because so many of the paths have a high degree of slack. Having numerous short paths increases the odds that a fault effect can feed both a short path and a long path.

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 results

Overall, 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.

Email
Print
Reprint
Learn RSS

Talkback

We would love your feedback!

Post a comment

» VIEW ALL TALKBACK THREADS

Related Content

Related Content

 

By This Author

There are no other articles written by this author.

Sponsored Links



 
Advertisement
SPONSORED LINKS

More Content

  • Blogs
  • Podcasts

Blogs

  • Martin Rowe
    Rowe's and Columns

    July 22, 2008
    Disposable test equipment
    While visiting a company for an upcoming T&MW print article, I heard an engineer talk about high...
    More
  • Martin Rowe
    Rowe's and Columns

    July 16, 2008
    Oscilloscope frustrations
    The other day, a reader e-mailed me about his oscilloscope frustrations. "I use my oscilloscope...
    More
  • » VIEW ALL BLOGS RSS

Podcasts

Advertisements





NEWSLETTERS

Click on a title below to learn more.

Test Industry News (3 Times Per Month)
Machine-Vision & Inspection (Monthly)
Communications Test (Monthly)
Design, Test & Yield (Monthly)
Automotive, Aerospace & Defense (Monthly)
Instrumentation (Monthly)
Resource Center E-Alert (Monthly)
©2008 Reed Business Information, a division of Reed Elsevier Inc. All rights reserved.
Use of this Web site is subject to its Terms of Use | Privacy Policy
Please visit these other Reed Business sites