Optimizing the manufacturing test program, data collection, and diagnosis for yield analysis

Many sources of yield loss, including out-of-spec equipment, incorrect handling of material, photomask defects, design-process sensitivities, library marginalities, and test issues, can occur during semiconductor manufacturing. The challenge at nanometer geometries is to quickly identify what caused the yield loss so that corrective action may be instituted. A yield problem that is not quickly eliminated erodes product margins and may make the difference between profit and loss. Manufacturing test combined with diagnosis-driven yield analysis can hasten the discovery of the root cause of yield loss or reveal that a yield problem exists [1].

To simplify manufacturing test and the process of generating test patterns, design-for-test (DFT) structures, such as scan chains, are incorporated into digital semiconductor devices. When the device is in “scan” mode, sequential elements are configured into a shift register where data can be easily scanned in and out. This makes it easy to control and observe the circuit and facilitates automatic test pattern generation (ATPG).

Scan diagnosis leverages the DFT structures and ATPG patterns, along with the design description and fail information from the tester to identify the location and type of defect most likely to be causing failures. By using logical path tracing and simulation techniques, the diagnosis tools identify a ranked list of suspected defects. The quality of diagnosis results is typically measured by accuracy and resolution [2]. Scan diagnosis has long been a staple of physical failure analysis (PFA) labs and has more recently become a way of leveraging the design data for yield learning, a process called diagnosis-driven yield analysis (DDYA).

Implementing certain best practices helps the product engineer to get the most value out of DDYA at the lowest cost. The goals are to identify the defect mechanism that caused an excursion, identify a previously unknown systematic yield limiter, or pick the best die to submit to the PFA lab for root-cause identification. The main optimizations in any DDYA process include writing the test program, minimizing test time for the data collection, increasing diagnosis throughput, and reducing time spent performing the yield analysis.

Optimize the test program

Test program ordering is initially optimized for test-time reduction (TTR). In a TTR flow, the test engineer will try and make the die fail the fastest by applying the tests that have the highest fallout first. For this reason, scan testing is generally done very early in the test program and transition delay fault (TDF) testing is done toward the end of the test program (Figure 1).

Figure 1: A typical test flow will test the chain function first, then the stuck-at pattern set, and finally the various transition delay fault (TDF) pattern sets. An ideal data collection flow will follow this same sequence.

Yield analysis is simplified if the vast majority of devices analyzed are failing for the same pattern type (TDF or stuck-at fault). Also, different types of pattern sets affect diagnosis run time differently (TDF diagnosis taking slightly longer), so diagnosis run time is worth considering in the overall strategy.

It is important to be able to distinguish between how much of the yield loss is caused by chain failures and how much is caused by logic failures to see if there is a sudden change in the percentage of one or the other. This can be accomplished by collecting soft bin data in the test program. It is not uncommon for more than 50 percent of the scan failures to be chain failures during testing. If a systematic chain failure is suspected, diagnosis-driven yield analysis for chain failures can be applied to look for systematic failing chains, flop-types, or nets.

Die that only fail the TDF pattern sets will often be a small contributor to the yield-loss Pareto; however, because of their parametric nature, they may be a large contributor to the DPPM or reliability Pareto. The main concern is that a systematic population of defects may be causing the parts to be at the edge of the operating-condition specification. If the existence of this population is detected early through yield analysis, similar parts in the population can be flagged. Collecting this kind of data is a best practice, but it must be analyzed separate from the stuck-at failures.