DFT lets ATE work magic

From scan-insertion to ATE emulation, tools are emerging to ensure the quick design of testable chips and the rapid development of ATE test programs.

Rick Nelson, Senior Technical Editor -- Test & Measurement World, 5/1/2001

Design for test (DFT) firms are advancing on several fronts in an effort to ensure the testability of complex digital and mixed-signal semiconductor devices. Their goals are shorter design cycles, lower defect levels, and lower costs of test. Their offerings are putting pressure on ATE manufacturers, who are beginning to see on-chip test circuits taking over functions once performed by multimillion dollar functional ATE systems. (See the list of DFT vendors and the types of tools they make.)

But DFT tools are facing pressure, too. Collapsing chip design flows are starting to subsume the convenient stages at which designers can insert DFT functions. Mixed-signal and RF functions, for which DFT tools are in their infancy or nonexistent, are increasingly populating SOCs. Even logic DFT faces pressures: Logic DFT excels at detecting faults in which circuit nodes are stuck at 1 or 0, but the “single-stuck-at” (SSA) fault model may prove inadequate for testing tomorrow’s deep-submicron designs.

The appropriate response to the pressures on the DFT and ATE communities is not an all-out war in which the victor is either a self-testing chip or a complete functional ATE system. Rather, the goal should be cooperation among ATE and DFT firms, in which DFT techniques implement high-fault-coverage structural test and functional ATE systems establish device operating margins and handle mixed-signal and time-critical digital functional-test chores. A look at emerging DFT tools and ATE platforms illustrates how the two can work together.

Some definitions

In this article, I use DFT as the enveloping term that includes built-in self test (BIST) or any other technique that improves device testability or facilitates test-program development. In my usage, DFT includes everything from inserting a test point to adapting design-verification vector data for use in production test programs. The term BIST refers to circuitry embedded in a device solely to facilitate test; it in no way supports, and in fact may degrade, device functionality.

You should note that the common industry usage of the terms is not consistent. Consider full-scan capability, which aims to let a tester stimulate and observe the response of internal ASIC circuit nodes. The scan chains and latches that implement full scan are structures built into a chip solely for test purposes, but scan insertion is not commonly called a BIST technique. In common usage, BIST often refers to microscopic ATE systems embedded within a complex chip; under this definition, to qualify as BIST a function must generate test vectors on-chip in response to an externally applied test command and must be able to compact test responses into external pass/fail signals.

Like DFT terms, tester definitions can also cause confusion. A functional tester ideally mimics the real world a device will encounter when embedded within a target product; the tester applies functional stimulus patterns and evaluates response patterns at rated speed. Structural testers, on the other hand, specifically interact with a device’s DFT and BIST characteristics. Ideally, they would activate on-chip test circuitry using what Yervant Zorian, LogicVision’s chief technology officer, calls a test-access mechanism, or TAM: a low-speed, low-pin-count channel connecting tester and DUT. Complicating the definition, today’s functional ATE systems provide such DFT-related functions as scan-buffer memory. Thus far, it’s unclear whether a dedicated structural tester that forgoes functional capabilities such as at-speed clocks will prove to be effective. Whether “DFT” can ever stand for “Delete Functional Testing” (as the title of Ref. 1 intimates) is doubtful.

Test challenges

In general, the expense and difficulty of test arises from the massive amounts of test data needed to characterize a complex SOC. How much of that data can be generated and digested on-chip by DFT and BIST structures and how much must be pumped in and out of a DUT by ATE remain open questions. Test difficulty is compounded if your production staff wants to take a test program written for one ATE platform and move it to another. Further, you might need to port your circuit design to a different foundry or process technology. Although the circuit’s functionality remains constant, the new implementation may present subtle test problems that will undercut production-test accuracy. Similarly, you must ensure that any BIST functions you use are compatible with new processes.

For example, Fluence Technology announced last October that it has integrated its VCOBIST product into Infineon’s 0.18-micron CMOS process, implementing a 500-MHz BIST-enabled phase-locked loop. When he is asked why process-to-process transfers aren’t transparent, Fluence marketing vice president Mike Kondrat points out that moving from one process to another involves resynthesis, not simply a transistor-to-transistor remapping. The additional synthesis and place-and-route operations can result in significant layout differences that could affect timing and other aspects of performance. Therefore, when evaluating a company’s products, it’s not enough to know simply that the company offers a BIST tool—you must ask whether it works within the fabrication process you intend to use.

