ch17.4.htm

介绍asci设计的一本书

C3</SPAN>
 and <SPAN CLASS="BodyComputer">
C4</SPAN>
 here) and a resistor (<SPAN CLASS="BodyComputer">
R3</SPAN>
 and <SPAN CLASS="BodyComputer">
R4</SPAN>
) adjusted to give the correct RC delay. Since the load on the output gate is modeled by the PI segment it does not matter what value of capacitance is chosen here.</LI>
<LI CLASS="BulletLast">
<A NAME="pgfId=17361">
 </A>
The RC elements at the gate inputs are driven by ideal voltage sources (<SPAN CLASS="BodyComputer">
E1</SPAN>
 and <SPAN CLASS="BodyComputer">
E2</SPAN>
) that are equal to the voltage at the output of the driving gate.</LI>
</UL>
<P CLASS="Body">
<A NAME="pgfId=17364">
 </A>
The <A NAME="marker=17362">
 </A>
<SPAN CLASS="Definition">
detailed SPF</SPAN>
 (<A NAME="marker=17363">
 </A>
<A NAME="marker=39135">
 </A>
DSPF) shows the resistance and capacitance of each segment in a net, again in a SPICE format. There are no models or assumptions on calculating the net delays in this format. Here is an example DSPF file that describes the interconnect shown in <A HREF="CH17.4.htm#13082" CLASS="XRef">
Figure&nbsp;17.23</A>
(a):</P>
<P CLASS="ComputerFirst">
<A NAME="pgfId=17365">
 </A>
.SUBCKT BUFFER OUT IN</P>
<P CLASS="Computer">
<A NAME="pgfId=17366">
 </A>
* Net Section</P>
<P CLASS="Computer">
<A NAME="pgfId=17367">
 </A>
*|GROUND_NET VSS</P>
<P CLASS="Computer">
<A NAME="pgfId=17368">
 </A>
*|NET IN 3.8E-01PF</P>
<P CLASS="Computer">
<A NAME="pgfId=17369">
 </A>
*|P (IN I 0.0 0.0 5.0)</P>
<P CLASS="Computer">
<A NAME="pgfId=17370">
 </A>
*|I (INV1:A INV A I 0.0 10.0 5.0)</P>
<P CLASS="Computer">
<A NAME="pgfId=17372">
 </A>
C1 IN VSS 1.1E-01PF</P>
<P CLASS="Computer">
<A NAME="pgfId=17373">
 </A>
C2 INV1:A VSS 2.7E-01PF</P>
<P CLASS="Computer">
<A NAME="pgfId=17374">
 </A>
R1 IN INV1:A 1.7E00</P>
<P CLASS="Computer">
<A NAME="pgfId=17375">
 </A>
*|NET OUT 1.54E-01PF</P>
<P CLASS="Computer">
<A NAME="pgfId=17376">
 </A>
*|S (OUT:1 30.0 10.0)</P>
<P CLASS="Computer">
<A NAME="pgfId=17377">
 </A>
*|P (OUT O 0.0 30.0 0.0)</P>
<P CLASS="Computer">
<A NAME="pgfId=17378">
 </A>
*|I (INV:OUT INV1 OUT O 0.0 20.0 10.0)</P>
<P CLASS="Computer">
<A NAME="pgfId=17379">
 </A>
C3 INV1:OUT VSS 1.4E-01PF</P>
<P CLASS="Computer">
<A NAME="pgfId=17380">
 </A>
C4 OUT:1 VSS 6.3E-03PF</P>
<P CLASS="Computer">
<A NAME="pgfId=17381">
 </A>
C5 OUT VSS 7.7E-03PF</P>
<P CLASS="Computer">
<A NAME="pgfId=17382">
 </A>
R2 INV1:OUT OUT:1 3.11E00</P>
<P CLASS="Computer">
<A NAME="pgfId=17383">
 </A>
R3 OUT:1 OUT 3.03E00</P>
<P CLASS="Computer">
<A NAME="pgfId=17384">
 </A>
*Instance Section</P>
<P CLASS="Computer">
<A NAME="pgfId=17385">
 </A>
XINV1 INV:A INV1:OUT INV</P>
<P CLASS="ComputerLast">
<A NAME="pgfId=17386">
 </A>
.ENDS</P>
<P CLASS="Body">
<A NAME="pgfId=24803">
 </A>
The nonstandard SPICE statements in DSPF are comments that start with <SPAN CLASS="BodyComputer">
'*|'</SPAN>
 and have the following formats:</P>
<P CLASS="ComputerFirst">
<A NAME="pgfId=24762">
 </A>
