📄 ch13.2.htm
字号:
A2 --> ZN .41 .72 R .26 .07 nd02d0 </P>
<P CLASS="Computer">
<A NAME="pgfId=85503">
</A>
b1_i2 </P>
<P CLASS="Computer">
<A NAME="pgfId=85504">
</A>
C --> ZN 1.36 2.08 F .13 .07 oa03d1 </P>
<P CLASS="Computer">
<A NAME="pgfId=85505">
</A>
b1_i6 </P>
<P CLASS="Computer">
<A NAME="pgfId=85506">
</A>
B --> ZN .94 3.01 R .24 .14 oa04d1 </P>
<P CLASS="Computer">
<A NAME="pgfId=85507">
</A>
b1_i5 </P>
<P CLASS="Computer">
<A NAME="pgfId=85508">
</A>
S --> Z 1.04 4.06 F .08 .04 mx21d1 </P>
<P CLASS="Computer">
<A NAME="pgfId=85509">
</A>
outp[0] .00 4.06 F .00 .00 comp_m...</P>
</TD>
</TR>
</TABLE>
</DIV>
<DIV>
<H2 CLASS="Heading2">
<A NAME="pgfId=56541">
</A>
13.2.2 Static Timing Analysis</H2>
<P CLASS="BodyAfterHead">
<A NAME="pgfId=81230">
</A>
A timing analyzer answers the question: “What is the longest delay in my circuit?” <A HREF="CH13.2.htm#23209" CLASS="XRef">
Table 13.1</A>
shows the timing analysis of the comparator/MUX structural model, module <SPAN CLASS="BodyComputer">
comp_mux_o2.v</SPAN>
. The longest or critical path delay is 4.06 ns under the following worst-case operating conditions: worst-case process, <SPAN CLASS="EquationVariables">
V</SPAN>
<SUB CLASS="SubscriptVariable">
DD</SUB>
= 4.75 V, and <SPAN CLASS="EquationVariables">
T</SPAN>
= 70<SPAN CLASS="Symbol">
∞</SPAN>
C (the same conditions as used for the library data book delay values). The timing analyzer gives us only the critical path and its delay. A timing analyzer does not give us the input vectors that will activate the critical path. In fact input vectors may not exist to activate the critical path. For example, it may be that the decimal values of the input vectors to the comparator/MUX may never differ by more than four, but the timing-analysis tool cannot use this information. Future timing-analysis tools may consider such factors, called <SPAN CLASS="Definition">
Boolean relations</SPAN>
<A NAME="marker=116977">
</A>
, but at present they do not.</P>
<P CLASS="Body">
<A NAME="pgfId=117037">
</A>
<A HREF="CH13.2.htm#23329" CLASS="XRef">
Section 13.2.1</A>
explained why dynamic functional simulation does not necessarily find the critical path delay. Nevertheless, the difference between the longest path delay found using functional simulation, 3.17 ns, and the critical path delay reported by the static timing-analysis tool, 4.06 ns, is surprising. This difference occurs because the timing analysis accounts for the loading of each logic cell by the input capacitance of the logic cells that follow, but the simplified Verilog models used for functional simulation in <A HREF="CH13.2.htm#23329" CLASS="XRef">
Section 13.2.1</A>
did not include the effects of capacitive loading. For example, in the model for the logic cell <SPAN CLASS="BodyComputer">
mx21d1</SPAN>
, the (rising) delay from the <SPAN CLASS="BodyComputer">
i0</SPAN>
input to the output <SPAN CLASS="BodyComputer">
z</SPAN>
, was fixed at 0.900 ns worst case (the maximum delay value is the third number in the first triplet in line <A HREF="CH13.2.htm#23032" CLASS="XRef">
7</A>
of module <SPAN CLASS="BodyComputer">
mx21d1</SPAN>
). Normally library models include another portion that adjusts the timing of each logic cell—this portion was removed to simplify the model <SPAN CLASS="BodyComputer">
mx21d1</SPAN>
shown in <A HREF="CH13.2.htm#23329" CLASS="XRef">
Section 13.2.1</A>
.</P>
<P CLASS="Body">
<A NAME="pgfId=61570">
</A>
Most timing analyzers do not consider the function of the logic when they search for the critical path. Thus, for example, the following code models <SPAN CLASS="BodyComputer">
z = NAND(a, NOT(a))</SPAN>
, which means that the output, <SPAN CLASS="BodyComputer">
z</SPAN>
, is always <SPAN CLASS="BodyComputer">
'1'</SPAN>
. </P>
<P CLASS="ComputerFirstLabelV">
<A NAME="pgfId=61774">
</A>
<B CLASS="Keyword">
module</B>
check_critical_path_1 (a, z);</P>
<P CLASS="ComputerLabelV">
<A NAME="pgfId=61571">
</A>
<B CLASS="Keyword">
input</B>
a; <B CLASS="Keyword">
output</B>
z; <B CLASS="Keyword">
supply1</B>
VDD; <B CLASS="Keyword">
supply0</B>
VSS;</P>
<P CLASS="ComputerLabelV">
<A NAME="pgfId=61577">
</A>
nd02d0 b1_i3 (.a1(a), .a2(b), .zn(z)); // 2-input NAND</P>
<P CLASS="ComputerLabelV">
<A NAME="pgfId=61582">
</A>
in01d0 b1_i7 (.i(a), .zn(b)); // inverter</P>
<P CLASS="ComputerLastLabelV">
<A NAME="pgfId=61585">
</A>
<B CLASS="Keyword">
endmodule</B>
</P>
<P CLASS="Body">
<A NAME="pgfId=61566">
</A>
A timing-analyzer report for this model might show the following critical path:</P>
<P CLASS="ComputerFirst">
<A NAME="pgfId=61625">
</A>
inPin --> outPin incr arrival trs rampDel cap cell </P>
<P CLASS="Computer">
<A NAME="pgfId=61626">
</A>
(ns) (ns) (ns) (pf) </P>
<P CLASS="Computer">
<A NAME="pgfId=61627">
</A>
--------------------------------------------------------------------</P>
<P CLASS="Computer">
<A NAME="pgfId=61628">
</A>
a .00 .00 R .00 .08 check_...</P>
<P CLASS="Computer">
<A NAME="pgfId=61927">
</A>
b1_i7</P>
<P CLASS="Computer">
<A NAME="pgfId=61630">
</A>
I --> ZN .38 .38 F .30 .07 in01d0 </P>
<P CLASS="Computer">
<A NAME="pgfId=61631">
</A>
b1_i3 </P>
<P CLASS="Computer">
<A NAME="pgfId=62025">
</A>
A2 --> ZN .28 .66 R .13 .04 nd02d0 </P>
<P CLASS="ComputerLast">
<A NAME="pgfId=61633">
</A>
z .00 .66 R .00 .00 check_...</P>
<P CLASS="BodyAfterHead">
<A NAME="pgfId=61640">
</A>
Paths such as this, which are impossible to activate, are known as <SPAN CLASS="Definition">
false paths</SPAN>
<A NAME="marker=62155">
</A>
. Timing analysis is essential to ASIC design but has limitations. A timing-analysis tool is more logic calculator than logic simulator. </P>
</DIV>
<DIV>
<H2 CLASS="Heading2">
<A NAME="pgfId=61565">
</A>
13.2.3 <A NAME="22198">
</A>
Gate-Level Simulation</H2>
<P CLASS="BodyAfterHead">
<A NAME="pgfId=80900">
</A>
To illustrate the differences between functional simulation, timing analysis, and gate-level simulation, we shall simulate the comparator/MUX critical path (the path is shown in <A HREF="CH13.2.htm#23209" CLASS="XRef">
Table 13.1</A>
). We start by trying to find vectors that activate this critical path by working forward from the beginning of the critical path, the input <SPAN CLASS="BodyComputer">
a[0]</SPAN>
, toward the end of the critical path, output <SPAN CLASS="BodyComputer">
outp[0]</SPAN>
, as follows:</P>
<OL>
<LI CLASS="NumberFirst">
<A NAME="pgfId=58854">
</A>
Input <SPAN CLASS="BodyComputer">
a[0]</SPAN>
to the two-input NAND, <SPAN CLASS="BodyComputer">
nd02d0</SPAN>
, cell instance <SPAN CLASS="BodyComputer">
b1_i3</SPAN>
, changes from a <SPAN CLASS="BodyComputer">
'0'</SPAN>
to a <SPAN CLASS="BodyComputer">
'1'</SPAN>
. We know this because there is an <SPAN CLASS="BodyComputer">
'R' </SPAN>
(for rising) under the <SPAN CLASS="BodyComputer">
trs</SPAN>
(for transition) heading on the first line of the critical path timing analysis report in <A HREF="CH13.2.htm#23209" CLASS="XRef">
Table 13.1</A>
.</LI>
<LI CLASS="NumberList">
<A NAME="pgfId=62550">
</A>
Input <SPAN CLASS="BodyComputer">
a[1]</SPAN>
to the two-input NAND, <SPAN CLASS="BodyComputer">
nd02d0</SPAN>
, cell instance <SPAN CLASS="BodyComputer">
b1_i3</SPAN>
, must be a <SPAN CLASS="BodyComputer">
'1'</SPAN>
. This allows the change on <SPAN CLASS="BodyComputer">
a[0]</SPAN>
to propagate toward the output, <SPAN CLASS="BodyComputer">
outp[0]</SPAN>
.</LI>
<LI CLASS="NumberList">
<A NAME="pgfId=58857">
</A>
Similarly, input <SPAN CLASS="BodyComputer">
b[1]</SPAN>
to the two-input NAND, cell instance <SPAN CLASS="BodyComputer">
b1_i4</SPAN>
, must be a <SPAN CLASS="BodyComputer">
'1'</SPAN>
.</LI>
<LI CLASS="NumberList">
<A NAME="pgfId=62464">
</A>
We skip over the required inputs to cells <SPAN CLASS="BodyComputer">
b1_i2</SPAN>
and <SPAN CLASS="BodyComputer">
b1_i6</SPAN>
for the moment.</LI>
<LI CLASS="NumberList">
<A NAME="pgfId=119998">
</A>
From the last line of <A HREF="CH13.2.htm#23209" CLASS="XRef">
Table 13.1</A>
we know the output of MUX, <SPAN CLASS="BodyComputer">
mx21d1</SPAN>
, cell instance <SPAN CLASS="BodyComputer">
b1_i5</SPAN>
, changes from <SPAN CLASS="BodyComputer">
'1'</SPAN>
to a <SPAN CLASS="BodyComputer">
'0'</SPAN>
. From the previous line in <A HREF="CH13.2.htm#23209" CLASS="XRef">
Table 13.1</A>
we know that the select input of this MUX changes from <SPAN CLASS="BodyComputer">
'0'</SPAN>
to a <SPAN CLASS="BodyComputer">
'1'</SPAN>
. This means that the final value of input <SPAN CLASS="BodyComputer">
b[0]</SPAN>
(the <SPAN CLASS="BodyComputer">
i1</SPAN>
input, selected when the select input is <SPAN CLASS="BodyComputer">
'1'</SPAN>
) must be <SPAN CLASS="BodyComputer">
'0'</SPAN>
(since this is the final value that must appear at the MUX output). Similarly, the initial value of <SPAN CLASS="BodyComputer">
a[0]</SPAN>
must be a <SPAN CLASS="BodyComputer">
'1'</SPAN>
.</LI>
</OL>
<P CLASS="BodyAfterHead">
<A NAME="pgfId=62571">
</A>
We have now contradicted ourselves. In step 1 we saw that the initial value of <SPAN CLASS="BodyComputer">
a[0]</SPAN>
must be a <SPAN CLASS="BodyComputer">
'0'</SPAN>
. The critical path is thus a false path. Nevertheless we shall proceed. We set the initial input vector to (<SPAN CLASS="BodyComputer">
a = '110'</SPAN>
, <SPAN CLASS="BodyComputer">
b = '111')</SPAN>
and then to (<SPAN CLASS="BodyComputer">
a = '111'</SPAN>
, <SPAN CLASS="BodyComputer">
b = '110'</SPAN>
). These vectors allow the change on <SPAN CLASS="BodyComputer">
a[0]</SPAN>
to propagate to the select signal of the MUX, <SPAN CLASS="BodyComputer">
mx21d1</SPAN>
, cell instance <SPAN CLASS="BodyComputer">
b1_i5</SPAN>
. In decimal we are changing <SPAN CLASS="BodyComputer">
a</SPAN>
from 6 to 7, and <SPAN CLASS="BodyComputer">
b</SPAN>
from 7 to 6; the output should remain unchanged at 6. The simulation results from the gate-level simulator we shall use (<A NAME="marker=86126">
</A>
CompassSim) can be displayed graphically or in the text form that follows:</P>
<P CLASS="ComputerFirst">
<A NAME="pgfId=59124">
</A>
...</P>
<P CLASS="Computer">
<A NAME="pgfId=59037">
</A>
# The calibration was done at Vdd=4.65V, Vss=0.1V, T=70 degrees C</P>
<P CLASS="Computer">
<A NAME="pgfId=59007">
</A>
Time = 0:0 [0 ns]</P>
<P CLASS="Computer">
<A NAME="pgfId=59008">
</A>
a = 'D6 [0] (input)(display)</P>
<P CLASS="Computer">
<A NAME="pgfId=59009">
</A>
b = 'D7 [0] (input)(display)</P>
<P CLASS="Computer">
<A NAME="pgfId=59010">
</A>
outp = 'Buuu ('Du) [0] (display)</P>
<P CLASS="Computer">
<A NAME="pgfId=59017">
</A>
outp --> 'B1uu ('Du) [.47]</P>
<P CLASS="Computer">
<A NAME="pgfId=59018">
</A>
outp --> 'B11u ('Du) [.97]</P>
<P CLASS="Computer">
<A NAME="pgfId=59019">
</A>
outp --> 'D6 [4.08]</P>
<P CLASS="Computer">
<A NAME="pgfId=59020">
</A>
a --> 'D7 [10]</P>
<P CLASS="Computer">
<A NAME="pgfId=59021">
</A>
b --> 'D6 [10]</P>
<P CLASS="Computer">
<A NAME="pgfId=59022">
</A>
outp --> 'D7 [10.97]</P>
<P CLASS="Computer">
<A NAME="pgfId=59023">
</A>
outp --> 'D6 [14.15]</P>
<P CLASS="ComputerLast">
<A NAME="pgfId=59024">
</A>
Time = 0:0 +20ns [20 ns]</P>
<P CLASS="Body">
<A NAME="pgfId=58980">
</A>
The code <SPAN CLASS="BodyComputer">
'Buuu</SPAN>
denotes that the output is initially, at <SPAN CLASS="EquationVariables">
t</SPAN>
= 0 ns, a binary vector of three unknown or <SPAN CLASS="Definition">
unsettled</SPAN>
<A NAME="marker=70687">
</A>
signals. The output bits become valid as follows: <SPAN CLASS="BodyComputer">
outp[2]</SPAN>
at 0.47 ns, <SPAN CLASS="BodyComputer">
outp[1] </SPAN>
at 0.97 ns, and <SPAN CLASS="BodyComputer">
outp[0]</SPAN>
at 4.08 ns. The output is stable at <SPAN CLASS="BodyComputer">
'D6</SPAN>
(decimal 6) or <SPAN CLASS="BodyComputer">
'110'</SPAN>
at <SPAN CLASS="EquationVariables">
t</SPAN>
= 10 ns when the input vectors are changed in an attempt to activate the critical path. The output glitches from <SPAN CLASS="BodyComputer">
'D6</SPAN>
(<SPAN CLASS="BodyComputer">
'110'</SPAN>
) to <SPAN CLASS="BodyComputer">
'D7</SPAN>
(<SPAN CLASS="BodyComputer">
'111'</SPAN>
) at t = 10.97 ns and back to <SPAN CLASS="BodyComputer">
'D6</SPAN>
again at <SPAN CLASS="EquationVariables">
t</SPAN>
= 14.15 ns. Thus, the output bit, <SPAN CLASS="BodyComputer">
outp[0]</SPAN>
, takes a total of 4.15 ns to settle. </P>
<P CLASS="Body">
<A NAME="pgfId=62915">
</A>
Can we explain this behavior? The data book entry for the <SPAN CLASS="BodyComputer">
mx21d1</SPAN>
logic cell gives the following equation for the rising delay as a function of <SPAN CLASS="BodyComputer">
Cld</SPAN>
(the load capacitance, excluding the output capacitance of the logic cell itself, expressed in picofarads): </P>
<TABLE>
<TR>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableEqnLeft">
<A NAME="pgfId=131271">
</A>
<SPAN CLASS="BodyComputer">
tI0Z (IO->Z) = 0.90 + 0.07 + (1.76 </SPAN>
<SPAN CLASS="Symbol">
¥</SPAN>
<SPAN CLASS="BodyComputer">
Cld) ns</SPAN>
</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableEqnNumber">
<A NAME="pgfId=131274">
</A>
<A NAME="17024">
</A>
(13.1)</P>
</TD>
</TR>
</TABLE>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -