Verifying DFT circuitry and test patterns is essential, but simulation takes too long.
What if all the DFT verification on your next big chip could be completed before tape-out? This “shift-left” of DFT verification would eliminate the need for shortcuts in verification and allow for more types of verification. The benefits of faster and earlier DFT verification include higher confidence in the “golden” RTL, eliminating DFT from the critical path of tape-out, and more predictable time-to-market.
DFT circuitry and test patterns are verified through gate-level simulation. This includes verifying the correctness of the test data as well as scan chain integrity, BIST structure functionality, and compression/decompression logic. But because of the complexity and size of today’s SoCs, the traditional simulator-based DFT verification process has become unreasonably slow, putting DFT verification in the project’s critical path. Chips are often taped out with minimal DFT verification, which increases the risk of undiscovered issues with the DFT—issues that can reduce yield and affect chip reliability. Reliability problems lead to field failures, an under-appreciated source of revenue loss and end-customer ire.
By using hardware-accelerated simulation, i.e. emulation, DFT verification is accomplished faster—much faster, as the runtime comparisons in Figure 1 show. Go ahead and make the tests as comprehensive as you want, with no shortcuts. You can even make your DFT netlist power-aware with UPF or Liberty-based constructs and perform accurate static and dynamic power measurements. Using emulation to verify DFT clears the critical path to tape-out, removes uncertainty and risk that a bug will make the design untestable, and improves your chip bring up in the lab as all the DFT patterns are validated against the final chip netlist.
Figure 1: Comparison of simulation runtime and Veloce hardware-assisted simulation runtime.
Because it supports the standard STIL file format, Mentor’s Veloce DFT App is interoperable with other tools. The DFT App fits seamlessly into the Veloce ecosystem enabling a host of other powerful apps and features in the context of DFT infrastructure verification. For example, within the Veloce system, you could also enable power estimation during scan shift to check the power infrastructure.
Here’s how it works.
Veloce DFT brings some changes to the hardware emulation process. One change is in the compilation flow, the other is in the runtime execution.
The first step is to compile the relevant files. The compilation step is illustrated in Figure 2.
Figure 2: Veloce Compile generates a DFT testbench and simulates a representation of the device under test.
The Veloce compiler creates a couple of outputs:
Figure 3: During DFT verification runtime, Veloce reads the test vectors from the STIL file, puts them through the DFT testbench and executes the pattern set on the design representation.
The next step is the emulation runtime, illustrated in Figure 3. You map the design and testbench onto the emulator. Veloce DFT reads the test vectors from the STIL file. It then sends the test vectors via the testbench to the DUT on the emulator, executing the complete pattern set for DFT verification. Outputs are sent back to the checker (also created during the compile step) on the host PC. Veloce DFT creates a log file to capture the miscompares. If the descriptive components of the DUT don’t change, multiple STIL patterns can be run on a single compiled database.
The Veloce compiler technology automatically generates the DFT testbench and reads the standard STIL file, which makes the entire flow easy to use and fully compatible with simulation. So you can reuse the same flow from simulation to emulation, which runs several orders of magnitude faster. Completing DFT verification earlier and faster translates also into better validated test structures and patterns. Learn more about Mentor’s Veloce DFT App in this whitepaper.