📄 ch14.4.htm
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML EXPERIMENTAL 970324//EN">
<HTML>
<HEAD>
<META NAME="GENERATOR" CONTENT="Adobe FrameMaker 5.5/HTML Export Filter">
<TITLE> 14.4 Fault Simulation</TITLE></HEAD><!--#include file="top.html"--><!--#include file="header.html"-->
<DIV>
<P>[ <A HREF="CH14.htm">Chapter start</A> ] [ <A HREF="CH14.3.htm">Previous page</A> ] [ <A HREF="CH14.5.htm">Next page</A> ]</P><!--#include file="AmazonAsic.html"--><HR></DIV>
<H1 CLASS="Heading1">
<A NAME="pgfId=53545">
</A>
14.4 <A NAME="26200">
</A>
Fault Simulation</H1>
<P CLASS="BodyAfterHead">
<A NAME="pgfId=75527">
</A>
We use <A NAME="marker=53550">
</A>
<SPAN CLASS="Definition">
fault simulation</SPAN>
after we have completed logic simulation to see what happens in a design when we deliberately introduce faults. In a production test we only have access to the package pins—the <SPAN CLASS="Definition">
primary inputs</SPAN>
<A NAME="marker=74123">
</A>
(<SPAN CLASS="Definition">
PIs</SPAN>
<A NAME="marker=117907">
</A>
<A NAME="marker=117908">
</A>
) and <SPAN CLASS="Definition">
primary outputs</SPAN>
<A NAME="marker=74124">
</A>
(<SPAN CLASS="Definition">
POs</SPAN>
<A NAME="marker=117910">
</A>
<A NAME="marker=117909">
</A>
). To test an ASIC we must devise a series of sets of input patterns that will detect any faults. A <A NAME="marker=74138">
</A>
<SPAN CLASS="Definition">
stimulus</SPAN>
is the application of one such set of inputs (a <A NAME="marker=74139">
</A>
<SPAN CLASS="Definition">
test vector</SPAN>
) to the PIs of an ASIC. A typical ASIC may have several hundred PIs and therefore each test vector is several hundred bits long. A <A NAME="marker=74141">
</A>
<SPAN CLASS="Definition">
test program</SPAN>
consists of a set of test vectors. Typical ASIC test programs require tens of thousands and sometimes hundreds of thousands of test vectors.</P>
<P CLASS="Body">
<A NAME="pgfId=74169">
</A>
The <A NAME="marker=74142">
</A>
<SPAN CLASS="Definition">
test-cycle time</SPAN>
is the period of time the tester requires to apply the stimulus, sense the POs, and check that the actual output is equal to the expected output. Suppose the test cycle time is 100 ns (corresponding to a test frequency of 10 MHz), in which case we might <SPAN CLASS="Definition">
sense</SPAN>
<A NAME="marker=74143">
</A>
(or <A NAME="marker=74144">
</A>
<SPAN CLASS="Definition">
strobe</SPAN>
) the POs at 90 ns after the beginning of each test cycle. Using fault simulation we mimic the behavior of the production test. The fault simulator deliberately introduces all possible faults into our ASIC, one at a time, to see if the test program will find them. For the moment we dodge the problem of how to create the thousands of test vectors required in a typical test program and focus on fault simulation.</P>
<P CLASS="Body">
<A NAME="pgfId=74147">
</A>
As each fault is inserted, the fault simulator runs our test program. If the fault simulation shows that the POs of the faulty circuit are different than the PIs of the good circuit at any strobe time, then we have a <A NAME="marker=74110">
</A>
<SPAN CLASS="Definition">
detected fault</SPAN>
; otherwise we have an <A NAME="marker=74112">
</A>
<SPAN CLASS="Definition">
undetected fault</SPAN>
. The list of <SPAN CLASS="Definition">
fault origins</SPAN>
<A NAME="marker=105563">
</A>
is collected in a file and as the faults are inserted and simulated, the results are recorded and the faults are marked according to the result. At the end of fault simulation we can find the <A NAME="marker=53553">
</A>
<SPAN CLASS="Definition">
fault coverage</SPAN>
, </P>
<TABLE>
<TR>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableEqn">
<A NAME="pgfId=133536">
</A>
fault coverage = detected faults / detectable faults.</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableEqnNumber">
<A NAME="pgfId=133538">
</A>
(14.1)</P>
</TD>
</TR>
</TABLE>
<P CLASS="Body">
<A NAME="pgfId=53558">
</A>
Detected faults and detectable faults will be defined in <A HREF="CH14.4.htm#16455" CLASS="XRef">
Section 14.4.5</A>
, after the description of fault simulation. For now assume that we wish to achieve close to 100 percent fault coverage. How does fault coverage relate to the ASIC defect level?</P>
<P CLASS="Body">
<A NAME="pgfId=75742">
</A>
<A HREF="CH14.4.htm#38966" CLASS="XRef">
Table 14.7</A>
shows the results of a typical experiment to measure the relationship between single stuck-at fault coverage and AQL. <A HREF="CH14.4.htm#38966" CLASS="XRef">
Table 14.7</A>
completes a circle with test and repair costs in <A HREF="CH14.1.htm#25163" CLASS="XRef">
Table 14.1</A>
and defect levels in <A HREF="CH14.1.htm#32494" CLASS="XRef">
Table 14.2</A>
. These experimental results are the only justification (but a good one) for our assumptions in adopting the SSF model. We are not quite sure why this model works so well, but, being engineers, as long as it continues to work we do not worry too much.</P>
<TABLE>
<TR>
<TD ROWSPAN="1" COLSPAN="3">
<P CLASS="TableTitle">
<A NAME="pgfId=53572">
</A>
TABLE 14.7 <A NAME="38966">
</A>
<A NAME="24795">
</A>
Average quality level as a function of single stuck-at fault coverage.</P>
</TD>
</TR>
<TR>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableFirst">
<A NAME="pgfId=53580">
</A>
<SPAN CLASS="TableHeads">
Fault coverage</SPAN>
</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableFirst">
<A NAME="pgfId=53582">
</A>
<SPAN CLASS="TableHeads">
Average defect level </SPAN>
</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableFirst">
<A NAME="pgfId=53584">
</A>
<SPAN CLASS="TableHeads">
Average quality level (AQL)</SPAN>
</P>
</TD>
</TR>
<TR>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="Table">
<A NAME="pgfId=53586">
</A>
50%</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="Table">
<A NAME="pgfId=53588">
</A>
7%</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="Table">
<A NAME="pgfId=53590">
</A>
93%</P>
</TD>
</TR>
<TR>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="Table">
<A NAME="pgfId=53592">
</A>
90%</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="Table">
<A NAME="pgfId=53594">
</A>
3%</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="Table">
<A NAME="pgfId=53596">
</A>
97%</P>
</TD>
</TR>
<TR>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="Table">
<A NAME="pgfId=53598">
</A>
95%</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="Table">
<A NAME="pgfId=53600">
</A>
1%</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="Table">
<A NAME="pgfId=53602">
</A>
99%</P>
</TD>
</TR>
<TR>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="Table">
<A NAME="pgfId=53604">
</A>
99%</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="Table">
<A NAME="pgfId=53606">
</A>
0.1%</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="Table">
<A NAME="pgfId=53608">
</A>
99.9%</P>
</TD>
</TR>
<TR>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="Table">
<A NAME="pgfId=53610">
</A>
99.9%</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="Table">
<A NAME="pgfId=53612">
</A>
0.01%</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="Table">
<A NAME="pgfId=53614">
</A>
99.99%</P>
</TD>
</TR>
</TABLE>
<P CLASS="Body">
<A NAME="pgfId=74240">
</A>
There are several algorithms for fault simulation: <SPAN CLASS="Emphasis">
serial</SPAN>
fault simulation, <SPAN CLASS="Emphasis">
parallel</SPAN>
fault simulation, and <SPAN CLASS="Emphasis">
concurrent</SPAN>
fault simulation. Next, we shall discuss each of these types of fault simulation in turn.</P>
<DIV>
<H2 CLASS="Heading2">
<A NAME="pgfId=53628">
</A>
14.4.1 Serial Fault Simulation</H2>
<P CLASS="BodyAfterHead">
<A NAME="pgfId=53629">
</A>
<SPAN CLASS="Definition">
Serial fault simulation</SPAN>
<A NAME="marker=56071">
</A>
is the simplest fault-simulation algorithm. We simulate two copies of the circuit, the first copy is a good circuit. We then pick a fault and insert it into the faulty circuit. In test terminology, the circuits are called <A NAME="marker=53630">
</A>
<SPAN CLASS="Definition">
machines</SPAN>
<A NAME="marker=117960">
</A>
, so the two copies are a <A NAME="marker=53631">
</A>
<SPAN CLASS="Definition">
good machine</SPAN>
and a <A NAME="marker=53632">
</A>
<SPAN CLASS="Definition">
faulty machine</SPAN>
. We shall continue to use the term <SPAN CLASS="Emphasis">
circuit</SPAN>
here to show the similarity between logic and fault simulation (the simulators are often the same program used in different modes). We then repeat the process, simulating one faulty circuit at a time. Serial simulation is slow and is impractical for large ASICs.</P>
</DIV>
<DIV>
<H2 CLASS="Heading2">
<A NAME="pgfId=53635">
</A>
14.4.2 Parallel Fault Simulation</H2>
<P CLASS="BodyAfterHead">
<A NAME="pgfId=53636">
</A>
<SPAN CLASS="Definition">
Parallel fault simulation</SPAN>
<A NAME="marker=56064">
</A>
takes advantage of multiple bits of the words in computer memory. In the simplest case we need only one bit to represent either a <SPAN CLASS="BodyComputer">
'1'</SPAN>
or <SPAN CLASS="BodyComputer">
'0'</SPAN>
for each node in the circuit. In a computer that uses a 32-bit word memory we can simulate a set of 32 copies of the circuit at the same time. One copy is the good circuit, and we insert different faults into the other copies. When we need to perform a logic operation, to model an AND gate for example, we can perform the operation across all bits in the word simultaneously. In this case, using one bit per node on a 32-bit machine, we would expect parallel fault simulation to be about 32 times faster than serial simulation. The number of bits per node that we need in order to simulate each circuit depends on the number of states in the logic system we are using. Thus, if we use a four-state system with <SPAN CLASS="BodyComputer">
'1'</SPAN>
, <SPAN CLASS="BodyComputer">
'0'</SPAN>
, <SPAN CLASS="BodyComputer">
'X'</SPAN>
(unknown), and <SPAN CLASS="BodyComputer">
'Z'</SPAN>
(high-impedance) states, we need two bits per node.</P>
<P CLASS="Body">
<A NAME="pgfId=53638">
</A>
Parallel fault simulation is not quite as fast as our simple prediction because we have to simulate all the circuits in parallel until the last fault in the current set is detected. If we use serial simulation we can stop as soon as a fault is detected and then start another fault simulation. Parallel fault simulation is faster than serial fault simulation but not as fast as concurrent fault simulation. It is also difficult to include behavioral models using parallel fault simulation.</P>
</DIV>
<DIV>
<H2 CLASS="Heading2">
<A NAME="pgfId=53650">
</A>
14.4.3 <A NAME="13120">
</A>
Concurrent Fault Simulation</H2>
<P CLASS="BodyAfterHead">
<A NAME="pgfId=53651">
</A>
<SPAN CLASS="Definition">
Concurrent fault simulation</SPAN>
<A NAME="marker=56070">
</A>
is the most widely used fault-simulation algorithm and takes advantage of the fact that a fault does not affect the whole circuit. Thus we do not need to simulate the whole circuit for each new fault. In concurrent simulation we first completely simulate the good circuit. We then inject a fault and resimulate a copy of only that part of the circuit that behaves differently (this is the <A NAME="marker=53652">
</A>
<SPAN CLASS="Definition">
diverged circuit</SPAN>
). For example, if the fault is in an inverter that is at a primary output, only the inverter needs to be simulated—we can remove everything preceding the inverter.</P>
<P CLASS="Body">
<A NAME="pgfId=53654">
</A>
Keeping track of exactly which parts of the circuit need to be diverged for each new fault is complicated, but the savings in memory and processing that result allow hundreds of faults to be simulated concurrently. Concurrent simulation is split into several chunks, you can usually control how many faults (usually around 100) are simulated in each chunk or <A NAME="marker=53655">
</A>
<SPAN CLASS="Definition">
pass</SPAN>
. Each pass thus consists of a series of test cycles. Every circuit has a unique <SPAN CLASS="Definition">
fault-activity signature</SPAN>
<A NAME="marker=74352">
</A>
that governs the divergence that occurs with different test vectors. Thus every circuit has a different optimum setting for <SPAN CLASS="Definition">
faults per pass</SPAN>
<A NAME="marker=74353">
</A>
. Too few faults per pass will not use resources efficiently. Too many faults per pass will overflow the memory.</P>
</DIV>
<DIV>
<H2 CLASS="Heading2">
<A NAME="pgfId=53665">
</A>
14.4.4 Nondeterministic Fault Simulation</H2>
<P CLASS="BodyAfterHead">
<A NAME="pgfId=53667">
</A>
Serial, parallel, and concurrent fault-simulation algorithms are forms of <A NAME="marker=53666">
</A>
<SPAN CLASS="Definition">
deterministic fault simulation</SPAN>
. In each of these algorithms we use a set of test vectors to simulate a circuit and discover which faults we can detect. If the fault coverage is inadequate, we modify the test vectors and repeat the fault simulation. This is a very time-consuming process. </P>
<P CLASS="Body">
<A NAME="pgfId=74400">
</A>
As an alternative we give up trying to simulate every possible fault and instead, using <A NAME="marker=74676">
</A>
<SPAN CLASS="Definition">
probabilistic fault simulation</SPAN>
, we simulate a subset or sample of the faults and extrapolate fault coverage from the sample.</P>
<P CLASS="Body">
<A NAME="pgfId=53673">
</A>
In <A NAME="marker=79154">
</A>
<SPAN CLASS="Definition">
statistical fault simulation</SPAN>
we perform a fault-free simulation and use the results to predict fault coverage. This is done by computing measures of observability and controllability at every node.</P>
<P CLASS="Body">
<A NAME="pgfId=79158">
</A>
We know that a node is not stuck if we can make the node toggle—that is, change from a <SPAN CLASS="BodyComputer">
'0'</SPAN>
to <SPAN CLASS="BodyComputer">
'1'</SPAN>
or vice versa. A <A NAME="marker=53672">
</A>
<SPAN CLASS="Definition">
toggle test</SPAN>
checks which nodes toggle as a result of applying test vectors and gives a statistical estimate of <SPAN CLASS="Definition">
vector quality</SPAN>
<A NAME="marker=74302">
</A>
, a measure of faults detected per test vector. There is a strong correlation between high-quality test vectors, the vectors that will detect most faults, and the test vectors that have the highest <SPAN CLASS="Definition">
toggle coverage</SPAN>
<A NAME="marker=74729">
</A>
. Testing for nodes toggling simply requires a single logic simulation that is much faster than complete fault simulation.</P>
<P CLASS="Body">
<A NAME="pgfId=74730">
</A>
We can obtain a considerable improvement in fault simulation speed by putting the high-quality test vectors at the beginning of the simulation. The sooner we can detect faults and eliminate them from having to be considered in each simulation, the faster the simulation will progress. We take the same approach when running a production test and initially order the test vectors by their contribution to fault coverage. This assumes that all faults are equally likely. Test engineers can then modify the test program if they discover vectors late in the test program that are efficient in detecting faulty chips.</P>
</DIV>
<DIV>
<H2 CLASS="Heading2">
<A NAME="pgfId=53676">
</A>
14.4.5 <A NAME="16455">
</A>
Fault-Simulation Results</H2>
<P CLASS="BodyAfterHead">
<A NAME="pgfId=53677">
</A>
The output of a fault simulator separates faults into several <SPAN CLASS="Definition">
fault categories</SPAN>
<A NAME="marker=74418">
</A>
. If we can detect a fault at a location, it is a <A NAME="marker=53678">
</A>
<SPAN CLASS="Definition">
testable fault</SPAN>
. A testable fault must be placed on a <A NAME="marker=53680">
</A>
<SPAN CLASS="Definition">
controllable net</SPAN>
, so that we can change the logic level at that location from <SPAN CLASS="BodyComputer">
'0'</SPAN>
to <SPAN CLASS="BodyComputer">
'1'</SPAN>
and from <SPAN CLASS="BodyComputer">
'1'</SPAN>
to <SPAN CLASS="BodyComputer">
'0'</SPAN>
. A testable fault must also be on an <A NAME="marker=53681">
</A>
<SPAN CLASS="Definition">
observable net</SPAN>
, so that we can see the effect of the fault at a PO. This means that <A NAME="marker=53682">
</A>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -