ASIC Technology

ASIC Multidimensional Design for Test

Test-related time-to-market delays and loss of market share are often the result of not fully understanding design for test methods.

by Nick Arreguy

Design for test (DFT) is commonly perceived as including functional tests, scan insertion, BIST, JTAG, automatic test-pattern generation (ATPG), and fault grading. Multidimensional design for test (MDFT) also includes these factors, but must also account for production test economics, test equipment, test methods, manufacturer's constraints, and design schedules (see Figure 1). If any one of these factors is overlooked, ASIC release-to-production delays may result. Addressing them in advance significantly improves the chances of successful MDFT and completion of the design on schedule.

Production test economics constraints Production test economics force the ASIC designer to maximize fault coverage and functional verification using both test vectors and ASIC functions. The customer must share functional, mission, ATPG, high-speed, and other tests with the manufacturer's required tests, such as parametric and I _ddq tests. This must be done within the allotted time and vector count.

Figure 1. ASIC (MDFT) components include more than traditional primary components: functional and scan tests, BIST, JTAG, ATPG, and fault grading.

Typically, parametric testing is the first test of the test suite. Parametric testing screens chips for defects in inputs, outputs, and excessive I _ddq current. Parametric testing is inherently time-consuming and can require a great many test cycles if an ASIC design is not optimized for test.

I _ddq testing measures the quiescent current of a device and can effectively detect several kinds of defects in CMOS that are not otherwise easily found with the usual stuck-at fault test. However, getting the device into a quiescent state makes I _ddq measurement a very slow process, supplying input vectors to get the internal nodes into a known state and waiting for the inrush currents to subside.

The designer can determine if high-speed testing is necessary by characterizing a few prototypes at high speed, then comparing the AC measurements to simulation results. If the measured results match or outperform simulation results, then the risk is small, and high-speed manufacturer testing is unnecessary. However, if high-speed characterization indicates that any AC specification is not met--such as longer propagation delays or insufficient setup and hold times--and if tester parasitics are understood and properly accounted for, then there is a failure with the manufacturer's process or timing extraction. This is when at-speed testing is required.

The number of test vectors can be substantially reduced by adding special circuitry to isolate, control, and improve observability of secondary objects, such as modules, submodules, memory, and cores. Along with specially designed test vectors, fault and functional coverage can be increased to acceptable levels. This strategy is particularly effective in highly pipelined architectures that require several millions of cycles for complete functional verification. Full or partial scan test, however, tends to increase power consumption or gate counts.

Test-equipment constraints Test equipment consists of a complex combination of hardware and software. Therefore, chip test functions and vectors must be made to match the tester's capabilities and limitations.

The tester's interaction with the ASIC may differ from the environment of the ASIC system. The chip may perform or behave differently in the tester than in the system (see Figure 2). For example, the rise times of tester inputs and the tester's output impedances may not be equivalent to those of the system. Specific functions and vectors are necessary for test, even though they are not used at any other time. Contention may not be permitted with a bi-directional signal. An input control signal cannot enable itself as an output on a test. Tester limitations as well as differences between the tester and system environments as seen by the ASIC require separate simulations for each environment: tester and system.

Tests exceeding equipment capabilities will be rejected by the manufacturer, because tests that exceed tester specifications reduce yields and do not ensure that only good parts are shipped. Good parts can fail a test, crimping product supplies, and limiting customer and manufacturer profits.

Methodology constraints For top-down DFT design verification, in which high-level vectors are employed for ASIC test, constraints can be incorporated into high-level simulations. Stimulus and the expected response generated from a programming language, a hardware description language, a data base, or a mixture of such sources must produce identical results when used in simulations at the system, behavioral, and gate levels.

Often, translation of higher-level simulation vectors is required to match lower- and gate-level simulations. For instance, a "C" program simulation may not account for the needs of gate-level simulation tests. Usually, only data values are of concern in the high-level verification procedure. Additionally, high-level vectors may not account for the ASIC's databus control or status signals required in gate-level simulation. Therefore, translation steps must occur between high and low-level simulations to correctly verify results.

Figure 2. Test parasitics often cannot match the system environment's parasitics. Tester input edge-rates and output-impedance differences can make accurate high-speed test impossible. Customized load boards can be built to match test with system impedances, but this is not always successful and increases test costs.

Data direction changes on bi-directional nets are a common verification problem. Often the manufacturer avoids driver contention between tester and ASIC by putting the tester's bi-directional driver into its third, or "neutral," state when a data direction change occurs. The tester neither asserts nor strobes data--the last value driven may remain, however. Properly accounted for, simulation of the tester and ASIC as a unit ensures data is neither asserted nor strobed during this test cycle.

