ch09.1.htm

介绍asci设计的一本书

 </A>
<A HREF="#26670" CLASS="XRef">
Figure&nbsp;9.2</A>
 shows some pictorial definitions of objects you can use in a simple schematic. We shall discuss the different types of objects that might appear in an ASIC schematic first and then discuss the different types of connections.  </P>
<TABLE>
<TR>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableFigure">
<A NAME="pgfId=11059">
 </A>
&nbsp;</P>
<DIV>
<IMG SRC="CH09-2.gif">
</DIV>
</TD>
</TR>
<TR>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableFigureTitle">
<A NAME="pgfId=11063">
 </A>
FIGURE&nbsp;9.2&nbsp;<A NAME="26670">
 </A>
Terms used in circuit schematics.</P>
</TD>
</TR>
</TABLE>
<P CLASS="Body">
<A NAME="pgfId=2494">
 </A>
Schematic-entry tools for ASIC design are similar to those for printed-circuit board (PCB) design. The basic object on a PCB schematic is a <A NAME="marker=2490">
 </A>
<SPAN CLASS="Definition">
component</SPAN>
 or <A NAME="marker=2493">
 </A>
<SPAN CLASS="Definition">
device</SPAN>
&#8212;a TTL IC or resistor, for example. There may be several hundred components on a typical PCB. If we think of a logic gate on an ASIC as being equivalent to a component on a PCB, then a large ASIC contains hundreds of thousands of components. We can normally draw every component on a few schematic sheets for a PCB, but drawing every component on an ASIC schematic is impractical. </P>
<DIV>
<H3 CLASS="Heading2">
<A NAME="pgfId=24301">
 </A>
9.1.1&nbsp;<A NAME="38849">
 </A>
Hierarchical Design</H3>
<P CLASS="BodyAfterHead">
<A NAME="pgfId=2500">
 </A>
<SPAN CLASS="Definition">
Hierarchy</SPAN>
<A NAME="marker=2498">
 </A>
 reduces the size and complexity of a schematic. Suppose a building has 10 floors and contains several hundred offices but only three different basic office plans. Furthermore, suppose each of the floors above the ground floor that contains the lobby is identical. Then the plans for the whole building need only show detailed plans for the ground floor and one of the upper floors. The plans for the upper floor need only show the locations of each office and the office type. We can then use a separate set of three detailed plans for each of the different office types. All these different plans together form a nested structure that is a <A NAME="marker=2508">
 </A>
<SPAN CLASS="Definition">
hierarchical design</SPAN>
. The plan for the whole building is the top-level plan. The plans for the individual offices are the lowest level. To clarify the relationship between different levels of hierarchy we say that a <A NAME="marker=24256">
 </A>
<SPAN CLASS="Definition">
subschematic</SPAN>
 (an office) is a <A NAME="marker=2511">
 </A>
<SPAN CLASS="Definition">
child</SPAN>
 of the <A NAME="marker=2513">
 </A>
<SPAN CLASS="Definition">
parent</SPAN>
 schematic (the floor containing offices). An electrical schematic can contain subschematics. The subschematic, in turn, may contain other subschematics. <A HREF="#23399" CLASS="XRef">
Figure&nbsp;9.3</A>
 illustrates the principles of schematic hierarchical design. </P>
<TABLE>
<TR>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableFigure">
<A NAME="pgfId=6256">
 </A>
<IMG SRC="CH09-3.gif" ALIGN="BASELINE">
&nbsp;</P>
</TD>
</TR>
<TR>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableFigureTitle">
<A NAME="pgfId=6259">
 </A>
FIGURE&nbsp;9.3&nbsp;<A NAME="23399">
 </A>
Schematic example showing hierarchical design. (a)&nbsp;The schematic of a half-adder, the subschematic of cell HADD. (b)&nbsp;A schematic symbol for the half adder. (c)&nbsp;A schematic that uses the half-adder cell. (d)&nbsp;The hierarchy of cell HADD.</P>
</TD>
</TR>
</TABLE>
<P CLASS="Body">
<A NAME="pgfId=2529">
 </A>
