The size and complexity associated with current ASIC design provides immense challenges to those of us responsible for test. It isn't unusual for many engineers to confine testability issues to areas related strictly to circuit design. Indeed, specific functional circuitry, such as embedded cores and on-chip memory, can pose unique problems for test. Just as important are less obvious factors, such as package selection and test vector formats. When classic design-for-test (DFT) methodologies, such as scan and built-in self-test (BIST), are combined with practical DFT, the path to a highly testable design becomes much clearer.

Start at the beginning

Overstating the obvious? You may think so, but the lack of involvement by test personnel during the initial phases of a project isn't unusual - just alarming. I can't think of a bigger error in project planning than the lack of early participation by test engineering. By getting in at an early stage, the DFT engineer can help to influence the design in many ways that will enhance testability. It's very beneficial to establish contact with both the design group and the test "floor" (final test) in order to avoid problems throughout the ASIC flow.

To begin with, I have found that creating a DFT questionnaire can be extremely helpful to the overall process. The questionnaire is essentially a checklist that provides fundamental information relevant to testability. Much of the information will be technical in nature (clocking schemes, input and output definitions, and so forth), while some of the information will cover non-technical issues that impact test (scheduling constraints, additional charges for non-standard tests).

When the opportunity presents itself, take the time to jot down all of the items (technical or otherwise) that have affected test in your programs. Normally, the ASIC vendor will have checklists associated with various phases of the ASIC flow. Scan these checklists to supplement your own items. Formalize the list, and circulate it for feedback within your design and test engineering groups to help ensure that you obtain buy-in from your peers. When the next ASIC program begins, utilize the DFT questionnaire to get the entire staff thinking about testability from day one.

Now I'm in trouble. I've just asked you to increase your paperwork. But wait - my intent is to make your job easier, not tougher. That's right, easier. By creating a manufacturing test specification, you are documenting the exact content of the manufacturing test suite. The manufacturing test specification will spell out exactly which tests are to be created, what they will cover, and their format(s). In addition, a list of all computer aided engineering (CAE) test tools, including version numbers, should be included. The tool list exists for historical purposes, and the ability to easily re-create any test using the appropriate software.

Any relevant test information of concern to you, your customer, or the ASIC vendor, should be included in the manufacturing test specification.

What's the minimum acceptable fault coverage?

In what format(s) will the automatic test pattern generation (ATPG) scan vectors be provided? These types of questions, among others, should be answered in the manufacturing test specification. The document should also include sections giving a brief description of the ASIC, as well as any specific non-standard tests required by either the ASIC vendor or final customer (such as extended range temperature testing).

Figure 1 - Shadow logic

Combinational shadow logic between registered circuit nodes and black-boxed RAM is untestable.

The real key to the manufacturing test specification is the cover sheet. It's a sign-off and release form with a section for test engineering (you), the customer, and the ASIC vendor. When everyone is in agreement about what's to be tested and how those tests will be implemented there is no ambiguity. Once completed and signed, the manufacturing test specification provides a firm stake in the ground where there are no surprises. In addition, completion of your first specification provides the template for successive programs, thus minimizing future efforts.

Design reuse guidelines

Today's ASIC design methodology follows a fairly well regimented flow. Usually, the first steps in the flow are specification development, followed by the register transfer level (RTL) Verilog or VHDL coding of the design. This RTL coding normally involves some level of hierarchy due to the complexity and size of current designs. Once complete, the RTL code is synthesized using a vendor library to form a gate-level description - or netlist - of the design.

Many ASICs contain certain complex functional blocks that are designed, synthesized, and instantiated (placed) throughout the design. An example of such a block could be a programmable arithmetic unit (PAU). Often, these blocks have functions that are used in one instantiation within the design, but not in another. Normal temptation can lead a designer to code one version of the block that covers all possible scenarios for that block. Not optimizing each block for its specific design intent may save time initially, however there are negative side effects involved:

1. There is unnecessary logic inside each instantiation of the block for any unused feature.
2. Overall ASIC area (die size) is increased.
3. Routing of the ASIC is compromised.
4. Testability of the ASIC is compromised.

