ch09.1.htm

介绍asci设计的一本书

 for example, to make it clear that it is different from all the other floors.</P>
<P CLASS="Body">
<A NAME="pgfId=2781">
 </A>
Some tools have the ability to <SPAN CLASS="Definition">
alias</SPAN>
<A NAME="marker=30293">
 </A>
 nets. Aliasing creates a net name from the highest level in the design. Local names are net names at the lowest level such as <SPAN CLASS="BodyComputer">
D</SPAN>
, and <SPAN CLASS="BodyComputer">
Q</SPAN>
 in a flip-flop cell. These local names are automatically replaced by the appropriate top-level names such as <SPAN CLASS="BodyComputer">
Clock1</SPAN>
, or <SPAN CLASS="BodyComputer">
Data2</SPAN>
, using a <SPAN CLASS="Definition">
dictionary</SPAN>
<A NAME="marker=30296">
 </A>
. This greatly speeds tracing of signals through a design containing many levels of hierarchy.</P>
</DIV>
<DIV>
<H3 CLASS="Heading2">
<A NAME="pgfId=14279">
 </A>
9.1.10&nbsp;Attributes</H3>
<P CLASS="BodyAfterHead">
<A NAME="pgfId=24318">
 </A>
You can attach a <A NAME="marker=2787">
 </A>
<SPAN CLASS="Definition">
name</SPAN>
, also known as an <A NAME="marker=2790">
 </A>
<SPAN CLASS="Definition">
identifier</SPAN>
 or <A NAME="marker=2792">
 </A>
<SPAN CLASS="Definition">
label</SPAN>
, to a component, cell instance, net, terminal, or connector. You can also attach an <A NAME="marker=2794">
 </A>
<SPAN CLASS="Definition">
attribute</SPAN>
, or <A NAME="marker=2796">
 </A>
<SPAN CLASS="Definition">
property</SPAN>
, which describes some aspect of the component, cell instance, net, or connector. Each attribute has a name, and some attributes also have values. The most common problems in working with schematics and netlists, especially when you try to exchange schematic information between different tools, are problems in naming. </P>
<P CLASS="Body">
<A NAME="pgfId=2812">
 </A>
Since cells and their contents have to be stored in a database, a cell name frequently corresponds (or is mapped to) a filename. This then raises the problems of naming conventions including: case sensitivity, name-collision resolution, dictionaries, handling of &#8220;common&#8221; special characters (such as embedded blanks or underscores), other special characters (such as characters in foreign alphabets), first-character restrictions, name-length problems (only 28 characters are permitted on an NFS compatible filename), and so on.</P>
</DIV>
<DIV>
<H3 CLASS="Heading2">
<A NAME="pgfId=2915">
 </A>
9.1.11&nbsp;Netlist Screener</H3>
<P CLASS="BodyAfterHead">
<A NAME="pgfId=6417">
 </A>
A surprising number of problems can be found by checking a schematic for obviously fatal errors. A program that analyzes a schematic netlist for simple errors is sometimes called a <A NAME="marker=6418">
 </A>
<SPAN CLASS="Definition">
schematic screener</SPAN>
 or <A NAME="marker=6419">
 </A>
<SPAN CLASS="Definition">
netlist screener</SPAN>
. Errors that can be found by a netlist screener include:</P>
<UL>
<LI CLASS="BulletFirst">
<A NAME="pgfId=6420">
 </A>
unconnected cell inputs,</LI>
<LI CLASS="BulletList">
<A NAME="pgfId=6421">
 </A>
unconnected cell outputs,</LI>
<LI CLASS="BulletList">
<A NAME="pgfId=2931">
 </A>
nets not driven by any cells,</LI>
<LI CLASS="BulletList">
<A NAME="pgfId=2933">
 </A>
too many nets driven by one cell,</LI>
<LI CLASS="BulletLast">
<A NAME="pgfId=2935">
 </A>
nets driven by more than one cell.</LI>
</UL>
<P CLASS="Body">
<A NAME="pgfId=2939">
 </A>