The alternative to hierarchical design is to draw all of the ASIC components on one giant schematic, with no hierarchy, in a <A NAME="marker=2527">
 </A>
<SPAN CLASS="Definition">
flat design</SPAN>
. For a modern ASIC containing thousands or more logic gates using a flat design or a flat schematic would be hopelessly impractical. Sometimes we do use <SPAN CLASS="Definition">
flat netlists</SPAN>
<A NAME="marker=24254">
 </A>
 though.</P>
</DIV>
<DIV>
<H3 CLASS="Heading2">
<A NAME="pgfId=24302">
 </A>
9.1.2&nbsp;The Cell Library</H3>
<P CLASS="BodyAfterHead">
<A NAME="pgfId=2539">
 </A>
Components in an ASIC schematic are chosen from a library of cells. Library elements for all types of ASICs are sometimes also known as <A NAME="marker=2543">
 </A>
<SPAN CLASS="Definition">
modules</SPAN>
. Unfortunately the term module will have a very specific meaning when we come to discuss hardware description languages. To avoid any chance of confusion I use the term cell to mean either a cell, a module, a macro, or a book from an ASIC library. Library cells are equivalent to the offices in our office building.</P>
<P CLASS="Body">
<A NAME="pgfId=30665">
 </A>
Most ASIC companies provide a <A NAME="marker=30664">
 </A>
<SPAN CLASS="Definition">
schematic library</SPAN>
 of primitive gates to be used for schematic entry. The first problem with ASIC schematic libraries is that there are no naming conventions. For example, a primitive two-input NAND gate in a Xilinx FPGA library does not have the same name as the two-input NAND gate in an LSI Logic gate-array library. This means that you cannot take a schematic that you used to create a prototype product using a Xilinx FPGA and use that schematic to create an LSI Logic gate array for production (something you might very likely want to do). As soon as you start entering a schematic using a library from an ASIC vendor, you are, to some extent, making a commitment to use that vendor&#8217;s ASIC. Most ASIC designers are much happier maintaining a large degree of vendor independence.</P>
<P CLASS="Body">
<A NAME="pgfId=30667">
 </A>
A second problem with ASIC schematic libraries is that there are no standards for cell behavior. For example, a two-input MUX in an Actel library operates so that the input labeled A is selected when the MUX select input S = '0'. A two-input MUX in a VLSI Technology library operates in the reverse fashion, so that the input labeled B is selected when S =  '0'. These types of differences can cause hard-to-find problems when trying to convert a schematic from one vendor to another by hand. These problems make changing or <A NAME="marker=30668">
 </A>
<SPAN CLASS="Definition">
retargeting</SPAN>
 schematics from one vendor to another difficult. This process is sometimes known as <A NAME="marker=30669">
 </A>
<SPAN CLASS="Definition">
porting</SPAN>
 a design.</P>
<P CLASS="Body">
<A NAME="pgfId=2553">
 </A>
Library cells that represent basic logic gates, such as a NAND gate, are known as <A NAME="marker=2549">
 </A>
<SPAN CLASS="Definition">
primitive cells</SPAN>
, usually referred to just as cells. In a hierarchical ASIC design a cell may be a NAND gate, a flip-flop, a multiplier, or even a microprocessor, for example. To use the office building analogy again, each of the three basic office types is a primitive cell. However, the plan for the second floor is also a cell. The second-floor cell is a subschematic of the schematic for the whole building. Now we see why the commonly accepted use of the term cell in schematic entry can be so confusing. The term cell is used to represent both primitive cells and subschematics. These are two different, but closely related, things.</P>
<P CLASS="Body">
<A NAME="pgfId=2565">
 </A>
There are two types of macros for MGAs and programmable ASICs. The most common type of macro is a <A NAME="marker=2561">
 </A>
<SPAN CLASS="Definition">
hard macro</SPAN>
 that includes placement information. A hard macro can change in position and orientation, but the relative location of the transistors, other layout, and wiring inside the macro is fixed. A <A NAME="marker=2564">
 </A>
