ch09.1.htm

介绍asci设计的一本书

. Now suppose we need another, identical, flip-flop and we call this <SPAN CLASS="BodyComputer">
BitFF</SPAN>
. We do not mind which of the six flip-flop parts in a 74174 we use for <SPAN CLASS="BodyComputer">
CarryFF</SPAN>
 and <SPAN CLASS="BodyComputer">
BitFF</SPAN>
. In fact they do not even have to be in the same package. We shall delay the choice of assigning <SPAN CLASS="BodyComputer">
CarryFF</SPAN>
 and <SPAN CLASS="BodyComputer">
BitFF</SPAN>
 to specific packages until we get to the PCB routing step. So at this point on our schematic we do not even know the pin numbers for <SPAN CLASS="BodyComputer">
CarryFF</SPAN>
 and <SPAN CLASS="BodyComputer">
BitFF</SPAN>
. For example the D input to <SPAN CLASS="BodyComputer">
CarryFF</SPAN>
 could be pin 3, 4, 6, 11, 13, or 14.</P>
<P CLASS="Body">
<A NAME="pgfId=30449">
 </A>
The number of wire crossings on a PCB is minimized by careful assignment of components to packages and choice of parts within a package. So the placement-and-routing software may decide which part of which package to use for <SPAN CLASS="BodyComputer">
CarryFF</SPAN>
 and <SPAN CLASS="BodyComputer">
BitFF</SPAN>
 depending on which is easier to route. Then, only after the placement and routing is complete, are unique reference designators assigned to the component parts. Only at this point do we know where <SPAN CLASS="BodyComputer">
CarryFF</SPAN>
 is actually located on the PCB by referring to the reference designator, which points to a specific part in a specific package. Thus <SPAN CLASS="BodyComputer">
CarryFF</SPAN>
 might be located in <SPAN CLASS="BodyComputer">
IC4</SPAN>
 on our PCB. At this point we also know which pins are used for each symbol. So we now know, for example, that the D-input to <SPAN CLASS="BodyComputer">
CarryFF</SPAN>
 is pin 3 of <SPAN CLASS="BodyComputer">
IC4</SPAN>
.</P>
<P CLASS="Body">
<A NAME="pgfId=30451">
 </A>
There is no process in ASIC design directly equivalent to the process of <A NAME="marker=30450">
 </A>
part assignment described above and thus no need to use reference designators. The reference-designator naming convention quickly becomes unwieldy if there are a large number of components in a design. For example, how will we find a NAND gate named <SPAN CLASS="BodyComputer">
X3146</SPAN>
 in an ASIC schematic with 100 pages? Instead, for ASICs, we use a naming scheme based on hierarchy. </P>
<P CLASS="Body">
<A NAME="pgfId=30452">
 </A>
In large hierarchical ASIC designs it is difficult to provide a unique reference designator to each element. For this reason ASIC designs use instance names to identify the individual components. Meaningful names can be assigned to low-level components and also the symbols that represent hierarchy. We derive the component names by joining all of the higher level cell names together. A special character is used as a delimiter and separates each level.</P>
<P CLASS="Body">
<A NAME="pgfId=30453">
 </A>
Examples of hierarchical instance names are:</P>
<P CLASS="ComputerFirst">
<A NAME="pgfId=30454">
 </A>
cpu.alu.adder.and01</P>
<P CLASS="ComputerLast">
<A NAME="pgfId=30455">
 </A>
MotherBoard:Cache:RAM4:ReadBit4:Inverter2</P>
</DIV>
<DIV>
<H3 CLASS="Heading2">
<A NAME="pgfId=29869">
 </A>
9.1.7&nbsp;Connections</H3>
<P CLASS="BodyAfterHead">
<A NAME="pgfId=29871">
 </A>
Cell instances have <A NAME="marker=29870">
 </A>
<SPAN CLASS="Definition">
terminals</SPAN>
 that are the inputs and outputs of the cell. Terminals are also known as <A NAME="marker=29872">
 </A>
<SPAN CLASS="Definition">
pins</SPAN>
, <A NAME="marker=29873">
 </A>
<SPAN CLASS="Definition">
connectors</SPAN>
, or <A NAME="marker=29874">
 </A>
<SPAN CLASS="Definition">
signals</SPAN>
. The term pin is widely used, but we shall try to use terminal, and reserve the term pin for the metal leads on an ASIC package. The term pin is used in schematic entry and routing programs that are primarily intended for PCB design. </P>
<TABLE>
<TR>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableFigure">
<A NAME="pgfId=29883">
 </A>
&nbsp;</P>
<DIV>
<IMG SRC="CH09-6.gif">
</DIV>
</TD>
</TR>
<TR>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableFigureTitle">
<A NAME="pgfId=29886">
 </A>
FIGURE&nbsp;9.6&nbsp;<A NAME="31302">
 </A>
