Testing ASICs means more than just designing for test. Although today's sophisticated DFT tools are a big step forward from earlier ones, intelligently tackling test requires a partnership between design and test--and designers' full appreciation of what test is all about.

Even if you think you know all you need to about ASIC test, don't turn the page quite yet. Sure, you know that, thanks to structured de-sign methods, you can create chips of in-credible complexity in less time than it took to develop devices only one-tenth as complex just a few years ago. And you probably also know that, in some cases, structured design-for- test (DFT) techniques can reduce creating test patterns to a pushbutton operation that takes less than a day on a workstation. A few years ago, pattern generation, per- formed manually, was a tedious, error-prone ritual that could consume months.

That's the good news about ASIC test. But there is a dirty little secret too--a part that too many design engineers have tried to pretend doesn't exist: Making sure before you have silicon that the devices will be testable when silicon finally arrives requires much more than turning an automatic-test-pattern-generation (ATPG) package loose on the design. Test-development can still take months and, in the case of mixed-signal ICs, sometimes stretches to over a year. But there's more good news: Suppliers of electronic-design-automation (EDA) tools and automatic test equipment (ATE) are introducing a host of products to automate dozens of tasks that are essential for developing adequate tests. Designers previously performed these tasks by hand.

[Picture 1] These tools fit into a category called "virtual-test" (VT) tools. Cadence Design Systems was among the first to use the term in connection with IC test but has not applied for a trademark and has no plans to apply for one. Indeed, the company would be happy if other vendors began using the phrase. Marv Wolfson, vice president of Cadence's test-software business, thinks that such acceptance would enhance the concept's credibility. Nevertheless, because there is no universally agreed-upon scheme for categorizing EDA tools, Wolfson is concerned that other companies could confuse users by attempting to alter Cadence's meaning.

That meaning is specific: VT tools allow test engineers to create, optimize, simulate, and debug test fixtures and device-test programs that can run on ATE systems. VT tools' main goal is to shorten product-development cycles through more efficient use of test-engineering resources. The tools, which begin by taking input from the device's design database, allow users to complete most test development before silicon becomes available without tying up scarce and expensive ATE.

An added benefit is the tools' ability to reveal device-design problems that affect testability. Through VT, users can demonstrate that devices are testable before transmitting the designs to a foundry. Designers who learn about test problems soon enough can modify their designs to eliminate the need for costly work-arounds or even costlier mask redesigns. VT recognizes that the roles of design and test engineers are complementary and that test engineers are designers, albeit not of products--but of the fixtures, test programs, and procedures that make possible economical production of high-quality products.

Don't be confused by the seeming similarity between VT tools and a more familiar type of EDA tool, the design-rule checker. To be sure, both types of packages help to ensure testability, but design-rule checks occur earlier in the design cycle--before the insertion of the chip features that provide testability. Design-rule checking aims to verify that automatic test-structure insertion packages can, in fact, add features that provide high fault coverage. As part of creating test packages, VT tools can complement design-rule checking by proving that rule checking has achieved its goals.