Regarding testability, a number of scenarios arise. Many ASICs use scan testing as a DFT methodology of choice. Traditional scan testing is based on the detection of stuck-at faults. Typically, an ATPG tool will be used to create a series of scan pattern tests. The goal of the scan patterns is to check each node of the circuit for stuck-at-one and stuck-at-zero conditions, resulting in 100 percent fault coverage. Realistically, 100 percent coverage is seldom obtainable. However, many customers will demand fault coverage of at least 95 percent. This makes it even more important to minimize situations that will degrade the fault coverage of the ASIC.

Unused features of a design block usually translate into unconnected inputs and outputs. Most often, the unconnected inputs will be tied to ground to prevent undesirable circuit transitions. By default, if a node is grounded, it can't be checked for a stuck-at-zero fault condition, since it can't be exercised to a high. The opposite condition holds true for nodes that are tied high. The tied nodes are normally categorized as "untestable," and therefore don't lower fault coverage. The real damage associated with these nodes is their negative "sphere of influence." Logic that is downstream from these nodes also needs to be exercised to both high and low states. The tied condition of the upstream nodes may very well prevent the controllability necessary for these conditions to occur. As numerous instantiations of the particular block are used, the impact to fault coverage can become substantial.

Compounding these issues is the lack of ability to observe faults associated with unconnected outputs, also normally classified as "untestable." These unconnected outputs may be the only propagation path out of the block for specific faults internal to the block. Once again, fault coverage is negatively impacted. The DFT message is clear: talk with designers about test considerations before they are well into coding the design.

Testing RAM shadow logic

Virtually all of today's ASIC designs employ some form of random access memory, or RAM. The design structure of RAM is such that it's very inefficient to test using the algorithms in ATPG tools. In addition, the conventional stuck-at fault model is inappropriate for RAM testing. As a result, RAMs are usually "black boxed" (converted to a simple I/O model) for ATPG purposes, and instead are often fully tested with a form of RAMBIST.

A result of these DFT techniques is that RAM shadow logic remains untested. Shadow logic refers to the combinational logic between a RAM's inputs and outputs, and their last registered point within the ASIC circuitry (see Figure 1).

Since the RAM has been black boxed as a simple non-functional model, the ATPG tool can't work its way through the RAM to check for faults in the shadow logic; it can only control and observe the scan chain register elements and surrounding combinational circuitry exclusive of the shadow logic. As designs incorporate more and larger RAMs, the negative effects of untested shadow logic can become significant.

A simple DFT method to address testing of the shadow logic is to implement an exclusive-OR tree around the data and address lines of the RAM (see Figure 2). The exclusive-OR tree provides a simple path of combinational logic around the RAM that the ATPG tool can easily work with. By controlling the data and address lines to the appropriate values, it's a simple matter for ATPG to propagate the testing of shadow logic faults while the ASIC is in scan mode. Be aware that any clock lines to the RAM mustn't be included as part of the exclusive-OR tree. Any signals capable of changing the state of a register element (for example, clocks and resets) are treated as a specific clock group within ATPG tools. Since these signals toggle within a test cycle, they aren't considered as inputs to the exclusive-OR tree.

As can be seen in Figure 2, the primary input signal scan_mode (active high) becomes the select line of the multiplexers placed on the RAM's data output lines.

Figure 2 - RAM shadow logic testability

The Exclusive-OR tree provides a testable path around the black boxed RAM

During scan operation (scan_mode = 1), the output(s) of the exclusive-OR tree are fed to the shadow logic on the output side of the RAM, and eventually to registered logic. In this manner, the shadow logic faults are thoroughly tested. When the ASIC is in normal mode (scan_mode = 0), the select line of the multiplexer simply allows the normal RAM output data to pass through, with the minimal added delay of the multiplexer.

It should be noted that while the exclusive-OR tree can be constructed to result in a single output to one multiplexer on a single data output, a higher number of outputs would make it easier for the ATPG tool to write test patterns. A reasonable solution is to match the number of exclusive-OR outputs to the number of data output lines of the RAM, therefore maximizing the efficiency of the ATPG tool.

Be sure to check if the CAD tools for RAMBIST allow for the automatic insertion of shadow logic test circuitry. If not, early discussions with design engineers will allow them to write the test circuitry into the HDL code, so that it becomes part of the netlist after synthesis.

Pin, package, and hardware

