Successful ASIC test requires cooperation

With increasing numbers of ASICs finding their way into high-volume products, production testing of these devices must be fast, complete, trouble-free, and economical. To achieve these goals, customers, chip designers, test engineers, and manufacturing personnel should hold early and frequent discussions.Before the chip design begins, all parties should understand and agree on the production-test requirements and how they will be met. At a design kickoff meeting, the following personnel should discuss the overall test plan:

• the customer (the OEM who will incorporate the ASIC into an end product or system),
• the ASIC designer,
• the DFT engineer, and
• a test engineer representing the target foundry.

To guide the discussion, participants can use a checklist that highlights many of the initial test requirements as well as the customer's expectations. Because ASIC designs are unique, and implementing a test methodology is a complex and daunting task, no single checklist can address all devices (see our sample checklist). In general, meeting participants should consider several factors when reaching a consensus on ASIC production testing:

• The required level of fault coverage for manufacturing defects;
• the type of fault models to support—for example, stuck-at faults or quiescent-current (I_DDQ) faults;
• the number of DFT elements, like boundary-scan cells and memory built-in self-test (BIST) circuits, that designers can embed without seriously adding to the chip's cost or compromising its functionality; and
• the incorporation of any prepared tests that accompany blocks of intellectual property (IP) from third parties.

Other key considerations focus on the capabilities of a foundry's available production testers—they include:

• How many I/O pins and scan chains can the target ATE system handle at once?
• Are backup test systems available and up to the task should the primary test system become unavailable?
• What if any requirements are there for supplemental tests, such as extreme voltage or temperature performance?
• What software tools—and what versions of those tools—will generate necessary test programs?

The earlier you decide which tests to run, the better. For example, if a consensus develops for I_DDQ tests, the design engineer could incorporate a global signal line that shuts down current-drawing circuitry like phase-locked loops. To accommodate logic scan, the design engineer could substitute scan equivalents for conventional flip-flops.

Without explicit requests by the customer to test at, say, temperature and voltage extremes, the foundry probably will perform no more than the bare minimum of tests. If an ASIC is destined for an undersea or satellite application, it needs to be tested for extreme temperatures and other conditions that a consumer product does not. The ASIC customer must specify those tests.

Any test plan must start with a basic DFT philosophy. Although a fully tested ASIC is critical to the success of the product built around it, the ASIC's first and most important job is to deliver its specified function. Therefore, the most basic rule behind any DFT philosophy is to test the part to the highest degree possible without compromising its functionality.

Working within this framework, the ASIC DFT engineer must balance tradeoffs among design considerations, available DFT techniques, and the needs of the production test floor. Toward this end, the DFT engineer should thoroughly review the documentation that details the customer's specifications and requirements. These documents can vary widely in the amount of test-related detail they contain. Some documents might call out highly specific methodologies, tools, and implementations, like the number of RAM BIST blocks and the type of RAM BIST controllers to use, while others will virtually ignore test topics. Regardless, the DFT engineer must make sure that the chosen DFT philosophy not only meets the customer's requirements, but also can be transferred to the manufacturing test floor.

Several proven test techniques—including scan test, boundary scan, and BIST—are available to the DFT engineer. Many commercial DFT tools include options that tailor their output to specific ASIC vendors and foundry processes, and typically, a foundry approves specific BIST tools that the DFT engineer can use in the ASIC design flow. Problems can arise, however, if the DFT engineer applies the tool in a way the foundry doesn't expect or if he or she employs a version of the tool that the foundry hasn't qualified. The tool itself is likely to give several choices for the BIST-circuitry structure and test-vector format, some of which might not be transferable to the foundry's manufacturing test floor. The DFT engineer considering a specific DFT tool should study application notes or guidelines published by the foundry relating to the tool's use.

The cost of added ASIC test elements in terms of the target product's application and life cycle will affect the DFT approach taken and must be accounted for up front. A customer may initially demand 97% fault coverage (requiring full scan cells) for logic circuitry as well as extensive memory BIST (to test memory cells that aren't amenable to scan test techniques). Such DFT demands might increase chip area by 10%. This test approach might be acceptable for some applications, but it also might be overkill, with the cost of these added structures becoming prohibitive for high-volume devices used, for instance, in engine control assemblies. Faced with such costs, the customer may choose to relax DFT requirements, especially if defective assemblies can be readily swapped out of the engine compartment.

