Technique Closes the Loop on Test System Uncertainty

A version of this article ran in the December-January 2000 edition of Test & Measurement Europe. Download the article as a PDF.

To develop an effective guardband, you need to analyze your test equipment’s measurement uncertainty. Such analysis often uncovers subtle but consequential flaws in test, particularly in test of high-speed products that push ATE performance limits.

Traditionally, you may have employed a development process (Fig. 1a) in which you measure your ATE’s uncertainty on the production floor after you complete basic test design. Then, you may have taken these measurements back to your desk and used spreadsheet tools to analyze them.

Unfortunately, your analysis may indicate results so close to the guardband that the yield would be reduced to an unprofitable level. Assuming there is not a product design problem, then you have an accuracy problem (results too close to the test limit), a precision problem (guardband is too wide), or a composite. In any case, you then face the trial-and-error task of modifying your test design, waiting for production to let you have access to the ATE, taking more measurements in the factory, returning to your desk for more analysis, and so on. This experimenting is potentially the most painful stage in test development—the proverbial 5% of the work that takes 95% of the time.

The situation improves, however, when you perform uncertainty analysis at the tester on the fly—without repeated trips to the office (Fig. 1b). By building the capability/correlation tools into your test program or into a development shell, you can assess the statistical effects of your improvements as you make them rather than as the ATE user schedule permits.

Figure 1. Tester uncertainty measurement takes place after basic test-program development. (a--top) Traditionally, uncertainty analysis involves repeated trips from factory to desk as you acquire tester data, study it, and develop test improvements. (b--bottom) If you build capability/correlation functions into your test program, you can make improvements on the fly.

Building Uncertainty Analysis on ATE
You should develop your test program concurrently with the built-in uncertainty analysis functions. At Burr-Brown, I engineered this technique when developing the test process for the company’s AFE120X 0.5-micron CMOS analog front-end for interfacing a DSP system with the outside world through HDSL. The device’s on-chip 48x oversampling DS DAC and HDSL pulse generator mandated the use of sophisticated ATE while the projected sales volume pointed to a dollar advantage in employing a quad-site test. Therefore, I developed the test solution on Hewlett-Packard’s HP 94000 mixed-signal tester.

This technique requires collecting two data types. One type—for uncertainty analysis—results from sample parts tested over four configurations (30 units over four test sites in our evaluation). The other—for risk estimation—requires a small pilot lot (100 pieces minimum) whose distribution is evaluated against calculated test limits to see if any overlap (risk) exists.

After collecting capability/correlation data, you will want a way to graphically represent the data. Our program created text files formatted for the freeware Xgraph utility.1 Xgraph reads files and displays a line chart for each parameter. Figure 2 plots data for each of the 30 correlation units for the parameter ECHO9_DB, which is a measure of error in a reflected pseudo-random 2B1Q pulse sequence from an 11-V load.

An eyeball estimate of how well the four results line up provides a rough indication of your test’s capability. If your results seem random, you will need to improve at least that test, and therefore you needn’t waste time running the pilot lot. Note also in Figure 2 the presence of a box around the data representing the spec limits. The box serves as a visual frame of reference for evaluating the data at hand. Data lying outside the box would suggest you need to do some serious re-engineering of either hardware or software—no amount of uncertainty improvement would allow parts to pass the test for this parameter. (Displaying the limits on the chart is an improvement over the tool we normally use at Burr-Brown, an internally developed Excel macro that shows the data but not the limits.)

Testing Sample Lots
Even if your results line up well, the test isn’t necessarily optimal; you can, however, proceed to evaluate risk by testing the pilot lot. As in the correlation phase, our program generated text files for use with the Xgraph utility.

Figure 3 shows an Xgraph example of the distribution chart for the 120X_Power parameter—the total power dissipates while the DUT transmits at maximum speed and power. It shows these values:

• spec or data-sheet limits—the two tallest blue bars,
• calculated test limits—the next two tallest blue bars,
• ±3-s guardband—the short blue bars at the bottom of the graph,
• the normal PDF (probability density function)—the red bell curve, and
• a 64-bin histogram of the actual data—the green step plot.
  

  Figure 3. This Xgraph plot shows data-sheet limits (the tallest blue bars), calculated test limits (the two next tallest blue bars), the 3-s guardband (the shortest blue bars) the normal PDF (the red bell curve), and a 64-bin histogram of the actual data (the green step plot).

The histogram is useful because the normal distribution, being an approximation, doesn’t tell the whole story. For example, the power is always expressed as a positive number in this test, but for a wide distribution, it is possible for the tail of the distribution to extend past the origin into negative territory even though there is no chance of a negative result occurring. This feature is another improvement over our home-grown Excel macro approach that shows the distribution but not the actual data.

If any part of the PDF or histogram lies beyond the test limit, your test might reject some good parts. The area of this region is called profit risk. Profit risk is the complement of yield because it is the fraction of the lot that is not shipped whereas yield is the fraction of the lot that is shipped. A high profit risk lowers the yield.

