21.1 Systematic Test Fails

During wafer testing, the set of failing dies may indicate that a systematic defect is present. As described in Section 19.7, test diagnostic procedures are pursued in an attempt to localize and determine the root cause of a defect. The ATPG tool flow is exercised in diagnostic mode, using the failing pattern syndrome to identify candidate faults. Physical locations on the die (and masks) are cross-referenced to the candidate faults for further investigation.

After wafer testing, good dies will be packaged and (likely) subjected to burn-in stress to screen infant fails. After (static or dynamic) burn-in, parts are retested. If there is significant population fallout at package testing, diagnostics are again pursued; in this case, however, a greater number of potential defect sources needs to be considered. The source of stuck-at, transition, or bridging fault identification could be due to defects accelerated by the burn-in stress conditions, including the following:

• “Weak” device gate oxide breakdown

• Device parameter drift (e.g., due to the presence of material contaminants, whose diffusivity is increased at elevated temperature and voltage)

• Material interface delamination, with structural cracks and/or permeability to humidity exposure (most often occurring at the interface between the die and the underfill material that seals the die to the package substrate)

• Die attach metallurgy fails (e.g., solder bump cracks or lifted bond wires)

For the root causes of these defect mechanisms, unique diagnostic techniques are applied. Subsequent sections of this chapter discuss methods of monitoring electrical parameters. For investigation of material defects, the package is removed, and high-resolution electron microscopy of the surface and/or cross-section of the die is performed.

The final stage of SoC bring-up testing occurs during end product evaluation. Fails that arise at this level are not typically related to die fabrication or assembly defects—hopefully burn-in screening has identified those issues—but rather to functional validation escapes or test escapes in the SoC methodology.

A validation escape implies that a feature of the SoC functional specification is incompletely or incorrectly designed, and SoC validation testbenches were insufficient. System software compiled to that specification likely uncovered the error. Product bring-up may be able to proceed if a software workaround is available or if it is possible to disable a feature; indeed, micro-architects may explicitly add disable signals to configuration registers in the SoC design for new features that are especially high risk. (These disable signals are commonly referred to as chicken bits.) The SoC bring-up team is tasked with assessing the impact of product failure on the logic design, validation testbench development, physical power/performance/area resources, and schedule. The product marketing group needs to evaluate this assessment against the value of the associated feature. Assuming that the validation escape has been detected as part of first-pass product bring-up and that a subsequent tapeout has been included in the SoC project plan, the overall impact should be manageable. However, if the SoC specification has experienced feature creep during development—that is, if new requirements have been added to the original specification late in the project design schedule—the risk of a validation escape on the last planned tapeout is higher. Assessing the trade-offs between the cost of another tapeout and the value of a differentiating feature requires challenging product management decisions.

Whereas a validation escape is pervasively evident at product bring-up (i.e., an SoC feature does not behave as expected), a test escape relates to a small population of bring-up parts with a fabrication or assembly defect that was not detected by the wafer/package test pattern set. The impact to the overall bring-up activity is usually small. (Ideally, the SoC on the bring-up board is socketed, and another prototype part is substituted for the defective part with the test escape.) The SoC test engineering team is responsible for fault diagnosis—not using the failing syndromes at the tester but with product runtime information on how the part with the test defect behaves differently than the population of good parts. The capability to breakpoint system functional operation and enter an SoC scan-shift test mode to observe runtime register data is extremely valuable in this regard; this is commonly referred to as a functional scan dump of the SoC internal state. The SoC test team is tasked with augmenting the existing test patterns to demonstrate that the test escape is covered; this may involve adding functional patterns to the patterns provided by the ATPG tool for the SoC DFT architecture.

21.2 “Shmoo” of Performance Dropout Versus Frequency

In addition to functional product testing, another bring-up task is evaluation of the performance of the prototype part distribution. The SoC design will have been subjected to static timing analysis at several “slow” process corners related to performance-limiting device and interconnect variations during fabrication. Path timing will have been closed at those corners to a target sigma of the process statistical distribution.

A sweep of the SoC clock frequency is applied to the parts during bring-up to evaluate correct functionality versus frequency. The cumulative distribution of pass/fail versus frequency in silicon is informative, as it should confirm the statistical variation design models. This distribution also offers insights into the percentage of parts that may be available in various performance bins, operating at a frequency higher than the baseline spec, as illustrated in Figure 21.1.