<SPAN CLASS="Definition">
soft macro</SPAN>
 contains only connection information (between transistors for a gate array or between logic cells for a programmable ASIC). Thus the placement and wiring for a soft macro can vary. This means that the timing parameters for a soft macro can only be determined after you complete the place-and-route step. For this reason the basic library elements for MGAs and programmable ASICs, such as NAND gates, flip-flops, and so on, are hard macros. </P>
<P CLASS="Body">
<A NAME="pgfId=2569">
 </A>
A standard cell contains layout information on all mask levels. An MGA hard macro contains layout information on just the metal, contact, and via layers. An MGA soft macro or programmable ASIC macro does not contain any layout information at all, just the details of connections to be made inside the macro. </P>
<P CLASS="Body">
<A NAME="pgfId=2573">
 </A>
We can stretch the office building analogy to explain the difference between hard and soft macros. A hard macro would be an office with fixed walls in which you are not allowed to move the furniture. A soft macro would be an office with partitions in which you can move the furniture around and you can also change the shape of your office by moving the partitions.</P>
</DIV>
<DIV>
<H3 CLASS="Heading2">
<A NAME="pgfId=2583">
 </A>
9.1.3&nbsp;Names</H3>
<P CLASS="BodyAfterHead">
<A NAME="pgfId=24303">
 </A>
Each of the cells, primitive or not, that you place on an ASIC schematic has a <A NAME="marker=2577">
 </A>
<SPAN CLASS="Definition">
cell name</SPAN>
. Each use of a cell is a different <A NAME="marker=2580">
 </A>
<SPAN CLASS="Definition">
instance</SPAN>
 of that cell, and we give each instance a unique <A NAME="marker=2582">
 </A>
<SPAN CLASS="Definition">
instance name</SPAN>
. A cell instance is somewhere between a copy and a reference to a cell in a library. An analogy would be the pictures of hamburgers on the wall in a fast-food restaurant. The pictures are somewhere between a copy and a reference to a real hamburger.</P>
<P CLASS="Body">
<A NAME="pgfId=32530">
 </A>
We represent each cell instance by a picture or <A NAME="marker=32528">
 </A>
<SPAN CLASS="Definition">
icon</SPAN>
, also known as a <A NAME="marker=32529">
 </A>
<SPAN CLASS="Definition">
symbol</SPAN>
. We can represent primitive cells, such as NAND and NOR gates, with familiar icons that look like spades and shovels. Some schematic editors offer the option of switching between these familiar icons and using the rectangular IEEE standard symbols for logic gates. Unfortunately the term icon is also often used to refer to any of the pictures on a schematic, including those that represent subschematics. There is no accepted way to differentiate between an icon that represents a primitive cell and one that represents a subschematic that may be in turn a collection of primitive cells. In fact, there is usually no easy way to tell by looking at a schematic which icons represent primitive cells and which represent subschematics.</P>
<P CLASS="Body">
<A NAME="pgfId=2604">
 </A>
We will have three different icons for each of the three different primitive offices in the imaginary office building example of <A HREF="#38849" CLASS="XRef">
Section&nbsp;9.1.1</A>
. We also will have icons to represent the ground floor and the plan for the other floors. We shall call the common plan for the second through tenth floors, <SPAN CLASS="BodyComputer">
Floor</SPAN>
. Then we say that the second floor is an instance of the cell name <SPAN CLASS="BodyComputer">
Floor</SPAN>
. The third through tenth floors are also instances of the cell name <SPAN CLASS="BodyComputer">
Floor</SPAN>
. The same icon will be used to represent the second through tenth floors, but each will have a unique instance name. We shall give them instance names: <SPAN CLASS="BodyComputer">
FloorTwo</SPAN>
, <SPAN CLASS="BodyComputer">
FloorThree</SPAN>
, <SPAN CLASS="BodyComputer">
...</SPAN>
, <SPAN CLASS="BodyComputer">
FloorTen</SPAN>
. We say that <SPAN CLASS="BodyComputer">
FloorTwo</SPAN>
 through <SPAN CLASS="BodyComputer">