Further complicating DFT implementation, a single-chip design might become an intellectual-property (IP) core that becomes merely a portion of a newer, larger chip that comprises other IP cores as well. The single-chip implementation that was testable on a high-end 1000-pin functional ATE system could present insurmountable test problems to the same test system when it’s submerged among other IP blocks with equally complex test demands. To help deal with such complexities, LogicVision offers its Core Test tool, which implements a BIST wrapper around legacy cores. Core Test renders multiple on-chip cores with such wrappers testable through external pins.

Today’s BIST implementations and core test wrappers are generally proprietary. There’s no standard that ensures compatibility between, for example, a PLL employing Fluence’s VCOBIST and a legacy core surrounded by a LogicVision test wrapper. That will change, if efforts of two groups come to fruition. The IEEE P1500 group (grouper.ieee.org/groups/1500) and the Virtual Socket Interface Alliance (www.vsi.org) are both working to develop standard interfaces for IP cores, with the goal of hiding proprietary internal intellectual property (IP) while providing a consistent functional interface with test capability.

Software mirrors bench instruments

Although most DFT efforts take place within computer simulation, many DFT tools mirror those deployed by more traditional hardware design and test engineers. For example, hardware-description-language (HDL) test benches mirror the breadboards and bench instruments that TTL jockeys use to troubleshoot logic prototypes. In fact, SynaptiCAD’s TestBencher Pro can make use of data from Agilent Technologies’ logic analyzers and pattern generators to produce high-level-language test-bench models in VHDL, Verilog, or SystemC. SystemC (Ref. 2) is a set of C/C++ class libraries and a simulation kernel that support development of device hardware models. Similarly, Diagonal Systems’ BenchLink product links the firm’s BestBench test bench with Agilent logic-analysis bench equipment.

Such HDL test benches are not, strictly speaking, DFT tools—they are design-for-functionality tools, whose goal is to determine whether a design responds properly to sets of functional input vectors. They don’t necessarily do anything to ensure that internal faults could be detected in production test. Nevertheless, they are an aid to test in that they provide a means of developing and organizing functional test vectors that can subsequently serve in production-floor functional-test applications. Bulent Dervisoglu of Cadence Design Systems noted that “Design Verification has become a very serious issue and as much as 55% of the total design effort might be spent in developing self-checking verification programs (plus the test benches to execute them).” He suggested that data gathered during design verification be remapped for use in IC test (Ref. 3). That’s happening already.

For example, tools from the IMS Virtual Test Division can adapt test-bench vectors for functional ATE systems. IMS’s virtual-test products extend the test-bench concept to embody complete ATE systems, rendering those systems as HDL models that can facilitate test-program development before DUT silicon becomes available.

Other tools analyze design data for testability and automatically convert the data into production test programs. These tools relieve the test engineer of the traditional need for a painstakingly thorough knowledge of the hardware quirks and software syntax requirements of the many available production test platforms. Illustrative of this class of tools is Fluence Technology’s TestScanPlus, which uses device simulation files and derives test programs for more than 90 models of ATE systems.

These tools from Diagonal Systems, Fluence, IMS, and SynaptiCAD automate processes that could be time-consuming and error-prone if implemented manually. But today’s DFT tools offer more than just faster, easier ways to perform traditional test-related chores. For gigahertz-rate million-transistor designs, traditional instrumentation is becoming inadequate. It’s not simply a matter of time and expense, or of automated tools being faster or more accurate than engineers trying trial-and-error troubleshooting approaches. The problem is becoming whether traditional test-program development approaches and tester hardware architectures are up to the task at all.

From functional to graded vectors