Whether or not top-down design methods are used, two verification steps are essential. First, the entire test-related database must comply with the tester's and manufacturer's specifications. After compliance is assured, the stimulus and the expected response are incorporated into a virtual testbench supplied by the manufacturer. A virtual testbench simulation applies the same stimuli as the tester, compares the response to that expected from the tester, and reports any differences. The virtual test simulation is meant to trigger failure mechanisms in functionality or vectors that would otherwise make themselves evident on the test floor.

The use of tester assertions in fault grading indicates final fault coverage of the test vectors. In general, bi-directional pins and tester input sensitivity to skew cause the majority of trouble. Input clock and data sensitivity to tester skew cause test simulation failures. A virtual tester skews input assertions to the maximum tester-uncertainty specification.

The designer should employ various strategies to uncover hidden flaws in the silicon. "Scan vectors," "mission vectors," and "parametric vectors" are the major methods.

• Scan vectors increase fault coverage to acceptably high levels in minimal vector counts. They are also extremely useful in providing maximum I _ddq coverage quickly.

• Mission vectors provide functional verification.

• Parametric vectors screen faults in the I/O functionality; often JTAG or other special circuitry is employed to meet parametric vector requirements quickly.

Static timing analysis eliminates multi-cycle problems resulting from best- and worst-case timing differences as well as those resulting from coverage misses in the simulation vector. Multi-cycle analysis eliminates false paths. Improper specification of timing information can eliminate a path that is not false, or it can incorrectly specify a multi-cycle definition, thus causing a design to be accepted that should be rejected or at least modified. Many iterations may be required between static timing analysis and simulations when timing failures occur before the static timing scripts are fully debugged.

Power considerations at test may become more of an issue in the future as design densities increase. Power estimation tools can help identify test debug issues or artificially high power usage by identifying vectors where maximum power capabilities of a design are approached. Areas of concern occur when all flip-flops simultaneously change state during a global reset or during ATPG test.

Successful test methods address test constraints from the beginning of a design through the production phases to ensure that hardware and test vectors adequately address every test requirement. This minimizes failure mechanisms in simulation and in actual testing. In general, test-related delays are caused by omitting needed test structures, by incorrectly designing stimulus and expected response vector sets, by not understanding tester software and hardware limits, and by not using exhaustive virtual test.

Figure 3. Mask memory overflow can require extensive effort to manipulate or shorten vectors, or modify or add ASIC functionality. This becomes an issue in less capable testers. Partial scan designs that generate destructive Xs or full scan designs where allowable setup/hold violations cause X states to propagate directly to ASIC outputs cause trouble.

Manufacturer constraints Every manufacturer requires design compliance with all economic, equipment, and methodological constraints for place and route or for mask release. Noncompliance forces the manufacturer to return the design or vectors for modification.

There are many reasons why a manufacturer is forced to return netlists or vectors. Among these are floating internal tri-state nets, untestable vendor-supplied modules, incomplete parametric tests, tester mask-memory overflow, insufficient fault coverage, excessive fanouts, and insufficient design margins. The following are other special considerations for test development:

• Internal bi-directional nets must always be driven, not allowed to float, during I _ddq testing. Therefore, circuitry is required to assure the nets are always driven. If ATPG is used, additional
  circuitry is required to eliminate contention while data are scanned through the registers that enable the internal bi-directional nets.

• Core modules must be multi-plexed to primary I/Os so that manufacturer proprietary test suites or preamble vectors directly access the isolated module, or the manufacturer supplied modules will be untestable.

• Parametric tests may require additional circuitry such as NAND trees or JTAG circuitry. This occurs when functionality makes test of all pins in all states impossible within a reasonable number of vectors.

• Insufficient fault coverage may require additional circuitry or vectors to increase testability.

• Net fanouts that exceed an allowable limit affect simulation accuracy and routing. Re-synthesis is necessary at a minimum. Design changes may be required if re-synthesis fails to correct the problem.

• Tester mask memory overflow (one of several possible tester memory errors) can force netlist changes, vector modification, or truncation. For some testers, the mask memory limit can be as few as 256 patterns. A mask register describes how the tester applies or samples chip inputs and outputs. An output that can be either 1 or 0 without affecting the test is masked. In doing so, the tester says, in effect, "I don't care what the level is on this output." Increasing the number of masked outputs can increase memory requirements. For instance, a two-output chip could require as many as four output mask patterns: compare both pins; mask both pins; mask one, compare the other; compare one, mask the other (see Figure 3).