*|I(InstancePinName InstanceName PinName PinType PinCap X Y)</P>
<P CLASS="Computer">
<A NAME="pgfId=24763">
 </A>
*|P(PinName PinType PinCap X Y)</P>
<P CLASS="Computer">
<A NAME="pgfId=24766">
 </A>
*|NET NetName NetCap</P>
<P CLASS="Computer">
<A NAME="pgfId=24767">
 </A>
*|S(SubNodeName X Y)</P>
<P CLASS="ComputerLast">
<A NAME="pgfId=24768">
 </A>
*|GROUND_NET NetName</P>
<P CLASS="BodyAfterHead">
<A NAME="pgfId=92329">
 </A>
<A HREF="CH17.4.htm#13082" CLASS="XRef">
Figure&nbsp;17.23</A>
(b) illustrates the meanings of the DSPF terms: <SPAN CLASS="BodyComputer">
InstancePinName</SPAN>
<A NAME="marker=92330">
 </A>
, <SPAN CLASS="BodyComputer">
InstanceName</SPAN>
<A NAME="marker=92331">
 </A>
, <SPAN CLASS="BodyComputer">
PinName</SPAN>
<A NAME="marker=92332">
 </A>
, <SPAN CLASS="BodyComputer">
NetName</SPAN>
<A NAME="marker=92333">
 </A>
, and <SPAN CLASS="BodyComputer">
SubNodeName</SPAN>
<A NAME="marker=92334">
 </A>
. The <SPAN CLASS="BodyComputer">
PinType</SPAN>
<A NAME="marker=92335">
 </A>
 is <SPAN CLASS="BodyComputer">
I</SPAN>
 (for IN) or <SPAN CLASS="BodyComputer">
O</SPAN>
 (the letter 'O', not zero, for OUT). The <SPAN CLASS="BodyComputer">
NetCap</SPAN>
<A NAME="marker=92336">
 </A>
 is the total capacitance on each net. Thus for net IN, the net capacitance is</P>
<P CLASS="Equation">
<A NAME="pgfId=92347">
 </A>
0.38 pF = C1 + C2 =   0.11 pF + 0.27 pF. </P>
<P CLASS="BodyAfterHead">
<A NAME="pgfId=92349">
 </A>
This particular file does not use the pin capacitances, <SPAN CLASS="BodyComputer">
PinCap</SPAN>
<A NAME="marker=92348">
 </A>
. Since the DSPF represents every interconnect segment, DSPF files can be very large in size (hundreds of megabytes).</P>
<TABLE>
<TR>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableFigure">
<A NAME="pgfId=92355">
 </A>
<IMG SRC="CH17-23.gif" ALIGN="BASELINE">
&nbsp;</P>
</TD>
</TR>
<TR>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableFigureTitle">
<A NAME="pgfId=92359">
 </A>
FIGURE&nbsp;17.23&nbsp;<A NAME="13082">
 </A>
The detailed standard parasitic format (DSPF) for interconnect representation. (a)&nbsp;An example network with two m2 paths connected to a logic cell, INV1. The grid shows the coordinates. (b)&nbsp;The equivalent DSPF circuit corresponding to the DSPF file in the text.</P>
</TD>
</TR>
</TABLE>
</DIV>
<DIV>
<H2 CLASS="Heading2">
<A NAME="pgfId=17395">
 </A>
17.4.2&nbsp;<A NAME="18513">
 </A>
Design Checks</H2>
<P CLASS="BodyAfterHead">
<A NAME="pgfId=17396">
 </A>
ASIC designers perform two major checks before fabrication. The first check is a <SPAN CLASS="Definition">
design-rule check</SPAN>
<A NAME="marker=39130">
 </A>
 (<A NAME="marker=39128">
 </A>
<A NAME="marker=39129">
 </A>
<SPAN CLASS="Definition">
DRC</SPAN>
) to ensure that nothing has gone wrong in the process of assembling the logic cells and routing. The DRC may be performed at two levels. Since the detailed router normally works with logic-cell phantoms, the first level of DRC is a <SPAN CLASS="Definition">
phantom-level DRC</SPAN>
<A NAME="marker=50798">
 </A>