Between the HDL test bench and the production test program lie a range of tools applicable throughout the design flow (Figure 1) that help ensure a device is testable. Whereas test benches help you to develop functional input and output vectors that verify design functionality, scan insertion remains a workhorse in efforts to ensure the testability of circuit structures within a DUT. Scan insertion analyzes a design, locates flip-flops and latches, and replaces some (partial scan) or all (full scan) of those flip-flops and latches with “scan-enabled” versions; when a test system asserts those versions’ scan-enable line, scan chains carry test vectors into and out of the scan-compatible flip-flops, which in turn apply signals to and read outputs from the combinational logic connected to those flip-flops.

Figure 1. To produce a chip, a designer begins with HDL descriptions of a circuit and functional test vectors. Scan-insertion and ATPG steps provide for testability as they are interspersed with other simulation and fabrication steps (which may differ in order from that shown here), leading to final functional and structural tests. Missteps along the way can lead to costly design iterations. To minimize those, EDA firms offer DFT analysis and compilation tools.

Full-scan provides high stuck-at fault coverage with relatively small sets of test vectors but at the cost of chip real estate. Partial scan occupies less valuable DUT real estate but requires large numbers of vectors for adequate stuck-at fault coverage. With either technique, automatic test-pattern generators (ATPGs) develop the vectors needed to operate the scan chains.

To determine the efficacy of your ATPG vectors—that is, to grade your fault coverage—you can employ fault simulators, which can tell you what the chances are of detecting any given stuck-at fault within a digital circuit. Fault simulators such as Cadence’s Verifault-XL, for example, apply successive input vectors to a simulation of a “good” version as well as to “faulty” versions, each with a stuck-at fault applied to a different circuit node. If the output pattern from a faulty simulation differs from that of the good simulation, then the particular stuck-at fault embodied by the faulty simulation is detectable.

The stuck-at fault model itself has come under attack, with some critics claiming it doesn’t detect conditions such as leaky transistors or path-delay errors. Nevertheless, it is likely to retain its place as a dominant approach, as several members of a 1998 ITC panel (Ref. 4) emphasized. The title of the panel—“Stuck-at Fault: The fault model of choice for the third millennium!?”—was punctuated to emphasize enthusiasm plus caution. Kenneth M. Butler said during the discussion that “The stuck-at fault has weathered at least two major revolutions . . . the transition from tubes to solid-state, and the move from bipolar to MOS technology . . . . It seems unlikely that future digital technologies will invalidate the use of the model” (emphasis his).

In the last calendar quarter of the second millennium, ITC authors were pointing out that “The claim that the single stuck-at fault model is sufficient for the purposes of test pattern generation has been attacked, defended, vilified, vindicated, rejected, yet ultimately embraced as a fundamental part of the ASIC design cycle” (Ref. 5), yet those authors went on to reveal flaws in the gate-level models that underlie the SSA approach.

Nevertheless, in this first year of the third millennium, the model is still going strong, although it is being augmented by models that deal with transistor leakage (I_DDQ models) and path delays. For example, Book Shone, operations manager for LG Electronics’ system-IC business, noted that delay faults were the cause of most test escapes for his firm’s 4 million-gate, 108-MHz multimedia ICs; his statement was included in the March announcement that LG had chosen to use SynTest’s TurboBIST-Logic product, which targets path-delay as well as stuck-at faults. And fault simulators including Verifault-XL now come with an I_DDQ capability to extend fault coverage.

Jon Turino, Fluence product marketing manager, explains that to implement his firm’s I_DDQ technology, a tester applies an appropriate vector, waits for switching transients associated with application of the vector to die out, and then measures DUT power-supply current while holding the vector constant. Excessive currents indicate faults. I_DDQ vectors should be minimized, Turino says, because I_DDQ tests can become more time-consuming than stuck-at fault tests. In general, he adds, customers specify an I_DDQ fault-coverage threshold—for example, an I_DDQ vector might not be included unless it can detect at least 5% of a chip’s potential I_DDQ faults.

Of course, new fault models aren’t a panacea. “They’re not as robust as single-stuck-at fault models,” explains Lee Song, engineering manager at Teradyne. He says that I_DDQ models may lose their efficacy in deep submicron processes, where quiescent currents go up, making it more difficult for test equipment to detect the subtle current-level shifts that would indicate an I_DDQ fault. He sees the industry exploring solutions that run I_DDQ tests at multiple voltage levels or with the DUT subjected to other operating extremes (a topic discussed in Ref. 6).