The most appropriate term for the universe of tools involved in ASIC test is "test-development automation" (TDA) tools. (Some vendors use the term "test-automation," but the tools, most of which are software, don't automate testing; ATE does that. The tools automate various aspects of test development.) The box, "The tortuous path to IC quality," and the table, "Test-development-automation tools," indicate the types of tools and their significance in test development. The listings should shed light on the roles of classes of tools. In the manufacturers' box, you'll find names of EDA suppliers that offer TDA tools as well as names of vendors of semiconductor ATE systems.

According to Ben Bennetts, senior test consultant at Synopsys, achieving a testable design for a digital IC involves the following five primary steps, which Bennetts attributes to Robert Aitken of Hewlett-Packard:

• Design-rule checking to make sure that the design conforms to the rules for the chosen DFT methodology or methodologies--full or partial scan, built-in self test (BIST), boundary scan, or IDDQ (a technique for CMOS ICs that finds faults by measuring a chip's quiescent supply current, I_DDQ). The rule-check preconditions the circuit for the insertion of test structures that implement the chosen methodologies.
• Test-structure insertion--for example, conversion of D flip-flops into scannable latches. Test-structure insertion is often called "test synthesis"--another somewhat misleading term. Test synthesis doesn't synthesize tests; it synthesizes silicon structures that make it convenient to design tests.
• Global reoptimization to assure that the design that now includes test structures meets the original constraints on such factors as timing, area, output-drive capability, and power dissipation.
• Test-pattern generation, or the generation of test patterns that, when applied to the circuit, make faults observable.
• Fault simulation and fault-coverage grading of test-vector sets. Fault-coverage grading is commonly referred to as "fault grading." However, fault grading doesn't grade faults; it grades vector sets' ability to detect faults.

Although modern test-pattern generators include fault simulators, freestanding fault simulators can still be useful. Such simulators start with functional vectors (developed for design verification). These vectors provide structural-defect coverage without additional effort. Functional vectors usually provide 40 to 50% fault coverage and often catch timing-related faults. Whereas fault coverage of 40 to 50% is usually not adequate for production test, it can be a good starting point. Moreover, timing-fault coverage is something that scan-test vectors don't normally provide.

Even though these five steps go a long way toward assuring testability with a specified degree of fault coverage, they do not, in general, complete the job of producing a testable design. That job involves steps such as design and debugging of test fixtures and test programs. Although the test vectors that ATPG tools create are the most important elements of a test program, they aren't the program. Moreover, until you debug the test fixture and test program, design problems that affect testability may remain hidden. This is especially true when devices are complex or have appreciable analog or mixed-signal content or when the specifications push process limits or tax test-equipment capabilities.

An objective of virtual-test tools is to minimize the likelihood that the test fixture, test program, or ATE idiosyncrasies can interfere with valid and adequate testing. To be useful for this purpose, the tools must not add appreciable delays to the design cycle. Design engineers and program managers cannot tolerate a process that delays the transmission of a design to a foundry by more than a few days.

However, the need to rush products to market is no greater than the need to turn over every stone when looking for device faults. Semiconductor test and process engineers often use the following equation to determine how high a test process' fault coverage must be. Although some of the assumptions underlying the equation are open to question (uniform density of defects across the wafer, for example), nobody has come up with a technique for calculating required fault coverage that is easier to apply or in which reliability experts have more faith.

where DL=defect level (the portion of devices that pass the test but are, in fact, defective), Y=yield (the portion of all devices tested that are good), and FC=fault coverage (the fraction of all possible faults that the test can finding).

Thus, if the fault coverage is 90% and you can't tolerate more than 0.1% bad devices' getting through your test process, you must be confident that the manufacturing process (before testing) yields at least 99.1% good devices.

In other words, if the fault coverage is 90%, and 80% of the devices you send to test are good, 2.2% of the devices that test tells you are good, are, in fact, defective.

[Picture 2] In today's market, few applications can tolerate defect levels as high as 1000 ppm, let alone 2.2%. Most applications, even commercial ones, require defect levels no higher than 200 ppm. The message is clear: 90% fault coverage is rarely adequate. Adding to the problem of achieving adequate fault coverage is the assertion that devices that purportedly can be tested with 100% fault coverage using scan-test vectors actually achieve fault coverages no higher than the low 90% range when tested with functional vectors. If this assertion is correct and if the faults detected in functional testing are not delay faults--which scan does not claim to catch--the allegation that scan-test vectors provide less than 100% coverage raises doubts about the effectiveness of scan methodologies.

Because no single test method reveals every fault, if you need a low rate of test escapes (defective devices that escape detection in test), you need to use a combination of test methodologies: full scan on portions of the chip that are amenable to full scan, partial scan elsewhere, boundary scan on the I/O lines, BIST on structures such as RAM, IDDQ to detect faults that elude the other methodologies, and possibly some delay-fault testing. Although such a mixed approach may sound too complex to be practical, industry experts are nearly unanimous on its validity. Moreover, with the right suite of test-development tools, you can achieve high fault coverage more easily by mixing methodologies than by doggedly applying a single, sometimes inappropriate, approach.

IDDQ is a promising technique. Thanks in part to a well-documented study that has become an industry classic (Ref 1), the approach is starting to see broad application. IDDQ has several advantages: It imposes minimal constraints on chip designers. Although it may be advisable to add structures to the silicon that initialize the chip for IDDQ tests, such structures aren't mandatory. Creation of IDDQ vectors requires minimal knowledge of a chip's operation. You need no more than a few hundred IDDQ vectors to provide high fault coverage--even for chips with half a million gates. And, although definitive studies are still lacking, several people familiar with the technology expect to see a high correlation between I_DDQ) and delay faults.

That's the good news about IDDQ testing. The bad news is that, today, the tests are so time-consuming that few foundries apply more than a small fraction of the IDDQ vectors needed to achieve high fault coverage. (The number of vectors applied usually is under 20. Such limited IDDQ tests act as an adjunct to functional and scan tests.) IDDQ tests are slow because you must measure tiny currents--micro- amps at most--and, on ATE systems, only the slow pin-measurement units can perform the task. Help is on the way, though. An industry group called QTAG (the name was adapted from JTAG, the Joint Test-Action Group that ultimately became the IEEE-1149 Boundary-Scan Committee) will shortly announce a design for a bipolar current-to-voltage-converter IC housed in an eight-pin SOIC package that test engineers can mount on device-under-test (DUT) boards. The IC significantly speeds IDDQ testing by supplying a voltage proportional to Ithat ATE systems' high-speed hardware can measure.

[Picture 3] A second problem with IDDQ is that setting test limits often involves a trial-and-error process, which, in turn, requires actual devices. However, software to predict the levels of Iin good devices should arrive soon, allowing designers to set test limits accurately before the arrival of first silicon.

Whereas nearly half of the types of TDA tools fall into the VT category, less than half of the available TDA products are VT tools. VT tools complement--but do not replace--the more classical DFT and ATPG tools. To be sure, designs of certain types--mixed signal, for example--need VT more than do other types of designs. The most ambitious EDA-related VT tool is probably Cadence's Dantes (an acronym derived from design and test engineering system) for analog and mixed-signal designs.

Version 2.0 of the two-year-old tool will debut at the 1994 International Test Conference in October. Among its capabilities is test-rule checking to make sure that proposed tests do not ask the test equipment to do things it can't do. This capability assures, for example, that you don't ask a voltage source to slew faster than its specified maximum rate. Dantes also provides several features to aid in documenting test setups and parameters; it can accept input in the form of test schematics. Moreover, it automates the layout of test fixtures such as DUT boards.

Dantes lets you simulate these boards, including their parasitic inductances and capacitances. Thanks to the cooperation of ATE vendors, Dantes also permits simulation of the resources of mixed-signal test systems. These resources include such components as voltage/current sources, measurement subsystems, and switch matrices. Coupled with design data on the device to be tested, this simulation capability lets you accurately predict how a device will behave on a real tester.

Even after you simulate individual tests, you don't have a complete test program; you have a collection of tests. Although you might think that a test program is nothing more than such a collection, that isn't the case. Transforming the tests into a working program involves a bit of science and a bit of art. This is where tester-specific VT tools enter the picture.

Test-sequencing tools (one type of tester-specific tool) attempt to minimize test time by looking at the tester and device states at the end of each test to make sure that a minimum number of things must happen before the next test can run. Here, "things" means vectors that must be applied to the DUT or commands that must be executed to make various tester resources ready for the next test.

Even when test sequences are determined in the manner described above, throughput is not necessarily maximized. Tests that devices are most likely to fail should run first. This minimizes the time spent testing devices that will ultimately be rejected. Test-program-optimization tools attempt to strike a balance between tester- and device-state considerations and the likelihood that devices will fail individual tests.

Another part of test-program optimization is binning of devices. Binning is more of a concern with standard analog and mixed-signal parts than with most ASICs. Vendors often sort analog ICs into multiple performance grades, but binning can also affect digital ICs--an example is µPs that are sorted into several speed grades. Binning strategies can influence test sequencing and throughput: You can save time when devices placed in lower performance categories need not undergo all tests.

A device can fail a test because the device is bad or because of problems with the test or the test program. Test-debugging tools provide visibility of the state of the tester, its individual resources, and, sometimes, the DUT itself to aid in determining what has gone wrong when the test results do not agree with the expected results.

[Picture 4] Some observers of the IC-design scene comment that the role of the test engineer is becoming superfluous or that modern EDA tools are reducing the role of the test engineer to that of a technician. That is not the case. In reality, test engineers are design engineers. Instead of designing products, they design the fixtures, test programs, and processes that make possible the economical, high-quality manufacture of products thought up by design engineers. New TDA tools offer test engineers power similar to the power that EDA tools place in the hands of design engineers. But for companies to derive the full benefit of TDA, design engineers must develop more understanding of the evolving role of test engineering. And, most important, partnering between design and test must begin very early in the life of each project.

1. Maxwell, Peter C, R Aitken, V Johansen, and I Chiang, "The effectiveness of IDDQ, functional, and scan tests: How much fault coverage do we need?" Proceedings of the International Test Conference 1992, pg 168.