, which checks for shorts, spacing violations, or other design-rule problems between logic cells. This is principally a check of the detailed router. If we have access to the real library-cell layouts (sometimes called <SPAN CLASS="Definition">
hard layout</SPAN>
<A NAME="marker=50799">
 </A>
), we can instantiate the phantom cells and perform a second-level DRC at the transistor level. This is principally a check of the correctness of the library cells. Normally the ASIC vendor will perform this check using its own software as a type of incoming inspection. The Cadence Dracula software is one de facto standard in this area, and you will often hear reference to a <SPAN CLASS="Definition">
Dracula deck</SPAN>
<A NAME="marker=50837">
 </A>
 that consists of the Dracula code describing an ASIC vendor&#8217;s design rules. Sometimes ASIC vendors will give their Dracula decks to customers so that the customers can perform the DRCs themselves.</P>
<P CLASS="Body">
<A NAME="pgfId=39127">
 </A>
The other check is a <A NAME="marker=39126">
 </A>
<SPAN CLASS="Definition">
layout versus schematic</SPAN>
 (<A NAME="marker=39124">
 </A>
<A NAME="marker=39125">
 </A>
<SPAN CLASS="Definition">
LVS</SPAN>
) check to ensure that what is about to be committed to silicon is what is really wanted. An electrical schematic is extracted from the physical layout and compared to the netlist. This closes a loop between the logical and physical design processes and ensures that both are the same. The LVS check is not as straightforward as it may sound, however. </P>
<P CLASS="Body">
<A NAME="pgfId=50886">
 </A>
The first problem with an LVS check is that the transistor-level netlist for a large ASIC forms an enormous graph. LVS software essentially has to match this graph against a reference graph that describes the design. Ensuring that every node corresponds exactly to a corresponding element in the schematic (or HDL code) is a very difficult task. The first step is normally to match certain key nodes (such as the power supplies, inputs, and outputs), but the process can very quickly become bogged down in the thousands of mismatch errors that are inevitably generated initially.</P>
<P CLASS="Body">
<A NAME="pgfId=50887">
 </A>
The second problem with an LVS check is creating a true reference. The starting point may be HDL code or a schematic. However, logic synthesis, test insertion, clock-tree synthesis, logical-to-physical pad mapping, and several other design steps each modify the netlist. The reference netlist may not be what we wish to fabricate. In this case designers increasingly resort to formal verification that extracts a Boolean description of the function of the layout and compare that to a known good HDL description.</P>
</DIV>
<DIV>
<H2 CLASS="Heading2">
<A NAME="pgfId=24823">
 </A>
17.4.3&nbsp;Mask Preparation</H2>
<P CLASS="BodyAfterHead">
<A NAME="pgfId=50918">
 </A>
Final preparation for the ASIC artwork includes the addition of a <A NAME="marker=39131">
 </A>
<SPAN CLASS="Definition">
maskwork symbol</SPAN>
 (M inside a circle), copyright symbol (C inside a circle), and company logos on each mask layer. A bonding editor creates a bonding diagram that will show the connection of pads to the lead carrier as well as checking that there are no design-rule violations (bond wires that are too close to each other or that leave the chip at extreme angles). We also add the <SPAN CLASS="Definition">
kerf</SPAN>
<A NAME="marker=51310">
 </A>
 (which contains alignment marks, mask identification, and other artifacts required in fabrication), the <SPAN CLASS="Definition">
scribe lines</SPAN>
<A NAME="marker=51311">
 </A>
 (the area where the die will be separated from each other by a diamond saw), and any special hermetic <A NAME="marker=39134">
 </A>
<SPAN CLASS="Definition">
edge-seal structures</SPAN>
 (usually metal).</P>
<P CLASS="Body">
<A NAME="pgfId=17409">
 </A>
The final output of the design process is normally a magnetic tape written in <SPAN CLASS="Definition">
Caltech Intermediate Format</SPAN>
<A NAME="marker=39596">
 </A>
 (<SPAN CLASS="Definition">
CIF</SPAN>
<A NAME="marker=39764">
 </A>
, a public domain text format) or <SPAN CLASS="Definition">
GDSII Stream</SPAN>
<A NAME="marker=36319">
 </A>
 (formerly also called <A NAME="marker=50969">
 </A>
Calma Stream, now <A NAME="marker=50970">
 </A>
Cadence Stream), which is a proprietary binary format. The tape is processed by the ASIC vendor or foundry (the <SPAN CLASS="Definition">
fab</SPAN>
<A NAME="marker=34911">
 </A>
) before being transferred to the <SPAN CLASS="Definition">
mask shop</SPAN>
<A NAME="marker=34912">
 </A>
. </P>
<P CLASS="Body">
<A NAME="pgfId=39591">
 </A>