Furthermore, a specified level of fault coverage can't be guaranteed until a design is complete and fault-coverage tests are actually run, either on hardware or in simulation. Some logic circuits, if they are in a critical timing path, may not accommodate the added delay of a scan flip-flop, making them untestable using scan techniques. In that case, the DFT engineer will have to write separate tests for the critical path elements. Under these circumstances, a 95% scan-based fault coverage coupled with separate critical-path tests can effectively meet the customer's testability goals.

Because even familiar and fundamentally simple test mechanisms can grow in complexity, the DFT engineer should be cautious when embracing the latest test tools and techniques. Even memory BIST, the most mature of BIST implementations, can be difficult to implement if an ASIC includes numerous single- and dual-port RAMs of widely varying sizes in multiple clock domains. Also, adding BIST has a ripple effect on other portions of the design flow: It must be accommodated in the physical layout, it alters the register-transfer-level (RTL) code, and it creates source-control issues (Figure 1). 
 

module MEMORY_72X64_COLLAR ( CLK , WE , ......... DO ); input CLK ; input [63:0] WE ;     .     .     . output [63:0] DO; wire BIST_wire_1;     .     .     . wire BIST_wire_20; MEMORY_72X64_MEMBIST_LOGIC MEMORY_72X64_MEMBIST_LOGIC_INST (........... ); MEMORY_72X64 MEMORY_72X64_INST ( ........... ); endmodule #------------------------------------------------------------- module MEMORY_72X64_MEMBIST_LOGIC ( ........... );     .     .     . COMPARE_FLAG_MUX COMPARE_FLAG_MUX_INST ( ........... );     .     .     . endmodule #------------------------------------------------------------- module COMPARE_FLAG_MUX ( ........... );     .     .     . endmodule

Figure 1. Even relatively familiar and fundamentally simple test mechanisms, like memory built-in self-test (BIST) circuits, can grow in complexity when applied to dense ASICs. Adding BIST and other test mechanisms alters RTL code and has a ripple effect on other portions of the design flow.

For example, if one RAM BIST controller is assigned to many RAMs, the number of nets required may be difficult to lay out, leading to congestion. An alternative approach would be to add BIST controllers, giving the DFT engineer freedom to space the controllers closer to the RAMs. Similarly, by placing BIST controllers at the different layers of a hierarchical design, the DFT engineer can adjust the effect—specifically the nets and ports required—on different layers. This, in turn, will affect the physical layout of the chip, the floor plan of various blocks, and, ultimately, the RTL code. In short, because it affects the design flow and the netlist, no DFT methodology should be taken lightly.

Once the customer and the design and test engineers settle on a suitable DFT philosophy, avoid straying from that philosophy. Making changes six months into a year-long project can be disastrous. Even if the ASIC design changes, you should change your test strategy only if the modifications cause the original test methodology to break down completely.

The test requirements for an ASIC fall into two major groups: functional and manufacturing (or production). Functional tests ensure the ASIC's performance is consistent with its design specification. These tests should be run at the chip's operating speed, typically in the hundreds of megahertz to gigahertz range. Thorough functional tests can take hours or days to run and frequently require complex verification environments. Consequently, if any functional tests are performed in a manufacturing environment, they are a very small subset of the complete functional test suite and typically are run at a fraction of the chip's operating frequency.

In contrast, the assumption behind production tests is that the ASIC has been correctly designed to meet its specified functionality. For that reason, it is neither necessary nor desirable during production test to apply the exhaustive and lengthy tests that the ASIC design team uses to validate functionality.

Instead, production tests most often are tailored to find defects associated with the ASIC manufacturing process (Table 1). Preferably compact and efficient, the production-test suite must run in as little time as possible, typically in less than a second. Many production tests apply a stimulus to an ASIC's inputs, monitoring one or more outputs for an expected value. A classic example of this form of production test is a scan test, in which a tester applies the vectors from an automatic test-pattern generation (ATPG) tool to check for stuck-at faults.