FloorTen</SPAN>
 are unique instance names of the cell name <SPAN CLASS="BodyComputer">
Floor</SPAN>
. </P>
<P CLASS="Body">
<A NAME="pgfId=2608">
 </A>
At the risk of further confusion I should point out that, strictly speaking, the definition of a primitive cell depends on the type of library being used. Schematic-entry libraries for the ASIC designer stop at the level of NAND gates and other similar low-level logic gates. Then, as far as the ASIC designer is concerned, the primitive cells are these logic gates. However, from the view of the library designer there is another level of hierarchy below the level of logic gates. The library designer needs to work with libraries that contain schematics of the gates themselves, and so at this level the primitive cells are transistors.</P>
<P CLASS="Body">
<A NAME="pgfId=2612">
 </A>
Let us look at the building analogy again to understand the subtleties of primitive cells. A building contractor need only concern himself with the plans for our office building down to the level of the offices. To the building contractor the primitive cells are the offices. Suppose that the first of the three different office types is a corner office, the second office type has a window, and a third office type is without a window. We shall call these office cells: <SPAN CLASS="BodyComputer">
CornerOffice</SPAN>
,<SPAN CLASS="BodyComputer">
 WindowOffice</SPAN>
, and <SPAN CLASS="BodyComputer">
NoWindowOffice</SPAN>
. These cells are primitive cells as far as the contractor is concerned. However, when discussing the plans with a client, the architect of our building will also need to see how each offices is furnished. The architect needs to see a level of detail of each office that is more complicated than needed by the building contractor. The architect needs to see the cells that represent the tables, chairs, and desks that make up each type of office. To the architect the primitive cells are a library containing cells such as <SPAN CLASS="BodyComputer">
chair</SPAN>
,<SPAN CLASS="BodyComputer">
 table</SPAN>
, and <SPAN CLASS="BodyComputer">
desk</SPAN>
.</P>
</DIV>
<DIV>
<H3 CLASS="Heading2">
<A NAME="pgfId=2622">
 </A>
9.1.4&nbsp;Schematic Icons and Symbols</H3>
<P CLASS="BodyAfterHead">
<A NAME="pgfId=24304">
 </A>
Most schematic-entry programs allow the designer to draw special or custom icons. In addition, the schematic-entry tool will also usually create an icon automatically for a subschematic that is used in a higher-level schematic. This is a <A NAME="marker=2618">
 </A>
<SPAN CLASS="Definition">
derived icon</SPAN>
, or <A NAME="marker=2621">
 </A>
<SPAN CLASS="Definition">
derived symbol</SPAN>
. The external connections of the subschematic are automatically attached to the icon, usually a rectangle.</P>
<P CLASS="Body">
<A NAME="pgfId=2637">
 </A>
<A HREF="#29121" CLASS="XRef">
Figure&nbsp;9.4</A>
(c) shows what a derived icon for a cell, <SPAN CLASS="BodyComputer">
DLAT</SPAN>
, might look like (we could also have drawn this by hand). The subschematic for <SPAN CLASS="BodyComputer">
DLAT</SPAN>
 is shown in <A HREF="#29121" CLASS="XRef">
Figure&nbsp;9.4</A>
(b). We say that the inverter with the instance name <SPAN CLASS="BodyComputer">
inv1</SPAN>
 in the subschematic is a <A NAME="marker=2634">
 </A>
<SPAN CLASS="Definition">
subcell</SPAN>
 (or <A NAME="marker=2636">
 </A>
submodule) of the cell <SPAN CLASS="BodyComputer">
DLAT</SPAN>
. Alternatively we say that cell instance <SPAN CLASS="BodyComputer">
inv1</SPAN>
 is a child of the cell <SPAN CLASS="BodyComputer">
DLAT</SPAN>
, and cell <SPAN CLASS="BodyComputer">
DLAT</SPAN>
 is a parent of cell instance <SPAN CLASS="BodyComputer">
inv1</SPAN>
. </P>
<TABLE>
<TR>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableFigure">
<A NAME="pgfId=6309">
 </A>
&nbsp;</P>