If any part of the guardband lies outside the spec or data-sheet limit and if any part of the PDF or histogram lies outside the test limit, then a bad part might pass your test, a situation called customer risk. You want to keep customer risk at zero regardless of where the data distribution is, but you’ll also want to keep the test limit as high as possible (|spec| – 3 s) to maximize yield while maintaining quality.   

Our program creates a new limits file alongside the existing limits files using the new test limits calculated during the analysis. These are the same limits as shown by the shorter limit bars in Figure 3. If the results of the uncertainty analysis are acceptable, these limits may be selected in the test-condition set and used in production test. If the results are not acceptable, this limits file is overwritten the next time we perform analysis.

Our capability/correlation goal was to achieve a 6-s guardband that is at most 10% of the spec limit. You may not always be able to achieve this goal, but sometimes it’s not imperative, either. For example, if the test limit is 20% of the spec limit but all the test data lies well below this limit, then the large guardbands will not affect yield or risk.

In the case of 120X_Power shown in Figure 3, the guardband is better than 10%, and the distribution of actual data lies so far from the actual limits that there is no risk of yield loss. Sometimes there is an overlap between the distribution and the guardband, which means a lot of potentially good parts will be rejected (profit risk). Such was the case for another parameter where a plot like Figure 3 enabled me to decide if the results were inaccurate, or the guardband was too wide, or both, and to make an improvement and re-evaluate the uncertainty without having to return to my desk.

Improvements to Uncertainty Analysis
Our analysis functions enable a test engineer to realistically asses the situation less than a minute after the test program is unloaded from the ATE. Although the uncertainty-analysis tools we built into this program have proved efficient and useful, you might consider several possible improvements.

For example, the Xgraph files for the 77 tested parameters associated with the AFE120X program use a lot of disk space. You might consider providing a GUI that enables users to specify which parameters to analyze and which to skip. You might also want to provide a means for specifying which limits ought to be updates—our program automatically updated all of them, even though in some cases that’s not necessary. For example, PSRR in decibels often has a minimum limit but no maximum. For the AFE120X program, we just put in “140 dB” to fill the space. Any result greater than the minimum is a good result, so why guardband the high limit? It would be useful to have the capability not to update one of the limits.

Not every parameter can be modeled as a normal random variable, so you might want to consider letting the users specify how to approximate the distribution of each parameter. Of course, there are many different types of random variables, but the inclusion of a few choices would help in evaluating the risk for some situations. T&MW

FOOTNOTE
1. Xgraph is available from various Web sites, including www.cs.utoronto.ca/~radford/xgraph.html.   

Tony Zizzo, Jr., is a test engineer at Burr-Brown Corp.

Test System Uncertainty Basics You can use the normal random variable to model results of tester experiments. Its probability density function is shown here. Every measurement has an associated uncertainty. The important question regarding ATE solutions is “how uncertain is each measurement?” The answer is important in safeguarding against shipping a product that tests good but, because of measurement uncertainty, is out of spec. It is also important for product yield, because a conservative guardband will result in the ATE rejecting good parts. To determine how uncertain each measurement is, you can model each test parameter as a random variable. Then, you can find the mean (m) and variance (s2) to gauge the test performance. A random variable has the probability density function (PDF) represented by the bell curve of the figure. Here, m is equal to the expectation of the random variable X: The variance equals the expectation of the square of X minus the square of the expectation of X: To provide zero probability of shipping a bad device because of tester uncertainty, you would keep the random variable distribution within the specification band (shown in the figure as a multiple of s). Of course, you can’t do that because f(x) extends to infinity in each direction. So how much of the distribution extends below the specification? The probability P that a random variable will take on the values in the range [a, b] is Therefore, 99.73% of all events will happen in the 6-s range centered on zero [m–3 s, m+3 s] because Now, if f(x) is the actual distribution of a parameter over many measurements of the same physical property, and if the test limit is set 3 s below the spec, there is only a 0.27% chance that the part whose measurement passes just below the limit is just barely a failure. It remains to determine s from actual data. We take several known-good units, which we call corr (correlation) units, sample them over several configurations (possible production setups—for example, if you have two testers and two DUT boards, you have four possible configurations), and then estimate the standard deviation from the sample data. Use a minimum of 30 units over at least four configurations. For quad-site testing, you can use all four sites on one DUT board. Now, calculate sn2, the sample variance of one unit n over m configurations: Then use the unbiased estimator sn2 to calculate the target standard deviation stest from the biased estimator sn:   The correction factor c4 is a measure of the bias of the estimator stest: Now you can guardband the specification limits by 3 stest to set the new test limits: |Test Limit | = |Specification| – 3 stest You can improve the worst-case risk (0.27%) by using wider criteria such as 4 stest, but you risk losing yield.--Tony Zizzo, Jr.