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
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,
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
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.
, 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
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
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);
'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
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
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
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.
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
e
e
V
U
S
T
P
Q
R
FAULT MODELING
333
Checkpoint faults can be associated with unique signal path fragments. This is
illustrated in Figure 7.4. The bold lines identify a signal path from input D
0
to the
output. During design verification it would be desirable to verify that the indicated
path behaves as intended. Verification involves propagating a signal e ∈ {0,1} from
input D
0
to the output while all other signals are in an enabling state. But, there are
many such signal path fragments. How can we be sure that all such paths have been
verified?
Note that sensitization of the path is no more and no less than a sensitization of
the SA1 on the input to gate T and an SA0 on the output of gate T. An SA1 on the
input to T can only be detected if a logic 0 can be propagated from D
0
to the output
V in such a way that the output value functionally depends on the presence or
absence of the stated fault. Meanwhile, an SA0 on the output of T can only be
detected if a 1 can be successfully propagated from D
DEVELOPING A TEST STRATEGY
The test strategy just described will check delay relative to clock pulse duration
along paths where source and destination may be flip-flops and/or I/O pins. The
strategy is also effective for detecting stuck-open faults in CMOS circuits (see
Section 7.6.3). The number of unique signal paths will usually be considerably less
than the number of checkpoint faults since several faults will usually lie along a
given signal path. Since the task of identifying signal paths and creating rising and
falling edges can be compute-intensive, it may be advisable to identify signal paths
most likely to have excessive delay and limit the propagation of edges to those paths.
Note that a complete signal path can include several flip-flops. It is not an easy
task to set up and propagate rising and falling edges along all segments of such
paths. For example, an ALU operation may be needed in a CPU to set up a 0 or 1. By
the time the complementary value has been set up several state transitions later, the
original value may have changed unintentionally. A concurrent fault simulator can
be instrumented to identify and track edge faults, just as easily as it tracks stuck-at
faults, and it can identify paths or path segments that have been exercised by rising
or falling edges.
7.5.3 Redundant Faults
Redundant connections can cause a fault to be undetectable. A connection is defined
as redundant if it can be cut without altering the output functions of a circuit.
3
If a
circuit has no redundant connections, then it is irredundant. The following theorem
follows directly from the definition of redundancy.
Theorem 7.1 All SA1 and SA0 faults in a combinational circuit are detectable iff
the circuit is irredundant.
The simplest kind of redundancy, when discrete components are used, is to tie
two or more signal pins together at the input of an AND gate or and OR gate. This is
done when an n-input gate is available in an IC package and a particular application
does not require all the inputs. For example, if an AND gate has inputs A, B, and C
pairs of shorted nets. However, it is possible to identify and model shorts that have a
high probability of occurrence.
Adjacent Pin Shorts A function F is elementary in variable x if it can be
expressed in the form
F = x* ⋅ F
1
or
F = x* + F
2
where x* represents x or x and F
1
, F
2
are independent of x. An elementary gate is a
logic gate whose function is elementary. An input-bridging fault of an elementary
gate is a bridging fault between two gates, neither of which fans out to another cir-
cuit. With these definitions, we have:
4
Theorem 7.2 A test set that detects all single input stuck-at faults on an elementary
gate also detects all input-bridging faults at the gate.
The theorem states that tests for stuck-at faults on inputs to elementary gates, such
as AND gates and OR gates, will detect many of the adjacent pin shorts that can
occur. However, because of the unpredictable nature of pin assignment in IC pack-
ages (relative to test strategies), the theorem rarely applies to IC packages. It is com-
mon in industry to model shorts between adjacent pins on these packages because
shorts have a high probability of occurrence, due to the manufacturing methods used
to solder ICs to printed circuit boards.
336
DEVELOPING A TEST STRATEGY
Adjacent pin shorts may cause a signal on a pin to alter the value present on the
array in Figure 7.6 is the AND array. Each vertical line selects a subset of the input
variables, as indicated by dots at the intersections or crosspoints, to create a prod-
uct term. The lower array is the OR array. Each horizontal line selects a subset of
the product terms, again indicated by dots, to create a sum-of-products term at the
outputs.
Figure 7.6 Programmable logic array.
x
1
x
4
x
3
x
2
y
1
y
2
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 (uncon-
nected) 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 logi-
cally expands if an additional input variable is connected to the vertical line. In the
OR array, a product term is added if an additional column is connected into the cir-
cuit, and a product term will disappear from the circuit output if a column is not con-
nected where required.
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 in order to convey a sense of their behavior, but in practice it is quite diffi-
cult to correlate faults in the actual circuit with faults in the behaviorally equivalent
circuit represented by logic gates. This is particularly true of faults that cause feed-
back (i.e., memory), in a combinational circuit.
7.6.1 MOS
A metal oxide semiconductor (MOS) circuit can also be implemented in ways that
make it difficult to characterize faults. The circuit of Figure 7.7 is designed to imple-
ment the function
F = (A + C)(B + D)
With the indicated open it implements
F = A⋅ B + C⋅ D
It is not immediately obvious how to implement this MOS circuit as an intercon-
nection of logic gates so as to conveniently represent both the fault-free and faulted
versions (although it can be done).
7.6.2 CMOS
The complementary metal oxide semiconductor (CMOS) NOR circuit is illus-
trated in Figure 7.8. When A and B are low, both p-channel transistors are on, and
both n-channel transistors are off. This causes the output to go high. If either A or
B goes high, the corresponding upper transistor(s) is cut off, the corresponding
lower transistor(s) is turned on, and the output goes low.
Conventional stuck-at faults occur when an input or output of a NOR circuit
shorts to V
SS
but it cannot turn on the
path to V
SS
. Therefore, the value at F will depend on the electrical charge trapped at
that point when signal A goes high. The equation for the faulted circuit is
F
n+1
= A
n+1
⋅ B
n+1
+ A
n
⋅ B
n
⋅ F
n
Table 7.1 illustrates the effect of all seven faults. In this table, F represents the fault-
free circuit. F
1
and F
2
represent the output SA0 and SA1, respectively. F
3
and F
4
represent open inputs at A and B. F
5
and F
6
6
F
7
001011111
F
n
01001010
F
n
0
1000110
F
n
00
1100100000
F
Q
3
Q
4
Q
2
Q
1
p-channel
n-channel
V
SS
V
DD
The preceding examples illustrate the problems that exist when digital circuits are
modeled at the gate level. In another investigation, this one involving emitter-cou-
pled logic (ECL), a macro-cell library that included functions at the complexity of
full-adders was examined. The authors demonstrated a need for test patterns over
and above those that gave 100% coverage of the stuck-at faults for the gate-equiva-
lent model.
10
Wadsack identified a similar situation wherein a small CMOS circuit
had 100% stuck-at coverage and yet, on the tester, devices were failing on vectors
after the point where 100% stuck-at coverage had occurred.
11
It is simply not possible to represent a large ensemble of transistors as a collection
of gates and expect to obtain a perfect test for the transistor level circuit by creating
tests for the gate equivalent model. The larger the ensemble, the more difficult the
challenge. Recall the observation made in Chapter 1: Testing is as much an economic
challenge as it is a technical challenge. The ideal technical solution is to perform
fault simulation at the transistor level. That, however, is not economically feasible.
To see just how difficult the problem of modeling circuit behavior can be, con-
sider the rather simple circuit represented in Figure 7.9 as a sum of products and as a
product of sums. These circuits are logically indistinguishable from one another,
except possibly for timing variations, when analyzed at the terminals. However, the
set of six vectors listed below will test all SA1 and SA0 faults in the NAND model
but only 50% of the faults in the NOR model. In fact, two of the NOR gates could be
completely missing and the test set would not discover it!
12
THE FAULT SIMULATOR
341
Figure 7.9 Two equivalent circuits.
Fortunately, circuits in real life are rarely that small. Fault coverage for structurally
equivalent circuits generally tends to converge as it approaches 100%. This can be
4
X
2
X
3
X
1
X
4
X
2
X
3
342
DEVELOPING A TEST STRATEGY
attributes of fault simulation that will enable a user to design strategies that are more
productive, irrespective of whether or not an ATPG is employed.
7.7.1 Random Patterns
The use of random patterns is motivated by the efficiency curve shown in Figure 7.10.
The first dozen or so patterns applied to a combinational logic circuit typically detect
anywhere from 35% to 60% of the faults selected for testing, after which the rate of
detection falls off.
To see why this curve holds, consider that any of functions can be imple-
mented by a simple n-input, 1-output circuit. Any single test pattern in which all
inputs have known values, 0 or 1, will partition the functions into two equivalence
classes, based on whether the output response is a 1 or 0. The response of half the
functions will match the response of the correct circuit. A second input will further
partition the functions so that there are four equivalence classes. The functions in
three of the classes will disagree with the correct circuit in one or both of the output
responses. In general, for a combinational circuit with n inputs, and assuming all
m
∑
⋅
100%⋅=
Number of patterns
Percent detected
THE FAULT SIMULATOR
343
Example The 16 possible functions that can be represented by a two-input circuit
are listed below. The two-input EXOR circuit is represented by F
6
. Its output is 1
whenever A and B differ.
Application of any single pattern to inputs A and B distinguishes between F
6
and
eight of the other 15 functions. Application of a second pattern will further distin-
guish F
6
from another four functions. Hence, after two patterns, the correct function
is distinguished from 80% of the possible functions. The formula expresses percent-
age tested for these single-output combinational functions strictly on the basis of the
number of unique input patterns applied and makes no distinction concerning the
values assigned to the inputs. It is a measure of test effectiveness for all kinds of
faults, single and multiple, and suggests why there is a high initial percentage of
faults detected.
3
F
4
F
5
F
6
F
7
F
8
F
9
F
10
F
11
F
12
F
13
F
14
F
15
000000000011111111
010000111100001111
100011001100110011
110101010101010101
ineffective, then the user of that tester is not getting a reasonable return on invest-
ment (ROI).
Capturing Design Verification Vectors A testbench used in conjunction
with an HDL model can be quite simple. It might simply be an array of vectors
applied, in sequence, to the target device. Alternatively, the testbench may be a com-
plex behavioral model whose purpose is to emulate the environment in which the
design eventually operates. In the former case, it is a simple matter to format the
array of vectors and input them to a fault simulator as depicted in Figure 7.2. Many
sequences of vectors can be sent through the fault simulator and evaluated, with
those most effective at improving fault coverage retained and formatted for the
tester. Because fault simulation is a compute-intensive activity, the task of evaluat-
ing design verification suites can be accomplished more quickly through the use of
fault sampling (discussed in Section 7.7.3).
When a design verification suite is generated by a complex bus functional model
(BFM) or similar such behavioral entity, with signals emanating from the stimulus
generator at seemingly random times during each clock cycle, and converging on a
THE FAULT SIMULATOR
345
design that contains numerous bidirectional pins, the task of selecting vector suites
and formatting them for the tester becomes a bit more involved. Referring again to
Figure 7.2, code can be inserted in the testbench to sample stimuli arriving at the cir-
cuit from the stimulus generator. The criteria for selecting stimuli may include cap-
turing stimuli at the I/O pads of the circuit under test whenever a clock edge occurs.
The stimuli are then written to a file that can be evaluated via fault simulation, with
the more effective stimuli formatted and ported to the tester.
One problem that must be addressed is signal direction on bidirectional pins. An
I/O pad may be driven by the stimulus generator, or it may be driven by the circuit
under test. This requires that enable signals on tri-state drivers be monitored. If the
enable signal is active, then the bidirectional pin is being driven by the circuit under
test. In that case, the vector file being created by the capture code in the testbench
DEVELOPING A TEST STRATEGY
Figure 7.12 Shifting the clock edge.
Determining Which Vectors to Retain A typical design verification effort
may generate many millions of test sequences, far more than could possibly fit into a
typical tester memory. To select from these sequences a subset that provides good
coverage of physical defects in the design requires fault simulation. But, fault simu-
lation is a CPU intensive task. To perform a detailed fault simulation of all the
design verification suites can take an incredibly long time. To assist in the selection
process, two approaches can be employed: fault sampling and fault coverage pro-
files. We will now discuss each of these concepts in detail.
7.7.3 Fault Sampling
When a circuit is modeled at the gate level, the size of the fault list for that circuit,
after collapsing, is generally in the range of 2.5X, where X is the number of logic
gates. So, for example, a 100,000 gate circuit can be expected to have about 250,000
stuck-at faults in its fault list. If the objective is to sift through a large number of
design verification vector suites in order to find a subset that provides useful fault
coverage, then it is unnecessary to fault simulate the entire list of faults.
The practice of sampling can be put to good use in fault simulation. The object
is to evaluate the effectiveness of one or more sets of test vectors with the smallest
possible expenditure of CPU time, subject to the availability of main memory.
When designers are generating many hundreds or thousands of test programs,
often simulating them on specialized hardware simulators or emulators, over a
period of several months, it is not practical to fault simulate all of the sequences in
detail.
Fault sampling selects a subset of a total fault population for consideration during
fault simulation. The goal is to quickly get a reasonably accurate estimate of the
fault coverage produced by a set of test vectors. We consider here the development
provided by Wadsack.
13
Consider a population of N faults and a test that can detect
these partitions should be approximately the same, as discussed in the preceding
subsection. If the fault partition is made up of faults, all selected from the same
functional area of the IC, then the fault coverage from these partitions can show
substantial variation.
Fault partition sizes can be determined by the fault simulator. The operating sys-
tem can advise as to how much memory is available to keep track of fault effects.
The size of the data structure used to record fault effects is known and, with experi-
ence, a reasonably accurate estimate can be made of the number of fault effects that
exist, on average, for each fault origin. With this information, it is possible to esti-
mate how many faults can be processed in each fault simulation pass. If the esti-
mate is too optimistic, and not enough memory exists to process all of the faults,
then some of the faults can be deleted and fault simulation can continue with the
reduced fault list. Those faults that were deleted can be added back in a subsequent
fault partition.
Figure 7.13 Ninety-five percent confidence interval.
0.0 0.2
0.002
0.000
1.0
0.004
0.60.4 0.8
0.006
0.008
0.010
Z - Fractional error
F - Sample fault coverage