In the initial planning stages of an ASIC program, a package type will be specified for prototype and final production parts. Once the package type has been defined, a variety of characteristics concerning the package, the design itself, and the target hardware tester must be considered. Failing to account for any one of these areas will usually result in unnecessary test vector rework - or in extreme cases, unusable test vectors.

Let's assume the package to be used is a 596-pin enhanced plastic ball grid array (EPBGA). Upon examining the package specification, we find that there are actually only 440 pins available for circuit I/O, since 156 pins are allocated for power and ground connections (104 Vss, 52 Vdd). With the circuit I/O defined, it's a simple matter of subtraction to determine how many pins are "left over" for test. For our example, we'll define 400 pins for circuit I/O, leaving 40 available test pins. Although the test engineer is seldom this fortunate, our example is intended to concentrate on the interaction of pin, package, and hardware concerns. Therefore we will conveniently ignore the more elaborate scan or DFT schemes (such as multiplexing I/O pins with scan pins) that are often necessary due to pin limitations.

Now it's time to develop a DFT strategy. To keep things simple, we will utilize a "basic" scan setup where discrete input and output pins are used for the scan_in, scan_out, and scan_enable pins of the scan chain. (Note that a scan chain requires a scan_enable pin to switch between scan and normal modes, however a single scan_enable pin can be used for multiple scan chains). Assume the design contains 50,000 register (flip-flop) elements, all of which are "scannable" (meaning no DFT violations exist to preclude them from scan chain consideration). Since a scan chain is a serial shift register, it would require 50,000 clocks to fully load this single scan chain. Although requiring only 3 I/O pins (scan_in, scan_out, and scan_enable) to be used, the single chain is an undesirable DFT solution. Since each ATPG vector associated with the chain requires an excessive amount of clocks (50,000) to load, the resulting vector set is very inefficient in terms of test time.

The most common way to reduce these requirements is to use multiple scan chains, dividing the single long chain into multiple shorter chains. This technique reduces the number of shifts necessary to fill each chain for a given ATPG vector. Of course, the question is how many chains should we use? The most obvious answer would be to use all of the extra pins available and have as many scan chains as possible to reduce total vector count. Unfortunately, the obvious choice is incorrect, as we have yet to consider hardware tester limitations.

Often, the package type is one of the few definitive items that are specified at program inception. The package and its corresponding I/O play a large part in determining which hardware tester is chosen at the ASIC vendor. Higher pin counts typically translate into larger and more complex designs. Testers capable of handling packages with many I/Os usually have greater features and memory capability as well. Every hardware tester is configured with a specific amount of memory. Total memory is typically divided into tester "channels," where each channel corresponds to a package I/O pin.

Leading by example

In our example, assume the target tester has 512 channels, divided into eight groups of 64 channels each. The memory specification for each of the eight groups is 64 Mbytes, with a maximum of four scan chains in any group.

When multiple scan chain configurations are used, ASIC hardware testers are normally configured to work with even numbers of scan chains. Our example design required 2,500 ATPG patterns to reach the desired fault coverage level of 95 percent. If a single scan chain were used, the tester memory depth required would be:
1 scan chain = (2,500 patterns) x (50,000 loads/pattern) = 125 Mbytes

This requirement exceeds the tester memory specification (64 Mbytes for any group of 64 channels) by approximately a factor of two. Increasing the number of scan chains to 2 would reduce the number of loads required, and hence the memory required, by a factor of two:
2 scan chains = (2,500 patterns) x (25,000 loads/pattern) = 62.5 Mbytes per chain (125 Mbytes total)

Increasing the number of chains by two has halved the memory requirement for each chain, while keeping the total memory requirement the same. A close examination of our new memory requirement of 62.5 Mbytes per scan chain reveals that we are still dangerously close to the 64 Mbyte limit for a tester group. Any circuit changes that result in more ATPG vectors may push us over the specified limit. A more flexible solution is needed.

Figure 3 - Parametric NAND tree

A simple parametric NAND tree provides a combinational path to check circuit input connectivity.

Referring to our initial pin description and DFT strategy, 40 pins are available for test. To optimize the scan chain setup, we should utilize these available pins, in combination with the hardware tester rules, to minimize the demands on tester memory. The creation of 16 scan chains will require 33 pins: 16 each for scan_in and scan_out, plus one additional pin for scan_enable (used for all chains). The scan chains can be evenly distributed (two chains in each of the eight tester groups) to minimize memory requirements:
16 scan chains = (2,500 patterns) x (3,125 loads/pattern) = 7.8125 Mbytes per chain (125 Mbytes total)