Bring-up may also involve a two-dimensional sweep to evaluate the functionality of a part population over ranges of applied voltage and frequency. An example of a two-dimensional pass/fail graph is provided in Figure 21.2; this plot format is familiarly known as a shmoo plot. Note that a shmoo plot is applicable to testing a single part, although it is most commonly used to represent a larger sample of the part population. It is also common to normalize the scale of the voltage and frequency axes, where 1.0 is the nominal value. Note that the voltage range on the shmoo extends beyond the published (VDD + n%) tolerance range specification.

The bring-up data may be used as part of a dynamic voltage and frequency scaling (DVFS) product strategy, in which the SoC may support performance boost or (power-saving) throttle operating modes, with VDD changes coming from a voltage regulator.

There are some limitations with the traditional bring-up performance characterization methods. A statistically significant volume of parts needs to be measured to provide confidence in the binning and DVFS product strategies. The number of distinct power and clock domains on current SoC designs is large (and growing). For example, bring-up evaluation of large SRAM arrays may focus on a specific operating VDD_min for the arrays, using a distinct voltage domain from other IP. As a result, quickly and concisely capturing shmoo data for multiple domains during bring-up is becoming more difficult.

The specific circuit methods used to measure shmoo data also present an engineering challenge. Traditionally, the statistical fabrication parameters for an individual bring-up part would be adequately represented by a single, distinct measurement circuit added to the SoC design. A performance-sense ring oscillator (PSRO) circuit would be integrated, and the oscillator frequency would be measured as part of bring-up testing. (Reference 21.1 provides a description of methods to efficiently implement a PSRO frequency counter/decoder.) The tracking of fabrication variation across the die implied that the oscillator frequency would be representative of the overall SoC performance. For advanced process nodes, the tracking of circuit and interconnect parameter variations is more localized, and the correlation of PSRO data to overall performance diminishes. Designs began to incorporate multiple PSRO macros placed throughout the die. Still, these stand-alone circuit measurements are difficult to interpret for bring-up performance characterization. Instead, specific test programs are developed by the product bring-up team to exercise critical timing paths for performance shmoo data generation.

The bring-up team may be asked to delve further into the diagnosis of the shmoo data to determine specific paths that are the root causes of performance failures; hopefully, there is a strong correlation between the measured performance paths and the static timing analysis path reports. The SoC project plan may allocate design resources to focus on optimizing these performance-limiting paths in subsequent tapeouts. This optimization phase may be prior to initial production ramp, or it may be scheduled for a subsequent product release. Another tapeout release after initial volume sales may be appropriate to sustain the revenue and market share; this performance specification improvement is commonly known as a mid-life kicker.

The bring-up results from the initial tapeout identify functional errors and electrical issues to be addressed as part of preparation for the next tapeout iteration. The tapeout review team determines which proposed fixes should be accepted, and it merges the design change requirements with the previously deferred items. A key consideration is the ability to identify whether the necessary design ECO updates can be limited to BEOL mask layer revisions and existing spare cells or whether an all-layer tapeout release is required (along with the corresponding cost and schedule impacts).

21.3 Product Qualification

21.4 Summary

The bring-up and qualification phase of an SoC design project is of critical priority. The fact that these activities are pursued concurrently with the set of planned tapeout revision tasks amplifies its importance. Any issues identified during bring-up or qualification need to be urgently diagnosed, decisions need to be made promptly about the best corrective actions, and ECO updates need to be developed quickly to avoid impacting the (final) tapeout schedule.

Note that qualification failures are typically much more far-reaching and disruptive than functional validation escapes or test escapes. Any issues with package substrates, encapsulation materials, die-to-package pin connection metallurgy, and so on require engineering decisions involving the entire SoC product management organization, working with foundry and OSAT customer support. Referring again to Figure 20.5, qualification issues could result in significant product release delays and financial impact.

Although not described in this text, mechanical CAD (MCAD) software tool vendors provide algorithms to support analysis of material stress and elastic flow for complex three-dimensional geometries when subjected to mechanical forces and thermal gradients. The input to these algorithms provides the geometric model description, along with material strength and surface properties. These tools are indispensable for early investigation of potential structural issues between die, underfill, and package substrate. The MCAD structural analysis, the foundry’s and OSAT’s manufacturing qualification efforts, and the verification of ESD and latchup layouts by the SoC team will hopefully result in zero qualification failures, and thus no additional product delays, and no lost revenue opportunities.

Reference

[1] Zick, K., and Hayes, J., “Low-Cost Sensing with Ring Oscillator Arrays for Healthier Reconfigurable Systems,” ACM Transactions on Reconfigurable Technology and Systems (TRETS), Volume 5, Issue 1, March 2012, pp. 1–26.

Further Research