Integrating DFT

The table accompanying the Web version of this article lists companies whose products can implement DFT capabilities such as BIST insertion, scan insertion, testability analysis, and test-program generation at various points throughout the chip-development cycle. That cycle typically begins with design of a register-transfer-level (RTL) description written in a hardware description language like Verilog or VHDL. The HDL description might include RTL models of BIST functions or BIST-enabled IP cores.

If you are inserting scan or BIST into your design, you’ll need to understand its impact on the design process. BIST insertion typically takes place concurrent with HDL design, when you choose BIST circuits or BIST-enabled cores from an HDL library. Whatever form it takes, BIST imposes overhead, and you’ll want to investigate ways of mitigating that overhead, perhaps by pursuing techniques that use functional circuitry within a device to implement BIST operations (Ref. 7).

Taking another approach, Credence Systems has implemented BIST-like features using its BOST (built-off self test) technology. Marc Loranger, senior marketing director at Credence, explains that BOST is a transitional approach that locates test circuitry, derived from BIST technology from Fluence (a Credence Systems subsidiary), on a tester load board rather than on the DUT itself. By keeping test circuitry near the DUT, BOST preserves test-signal fidelity; by keeping test circuitry off the DUT, it reduces test-related DUT silicon overhead. At an ITC presentation, Arnold Frisch of Fluence detailed the partitioning of BIST-like functions among a DUT, load board, and tester (Ref. 8).

Scan insertion typically takes place after gate-level synthesis of an HDL design that responds properly to test-bench functional vectors. Many DFT approaches have been add-on efforts that attempt to shoehorn DFT functions into a circuit that’s been synthesized to the gate or silicon-layout levels.

Figure 2. DFT circuitry can complicate a chip’s design, as the top scan-chain map shows. Synopsys’s DFT Compiler orders design data in accordance with physical placement to minimize DFT overhead, reducing wiring congestion by 10% to 15%, as the bottom map of the same DFT functionality illustrates.

Figure 3. A boundary-scan TAP provides access to an internal scan chain as well as to logic and memory test circuitry in this Mentor Graphics BIST implementation.

At those levels, DFT additions can seriously compromise device functionality. Silicon overhead and timing delays resulting from the DFT add-ons can give you a chip that’s testable but never works. To avoid such an outcome, you can employ tools such as Mentor Graphics’ DFTInsight, which helps you pinpoint test problems. Synopsys’s DFT Compiler (Figure 2) makes scan insertion part of the initial synthesis step, making it unnecessary to run countless iterations to implement adequate DFT without compromising device functionality.

Boundary scan

A key DFT technology is boundary scan, defined in the IEEE 1149.1 standard. Boundary scan emerged as the addition of test circuitry, in the form of a four-line Test Access Port (TAP) and associated control circuitry, to digital ICs. The initial goal was for boundary scan to serve primarily in PCB test, allowing daisy-chained data-in and data-out lines of the TAP to carry test signals to and from nodes that might be buried under surface-mount devices or be otherwise inaccessible to tester probes. Apart from the self-test considerations of the chip you’re designing, you’ll want to consider including boundary scan to facilitate testing of the product in which your chip will reside.

While boundary scan remains valuable for board and system tests, its TAP is also proving to be valuable as a conduit for carrying test signals to and from internal BIST structures. In Figure 3, for example, the TAP, implemented using Mentor Graphics’ BSDArchitect, routes signals to internal nodes interconnected by an internal scan chain and to memory and logic BIST structures.

Just as digital boundary scan provides access to a chip’s internal nodes, you might expect that analog boundary scan, defined in the IEEE 1149.4 standard, would provide a window into analog levels within a chip. That’s not happening, though. LogicVision and National Semiconductor have worked together to develop an 1149.4-based chip (Ref. 9), but that chip provides access to board-level analog nodes, not nodes internal to a chip. Fluence offers an analog-probe implementation that will bring analog levels to external pins, but Fluence’s Kondrat doesn’t see much demand for the capability. External analog probing imposes bandwidth limitations, he says, and most customers want external digital indications of internal high-speed analog performance—the approach most of his firm’s mixed-signal BIST tools employ.

Structural ATE