The screener can work continuously as the designer is creating the schematic or can be run as a separate program independently from schematic entry. Usually the designer provides attributes that give the screener the information necessary to perform the checks. A few of the typical attributes that schematic-entry programs use are described next.</P>
<P CLASS="Body">
<A NAME="pgfId=2945">
 </A>
A screener usually generates a list of errors together with the locations of the problem on the schematic where appropriate. Some editors associate an identifier, or <A NAME="marker=2943">
 </A>
<SPAN CLASS="Definition">
handle</SPAN>
, to every piece of a schematic, including comments and every net. Normally there is some convention to the assigned names such as a grid on a schematic. This works like the locator codes on a map, so that a net with <SPAN CLASS="BodyComputer">
A1</SPAN>
 as part of the name is in the upper-left-hand corner, for example. This allows you to quickly and uniquely find any problems found by a screener. The term handle is a computer programming term that is used in referring to a location in memory. Each piece of information on a schematic is stored in lists in memory. This technique breaks down completely when we move to HDLs.</P>
<P CLASS="Body">
<A NAME="pgfId=30579">
 </A>
Most schematic-entry programs work on a grid. The designer can control the size of the grid and whether it is visible or not. When you place components or wires you can instruct the editor to force your drawing to <A NAME="marker=30580">
 </A>
<SPAN CLASS="Definition">
snap to grid</SPAN>
. This means that drawing a schematic is like drawing on graph paper. You can only locate symbols, wires, and connections on grid points. This simplifies the internal mechanics of the schematic-entry program. It also makes the transfer of schematics between different EDA systems more manageable. Finally, it allows the designer to produce schematic diagrams that are cleaner in appearance and thus easier to read. </P>
<P CLASS="Body">
<A NAME="pgfId=30581">
 </A>
Most schematic-entry programs allow you to find components by instance name or cell name. The editor may either jump to the component location and center the graphic window on the component or highlight the component. More sophisticated options allow more complex searches, perhaps using <A NAME="marker=30582">
 </A>
<SPAN CLASS="Definition">
wildcard</SPAN>
 matching. For example, to find all three-input NAND gates (primitive cell name ND3) or three-input NOR gates (primitive cell name NO3), you could search for cell name N*3, where * is a wildcard symbol standing for any character. The editor may generate a list of components, perhaps with page number and coordinate locations. Extensive find features are useful for large schematics where it quickly becomes impossible to find individual components.</P>
<P CLASS="Body">
<A NAME="pgfId=30584">
 </A>
Some schematic editors can complete <A NAME="marker=30583">
 </A>
<SPAN CLASS="Definition">
automatic naming</SPAN>
 of reference designators or instance names to the schematic symbols either as the editor is running or as a postprocessing step. A component attribute, called a prefix, defines the prefix for the name for each type of component. For example, the prefix for all resistor component types may be <SPAN CLASS="BodyComputer">
R</SPAN>
. Each time a prefix is found or a new instance is placed, the number in the reference designator or name is automatically incremented. Thus if the last resistor component type you placed was <SPAN CLASS="BodyComputer">
R99</SPAN>
, the next time you place a resistor it would automatically be named <SPAN CLASS="BodyComputer">
R100</SPAN>
.</P>
<P CLASS="Body">
<A NAME="pgfId=30585">
 </A>
For large schematics it is useful to be able to generate a report on the used and unused reference designators. An example would be:</P>
<P CLASS="ComputerFirst">
<A NAME="pgfId=30586">
 </A>
Reference designator prefix: R</P>
<P CLASS="Computer">
<A NAME="pgfId=30587">
 </A>
Unused reference designator numbers: 153, 154</P>
<P CLASS="ComputerLast">
<A NAME="pgfId=30588">
 </A>
Last used reference designator number: 180</P>
<P CLASS="Body">
<A NAME="pgfId=30589">
 </A>
If you need this feature, you probably are not using enough hierarchy to simplify your design.</P>
<P CLASS="Body">
<A NAME="pgfId=30590">
 </A>
During schematic entry of an ASIC design you will frequently need multiple copies of components. This often occurs during <A NAME="marker=30591">
 </A>