A simulation in which all outputs are known for all vectors and are stable within tester specifications has only one mask pattern--no patterns are masked.

Masking any one pin for a particular vector increases the memory required for that vector to two patterns. Destructive mask generation during simulation for partial scan-based designs can easily generate many mask patterns. Also, scanned registers that control memory-read signals can cause large numbers of mask patterns when memory setup and hold violations propagate X values to ASIC outputs.

Figure 4. Successful ASIC schedules incorporate MDFT requirements at all design phases, targeting achievable goals within realistic time frames. Note with MDFT, vectors are prepared and verified with all constraints before a netlist is released to layout and mask. Major schedule errors marked in black must be avoided.

Competing requirements complicate the designers' and manufacturer's task almost beyond comprehension. Meeting the requirements before layout and mask release reduces cycle time, minimizes avoidable test related failure mechanisms, and maximizes manufacturability and yields.

Manufacturer-supplied software tools should rigorously examine design and test patterns against these and other innumerable requirements. Your circuit should only be released after successfully meeting every requirement.

Schedule constraints Schedules can affect DFT, in spite of a common perception that the two are unrelated. Frequently, design engineers consider their work complete after they finish functional timing simulations. The chip is released to mask, vectors are released, and the designer goes on vacation. Unfortunately, the DFT work has just begun (see Figure 4).

Overly aggressive schedules force unrealistic deadlines onto design teams. Schedule- driven engineers tend to minimize test issues until functional simulations are complete, whereas a thorough review of test issues can highlight needed design changes. If they are overlooked, a major unplanned schedule revision to make such changes is highly visible and difficult to explain to managers. Unfortunately, schedule pressures cause the designer to overlook test considerations or to attend to them on a minimal basis, hoping that the final design will be correct and complete.

Most manufacturers identify poorly prepared vectors or insufficient test functionality during the design release process. They work with the designer to re-submit a testable vector set or modified design. If an inadequate test suite or a design loaded with errors reaches the test floor, the chip is likely to fail mysteriously. After investigation, corrections to the design or tests must be made, requiring a second pass. Since schedules do not account for test delays, troubleshooting prototype-test failures in the glare of the schedule-pressure spotlight becomes excruciating as schedules slip, costs mount for both manufacturer and customer, and all sense of "satisfaction" is lost.

Designers, to their dismay, often discover late in the design process how much overhead and work is involved in eliminating false paths during static timing analysis.

Manufacturers cannot release to mask or production an ASIC that does not meet all test requirements. Manipulating failing vectors can make them work; however, this may reduce fault coverage, increasing the likelihood of shipping bad prototypes.

Temporary patches, such as test waivers, can be used to preserve prototype schedules. Such waivers are written with the intention, or the hope, that the test problem will be solved by production time. Waivers involve "blind" shipment of prototypes--prototypes that have been tested either partially or not at all. If a test waiver for a release to production were written, it could lead to a public relations disaster. The manufacturer could ultimately take the blame for chip failure in the application. The necessary changes in the design could require the manufacture of several mask sets before the successfully tested chip is released to production.

Schedules based on realistic expectations, tools, and engineering capabilities allow designers adequate time to handle these issues. The classic struggle of quality versus schedule should not be fully dominated by schedule constraints. ASIC design cannot be hurried past the point of reality.

Caveats The multidimensional approach to DFT will not prevent a manufacturer's tools from failing during a test, or prevent functional or timing-related failures based on process extraction, modeling, or other errors or inaccuracies. Sometimes when the cause of failure cannot be determined, prototypes are shipped untested for system trials. Useful for debugging purposes, this can determine whether the problem is in the chip, model, or the test program. For instance, an incorrect simulation model might indicate a determinate response when in fact there isn't one. This can occur on clock outputs or phase-locked loops that are not synchronized during a test. Failures can occur when there are differences between the simulation model and the mask set. Of course, these problems are the manufacturer's responsibility. The quality of the manufacturer's processes, timing extraction, and modeling provide a level of confidence in acceptable correlation between ASIC simulation and system performance over temperature, voltage, and process variations.

Incorporation of test development into the entire design cycle not only minimizes potential mask and vector revisions but optimally tests the ASIC and makes successful system hardware and software verification progress in a reliable manner. The result is higher yields, first time success, and a satisfying relationship between ASIC manufacturer and design house.

Nick Arreguy is a senior program manager of ASIC produts at Motorola Semiconductor's Western Regional Design Center (Sunnyvale, CA).

To voice an opinion on this or any Integrated System Design article, please e-mail your message to michael@isdmag.com.

integrated system design  June 1997