Logic kỹ thuật số thử nghiệm và mô phỏng P7

323 Digital Logic Testing and Simulation , Second Edition , by Alexander Miczo ISBN 0-471-43995-9 Copyright © 2003 John Wiley & Sons, Inc. CHAPTER 7 Developing a Test Strategy 7.1 INTRODUCTION The first five chapters provided a survey of algorithms for logic simulation, fault simulation, and automatic test pattern generation. That was followed by a brief sur- vey of tester architectures and strategies to maximize tester effectiveness while min- imizing overall test cost. We now turn our attention to methods for combining the various algorithms and testers in ways that make it possible to achieve quality levels consistent with product requirements and design methodologies. It has been recognized for some time now that true automatic test pattern genera- tion is a long way from realization, meaning that software capable of automatically generating high-quality tests for most general sequential logic circuits does not cur- rently exist, nor is it likely to exist in the forseeable future. Hence, it is necessary to incorporate testability structures in digital designs to make them testable. We begin this chapter with a look at the design and test environment. That will provide a framework for discussion of the various topics related to test and will help us to see how the individual pieces fit together. Most importantly, by starting with a comprehensive overview of the total design and test process, we can identify oppor- tunities to port test stimuli created during design verification into the manufacturing test development process. After examining the design and test environment, we will take an in-depth look at fault modeling because, in the final analysis, the fault model that is chosen will have a significant effect on the quality of the test. Other topics that fit into a comprehensive design and test framework, including design-for-test (DFT) and built-in-self-test (BIST), will be discussed in subsequent chapters. 7.2 THE TEST TRIAD Several strategies exist for developing test programs for digital ICs; these include: Functional vectors Fault-directed vectors I DDQ 324 DEVELOPING A TEST STRATEGY Functional vectors may be derived from design verification suites or they may be written specifically to serve as manufacturing test programs. A fault simulator may be part of the selection/development process or the test program developer may take it on faith that his test program will effectively distinguish between faulty and fault- free product. Fault-directed vectors are usually generated by an automatic test pat- tern generator (ATPG), although the current state of the art in ATPG is quite primi- tive and commercial programs currently in existence operate either in full-scan or in partial-scan mode, where the percentage of storage devices (flip-flops and latches) in the scan path is usually in excess of 50% of the total number of storage devices. The I DDQ test strategy (cf. Chapter 11) is based on the observation that CMOs circuits normally draw near-zero quiescent current when the clock is halted, and therefore defects in the form of shorts to ground or power will generate a quiescent current that is orders of magnitude greater than the normal quiescent current. In a paper published in 1992, it was shown that a high-quality test benefited from all three of the test methodologies listed above. 1 The authors examined in detail a chip that contained 8577 gates and 436 flip-flops. A total of 26,415 die were analyzed. These were die that had passed initial continuity and parametric tests. Three different tests were applied to the die. The functional test had a coverage of 76.4% and the combined functional plus scan tests produced a combined stuck-at coverage of 99.3%. Of the 26,415 die that were analyzed, 4349 were determined to be faulty. The Venn diagram in Figure 7.1 shows the distribution of failures detected by each of the three methods. Of the defective die, 2655 failed all three tests, 1358 die failed only the I DDQ test, 25 die failed only the functional test, and 19 failed only the scan test, while 134 die failed both the functional and scan test, but passed the I DDQ test. There were 122 die that failed I DDQ and scan, but not the functional test, and 36 that failed I DDQ and functional but not the scan test. For a product that requires the highest possi- ble quality, the results suggest that tests with high stuck-at coverage and I DDQ test are necessary. In this chapter we will focus on the functional test; in subsequent chapters we will examine in detail the scan, partial-scan, and I DDQ test methodologies. Figure 7.1 Results of different tests. Fail functional Fail scan Fail I DDQ 2655 36 25 19 1358 122 134 Distribution of failing die in each test class. OVERVIEW OF THE DESIGN AND TEST PROCESS 325 7.3 OVERVIEW OF THE DESIGN AND TEST PROCESS A functional test program of the type referred to in the previous section can be derived as a byproduct of the design verification process. This section examines the design and test process, starting with the data flow diagram of Figure 7.2, which highlights the main features of a design and test workflow for an IC. The main fea- tures of the data flow diagram will be briefly described here; subsequent sections will cover the operations in greater detail. The testbench is a hardware design lan- guage (HDL) construct that instantiates a top-level module of a design whose cor- rectness is being evaluated, together with additional software whose purpose is to stimulate the design and capture/print out response values. We assume in this discus- sion that the top-level circuit is an IC, rather than a PCB. We assume, further, that the circuit instantiated in the testbench is described using RTL (register transfer level) language constructs. The testbench affords great flexibility in creating test stimuli for a design. The stimuli can be written in the same language as the circuit model, or in a special language per- haps better suited to describing waveforms to be applied to the circuit. The designer can incrementally add stimuli to the testbench and simulate until, at some point, he or she becomes convinced that circuit behavior conforms to some specification. Figure 7.2 Design and test workflow. Testbench Stimuli Circuit Netlist Netlist compiler Flattened netlist Faultlist compiler Fault file Fault simulator ATPG Filter Test vectors Manual or program generated Reports Library Synthesis Tester 326 DEVELOPING A TEST STRATEGY At that point the design will be converted into a netlist. The conversion process can be performed manually or it can be accomplished through the use of synthesis pro- grams. In practice, a typical IC will be synthesized using a combination of manual and automatic means. Some modules, including memories (RAM and ROM) and large data path functions, are often handcrafted. In addition, state machines, control paths, and other logic that are synthesized via synthesis programs may receive addi- tional scrutiny from the logic designer if subsequent simulation or timing analysis reveals that timing constraints are not satisfied. The synthesized netlist is usually partitioned along the same boundaries as the original circuit, with the original RTL modules now represented as an interconnec- tion of macrocells or standard cells . The macrocells are low-level functions, rang- ing from simple buffers to full-adders and multiplexers. The netlist compiler flattens the netlist so that module boundaries become indistinguishable. However, naming conventions are used that make it possible to identify, hierarchically, where the logic element originated. For example, if top-level module A contains module B , and B contains an AND gate labeled C , then in the flattened netlist the AND gate could be recognized as A.B.C , or it could be recognized as B.C , where the top-level module A is implied; that is, every element is contained in the top- level module. From the flattened netlist the fault-list compiler produces a fault file. The fault file is extremely important because it is used to measure the effectiveness of test pro- grams. The fault-list compiler must create a fault list that is representative of faults in the circuit, but at the same time it must be careful to produce a fault list that can be simulated in a reasonable amount of CPU time. It is possible for the fault simula- tor to be extremely accurate and efficient, and still produce deceptive and/or mean- ingless results if the fault list that it is working from is not a representative fault list. Walking the tightrope between these sometimes conflicting requirements of accu- racy and speed is a major challenge that will receive considerable attention in this chapter. The fault simulator and ATPG algorithms received considerable attention in pre- vious chapters. Here we simply note that, if a test strategy includes an ATPG, then the netlist must be expressed as an interconnection of primitives recognized by the ATPG. If the netlist includes primitives not recognized by the ATPG, these primi- tives must be remodeled in terms of other primitives for which the ATPG has pro- cessing capability. This is usually accomplished as part of the library development/ maintenance task. A singular cover, propagation D-cubes, and primitive D-cubes of failure (PDCF) may also exist for circuit primitives, either in a library or built into the ATPG. The purpose of the filter in Figure 7.2 is to select design verification vectors and reformat them for the target tester. By including a fault simulation operation in this phase of the task, it is possible to intelligently select a small subset of the design ver- ification vectors that give acceptable fault coverage. This is necessary because design verification usually involves creation and simulation of far more vectors than could possibly fit into a tester’s memory. More will be said about this in a subse- quent section. A TESTBENCH 327 In this chapter, fault simulation and ATPG will be examined from the user’s per- spective. What kind of reports should be generated, and how do test programs get translated into tester format? Users have, in the past, been quite critical of fault sim- ulators, complaining that they simply produced a fault coverage number based on the test vectors and the fault list, without producing any meaningful suggestions, help, or insight into how to improve on that number. We will examine ways in which fault simulation results can be made more meaningful to the end user. The workflow depicted in Figure 7.2 is quite general; it could describe almost any design project. The circuit being designed may be constrained by rigid design rules or it may be free form, with the logic designers permitted complete freedom in how they go about implementing their design. However, as details get more specific (e.g., is the design synchronous or asynchronous?), choices start becoming bounded. Many of the vexing problems related to testing complex sequential circuits will be post- poned to subsequent chapters where we address the issue of design-for-testability (DFT). For now, the focus will be on the fault simulator and the ATPG and how their interactions can be leveraged to produce a test program that is thorough while at the same time brief. 7.4 A TESTBENCH A testbench will be created for the circuit in Figure 7.3 using Verilog. A VHDL description at the structural level would be quite similar, and the reader who under- stands the following discussion should have no difficulty understanding an equiva- lent VHDL description of this circuit. The testbench instantiates two modules; the first is the circuit description, while the second contains the test stimuli, including timing data. The circuit description is hierarchical, containing modules for a mux and a flip-flop. The test stimulus module follows the hierarchical netlist testbench. 7.4.1 The Circuit Description The Verilog circuit description that follows is rather brief. The reader who wishes to acquire a more thorough understanding of the Verilog HDL is encouraged to consult Figure 7.3 Gate-level interconnection. SEL CLR E CK TSE C D Y Clr F G B A 328 DEVELOPING A TEST STRATEGY one of the many textbooks dedicated to that subject. Because the language is quite robust, the following code represents but one of several ways to describe a particular behavior. Also note that the first line of each module is set in boldface for conve- nience in locating the start of each new module. 'timescale 1 ns / 100 ps module testbench; ckt7p3 X1 (tse, sel, ck, clr, y); stimuli X2 (tse, sel, ck, clr, y); endmodule module ckt7p3 (tse, sel, ck, clr, y); input tse, sel, ck, clr; inout y; wire hold; wire load, choose; mux2 x1 (.A(hold), .B(load), .Sel(sel), .C(choose)); dff x2 (.Q(hold),.QN(),.data(choose),.clock(ck), .preset(1'b1),.clear(clr)); bufif1 #(7,7) x3 (y, hold, tse); buf #(4,4) (load, y); endmodule module mux2(A, B, Sel, C); input A, B, Sel; output C; not #(5,5) n1 (Sel_, Sel); and #(5,5) n2 (L1, Sel_, A); and #(5,5) n3 (L2, Sel, B); or #(6,6) n4 (C, L1, L2); endmodule module dff(Q,QN,data,clock,preset,clear); input data; input clock; input preset; input clear; output Q; output QN; nand #(5,5)N1 (L1, preset,L4, L2), N2 (L2, L1, clear, clock), N3 (L3, L2, clock, L4), N4 (L4, L3, data, clear), N5 (Q, preset, L2, QN), N6 (QN, Q, L3, clear); endmodule module stimuli(tse, sel, ck, clr, y); output tse, sel, ck, clr; inout y; A TESTBENCH 329 reg [3:0] inputs; reg ck; parameter clock_high = 50; // 100ns period, clock high 50ns 'define cycle #1000 inputs = 4'b assign {tse, sel, clr, y} = inputs; initial begin ck = 0; $dumpfile("ckt7p3.dump"); $dumpvars(3, X1); $monitor($time,," tse = %b sel = %b ck = %b clr = %b y = %b", tse, sel, ck, clr, y); 'include "ckt7p3.fvc" // include vector file $finish; // end simulation end always #clock_high ck = ~ck; endmodule // ckt7p3.fvc -- tse, sel, clr, y #0 inputs = 4'b110Z; // Reset 'cycle 0111; 'cycle 0111; 'cycle 101Z; 'cycle 101Z; 'cycle 110Z; 'cycle 111Z; 'cycle 0111; 'cycle 101Z; 'cycle 101Z; 'cycle 0110; The first module in the listing is the top-level testbench, aptly named testbench . It begins with a timescale compiler directive that allows modules with different time units to be simulated together. The first number specifies the unit of measurement for delays in the module, and the second number specifies the accuracy with which delay values are rounded before being used in simulation. In the modules that fol- low, delays are multiples of 1 ns, and they are rounded to 100 ps during simulation. So, if a delay value of 2.75 is specified, it represents 2.75 ns and is rounded to 2.8 ns. The next entry is the name of the module, which ends with a semicolon, as do most lines in Verilog. The modules ckt7p3 and stimuli are then instantiated. Ckt7p3 con- tains the circuit description while the module stimuli contains the test program. End- module is a keyword denoting the end of the module. The circuit ckt7p3 again begins by listing the module name, followed by a declara- tion of the I/O ports in the circuit. The second line of ckt7p3 defines the ports tse , sel , ck , and clr as inputs. The third line defines the port y as an inout—that is, a bidirec- tional signal. The signals hold , load , and choose are internal signals. As wires, they can carry signals but have no persistence; that is, there is no assurance that values on those signals will be valid the next time the module is entered during simulation. 330 DEVELOPING A TEST STRATEGY The next line instantiates mux2 . It is a two-input multiplexer whose definition fol- lows the definition for ckt7p3 . Note that the signals in mux2 are associated with wires in ckt7p3 by using a period (.) followed by the signal name from mux2 and then the wire called hold in ckt7p3 is enclosed in parentheses. The signal named Q in dff is also associated with the wire hold . It is not necessary to associate names in this fashion, but it is less error-prone. If this method is not employed, then signals become position-dependent; in large circuits, errors caused by signals inadvertently juxtaposed can be extremely difficult to identify. The dff instantiated in ckt7p3 is the next module listed. It corresponds to the cir- cuit in Figure 2.8. The signal 1’b1 connected to the preset in the dff denotes a logic 1. Similarly, 1’b0 denotes a logic 0. The next element in ckt7p3 is called bufif1 . The bufif1 is a tri-state buffer and is a Verilog primitive. There is a corresponding ele- ment called bufif0 . Bufif1 is active when a logic 1 is present on its enable pin. Bufif0 is active when the enable signal is a logic 0. Other Verilog primitives in the above listing include buf, and, or, and nand. Any Verilog simulator must provide simula- tion capability for the standard primitives. Verilog does not support built-in sequential primitives for the latches and flip- flops; however, it does support user-defined primitives (UDPs). The UDP is defined by means of a truth table, and the facility for defining UDPs allows the user to extend the set of basic primitives supported by Verilog. Through the use of UDPs it is possible for the user to define any combination of gates as a primitive, so long as the model only contains a single output pin. Sequential elements can also be defined. The requirement is that the sequential element must directly drive the output. 7.4.2 The Test Stimulus Description The module called stimuli has the same I/O ports as ckt7p3. However, in this module the signals that were inputs in ckt7p3 have become outputs. The inout signal y remains an inout. A 4-bit register named inputs is defined. The “reg” denotes an abstract storage element that is used to propagate values to a part. The signal called ck is defined as a register. Then a parameter called clock_high is defined and set equal to 500. That is followed by the definition of the ASCII string #1000 inputs = 4’b. These two statements are used to define a clock period of 1000 ns, with a 50% duty cycle. The values in the register inputs are assigned to the input and inout signals by means of the assign statement that follows. An initial statement appears after the assign statement. The first initialization statement causes a 0 to be assigned to ck prior to the start of simulation. Then a dump-file statement appears; it causes internal signal values to be written to a dump file during simulation. The dumpvars statement requests that the dump be per- formed through three levels of hierarchy. The dump file holds values generated by internal signals during simulation so that they can later be retrieved for visual wave- form display. In the ckt7p3 circuit, there are three levels of hierarchy; the top level contains mux2 and dff, and these in turn contain lower-level primitive elements. The monitor statement requests that the simulator print out specified values during simulation so FAULT MODELING 331 that the user can determine whether the simulation was successful. It instructs the simulator on how to format the signal values. The text enclosed in quotes is the for- mat statement; it is followed by a list of variables to be printed. The include state- ment requests that a file named ckt7p3.fvc be included; this file contains the stimuli to be simulated. The $finish indicates the end of simulation. The ck signal is assigned an initial value of 0. Then, every 500 ns it switches to the opposite state. The next file contains the stimuli used during simulation. Although the stimuli in this example are vectors listed in matrix form, they could just as easily be generated by a Verilog model whose sole purpose is to emit stimuli at random times, thus imi- tating the behavior of a backplane. In this vector file, the word cycle is replaced by the ASCII text string defined in stimuli.v. That text contains a time stamp, set to the value 1000. The simulator applies each vector 1000 time units after the previous vector. The time stamp is followed by the variable inputs; it causes the following four values to be assigned to the variable inputs from which they will subsequently be assigned to the four I/O ports by the assign statement. The values begin with the number 4, indicating the number of signal values in the string; the apostrophe and the letter b indicate that the string is to be interpreted as a set of binary signals. The four values follow, ended by a semicolon. The values are from the set {0, 1, X, Z}. The fourth value is applied to the inout signal y. Recall the y is an inout; sometimes it acts as an input, and other times it acts as an output. When y acts as an input, a logic 0 or 1 can be applied to that pin. When y acts as an output, then the I/O pad is being driven by the tri-state buffer, so the external signal must be a floating value; in effect the external driving signal is disconnected from the I/O pad. 7.5 FAULT MODELING In Chapter 3 we introduced the basic concept of a stuck fault. That was followed by a discussion of equivalence and dominance. The purpose of equivalence and domi- nance was to identify stuck-at faults that could be eliminated from the fault list, in order to speed up fault simulation and test pattern generation, without jeopardizing the validity of the fault coverage estimate computed from the representative faults. Other factors that must be considered were postponed so that we could concentrate on the algorithms. The fault list is determined, at least in part, by the primitives appearing in the netlist. But, even within primitives, defects in different technologies do not always produce similar behavior, and there are several MOS and bipolar tech- nologies in use. 7.5.1 Checkpoint Faults Theorem 3.3 asserted that in a fanout-free circuit realized by symmetric, unate gates, it was sufficient to put SA1 and SA0 faults on each primary input. All of the interior faults are either equivalent to or dominate the faults on the primary inputs. All faults interior to the circuit will be detected if all the faults on the inputs are detected. This 332 DEVELOPING A TEST STRATEGY suggests the following approach: identify all fanout-free regions. Start by identify- ing logic elements that drive two or more destination gates. That part of the wire common to all of the destination gate inputs is called a stem. The signal path that originates at a primary input or at one of the fanout paths from a stem is called a checkpoint arc. 2 Faults on the gate inputs connected to checkpoint arcs are called checkpoint faults. It is possible to start out with a fault set consisting of SA0 and SA1 faults at all checkpoint arcs and stems. This set can be further reduced by observing that if two or more checkpoint arcs terminate at the same AND (OR) gate, then the SA0 (SA1) faults on those arcs are equivalent and all but one of them can be deleted from the fault list. The remaining SA0 (SA1) fault can be transferred to the output of the gate. Example The circuit in Figure 7.4 has eight checkpoint arcs: four primary inputs and two fanout paths from each of P and R. Therefore, there are initially 16 faults. Faults on the inputs of the inverters can be transferred to their outputs; then the faults on the output of Q can be transferred to the input to S. The 16 faults now appear as SA0 and SA1 faults on the outputs of P and R and on each of the three inputs to S and T. The SA0 faults at the inputs of AND gates S and T are equivalent to a single SA0 fault on their outputs; hence they can be represented by equivalent SA0 faults, result- ing in a total of 12 faults.  Using checkpoint arcs made it somewhat simpler to algorithmically create a min- imum or near minimum set of faults, in contrast to assigning stuck-at faults on all inputs and outputs of every gate and then attempting to identify and eliminate equiv- alent or dominant faults. In general, it is a nontrivial task to identify the absolute minimum fault set. Recall that fault b dominates fault a if T a ⊆ T b , where T e is the set of all tests that detect fault e. If b is a stem fault and a is a fault on a checkpoint arc and is T a = T b , then fault b can be omitted from the fault list. But, consider the circuit of Figure 4.1. If the test vector (I 1 , I 2 , I 3 , I 4 , I 5 ) = (0, 0, 1, 0, 0) is applied to the circuit, an SA0 on the output of gate D will not be detected, but an SA0 on the input to gate I driven by gate D will be detected, as will an SA0 on the input to inverter J (verify this). Figure 7.4 Propagating a signal. D 1 D 0 S E 1 1 0 e e e V U S T P Q R [...]... detect Redundancy incorporated into logic to prevent a hazard will create an undetectable fault If the fault occurs, it may or it may not produce an error symptom since a hazard represents only the possibility of a spurious signal No general method exists for spotting redundancies in logic circuits 7.5.4 Bridging Faults Faults can be caused by shorts or opens In TTL logic, an open at an input to an AND... 7.6 Programmable logic array TECHNOLOGY-RELATED FAULTS 337 The PLA is susceptible to bridging faults and crosspoint faults.5 The crosspoint fault is a physical defect caused by a diode at a crosspoint that is connected (unconnected) when it should not (should) have been connected In the AND array, the product term logically shrinks if a device is disconnected and the product term logically expands... behavior of that cell at the logic 354 DEVELOPING A TEST STRATEGY level A significant amount of effort goes into the design of standard cell libraries to ensure that the behavior of each member is described as accurately as possible, both with respect to logic behavior and with respect to propagation delays from input pins to output pins However, as we previously saw, matching logic behavior to transistor-level... crosspoint fault may cause an OR operation The crosspoint open is similar in behavior to opens in conventional gates The bridging fault, like shorts between signal lines in any logic, is complicated by the fact that a signal is affected by a logically unrelated signal However, the regular structure of the PLA makes it possible to identify potential sources of bridging faults and to perform fault simulation,... magnitude more logic is integrated onto packages with proportionately fewer additional pins 7.6 TECHNOLOGY-RELATED FAULTS The effectiveness of the stuck-at fault model has been the subject of heated debate for many years Some faults are technology-dependent and cause behavior unlike 338 DEVELOPING A TEST STRATEGY the traditional stuck-at faults Circuits are modeled with the commonly used logic symbols... thousands of logic gates and numerous complex state machines engaged in extremely detailed and sometimes lengthy “hand-shaking” sequences tend to be quite random-resistant, meaning that sequences of input stimuli applied to the circuit must be precisely calculated to steer the circuit through state transitions Any single misstep in a sequence of n vectors can frustrate attempts to reach a desired state Logic. .. illustrated in Figure 7.11 The external driver, in this case the vector file being generated in the testbench, will drive the I/O pad at some times, and at other times the internal logic of the IC will drive the pad When the internal logic is driving the pad, the external signal must be inactive The circuit in Figure 7.3 and described in Section 7.4.1 illustrates the issues discussed here It has four inputs... by the user For example, the interrupt logic in a microprocessor might be spread across several submodules grouped together under a top-level module identified as INT The user can request fault coverage statistics for INT and for all submodules contained in INT Alternatively, the user may request that the profiler list only the undetected faults in that section of logic If fault coverage for a particular... identify the I/O pins most susceptible to solder shorts, namely, the pins that are adjacent Structural information is also available for programmable logic arrays (PLAs) and can be used to derive tests for faults with a high probability of occurrence Logically, the PLA is a pair of arrays, the AND array and the OR array The upper array in Figure 7.6 is the AND array Each vertical line selects a subset... JK, D, T Multiplexers Encoders and decoders Comparators Parity checkers Registers ALUs: logic, arithmetic—fixed point, binary coded decimal (BCD), floating point Memory arrays State machine In the final analysis, fault models are used to evaluate the effectiveness of test vectors for detecting physical defects in logic circuits To that end, the modeling of faults for functional primitives should reflect . machines, control paths, and other logic that are synthesized via synthesis programs may receive addi- tional scrutiny from the logic designer if subsequent. The signal 1’b1 connected to the preset in the dff denotes a logic 1. Similarly, 1’b0 denotes a logic 0. The next element in ckt7p3 is called bufif1 . The