Twin DFT and Mission-Critical Safety Apps for Pre-Silicon Design Verification
The design-for-test (DFT) technology was driven by the need to harness the runaway cost of testing silicon chips on the manufacturing floor. This phenomenon eventually became close to 40% of the cost of building the chip. To combat this challenge, the battle cry became “simplify, accelerate, and optimize” the testing of the manufactured chips.
Unfortunately, for all of DFT’s benefits, the technology came with a drawback. Inserting DFT logic structures in the netlist of an already tested design forced designers to verify that the design integrity hadn’t been broken––easier to say than to do. The added logic on complex designs significantly increased their sizes. And the larger the added logic, the larger the volume of test patterns required to test the design.
Software-based simulation tools barely handled the original design netlists, and the added burden stretched the verification cycle to a point beyond the schedule determined by management.
This is where hardware emulation came to the rescue. Its ability to verify multi-billion gate designs at the gate level with performance close to six orders of magnitude faster than traditional software-based simulation tools dramatically sped up DFT verification. The result was higher-quality designs, enhanced production yields, reduced lab bring-up time, lower product and test costs, and faster time to entitlement.
Reflecting on these events, I scheduled a phone discussion with Robert Serphillips, Veloce DFT product specialist at Mentor, a Siemens Business. We talked about twin Veloce Applications: Veloce DFT App and Veloce Fault App. The App/emulation combination accelerates DFT verification for complete validation of test vectors and DFT logic, as well as increases fault coverage prior to tape-out.
DFT App
The Veloce DFT App and emulation platform verify the DFT-modified design netlist with long sequences of test vectors and accelerate test vector development. By shortening the execution of tests from a few months on a simulator to one or two hours, emulation allows complete validation of test vectors and DFT logic before chip tape-out. This further increases fault coverage and accelerates time to entitlement.
All patterns that run on automatic test equipment (ATE), such as structural, built-in self-test (BIST), parametric, I/O characterization, and functional are fully supported by the DFT App. Based on the Standard Test Interface Language (STIL), the compile flow is straightforward. It reads the design under test (DUT) gate-level netlist instrumented with scan cells and BIST engines, and STIL files, including DUT I/O information, clock information, and test vectors and timing. It generates the DFT testbench and DUT mapping onto the emulator.
A compilation flow for emulation with the DFT App verifies a DFT-modified netlist to accelerate test vector development. (Source: Mentor, a Siemens Business)
The emulation session runs in two modes. In single-pattern mode, the App executes one pattern, reinitializes the design, and runs the next pattern. This mode can be inefficient due to the overhead to reinitialize the DUT and bring the state of the hardware back to time zero.
Single-pattern mode executes one pattern, reinitializes the design, and runs the next pattern. (Source: Mentor, a Siemens Business)
In a pattern burst mode, similar to running STIL vectors on the tester, the user puts the STIL file into a burst list and runs all patterns in it in one execution, saving time.
Burst-pattern mode runs all patterns in one time-saving execution. (Source: Mentor, a Siemens Business)
For example, 100 STIL patterns in single pattern mode took 45 minutes, but only 90 seconds in burst mode.
Combining the DFT App with the Fault App
By combining the Veloce DFT App with the Veloce Fault App, the user can achieve a powerful pre-silicon fault coverage solution.
If a user generates 10,000 automatic test pattern generation (ATPG) patterns, AC and DC scans and patterns reached 99% DC coverage and 85% AC fault coverage, the few remaining uncovered faults could be due to several reasons, such as test tools that don't have controllability over the net or no observation. Either way, the user can write BIST patterns, functional patterns, difficult parametric patterns, and IO patterns to cover those untested ATPG faults. Using the ad hoc flow shown below, the user can inject a fault pre-silicon to see if that fault would be covered.
Combining the DFT App with the Fault App delivers a pre-silicon fault coverage solution. (Source: Mentor, a Siemens Business)
According to Serphillips, the ability to run ATPG, functional, and BIST simultaneously is valuable to the user community.
The Fault App
The Veloce Fault App aims to ascertain the fault tolerance of a design that’s designed for high-reliability and safety-critical markets such as automotive. While functional verification determines whether a design performs what it’s supposed to accomplish, safety verification ensures a design behaves correctly even in presence of hardware faults.
It works in tandem with the emulation platform. At compile time, it generates a fault universe to be injected into the design. Fault types are grouped in four categories: stuck-at, transient, single-event upset (charge particle deposition), and bridge (four-way dominant fault model). The user can inject them into any net or nets of the design in any capacity.
Emulation’s raw power is then able to verify the faulty design at the RTL or gate level with a set of test patterns of any length and compare its behavior against the fault-free design previously emulated. Upon reaching a behavioral mismatch, the emulator can be stopped to avoid running needless further cycles. The results can be used to generate a fault coverage report.
The setup meets the requirements of safety standards such as ISO 26262.
Combining the DFT App with the Power App
The number one reason that patterns fail on the tester is due to factual manufacturing defects. Test vectors can only identify a broken part, not fix it.
Sometimes, during testing on the manufacturing floor, physical variations across the process, voltage, and temperature (PVT) may occur. These may be due to internal integrated-circuit quiescent current (IDDQ) events, such as crosstalk, ground bounce, or collapsing voltage rail. The IDDQ events don’t happen on all parts under testing. Realistically, they may lead to a 3% fallout on a batch of 10,000 parts.
An IDDQ event typically occurs when the pattern is factored in. In performing embedded deterministic test (EDT) compressed scan, a massive amount of data is scanned into the part, none of it functional. It may be because the power supply doesn’t have enough capacity to feed and sustain the switching of all the elements.
In the past, the occurrence was noticed in big networking chips. Today, it affects automotive chips with many megabytes of onboard memory. The DFT engineer may test all memories at the same time, but functionally doesn't work like that. The end result is that all of that switching activity causes the collapse of the power supply, leading to an IDDQ event.
The combination of the DFT App and Power App allows for bursting all ATPG patterns and generating a power profile. If a particular pattern or multiple patterns are generating too much switching activity, it’s reasonable to assume that there may be an issue. All testing should be done in pre-silicon before shipping it to the tester.
Serphillips recalled a case where BIST patterns were running 200 MHz slower than functional patterns due to an IDDQ event, though there was no visibility on the tester to understand what was happening.
Combining the DFT App with the Power App enables bursting for all ATPG patterns to generate a power profile. (Source: Mentor, a Siemens Business)
Tester vs. Emulator
The DFT App has an advantage over a tester. A user debugging embedded deterministic test (EDT)-compressed ATPG patterns can substitute an emulator for the tester. When an EDT-compressed pattern fails on a tester, the user can’t tell which element on the chain is failing and is forced to go back through the tools that generated the “one hot” and run the test again.
The DFT App enables the user to run the same scenario through emulation and supports both compressed files through a serial style with compression or decompression in the compression or EDT logic. Simultaneously, it supports the EDT internal mode where the user is scanning through the top of the chains individually in an uncompressed manner.
Not supported is parallel or backdoor preload. That’s where users shift instead to scan preloaded sequential elements. Emulators in general don’t sort backdoor preload because it limits performance. Instead, DFT App users would load compressed EDT-enabled serial and internal uncompressed files.
Conclusion
By combining the DFT App Fault App and Power App with the emulation environment, the user can increase fault coverage, increase production yield, and reduce ATE test time and cost. Ultimately, the user is able to accelerate the design schedule for faster time to market, boosting profits and reducing ATE test escape and increase product returns.
Author’s Note: The emulation apps described here are Veloce DFT App and Veloce Fault App, offered by Mentor, a Siemens Business. These help accelerate DFT verification for complete validation of test vectors and DFT logic and increase fault coverage prior to tape-out. More information can be found at https://bit.ly/2e0ydhK