datapath design, where operations are carried out across multiple signals on a bus. A common example would be multiple copies of a latch, one for each signal on a bus. It is tedious and inefficient to have to draw and label the same cell many times on a schematic. To simplify this task, most editors allow you to place a special <A NAME="marker=30592">
 </A>
vectored cell instance of a cell. A vectored cell instance, or <A NAME="marker=30593">
 </A>
vectored instance for short, uses the same icon for a single instance but with a special attribute, the <A NAME="marker=30594">
 </A>
<SPAN CLASS="Definition">
cell cardinality</SPAN>
, that denotes the number of copies of the cell. Connections between signals on a bus and vectored instances should be handled automatically. The width or <A NAME="marker=30595">
 </A>
cardinality of the bus and the cell cardinality must match, and the design-entry tool should issue a warning if this is not the case.</P>
<P CLASS="Body">
<A NAME="pgfId=2959">
 </A>
A schematic-entry program can use a terminal attribute to determine which cell terminals are output terminals and which terminals are input terminals. This attribute is usually called <A NAME="marker=2955">
 </A>
<SPAN CLASS="Definition">
terminal polarity</SPAN>
 or <A NAME="marker=2958">
 </A>
<SPAN CLASS="Definition">
terminal direction</SPAN>
. Possible values for terminal polarity might be: <SPAN CLASS="BodyComputer">
input</SPAN>
, <SPAN CLASS="BodyComputer">
output</SPAN>
, and <SPAN CLASS="BodyComputer">
bidirectional</SPAN>
. Checking the terminal polarity of the terminals on a net can help find problems such as a net with all input terminals or all output terminals.</P>
<P CLASS="Body">
<A NAME="pgfId=2971">
 </A>
The <A NAME="marker=2965">
 </A>
<SPAN CLASS="Definition">
fanout</SPAN>
 of a cell measures the driving capability of an output terminal. The <A NAME="marker=2968">
 </A>
<SPAN CLASS="Definition">
fanin</SPAN>
 of a cell measures the number of input terminals. Fanout is normally measured using a <A NAME="marker=2970">
 </A>
standard load. A <SPAN CLASS="Definition">
standard load</SPAN>
 is the load presented by one input of a primitive cell, usually a two-input NAND. For example, a library cell <SPAN CLASS="BodyComputer">
Counter</SPAN>
 may have an input terminal, <SPAN CLASS="BodyComputer">
Clock</SPAN>
, that is connected to the input terminals of five primitive cells. The loading at this terminal is then five standard loads. We say that the fanout of <SPAN CLASS="BodyComputer">
Clock</SPAN>
 is five. In a similar fashion, we say that if a cell <SPAN CLASS="BodyComputer">
Buffer</SPAN>
 is capable of driving the inputs of three primitive cells, the fanout of <SPAN CLASS="BodyComputer">
Buffer</SPAN>
 is three. Using the fanin and fanout attributes a netlist screener can check to see if the fanout driving a net is greater than the sum of all loads on that net. (See Figure 9.2 on page 329.)</P>
</DIV>
<DIV>
<H3 CLASS="Heading2">
<A NAME="pgfId=2988">
 </A>
9.1.12&nbsp;Schematic-Entry tools</H3>
<P CLASS="BodyAfterHead">
<A NAME="pgfId=3000">
 </A>
Some editors offer <A NAME="marker=2998">
 </A>
<SPAN CLASS="Definition">
icon edit-in-place</SPAN>
 in a similar fashion as schematic edit-in-place for cells. Often you have to toggle editing modes in the schematic-entry program to switch between editing cells and editing cell icons. A schematic-entry program must keep track of when cells are edited. Normally this is done by using a <A NAME="marker=3006">
 </A>
<SPAN CLASS="Definition">
timestamp</SPAN>
 or <A NAME="marker=3009">
 </A>