We have successfully reduced the memory required by our ATPG vectors to well within those of the target hardware tester, with room to spare. Since each pattern will load much quicker, the total test time has also been significantly reduced. An added benefit of minimizing tester requirements can be the flexibility of using multiple testers. By fitting your DFT scan methodology within the specifications of multiple testers, the ASIC vendor can schedule your part's time on the test floor much more easily, avoiding potential delays.

A further consideration in your scan chain setup is its affect on the ASIC design. There are design-dependent factors associated with each ASIC that need to be taken into account when selecting pin assignments for the scan chain(s). Is there a signal group (bus) that should remain uninterrupted for signal integrity purposes? Don't break it up with scan pins. Are specific pins assigned to certain signals to fulfill printed circuit board layout requirements? Make sure these pins aren't "bumped" by scan chain pins. Always ensure design integrity isn't compromised by test.

PCB test considerations

An ASIC is normally only one element of a total electrical system solution, typically placed on a printed circuit board (PCB) with other ASICs and electrical components. Thought must be given to not only testing the ASIC as an individual part, but as part of the total system. Usually, this entails ensuring that the ASIC has proper connectivity to the PCB (no shorts or opens exist).

One common DFT method used to test ASICs at the PCB level is boundary scan. The fundamental concept of boundary scan is the isolation of device inputs and outputs from its internal or "core" logic. Isolation is achieved by placing a boundary scan cell between each I/O pin and the core. These cells form a shift register ring around the chip that can be loaded and unloaded serially, as well as in parallel. The JTAG/IEEE standard 1149.1 fully describes the boundary scan standard and its application. But what happens when boundary scan isn't used?

There can be numerous reasons for not utilizing boundary scan in an ASIC design. If the ASIC in question is the only one on a PCB, and no other discrete parts on the PCB are JTAG compliant, it may not make sense to include JTAG in the ASIC design. In a small, high volume ASIC design, the additional die area required for boundary scan can be high in relationship to its functional circuitry. In this case, its addition might not justify the extra cost. The question remains, how can ASIC connectivity tests at the PCB level be accounted for if boundary scan isn't used?

One method to accomplish ASIC PCB test is the use of a parametric NAND tree. A simple parametric NAND tree performs connectivity checks on all ASIC inputs, including bi-directional pins (see Figure 3).

Implementation of the NAND tree would require an additional primary output pin, TESTOUT. The NAND gates are tied together, with each output feeding the input of the next. The very first input is tied high to Vdd, and the last output becomes TESTOUT. A "walking zeroes" pattern is then used on the ASIC inputs. All inputs are initially set to logic one, and a logic zero is then "walked" (asserted) on each input in succession, while all other inputs remain at logic one. The net result of this pattern is a series of alternating ones and zeroes that are observed on the TESTOUT pin. Failure to observe the alternating pattern indicates a connectivity failure between the input pin and ASIC bonding pad for the corresponding pattern location.

The use of bi-directional buffers on all outputs (whether required or not) would allow for connectivity checks on all ASIC I/O. This is accomplished by configuring the bi-directional buffers to be in "input mode" during the NAND tree test. The use of a single primary input pin is necessary to tristate the bi-directional buffers, placing them into input mode during the test. There are further complications that arise from the use of bi-directional buffers that require modifications to the NAND circuit that won't be covered here. The major point of emphasis is that there are alternative methods to boundary scan to achieve basic PCB testability.

Effective DFT for today's ASICs requires a mixture of continuous involvement from project inception, technical expertise, and practical knowledge. I have found that constant attention to DFT details can only add to the success of a project and is well worth the time it requires. The combined efforts of the design and test communities are necessary to achieve success in the production of highly testable ASICs.

Paul Yohannes currently works as a senior design-for-test engineer at Mint Technology (a subsidiary of LSI Logic Corporation) in Rochester, NY, where he is responsible for implementing DFT solutions (scan, JTAG, BIST, etc.) on VLSI custom ASICs. Prior to joining Mint in 1998, he spent 23 years with the Eastman Kodak Co. in ASIC engineering. To voice an opinion on this or any other article in Integrated System Design, please e-mail your comments to sdean@cmp.com.