What skills should a DFT engineer have

Moving DFT into the chip design with hardware emulation

Create testability in a custom chip during the design phase

LAURO RIZZATTI, verification expert,

Of all the EDA (Electronic Design Automation) tools on the market, Design for Test (DFT) can be the least valued; although testability results in a chip during the design phase, test costs are significantly reduced. According to a recent analysis, the cost of testing a batch of chips after manufacture to determine which parts are free from manufacturing defects has hit an alarming threshold of 40% of the cost of building the chip.

DFT can eliminate the risk that a problematic device that may be caught in the field will be carried over at a much higher cost than if it was found on the shop floor. It can also avoid rejecting healthy devices, thus increasing the yield. The inclusion of DFT also reduces the time associated with test development as well as the execution time of testing fabricated chips.

DFT, a buzzword in the electronics industry, goes hand in hand with automatic test pattern generators (ATPG) and memory-built-in self-tests (MBIST) and is the insertion of an on-chip test infrastructure such as a scan chain, MBIST structure or compression / decompression logic. The scan chain offers controllability and observability through serial shift registers. The scan chain simplifies and reduces the problem of testing a circuit to test the combinational logic between registers. The ability to automatically generate test patterns via ATPG tools can reduce the time-consuming and tedious task of generating test vectors.

The on-chip test infrastructure, or scan chain, is added to the gate-level netlist after the design has been functionally verified and caution is required as it can disrupt the functional correctness of the chip. The design change requires a gate level review to ensure that the design integrity has not been compromised. Testing is carried out using long sequences of test patterns, a computationally intensive task that is far more complex than RTL verification (Register Transfer Level).

It is worth noting that the creation and insertion of the DFT structures is quite straightforward from a design standpoint. However, from the density and size perspective, the design becomes quite large, and the amount of test patterns required to test the design increases the size significantly.

DFT verification

Simulator-based verification is too slow for gate-level checks when design sizes extend into the hundreds of millions of gates. The DFT approach only makes things worse. If that weren't enough, priority access to a simulation farm approaching tape-out favors development engineers and plays against test engineers. Chips are often taped with minimal DFT verification and a thorough DFT test is done after tape out, too late to fix design flaws.

DFT verification comes in several forms, including custom initialization patterns that need to be verified. It could be an on-chip clock controller inserted by an automatic test pattern generation tool that needs to be dynamically verified during pattern execution, or logic added for MBIST that requires functional verification of the associated logic with the test pattern. A SoC can contain a user-defined initialization pattern that configures a test and effects a transition from a functional mode to a test mode. Other test modes may include low-power techniques in which parts of the chip are placed in a low-power mode during the test, which requires validation of the test infrastructure under appropriate conditions.

Hardware emulation with a DFT app

Hardware acceleration speeds up the simulation cycles required for thorough DFT verification. It can verify the chip functionality regardless of its size and complexity.

While hardware emulation has been used for 30 years to extend verification cycles by providing reprogrammable hardware, new deployment modes are a far more viable verification tool and paved the way for an "apps" approach. Some recently announced hardware emulation applications could be welcome news for those chip design teams using the more difficult simulator-based verification approach. The DFT app speeds up a chip design schedule that requires extensive simulations at the gate level. Using automatically generated patterns, the design team can shorten the entire pattern development cycle.

This type of hardware emulation, scalable hardware and compilers enable test pattern validation for large gate-level designs, with scan and other test structures embedded in the design. Its high performance enables more simulation cycles and speeds up DFT analysis. The DFT app is compatible with other tools as it supports the industry standard STIL file that is used on the production tester to identify damaged chips during manufacture.

Hardware emulation DFT applications modify the compilation flow and run-time execution in the deployment process of a hardware emulator. These are changes in the translation process and in the execution of the runtime. A design at the gate level with scan and MBIST is entered into the compiler of the hardware emulation. The compiler creates the necessary test infrastructure to read test vectors from the STIL file, apply them to the synthesized test object (DUT), and compare the outputs. The compiler compiles and synthesizes the user netlist into a structure description that is compatible with hardware emulation. At compile time, the emulator creates the infrastructure necessary to read test vectors from the STIL file and apply them to the synthesized DUT, then compile and synthesize the netlist into a structure description that is compatible with the emulation. The test harness includes a mechanism for comparing the outputs. See figure 1.

Fig. 1: The compilation sequence modified by the DFT app.

The design and the test bench are mapped into the emulator when called. During runtime, the hardware emulation pulls test vectors from the STIL file, applies them to the DUT and compares the output - all at emulation speed. See figure 2.

Fig. 2: The runtime diagram shows the operating sequence in the host PC and emulator.

DFT apps enable complete sets of patterns to be executed for DFT verification to shorten the pattern development cycle. A scalable emulation platform that can support designs of up to two billion gates, as well as a compiler that can support a DFT method, enable test pattern validation for large gate-level designs with embedded scan and other test structures.

Once the chip has been made, the same STIL file can be used on the test floor. Loaded into an ATE, the test vectors exercise the chip and its responses are compared to the expected values ​​in the STIL file.

Design for the test

Hardware emulation does not simulate incrementally better speeds than simulation - it is orders of magnitude faster. Some benchmarks show an improvement of four or five orders of magnitude in the execution of DFT patterns in hardware emulation. See table 1.

Table 1: A comparison of DFT app benchmarks shows an improvement in performance.

By reducing tests, which typically take three months, to a simulator to two hours, hardware emulation enables full validation of test vectors and DFT logic prior to chip tape-out. Offering a DFT app for hardware emulation expands the usage model, improves performance, and helps a verification engineer avoid risk. DFT engineers now have a way to leverage the power of hardware emulation to ensure that a chip with an "app" is good for manufacturing.