<SPAN CLASS="Definition">
datestamp</SPAN>
 for each cell. This is a text field within the data file for each cell that holds the date and time that the cell was last modified. When a new schematic or cell is loaded, the program needs to compare its timestamp with the timestamps of any subcells. If any of the subcell timestamps are more recent, then the designer needs to be alerted. Usually a message appears to inform you that changes have been made to subcells since the last time the cell currently loaded was saved. This may be what you expect or it may be a warning that somehow a subcell has been changed inadvertently (perhaps someone else changed it) since you last loaded that cell. </P>
<P CLASS="Body">
<A NAME="pgfId=3014">
 </A>
Normally the primitive cells in a library are locked and cannot be edited. If you can edit a primitive cell, you have to make a copy, edit the copy, and rename it. Normally the ASIC designer cannot do this and does not want to. For example, to edit a primitive NAND gate stored in an ASIC schematic library would require that the subschematic of the primitive cell be available (usually not the case) and also that the next lower level primitives (symbols for the transistors making up the NAND gate) also be available to the designer (also usually not the case).</P>
<P CLASS="Body">
<A NAME="pgfId=3024">
 </A>
What do you do if somehow changes were made to a cell by mistake, perhaps by someone else, and you don&#8217;t want the new cell, you want the old version? Most schematic-entry and other EDA tools keep old versions of files as a back-up in case this kind of problem occurs. Most EDA software automatically keeps track of the different <A NAME="marker=3020">
 </A>
<SPAN CLASS="Definition">
versions</SPAN>
 of a file by appending a <A NAME="marker=3023">
 </A>
<SPAN CLASS="Definition">
version number</SPAN>
 to each file. Usually this is transparent to the designer. Thus when you edit a cell named <SPAN CLASS="BodyComputer">
Floor</SPAN>
, the file on disk might be called <SPAN CLASS="BodyComputer">
Floor.6</SPAN>
. When you save the changes, the software will not overwrite <SPAN CLASS="BodyComputer">
Floor.6</SPAN>
, but write out a new file and automatically name it <SPAN CLASS="BodyComputer">
Floor.7</SPAN>
. </P>
<P CLASS="Body">
<A NAME="pgfId=3032">
 </A>
Some design-entry tools are more sophisticated and allow users to create their own libraries as they complete an ASIC design. Designers can then control access to libraries and the cells that they build during a design. This normally requires that a schematic editor, for example, be part of a larger EDA system or framework rather than work as a stand-alone tool. Sometimes the process of library control operates as a separate tool, as a <A NAME="marker=3028">
 </A>
<SPAN CLASS="Definition">
design manager</SPAN>
 or <A NAME="marker=3031">
 </A>
<SPAN CLASS="Definition">
library manager</SPAN>
. Often there is a program similar to the UNIX <SPAN CLASS="BodyComputer">
make</SPAN>
<A NAME="marker=30510">
 </A>
 command that keeps track of all files, their dependencies, and the tools that are necessary to create and update each file.</P>
<P CLASS="Body">
<A NAME="pgfId=3040">
 </A>
You can normally set the number of back-up versions of files that EDA software keeps. The <A NAME="marker=3038">
 </A>
<SPAN CLASS="Definition">
version history</SPAN>
 controls the number of files the software will keep. If you accidentally update, overwrite, or delete a file, there is usually an option to select and revert to an earlier version. More advanced systems have <SPAN CLASS="Definition">
check-out</SPAN>
<A NAME="marker=30500">
 </A>
 services (which work just as in source control systems in computer programming databases) that prevent these kinds of problems when many people are working on the same design. Whenever possible, the management of design files and different versions should be left under software control because the process can become very complicated. Reverting to an earlier version of a cell can have drastic consequences for other cells that reference the cell you are working with. Attempts to manually edit files by changing version numbers and timestamps can quickly lead to chaos.</P>
<P CLASS="Body">
<A NAME="pgfId=3052">
 </A>
Most schematic-entry programs allow you to <A NAME="marker=3050">
 </A>
<SPAN CLASS="Definition">
undo</SPAN>
 commands. This feature may be restricted to simply undoing the last command that you entered, or may be an unlimited undo and redo, allowing you to back up as many commands as you want in the current edit