A good functional ATE system must offer gigahertz clock rates, upwards of a thousand pins, and timing accuracy measured in less than a hundred picoseconds. So, what makes a good structural tester, the supposed economical alternative to full-featured functional ATE? Is it simply a matter of being slower, having fewer pins, and offering less timing accuracy?

Not quite . . . .

The ideal device tester would have a power supply and the four pins of the IEEE 1149.1 standard’s TAP, Fluence’s Turino notes facetiously. Of course, he adds, device test times on such a system would be days instead of seconds, and some high-speed functions would be untestable.

Bob Bartlett, marketing director at Credence Systems’ NewMillennia Solutions division, which develops test strategies targeted at specific devices, including RAMBUS memories, sees the industry’s wish list including a one-size-fits-all tester offering a few hundred pins for less than $1000 per pin—a goal much more attainable than Turino’s fanciful four-pin tester, but one Bartlett believes will remain illusive. He and his colleague Loranger emphasize that software will be a key ingredient in successful test approaches—an extensive software suite will be necessary, they say, to develop testable products, to develop test programs, to interpret results, and to provide feedback to EDA tools based on failure-analysis data. Bartlett foresees approaches emerging in which a tester might include a few 800-MHz pins, for example, with the remainder restricted to 50 MHz to keep costs down.

There's no doubt that price and performance tradeoffs will be a big part of the decision to use structural or functional test. Teradyne has taken a step in that direction with the J973EP VLSI tester, whose Real Time Enabling feature lets you order temporary upgrades in frequency, accuracy, and pattern memory over the Web in an effort to economically juggle structural and functional test operations. The J973EP offers a 200-A power-supply option, as opposed to the 20-A capability of typical systems, to handle the high current that structural test can require for handling the high simultaneous switching rates of large numbers of chip components, including scan latches and other DFT circuitry.

According to Rod Stewart, Teradyne product marketing manager, the J973EP’s approach enables users to experiment with structural tests yet add functional test capabilities with a phone call should they encounter defects that escape structural-test detection. In three to five years, though, he expects some customers to know before they buy what levels of structural and functional test they need. At that point, he says, dedicated structural and functional test approaches will begin replacing the more flexible approach embodied in the J973EP for some portion of the market.

He sees structural test emerging as an adequate approach for next-to-latest generation processes—it might be adequate for 0.25-micron processes, for example, but inadequate for 0.13-micron designs. He adds, though, that more than just raw fault-detection capability will always play a role in test-strategy selection. For example, he says, a vendor selling an ASIC to a single customer may be able to negotiate a relatively high defects per million (DPM) level that structural test alone can meet. A vendor selling one chip to 50 customers, though, won’t have the luxury of negotiating DPM levels with each customer and may require the full functional testing that would ensure DPM levels near zero.

Rudy Garcia, strategic marketing manager at Schlumberger’s Semiconductor Solutions group, foresees a move toward a distributed test strategy in which structural tests might take place at the wafer-sort stage, with final functional tests occurring on packaged devices. For a manufacturing flow involving this distributed-test strategy, he sees structural testers emerging as specialized systems, not simply lower-cost, lowerperformance versions of functional testers.

The structural testers, Garcia says, would make use of the scan chains and other embedded DFT to provide high levels of graded fault coverage to detect stuck-at, transition, delay, and I_DDQ faults. But Garcia adds that there will remain other defects that can’t be detected by all the avaliable fault models, and he suggests that simpler, yet at-speed, functional tests that aren’t necessarily fault graded can target those defects and exercise mixed-signal cores, RF segments, and other device elements that won’t yield their secrets to structural tests.

Garcia notes, too, that structural testers might require clock performance that rivals that of functional testers. Although toggling test vectors into scan chains isn’t a demanding task, structural tests of on-chip functions such as PLLs might require a high-speed, rock-solid clock. He adds that for some chips, it might not be possible to exercise multiple scan chains simultaneously, either because of restrictions stemming from multiple DUT clock domains and the DFT implementations used, or because of power-dissipation considerations. An effective structural tester must efficiently schedule successive scan tests without imposing excessive test-socket-insertion time penalties. That, he says, is a function at which today’s functional testers with scan-buffer memory don’t excel.