If the layout contains drawn <SPAN CLASS="EmphasisPrefix">
n</SPAN>
-diffusion and <SPAN CLASS="EmphasisPrefix">
p</SPAN>
-diffusion regions, then the fab generates the active (thin-oxide), <SPAN CLASS="EmphasisPrefix">
p</SPAN>
-type implant, and <SPAN CLASS="EmphasisPrefix">
n</SPAN>
-type implant layers. The fab then runs another polygon-level DRC to check polygon spacing and overlap for all mask levels. A <SPAN CLASS="Definition">
grace value</SPAN>
<A NAME="marker=39608">
 </A>
 (typically 0.01 <SPAN CLASS="Symbol">
m</SPAN>
m) is included to prevent false errors stemming from rounding problems and so on. The fab will then adjust the mask dimensions for fabrication either by bloating (expanding), shrinking, and merging shapes in a procedure called <SPAN CLASS="Definition">
sizing</SPAN>
<A NAME="marker=34916">
 </A>
 or <SPAN CLASS="Definition">
mask tooling</SPAN>
<A NAME="marker=34917">
 </A>
. The exact procedures are described in a <SPAN CLASS="Definition">
tooling specification</SPAN>
<A NAME="marker=50921">
 </A>
. A <SPAN CLASS="Definition">
mask bias</SPAN>
<A NAME="marker=33953">
 </A>
 is an amount added to a drawn polygon to allow for a difference between the mask size and the feature as it will eventually appear in silicon. The most common adjustment is to the active mask to allow for the <SPAN CLASS="Definition">
bird&#8217;s beak effect</SPAN>
<A NAME="marker=33952">
 </A>
, which causes an active area to be several tenths of a micron smaller on silicon than on the mask.</P>
<P CLASS="Body">
<A NAME="pgfId=17403">
 </A>
The mask shop will use e-beam mask equipment to generate metal (usually chromium) on glass <A NAME="marker=39606">
 </A>
masks or <SPAN CLASS="Definition">
reticles</SPAN>
<A NAME="marker=39607">
 </A>
. The e-beam <SPAN CLASS="Definition">
spot size</SPAN>
<A NAME="marker=29608">
 </A>
 determines the resolution of the mask-making equipment and is usually 0.05 <SPAN CLASS="Symbol">
m</SPAN>
m or 0.025 <SPAN CLASS="Symbol">
m</SPAN>
m (the smaller the spot size, the more expensive is the mask). The spot size is significant when we break the integer-lambda scaling rules in a deep-submicron process. For example, for a 0.35  <SPAN CLASS="Symbol">
m</SPAN>
m process (<SPAN CLASS="Symbol">
l</SPAN>
 = 0.175 <SPAN CLASS="Symbol">
m</SPAN>
m), a 1.5 <SPAN CLASS="Symbol">
l</SPAN>
 separation is 0.525 <SPAN CLASS="Symbol">
m</SPAN>
m, which requires more expensive mask-making equipment with a 0.025 <SPAN CLASS="Symbol">
m</SPAN>
m spot size. For <SPAN CLASS="Definition">
critical layers</SPAN>
<A NAME="marker=33879">
 </A>
 (usually the polysilicon mask) the mask shop may use<SPAN CLASS="Definition">
 optical proximity correction</SPAN>
<A NAME="marker=29611">
 </A>
 (<A NAME="marker=29610">
 </A>
<A NAME="marker=39123">
 </A>
<SPAN CLASS="Definition">
OPC</SPAN>
<A NAME="marker=50922">
 </A>
), which adjusts the position of the mask edges to allow for light diffraction and reflection (the deep-UV light used for printing mask images on the wafer has a wavelength comparable to the minimum feature sizes). </P>
</DIV>
<HR>
<DIV CLASS="footnotes">
<DIV CLASS="footnote">
<P CLASS="TableFootnote">
<SPAN CLASS="footnoteNumber">
1.</SPAN>
<A NAME="pgfId=76953">
 </A>
Fringing capacitances are per isolated line. Closely spaced lines will have reduced fringing capacitance and increased interline capacitance, with increased total capacitance.</P>
</DIV>
<DIV CLASS="footnote">
<P CLASS="TableFootLast">
<SPAN CLASS="footnoteNumber">
2.</SPAN>
<A NAME="pgfId=76971">
 </A>
NA = not applicable.</P>
</DIV>
</DIV>
<HR><P>[&nbsp;<A HREF="CH17.htm">Chapter&nbsp;start</A>&nbsp;]&nbsp;[&nbsp;<A HREF="CH17.3.htm">Previous&nbsp;page</A>&nbsp;]&nbsp;[&nbsp;<A HREF="CH17.5.htm">Next&nbsp;page</A>&nbsp;]</P></BODY>

<!--#include file="Copyright.html"--><!--#include file="footer.html"-->