Analytics-driven yield diagnostics and failure analysis integration for advanced-node devices.
By Guy Cortez and Maheshwaran Jothi
Yield ramp has always been a concern in semiconductor manufacturing: systems companies need confidence that devices meet quality targets before shipment, and chipmakers need to reach yield entitlement quickly to control cost and supply. While this has never been easy, advanced nodes are raising the bar again.
First, designs are larger and more heterogeneous, with tighter margins for timing, power, and signal integrity. Second, test content and test data volumes are increasing rapidly (more patterns, more compression, more logs), while engineering bandwidth is not scaling at the same rate. The result is that learning cycles can become the limiter during early NPI and ramp.
At the same time, root-cause workflows often span multiple teams and environments—test engineering, design debug, process engineering, and failure analysis (FA). Data handoffs are frequently manual, candidate lists can be noisy, and confirmations from the lab may not be systematically fed back into the analytics that generated the original suspects.
A closed-loop yield learning flow is one way to compress this cycle. At a high level it connects diagnosis, volume analytics, and FA: failed ATE patterns are traced back to likely internal locations, issues are ranked by yield impact across the population, and a short list of high-probability candidates is sent to the FA lab for confirmation. The loop closes when FA findings are returned to improve candidate quality, reduce repeated FA cycles, and support trend analysis of recurring mechanisms.
Figure 1 shows a common four-stage yield ramp flow used in early NPI. A frequent gap is the feedback path from FA back into volume diagnostics, especially when the diagnostics and FA environments are not tightly connected. Closing that loop helps validate candidate ranking, refine analytics, and reduce repeated FA cycles.
Fig. 1: Four-stage end-to-end closed-loop product yield ramp and learning flow.
Stage 1 is to generate full-scan ATPG patterns for digital logic and memory BIST patterns for embedded memories and prepare them for testing on an ATE. These pattern types provide high manufacturing defect coverage and help catch many process-related defects.
Stage 2 uses failure logs captured during test and runs diagnosis on each failed pattern. Because the tester only observes input stimulus and output response at device pins, diagnosis backtraces from failing outputs to identify internal points that could have produced the observed behavior. The resulting candidate lists are then provided to volume diagnostics. Since pattern compression is proprietary, ATPG/BIST and diagnosis tools typically come from the same provider, so the diagnosis engine can correctly interpret the encoding.
Stage 3 inputs the diagnosis candidates into a volume diagnostics tool. The primary goals are (1) to reduce the number of candidates per failure and identify the candidate(s) most likely to explain the failure, and (2) to rank candidates across the population by overall yield impact so teams can focus first on systematic limiters. Unlike ATPG/BIST and diagnosis, diagnosis and volume diagnostics do not have to come from the same provider.
Stage 4 provides the final list of failure candidates from volume diagnostics to FA for confirmation. In this flow, FA includes both predominant lab activities—electrical failure analysis (eFA) and physical failure analysis (pFA). Supporting FA software bridges suspected locations in the layout to the device under test, enables CAD navigation, and helps with fault isolation, such as correlating multiple hot spots observed during eFA back to a single source.
Since FA software has access to the layout, netlist, and schematic, it can determine whether multiple hot spots encountered during eFA can be attributed to a single source location (for example, the output of one gate driving a cone of logic where other hot spots reside). When FA findings are shared back to volume diagnostics, teams can confirm whether proposed candidates were hits or misses, refine future ranking, and track failure mechanisms over time. This stage concludes with corrective action in the design, silicon process, and/or test program.
To make the methodology concrete, the sections that follow describe one implementation using Synopsys TestMAX ATPG and TestMAX Diagnosis for logic pattern generation and diagnosis, TestMAX SMS for memory BIST and memory diagnosis, Silicon.da for logic and memory volume diagnostics, and Avalon for FA navigation and workflow. The focus is on how data moves from diagnosis to volume diagnostics to FA, and how FA results can be used to improve subsequent analyses.
In this implementation, TestMAX ATPG and TestMAX SMS are used to generate high-coverage manufacturing tests for logic and embedded memories, and TestMAX Diagnosis converts tester failures into candidate lists. Those candidate lists become the input to volume diagnostics, which then prioritizes likely systematic yield limiters and prepares a short set of FA targets.
We start with logic volume diagnostics and then cover embedded memory volume diagnostics.
In this implementation, logic volume diagnostics is performed using Silicon.da. The process can be broken down into three steps (Figure 2): (1) screen and curate diagnosis results to improve signal-to-noise, (2) apply analytics to identify and prioritize likely yield limiters, and (3) assemble an FA-ready candidate list ranked by yield impact.
Fig. 2: Three-step volume diagnostics process in Silicon.da for digital logic.
Step 1 uses the Diagnostic Analysis Readiness Tool (DART) to reduce diagnostic noise and help users recognize population-level signatures (for example, zonal or wafer-level patterns). When a failure is explained by hundreds of candidates, downstream ranking becomes less reliable; DART helps focus analytics on higher-quality candidate sets.
The DART views also support filtering by wafer, partition, or other context when failures are more dispersed. The curated set is then used as input to the automated analytics.
Step 2 runs analytics intended to identify and rank likely failure sources. Two complementary approaches are Automated Volume Diagnostics (AVD) and Failure Mechanism Analysis (FMA). Agreement between the two can increase confidence in the final FA targets.
AVD is a statistical data-mining approach that runs tests associated with different failure mechanisms on the design and analyzes the observed failures as a response variable compared to design statistics in order to identify systematic yield limiters. The P-value highlights the significance of the limiters, and the Gap% highlights the difference between the expected vs observed fails. These are key metrics to guide users on where to focus.
The findings are collected in the LaunchPad view to provide summary and drilldown options for exploring significant yield limiters.
FMA is used to reduce diagnostic noise by looking across the full diagnosis population and uncovering dominant failure mechanisms that repeat across many dies.
While an individual diagnostic report might have too many candidates to clearly identify the causal failure mechanism, looking across the rest of the population can help identify the correct candidate within an otherwise noisy report.
AVD often performs well when there are clear systematic sensitivities (for example, an excursion wafer or spatial pattern). FMA can be effective when there are no obvious systematic sensitivities and the underlying yield loss is more defect-driven. A common practice is to run both and prioritize yield limiters that appear in both analyses.
Step 3 is to create the final list of failure candidates for FA. The Failure Analysis Selection Tool (FAST) helps review, sort, and annotate candidates based on diagnosis quality and physical attributes (for example, fail area, net length, and top layer), and supports visual exploration to prepare an FA “shopping cart.”
For selected results, FAST can also show the corresponding AVD/FMA context to support candidate selection and includes annotation capability (for example, snapshots and notes). Exports can be generated for Synopsys FA tools (for example, Avalon Maskview) and for third-party FA tools.
In this implementation, memory volume diagnostics is performed using Silicon.da. One of the main challenges in memory analysis is setting up the memory design database. A memory-aware physical database allows failed bits to be mapped precisely (logical and physical) across many memory instances and visualized at wafer, die, and bit level.
Consistent with the digital logic flow, the volume diagnostics process for embedded memory can be broken down into three steps (Figure 3): signature classification, analytics to identify significant yield limiters, and selection/packaging of bits and signatures for FA targeting and navigation.
Fig. 3: Three-step volume diagnostics process in Silicon.da for embedded memories.
A key step in embedded memory analysis is automated signature classification. Signatures are topological patterns of failed bits. In addition to default signatures, definitions can be customized and parameterized based on memory attributes such as bank, word size, row size, and column size.
Signature definitions for failed-bit classification can be created and updated using the signature editor tool, along with customized search-area definitions.
In addition to topological signatures, electrical fault signatures can be derived from march-type test patterns in the memory diagnosis results and stored during data load. AVD can also be applied to memory data using control factors such as cell types, compilers, and test conditions, with results summarized in the same LaunchPad experience.
For FA preparation, wafer-level visualization can support filtering and stacked views across wafers, reticles, dies, memories, signatures, and individual bits. Using these views, engineers can select signatures or bits of interest and export the physical coordinates and supporting context needed for downstream FA navigation (including third-party FA tools).
After candidates are selected, they are packaged into an FA request and shared with the lab. The FA team can confirm the proposed locations (or select different locations), then return findings for correlation with diagnostics data. This feedback supports closed-loop learning by validating candidate selection and improving future analysis.
Once loaded, FA findings and images can be reviewed in an FA viewer and correlated against new diagnostic loads. This can reduce duplicate FA requests and preserve traceability of what was sent, what was confirmed, and what corrective action followed.
In practice, teams applying this type of closed-loop flow at 7nm-class nodes report faster identification of dominant yield limiters, fewer investigation iterations, and better reuse of diagnostics and FA results across distributed organizations (including fabless–foundry handoffs). The common theme is disciplined data exchange and traceability from volume analytics to FA and back into analysis.
A closed-loop yield learning flow connects high-coverage test, diagnosis, volume diagnostics, and FA so teams can prioritize yield limiters, validate root causes, and shorten learning cycles. Typical outcomes include:
As device complexity increases, scalable analytics and disciplined collaboration become increasingly important. Integrating diagnostics with FA feedback helps improve candidate quality over time and preserves learning so subsequent ramps can start from a stronger baseline.
To explore the example closed-loop flow for volume diagnostics and FA navigation, see Synopsys Silicon.da and Avalon.
Maheshwaran Jothi is a principal applications engineer at Synopsys.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
Leave a Reply