In addition to structural-tester functions, a matter of concern is the method of adapting design-automation data for test-program use. Proprietary tools such as Fluence's TestScanPlus help serve that purpose now, and one standard—the IEEE 1450 STIL (Standard Test Interface Language)—is emerging that could smooth the task (Ref. 10).

An open question is who will drive the move from proprietary formats to STIL—EDA companies, ATE companies, both, or neither? Firms on both sides of the wall separating design from test have business interests in protecting their proprietary formats; ATE firms, for example, would prefer it not be easy for you to move your test program to another manufacturer's system. The move toward STIL could be driven by the firms' customers who push the hardest. That said, firms on both sides of the wall have evinced interest in STIL. For example, Fluence (whose WGL language served as a basis of the STIL standard) offers STIL compliance-testing tools, and an Advantest engineer has detailed how to convert STIL outputs for use in his firm's test systems (Ref. 11).

An efficient design-for-test strategy would benefit greatly from the removal of the wall separating design and test. Synopsys and Agilent Technologies are hoping to do just that—in March, they announced a joint initiative in which Synopsys will explore methods of making its EDA and DFT tools, such as DFT Compiler, aware of a target ATE system's capabilities so DFT structures might be optimized for that particular test system. For its part, Agilent Technologies will fine-tune its ATE systems, particularly the 93000 Series SOC testers, to take full advantage of DFT capabilities that designers implement within a chip using Synopsys tools.

The goal, says David Hsu, director of marketing for Synopsys's test-automation products, is "ATE-aware design tools and DFT-aware ATE systems" to ensure that Agilent and Synopsys engineers—not their customers—uncover potential test-related glitches in product designs. Mick Tegethoff, Agilent Technologies' EDA/DFT marketing manager, says the joint initiative will build on standards like 1149.1 and STIL to enable optimized structural test and automate tasks such as test-vector formatting. Details remain to be worked out, and results of the initiative could range from self-repairing chips to ones that reconfigure themselves based on the ATE system used to test them. T&MW

References

1. Wu, David M, et. al., “Can DFT Totally Delete Traditional Functional Testing?” Proceedings, IEEE International Test Conference 2000. p. 1142.

2. Available from the Open SystemC Initiative, www.systemc.org.

3. Dervisoglu, Bulent, “Why Can’t DFT Totally Eliminate Functional Test?” Proceedings, IEEE International Test Conference 2000. p. 1145.

4. Patel, Janak H, organizer, “Stuck-at Fault: The fault model of choice for the third millennium!?” Proceedings, IEEE International Test Conference 1998. p. 1164.

5. Rearick, Jeff, and Peter Maxwell, “Deception by Design: Fooling Ourselves with Gate-level Models,” Proceedings, IEEE International Test Conference 2000. p. 921.

6. Mitchell, Barry T., “Operating-Extremes Test Improves Reliability, ” Test & Measurement World, November 2000. p. 45.

7. Chiusano, Silvia, et. al., “Non-Intrusive BIST for Systems-on-a-Chip,” Proceedings, IEEE International Test Conference 2000. p. 644.

8. Frisch, Arnold, “Mixed Signal BIST Resource Partitioning.” You can download a PDF version of the paper, presented at an ITC 2000 panel but not included in the Proceedings, from this page: www.fluence.com/bistmaxx/index.html.

9. “Boundary Scan Gains ITC Attention,” Test & Measurement World , November 2000. p. 6.

10. Taylor, Tony, and Robert Ruiz, “Elements of STIL bridge design and test, ” Test & Measurement World, January 2001. p. 39. 

11. Parnas, Bruce R., “Doing it in STIL: Intelligent Conversion From STIL to an ATE Format,” Proceedings, IEEE International Test Conference 2000, p. 64.

Rick Nelson received a BSEE degree from Penn State University. He has six years experience designing electronic industrial-control systems. A member of the IEEE, he has served as the managing editor of EDN, and he became a senior technical editor at T&MW in 1998. E-mail: rnelson@tmworld.com.

    Copyright 2001, Test & Measurement World. Published by Cahners Business Information, Newton, MA.

Table 1. DFT tools for semiconductor devices