ch12.4.htm
来自「介绍asci设计的一本书」· HTM 代码 · 共 1,301 行 · 第 1/3 页
HTM
1,301 行
<P CLASS="ComputerLabelV">
<A NAME="pgfId=284461">
</A>
<B CLASS="Keyword">
output</B>
[width - 1 : 0] Q; <B CLASS="Keyword">
reg</B>
[width - 1 : 0] Q; <B CLASS="Keyword">
input</B>
Clk, Rst;</P>
<P CLASS="ComputerLabelV">
<A NAME="pgfId=284462">
</A>
<B CLASS="Keyword">
initial</B>
Q <= {width{1'bx}};</P>
<P CLASS="ComputerLabelV">
<A NAME="pgfId=284463">
</A>
<B CLASS="Keyword">
always</B>
@ ( <B CLASS="Keyword">
posedge</B>
Clk <B CLASS="Keyword">
or</B>
<B CLASS="Keyword">
negedge</B>
Rst )</P>
<P CLASS="ComputerLabelV">
<A NAME="pgfId=284464">
</A>
<B CLASS="Keyword">
if</B>
( Rst == 0 ) Q <= #1 reset_value; <B CLASS="Keyword">
else</B>
Q <= #1 D;</P>
<P CLASS="ComputerLabelV">
<A NAME="pgfId=284465">
</A>
<B CLASS="Keyword">
endmodule</B>
</P>
</DIV>
<DIV>
<H2 CLASS="Heading2">
<A NAME="pgfId=250991">
</A>
12.4.3 The Top-Level Model</H2>
<P CLASS="BodyAfterHead">
<A NAME="pgfId=284373">
</A>
The following code models the top-level Viterbi decoder and instantiates (with instance name <SPAN CLASS="BodyComputer">
v_1</SPAN>
) a copy of the Verilog module <SPAN CLASS="BodyComputer">
viterbi</SPAN>
from Chapter 11. The model uses generic input, output, power, and clock I/O cells from the standard-component library supplied with the synthesis software. The synthesizer will take these generic I/O cells and map them to I/O cells from a technology-specific library. We do not need three-state I/O cells or bidirectional I/O cells for the Viterbi ASIC. </P>
<P CLASS="ComputerFirstLabelV">
<A NAME="pgfId=245640">
</A>
/* This is the top-level module, viterbi_ASIC.v */</P>
<P CLASS="ComputerLabelV">
<A NAME="pgfId=245651">
</A>
<B CLASS="Keyword">
module</B>
viterbi_ASIC</P>
<P CLASS="ComputerLabelV">
<A NAME="pgfId=246280">
</A>
(padin0, padin1, padin2, padin3, padin4, padin5, padin6, padin7, </P>
<P CLASS="ComputerLabelV">
<A NAME="pgfId=246285">
</A>
padOut, padClk, padRes, padError);</P>
<P CLASS="ComputerLabelV">
<A NAME="pgfId=246287">
</A>
<B CLASS="Keyword">
input </B>
[2:0] padin0, padin1, padin2, padin3,</P>
<P CLASS="ComputerLabelV">
<A NAME="pgfId=353643">
</A>
padin4, padin5, padin6, padin7;</P>
<P CLASS="ComputerLabelV">
<A NAME="pgfId=246294">
</A>
<B CLASS="Keyword">
input </B>
padRes, padClk;<B CLASS="Keyword">
output </B>
padError; <B CLASS="Keyword">
output </B>
[2:0] padOut; </P>
<P CLASS="ComputerLabelV">
<A NAME="pgfId=245652">
</A>
<B CLASS="Keyword">
wire</B>
Error, Clk, Res; <B CLASS="Keyword">
wire</B>
[2:0] Out; // core </P>
<P CLASS="ComputerLabelV">
<A NAME="pgfId=246207">
</A>
<B CLASS="Keyword">
wire</B>
padError, padClk, padRes; <B CLASS="Keyword">
wire</B>
[2:0] padOut; </P>
<P CLASS="ComputerLabelV">
<A NAME="pgfId=245704">
</A>
<B CLASS="Keyword">
wire</B>
[2:0] in0,in1,in2,in3,in4,in5,in6,in7; // core </P>
<P CLASS="ComputerLabelV">
<A NAME="pgfId=246131">
</A>
<B CLASS="Keyword">
wire</B>
[2:0] </P>
<P CLASS="ComputerLabelV">
<A NAME="pgfId=284675">
</A>
padin0, padin1,padin2,padin3,padin4,padin5,padin6,padin7;</P>
<P CLASS="ComputerLabelV">
<A NAME="pgfId=246064">
</A>
// Do not let the software mess with the pads.</P>
<P CLASS="ComputerLabelV">
<A NAME="pgfId=246324">
</A>
//compass dontTouch u* </P>
<P CLASS="ComputerLabelV">
<A NAME="pgfId=246065">
</A>
asPadIn #(3,"1,2,3") u0 (in0, padin0);</P>
<P CLASS="ComputerLabelV">
<A NAME="pgfId=246083">
</A>
asPadIn #(3,"4,5,6") u1 (in1, padin1);</P>
<P CLASS="ComputerLabelV">
<A NAME="pgfId=246087">
</A>
asPadIn #(3,"7,8,9") u2 (in2, padin2);</P>
<P CLASS="ComputerLabelV">
<A NAME="pgfId=246091">
</A>
asPadIn #(3,"10,11,12") u3 (in3, padin3);</P>
<P CLASS="ComputerLabelV">
<A NAME="pgfId=246095">
</A>
asPadIn #(3,"13,14,15") u4 (in4, padin4);</P>
<P CLASS="ComputerLabelV">
<A NAME="pgfId=246099">
</A>
asPadIn #(3,"16,17,18") u5 (in5, padin5);</P>
<P CLASS="ComputerLabelV">
<A NAME="pgfId=246103">
</A>
asPadIn #(3,"19,20,21") u6 (in6, padin6);</P>
<P CLASS="ComputerLabelV">
<A NAME="pgfId=246256">
</A>
asPadIn #(3,"22,23,24") u7 (in7, padin7);</P>
<P CLASS="ComputerLabelV">
<A NAME="pgfId=246157">
</A>
asPadVdd #("25","both") u25 (vddb);</P>
<P CLASS="ComputerLabelV">
<A NAME="pgfId=246158">
</A>
asPadVss #("26","both") u26 (vssb);</P>
<P CLASS="ComputerLabelV">
<A NAME="pgfId=246191">
</A>
asPadClk #("27") u27 (Clk, padClk);</P>
<P CLASS="ComputerLabelV">
<A NAME="pgfId=246224">
</A>
asPadOut #(1,"28") u28 (padError, Error);</P>
<P CLASS="ComputerLabelV">
<A NAME="pgfId=246242">
</A>
asPadin #(1,"29") u29 (Res, padRes);</P>
<P CLASS="ComputerLabelV">
<A NAME="pgfId=251144">
</A>
asPadOut #(3,"30,31,32") u30 (padOut, Out);</P>
<P CLASS="ComputerLabelV">
<A NAME="pgfId=245668">
</A>
// Here is the core module:</P>
<P CLASS="ComputerLabelV">
<A NAME="pgfId=246069">
</A>
viterbi v_1</P>
<P CLASS="ComputerLabelV">
<A NAME="pgfId=245669">
</A>
(in0,in1,in2,in3,in4,in5,in6,in7,Out,Clk,Res,Error);</P>
<P CLASS="ComputerLastLabelV">
<A NAME="pgfId=245670">
</A>
<B CLASS="Keyword">
endmodule</B>
</P>
<P CLASS="Body">
<A NAME="pgfId=246650">
</A>
At this point we are ready to begin synthesis. In order to demonstrate how synthesis works, I am cheating here. The code that was presented in Chapter 11 has already been simulated and synthesized (requiring several iterations to produce error-free code). What I am doing is a little like the Galloping Gourmet’s television presentation: “And then we put the soufflé in the oven . . . and look at the soufflé that I prepared earlier.” The synthesis results for the Viterbi decoder are shown in <A HREF="#27256" CLASS="XRef">
Table 12.6</A>
. Normally the worst thing we can do is prepare a large amount of code, put it in the synthesis oven, close the door, push the “synthesize and optimize” button, and wait. Unfortunately, it is easy to do. In our case it works (at least we may think so at this point) because this is a small ASIC by today’s standards—only a few thousand gates. I made the bus widths small and chose this example so that the code was of a reasonable size. Modern ASICs may be over one million gates, hundreds of times more complicated than our Viterbi decoder example.</P>
<TABLE>
<TR>
<TD ROWSPAN="1" COLSPAN="2">
<P CLASS="TableTitle">
<A NAME="pgfId=246688">
</A>
TABLE 12.6 <A NAME="27256">
</A>
Initial synthesis results of the Viterbi decoder ASIC.</P>
</TD>
</TR>
<TR>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableFirst">
<A NAME="pgfId=246693">
</A>
Command</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableFirst">
<A NAME="pgfId=246698">
</A>
Synthesizer output<A HREF="#pgfId=246697" CLASS="footnote">
1</A>
<SUP CLASS="Superscript">
, </SUP>
<A HREF="#pgfId=264841" CLASS="footnote">
2</A>
</P>
</TD>
</TR>
<TR>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="Computer">
<A NAME="pgfId=246700">
</A>
> optimize</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="Computer">
<A NAME="pgfId=252854">
</A>
Num Gate Count Tot Gate Width Total</P>
<P CLASS="Computer">
<A NAME="pgfId=252855">
</A>
Cell Name Insts Per Cell Count Per Cell Width</P>
<P CLASS="Computer">
<A NAME="pgfId=252856">
</A>
--------- ----- ---------- -------- -------- --------</P>
<P CLASS="Computer">
<A NAME="pgfId=252857">
</A>
pc5c01 1 315.4 315.4 100.8 100.8</P>
<P CLASS="Computer">
<A NAME="pgfId=252858">
</A>
pc5d01r 26 315.4 8200.4 100.8 2620.8</P>
<P CLASS="Computer">
<A NAME="pgfId=252859">
</A>
pc5o06 4 315.4 1261.6 100.8 403.2</P>
<P CLASS="Computer">
<A NAME="pgfId=252860">
</A>
pv0f 1 315.4 315.4 100.8 100.8</P>
<P CLASS="Computer">
<A NAME="pgfId=252861">
</A>
pvdf 1 315.4 315.4 100.8 100.8</P>
<P CLASS="Computer">
<A NAME="pgfId=252862">
</A>
viterbi_p 1 1880.0 1880.0 18048.0 18048.0</P>
</TD>
</TR>
</TABLE>
<P CLASS="Body">
<A NAME="pgfId=247785">
</A>
The derived schematic for the synthesized core logic is shown in <A HREF="#33719" CLASS="XRef">
Figure 12.6</A>
. There are eight boxes in <A HREF="#33719" CLASS="XRef">
Figure 12.6</A>
that represent the eight modules in the Verilog code. The schematics for each of these eight blocks are too complex to be useful. With practice it is possible to “see” the synthesized logic from reports such as <A HREF="#27256" CLASS="XRef">
Table 12.6</A>
. First we check the following cells at the top level:</P>
<TABLE>
<TR>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableFigure">
<A NAME="pgfId=247792">
</A>
<IMG SRC="CH12-6.gif" ALIGN="BASELINE">
</P>
</TD>
</TR>
<TR>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableFigureTitle">
<A NAME="pgfId=247794">
</A>
FIGURE 12.6 <A NAME="33719">
</A>
The core logic of the Viterbi decoder ASIC. Bus names are abbreviated in this figure for clarity. For example the label m_out0-3 denotes the four buses: m_out0, m_out1, m_out2, and m_out3.</P>
</TD>
</TR>
</TABLE>
<UL>
<LI CLASS="BulletFirst">
<A NAME="pgfId=252235">
</A>
<SPAN CLASS="BodyComputer">
pc5c01</SPAN>
is an I/O cell that drives the clock node into the logic core. ASIC designers also call an I/O cell a <SPAN CLASS="Definition">
pad cell</SPAN>
<A NAME="marker=267783">
</A>
, and often refer to the pad cells (the bonding pads and associated logic) as just “the <SPAN CLASS="Definition">
pads</SPAN>
<A NAME="marker=267782">
</A>
.” From the library data book we find this is a “core-driven, noninverting clock buffer capable of driving 125 pF.” This is a large logic cell and does not have a bonding pad, but is placed in a pad site (a slot in the ring of pads around the perimeter of the die) as if it were an I/O cell with a bonding pad. </LI>
<LI CLASS="BulletList">
<A NAME="pgfId=251017">
</A>
<SPAN CLASS="BodyComputer">
pc5d01r</SPAN>
is a 5V CMOS input-only I/O cell with a bus repeater. Twenty-four of these I/O cells are used for the 24 inputs (<SPAN CLASS="BodyComputer">
in0</SPAN>
to <SPAN CLASS="BodyComputer">
in7</SPAN>
). Two more are used for <SPAN CLASS="BodyComputer">
Res</SPAN>
and <SPAN CLASS="BodyComputer">
Clk</SPAN>
. The I/O cell for <SPAN CLASS="BodyComputer">
Clk</SPAN>
receives the clock signal from the bonding pad and drives the clock buffer cell (<SPAN CLASS="BodyComputer">
pc5c01</SPAN>
). The <SPAN CLASS="BodyComputer">
pc5c01</SPAN>
cell then buffers and drives the clock back into the core. The power-hungry clock buffer is placed in the pad ring near the VDD and VSS pads. </LI>
<LI CLASS="BulletList">
<A NAME="pgfId=251021">
</A>
<SPAN CLASS="BodyComputer">
pc5o06</SPAN>
is a CMOS output-only I/O cell with 6X drive strength (6 mA AC drive and 4 mA DC drive). There are four output pads: three pads for the signal outputs, <SPAN CLASS="BodyComputer">
outp[2:0</SPAN>
], and one pad for the output signal, <SPAN CLASS="BodyComputer">
error</SPAN>
.</LI>
<LI CLASS="BulletList">
<A NAME="pgfId=251019">
</A>
<SPAN CLASS="BodyComputer">
pv0f</SPAN>
is a power pad that connects all VSS power buses on the chip. </LI>
<LI CLASS="BulletList">
<A NAME="pgfId=251020">
</A>
<SPAN CLASS="BodyComputer">
pvdf</SPAN>
is a power pad that connects all VDD power buses on the chip.</LI>
<LI CLASS="BulletList">
<A NAME="pgfId=252461">
</A>
<SPAN CLASS="BodyComputer">
viterbi_p</SPAN>
is the core logic. This cell takes its name from the top-level Verilog module (<SPAN CLASS="BodyComputer">
viterbi</SPAN>
). The software has appended a <SPAN CLASS="BodyComputer">
"_p" </SPAN>
suffix (the default) to prevent input files being accidentally overwritten.</LI>
</UL>
<P CLASS="BodyAfterHead">
<A NAME="pgfId=252686">
</A>
The software does not tell us any of this directly. We learn what is going on by looking at the names and number of the synthesized cells, reading the synthesis tool documentation, and from experience. We shall learn more about I/O pads and the layout of power supply buses in Chapter 16. </P>
<P CLASS="Body">
<A NAME="pgfId=253390">
</A>
Next we examine the cells used in the logic core. Most synthesis tools can produce reports, such as that shown in <A HREF="#17078" CLASS="XRef">
Table 12.7</A>
, which lists all the synthesized cells. The most important types of cells to check are the sequential elements: flip-flops and latches (I have omitted all but the sequential logic cells in <A HREF="#17078" CLASS="XRef">
Table 12.7</A>
). One of the most common mistakes in synthesis is to accidentally leave variables unassigned in all situations in the HDL. Unassigned variables require memory and will generate unnecessary sequential logic. In the Viterbi decoder it is easy to identify the sequential logic cells that should be present in the synthesized logic because we used the module <SPAN CLASS="BodyComputer">
dff</SPAN>
explicitly whenever we required a flip-flop. By scanning the code in Chapter 11 and counting the references to the <SPAN CLASS="BodyComputer">
dff</SPAN>
model, we can see that the only flip-flops that should be inferred are the following:</P>
<UL>
<LI CLASS="BulletFirst">
<A NAME="pgfId=252876">
</A>
24 (3 <SPAN CLASS="Symbol">
¥</SPAN>
8) D flip-flops in instance <SPAN CLASS="BodyComputer">
subset_decode</SPAN>
</LI>
<LI CLASS="BulletList">
<A NAME="pgfId=252879">
</A>
132 (11 <SPAN CLASS="Symbol">
¥</SPAN>
12) D flip-flops in instance <SPAN CLASS="BodyComputer">
path_memory</SPAN>
that contains 11 instances of <SPAN CLASS="BodyComputer">
path</SPAN>
(12 D flip-flops in each instance of <SPAN CLASS="BodyComputer">
path</SPAN>
)</LI>
<LI CLASS="BulletList">
<A NAME="pgfId=252880">
</A>
12 D flip-flops in instance <SPAN CLASS="BodyComputer">
pathin</SPAN>
</LI>
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?