In addition, some production tests measure analog parametric values, like V_IL and V_OH, or leakage current (I_DDQ). These parametric tests detect manufacturing defects, other than stuck-at faults, that can affect ASIC quality and performance. Further vector sets that complete the manufacturing test suite can include memory or logic BIST, on-chip process monitors, and I/O tests for three-state and bidirectional buffers.

Among the subtler problems that can arise when applying a set of test vectors to an ASIC is the effect of batch-to-batch process variations. Each manufacturing test must be simulated against best-, nominal-, and worst-case timing conditions to ensure that the expected test-vector data is consistent across chip manufacturing variations.

The importance of knowing, as fully as possible, the exact manufacturing test requirements from the outset of an ASIC's design cannot be overstressed. These requirements typically include two main components: the requirements of the customer and the requirements of the ASIC vendor. The customer typically will impose general requirements, such as a minimum fault-coverage percentage or a requirement that all RAMs be fully tested. The ASIC vendor also will have a strictly regimented series of manufacturing tests that each part must pass. These tests, which usually include an open/short test of all I/O lines and a gross I_DD current measurement test, weed out gross failures, so you don't waste precious time with unnecessary testing.

It's easy to see why you need to spell out the test requirements up front. Consider a case in which a customer wants a test that exercises all three-state buffers, including bidirectional buffers. The test will ensure the buffers can achieve all applicable input, output (for bidirectional), and high-impedance states.

By knowing about this requirement up front, the DFT engineer can insert boundary-scan cells on the buffers and their enable lines to make it easy to control the appropriate enable line and to load input or output values. The buffers then can be exercised and monitored in all possible states in a straightforward manner.

This approach obviously is better than one in which the customer or ASIC vendor casually mentions halfway through the ASIC program that he or she requires that all three-state buffers be tested. At that point, it may be difficult or impossible to develop a short, effective functional test that toggles all the three-state buffers. Without boundary-scan cells, achieving these states for every three-state and bidirectional buffer in a large ASIC would require a long and complex functional test if, as is likely, the buffers and their enable lines are driven by circuitry deep within the ASIC's core.

Should the customer want a "warm and fuzzy" assurance of the chip's functionality, the ASIC designer may need to assemble a small suite of functional tests to augment the production test suite. In many cases, these tests cannot be run at speed because of the physical limitations of the tester itself or other limitations such as connectivity (for instance, long lead lengths between the tester, the test head, and the DUT). Even if all requirements for at-speed testing can be met, the customer must realize that difficulties encountered with such testing typically warrant additional charges.

The customers also may request specific manufacturing test procedures beyond the routine, calling for supplemental tests. Some examples include checking sample devices at temperature or voltage extremes or logging the results of parametric tests. Like other points on the test checklist, these requirements should be aired early on. Key factors to consider are whether the foundry is equipped to handle such tests and what they will cost.

Factors that determine whether a particular manufacturing tester is suitable include the chip's function, package type, pin count, and test throughput. In devising a manufacturing test suite, a DFT engineer must not exceed a tester's capacity. For example, take the case of an engineer seeking to cut test time by increasing the number of scan chains. If a design has 1000 flip-flops and one scan chain, it takes 1,000 clock cycles to load the chain.

For a faster test, a DFT engineer may decide to raise the number of scan chains to four, eight, 16, or even more, proportionately decreasing the number of required clock cycles. The effort is wasted, however, if the target tester cannot handle—by virtue of limited pin count or scan-buffer memory—the chosen number of scan chains.

Make sure the test plan does not limit manufacturing test suites to ones that can run only on a foundry's most advanced tester. Should that tester become unavailable, it's reassuring to know that the suite can fall back to another, less capable, machine. If two testers can handle an ASIC's 1000-pin package, but one can check 16 scan chains at once while the other can test only eight at a time, a designer might wisely limit the number of scan chains to eight. In the case where only 3000 parts are planned over the course of a year, the option of going to another tester hardly matters. If millions of parts are planned, however, the flexibility of switching to another tester could be a lifesaver.

In summary, experience shows a direct correlation between trouble-free ASIC testing on the manufacturing floor and communication among the customer and DFT and test engineers. More often than not, a decision by any one group affects the others. So contact your peers. Start a checklist. Add to it, subtract from it, and modify it as needed. But most important, start now! The success of your production tests can depend on it.