An example of the use of a bus to simplify a schematic. (a)&nbsp;An address decoder without using a bus. (b)&nbsp;A bus with bus rippers simplifies the schematic and reduces the possibility of making a mistake in creating and reading the schematic.</P>
</TD>
</TR>
</TABLE>
<P CLASS="Body">
<A NAME="pgfId=29755">
 </A>
Electrical connections between cell instances use <A NAME="marker=29754">
 </A>
<SPAN CLASS="Definition">
wire segments</SPAN>
 or <A NAME="marker=29756">
 </A>
<SPAN CLASS="Definition">
nets</SPAN>
. We can group closely related nets, such as the 32 bits of a 32-bit digital word, together into a <A NAME="marker=29757">
 </A>
<SPAN CLASS="Definition">
bus</SPAN>
 or into <A NAME="marker=29758">
 </A>
<SPAN CLASS="Definition">
buses</SPAN>
 (not <A NAME="marker=29759">
 </A>
busses). If signals on a bus are not closely related, we usually use the term <A NAME="marker=29760">
 </A>
<SPAN CLASS="Definition">
bundle</SPAN>
 or <A NAME="marker=29761">
 </A>
<SPAN CLASS="Definition">
array</SPAN>
 instead of bus. An example of a bundle might be a bus for a SCSI disk system, containing not only data bits but handshake and control signals too. <A HREF="#31302" CLASS="XRef">
Figure&nbsp;9.6</A>
 shows an example of a bus in a schematic. If we need to access individual nets in a bus or a bundle, we use a <A NAME="marker=29775">
 </A>
<SPAN CLASS="Definition">
breakout</SPAN>
 (also known as a <A NAME="marker=29776">
 </A>
<SPAN CLASS="Definition">
ripper</SPAN>
, an EDIF term, or <A NAME="marker=29777">
 </A>
<SPAN CLASS="Definition">
extractor</SPAN>
). For example, a breakout is used to access bits 0&#8211;7 of a 32-bit bus. If we need to rearrange bits on a bus, some schematic editors offer something called a <A NAME="marker=29779">
 </A>
<SPAN CLASS="Definition">
swizzle</SPAN>
. For example, we might use a swizzle to reorder the bits on an 8-bit bus so that the MSB becomes the LSB and so on down to the LSB, which now becomes the MSB. Swizzles can be useful. For example, we can multiply or divide a number by 2 by swizzling all the bits up or down one place on a bus.</P>
</DIV>
<DIV>
<H3 CLASS="Heading2">
<A NAME="pgfId=2655">
 </A>
9.1.8&nbsp;Vectored Instances and Buses</H3>
<P CLASS="BodyAfterHead">
<A NAME="pgfId=29612">
 </A>
So far the naming conventions are fairly standard and easy to follow. However, when we start to use vectored instances and buses (as is now common in large ASICs), there are potential areas of difficulty and confusion. <A HREF="#24300" CLASS="XRef">
Figure&nbsp;9.7</A>
(a) shows a schematic for a 16-bit latch that uses multiple copies of the cell <SPAN CLASS="BodyComputer">
FourBit</SPAN>
. The buses are labeled with the appropriate bits. <A HREF="#24300" CLASS="XRef">
Figure&nbsp;9.7</A>
(b) shows a new cell symbol for the 16-bit latch with 16-bit wide buses for the inputs, D, and outputs, Q. </P>
<TABLE>
<TR>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableFigure">
<A NAME="pgfId=33914">
 </A>
<IMG SRC="CH09-7.gif" ALIGN="BASELINE">
&nbsp;</P>
</TD>
</TR>
<TR>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableFigureTitle">
<A NAME="pgfId=33917">
 </A>
FIGURE&nbsp;9.7&nbsp;<A NAME="24300">
 </A>
 A 16-bit latch: (a)&nbsp;drawn as four instances of cell FourBit; (b) &nbsp;drawn as a cell named SixteenBit; (c)&nbsp;drawn as four multiple instances of cell FourBit.</P>
</TD>
</TR>
</TABLE>
<P CLASS="Body">
<A NAME="pgfId=29655">
 </A>
<A HREF="#24300" CLASS="XRef">
Figure&nbsp;9.7</A>
(c) shows an alternative representation of the 16-bit latch using a vectored instance of <SPAN CLASS="BodyComputer">
FourBit</SPAN>
 with cardinality 4. Suppose we wish to make a connection to expressly one bit, D1 (we have used D1 as the first bit rather than the more conventional D0 so that numbering is easier to follow). We also wish to make a connection to bits D9&#8211;D12, represented as D[9:12]. We do this using a bus ripper. Now we have the rather awkward situation of bus naming shown in <A HREF="#24300" CLASS="XRef">
Figure&nbsp;9.7</A>
(c). Problems arise when we have &#8220;buses of buses&#8221; because the numbers for the bus widths do not match on either side of a ripper. For this reason it is best to use the single-bus approach shown in <A HREF="#24300" CLASS="XRef">
Figure&nbsp;9.7</A>
(b) rather than the vectored-bus approach of <A HREF="#24300" CLASS="XRef">
Figure&nbsp;9.7</A>
(c).</P>
</DIV>
<DIV>
<H3 CLASS="Heading2">
<A NAME="pgfId=2666">
 </A>
9.1.9&nbsp;Edit-in-Place</H3>
<P CLASS="BodyAfterHead">
<A NAME="pgfId=24305">
 </A>
<A HREF="#24300" CLASS="XRef">
Figure&nbsp;9.7</A>
(b) shows a symbol <SPAN CLASS="BodyComputer">
SixteenBit</SPAN>
, which uses the subschematic shown in <A HREF="#24300" CLASS="XRef">
Figure&nbsp;9.7</A>
(a) containing four copies of <SPAN CLASS="BodyComputer">
FourBit</SPAN>
, named <SPAN CLASS="BodyComputer">
NB1</SPAN>
, <SPAN CLASS="BodyComputer">
NB2</SPAN>
, <SPAN CLASS="BodyComputer">
NB3</SPAN>
, and <SPAN CLASS="BodyComputer">
NB4</SPAN>
 (the <SPAN CLASS="BodyComputer">
NB</SPAN>
 stands for <A NAME="nibble">
 </A>
nibble, which is half of a word; a nibble is 4 bits for 8-bit words). Suppose we use the schematic-entry program to edit the subcell <SPAN CLASS="BodyComputer">
NB1.L1</SPAN>
, which is an instance of <SPAN CLASS="BodyComputer">
DLAT</SPAN>
 inside <SPAN CLASS="BodyComputer">
NB1</SPAN>
. Perhaps we wish to change the D latch to a D latch with a reset, for example. If the schematic editor supports <SPAN CLASS="Definition">
edit-in-place</SPAN>
<A NAME="marker=2664">
 </A>
, we can edit a cell instance directly. After we edit the cell, the program will update all the <SPAN CLASS="BodyComputer">
DLAT</SPAN>
 subcells in the cell that is currently loaded to reflect the changes that have been made. </P>
<P CLASS="Body">
<A NAME="pgfId=2670">
 </A>
To see how edit-in-place works, consider our office building again. Suppose we wish to change some of the offices on each floor from offices without windows to offices with windows. We select the cell instance <SPAN CLASS="BodyComputer">
FloorTwo</SPAN>
&#8212;that is, an instance of cell <SPAN CLASS="BodyComputer">
Floor</SPAN>
. Now we choose the edit mode in the schematic-entry program. But wait! Do we want to edit the cell <SPAN CLASS="BodyComputer">
Floor</SPAN>
, or do we want to edit the cell instance <SPAN CLASS="BodyComputer">
FloorTwo</SPAN>
? If we edit the cell <SPAN CLASS="BodyComputer">
Floor</SPAN>
, we will be making changes to all of the floors that use cell name <SPAN CLASS="BodyComputer">
Floor</SPAN>
&#8212;that is, instances <SPAN CLASS="BodyComputer">
FloorTwo</SPAN>
 through <SPAN CLASS="BodyComputer">
FloorTen</SPAN>
. If we edit the cell instance <SPAN CLASS="BodyComputer">
FloorTwo</SPAN>
, then the second floor will become different from all the other floors. It will no longer be an instance of cell name <SPAN CLASS="BodyComputer">
Floor</SPAN>
 and we will have to create another cell name for the cell used by instance <SPAN CLASS="BodyComputer">
FloorTwo</SPAN>
. This is like the difference between ordering just one hamburger without pickles and changing the picture on the wall that will change all future hamburgers.</P>
<P CLASS="Body">
<A NAME="pgfId=2678">
 </A>
Using edit-in-place we can edit the cell <SPAN CLASS="BodyComputer">
Floor</SPAN>
. Suppose we change some of the cell instances of cell name <SPAN CLASS="BodyComputer">
NoWindowOffice</SPAN>
 to instances of cell name <SPAN CLASS="BodyComputer">
WindowOffice</SPAN>
. When we finish editing and save the cell <SPAN CLASS="BodyComputer">
Floor</SPAN>
, we have effectively changed all of the floors that contain instances of this cell. </P>
<P CLASS="Body">
<A NAME="pgfId=2684">
 </A>
Instead of editing a cell in place, you may really want to edit just one instance of a cell and leave any other instances unchanged. In this case you must create a new cell with a new symbol and new, unique cell name. It might also be wise to change the instance name of the new cell to avoid any confusion. </P>
<P CLASS="Body">
<A NAME="pgfId=2688">
 </A>
For example, we might change the third-floor plan of our office to be different from the other upper floors. Suppose the third floor is now an instance of cell name <SPAN CLASS="BodyComputer">
FloorVIP</SPAN>
 instead of <SPAN CLASS="BodyComputer">
Floor</SPAN>
. We could continue to call the third floor cell instance <SPAN CLASS="BodyComputer">
FloorThree</SPAN>
, but it would be better to rename the instance differently, <SPAN CLASS="BodyComputer">
FloorSpecial</SPAN>