ch09.4.htm

来自「介绍asci设计的一本书」· HTM 代码 · 共 1,773 行 · 第 1/4 页

pathWidth</SPAN>
 from the <SPAN CLASS="BodyComputer">
figureGroup</SPAN>
 or <SPAN CLASS="BodyComputer">
figureGroupOverride</SPAN>
; circles and rectangles use <SPAN CLASS="BodyComputer">
borderWidth</SPAN>
.</P>
<P CLASS="Body">
<A NAME="pgfId=3845">
 </A>
The fixed text for a symbol uses <SPAN CLASS="BodyComputer">
annotate</SPAN>
 forms. The <SPAN CLASS="BodyComputer">
stringDisplay</SPAN>
 in <SPAN CLASS="BodyComputer">
annotate</SPAN>
 contains the text as a string. The <SPAN CLASS="BodyComputer">
stringDisplay</SPAN>
 contains a <SPAN CLASS="BodyComputer">
display</SPAN>
 with the <SPAN CLASS="BodyComputer">
textHeight</SPAN>
, <SPAN CLASS="BodyComputer">
justification</SPAN>
, and <SPAN CLASS="BodyComputer">
location</SPAN>
. The <SPAN CLASS="BodyComputer">
symbol</SPAN>
 form can contain multiple <SPAN CLASS="BodyComputer">
figure</SPAN>
 and <SPAN CLASS="BodyComputer">
annotate</SPAN>
 forms.</P>
</DIV>
<DIV>
<H3 CLASS="Heading2">
<A NAME="pgfId=3849">
 </A>
9.4.4&nbsp;An EDIF Example</H3>
<P CLASS="BodyAfterHead">
<A NAME="pgfId=3853">
 </A>
In this section we shall illustrate the use of EDIF in translating a cell library from one set of tools to another&#8212;from a Compass Design Automation cell library to the Cadence schematic-entry tools. The code in <A HREF="#24981" CLASS="XRef">
Table&nbsp;9.12</A>
 shows the EDIF description of the symbol for a two-input AND gate, an02d1, from the Compass cell library.</P>
<TABLE>
<TR>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableTitle">
<A NAME="pgfId=25921">
 </A>
TABLE&nbsp;9.12&nbsp;<A NAME="24981">
 </A>
EDIF file for a Compass standard-cell schematic icon.</P>
</TD>
</TR>
<TR>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="Table">
<A NAME="pgfId=26064">
 </A>
&nbsp;</P>
<DIV>
<MAP NAME="CH09-11">
</MAP>
<IMG SRC="CH09-11.gif" USEMAP="#CH09-11">
</DIV>
</TD>
</TR>
</TABLE>
<P CLASS="Body">
<A NAME="pgfId=11486">
 </A>
The Cadence schematic tools do contain a procedure, EDIFIN, that reads the Compass EDIF files. This procedure works, but, as we shall see, results in some problems when you use the icons in the Cadence schematic-entry tool. Instead we shall make some changes to the original files before we use EDIFIN to transfer the information to the Cadence database, <SPAN CLASS="BodyComputer">
cdba</SPAN>
. </P>
<P CLASS="Body">
<A NAME="pgfId=26536">
 </A>
The original Compass EDIF file contains a <SPAN CLASS="BodyComputer">
figureGroup </SPAN>
for each of the following four EDIF cell symbols:</P>
<P CLASS="ComputerOneLine">
<A NAME="pgfId=4180">
 </A>
connector_FG  icon_FG  instance_FG  net_FG bus_FG</P>
<P CLASS="Body">
<A NAME="pgfId=4192">
 </A>
The EDIFIN application translates each <SPAN CLASS="BodyComputer">
figureGroup</SPAN>
 to a Cadence layer&#8211;purpose pair definition that must be defined in the Cadence technology file associated with the library. If we use the original EDIF file with EDIFIN this results in the automatic modification of the Cadence technology file to define layer names, purposes, and the required properties to enable use of the <SPAN CLASS="BodyComputer">
figureGroup</SPAN>
 names. This results in non-Cadence layer names in the Cadence database.</P>
<P CLASS="Body">
<A NAME="pgfId=4196">
 </A>
First then, we need to modify the EDIF file to use the standard Cadence layer names shown in <A HREF="#10139" CLASS="XRef">
Table&nbsp;9.13</A>
. These layer names and their associated purposes and properties are defined in the default Cadence technology file, <SPAN CLASS="BodyComputer">
default.tf</SPAN>
. There is one more layer name in the Compass files (<SPAN CLASS="BodyComputer">
bus_FG</SPAN>
 <SPAN CLASS="BodyComputer">
figureGroup</SPAN>
), but since this is not used in the library we can remove this definition from the EDIF input file. </P>
<TABLE>
<TR>
<TD ROWSPAN="1" COLSPAN="4">
<P CLASS="TableTitle">
<A NAME="pgfId=2037">
 </A>
TABLE&nbsp;9.13&nbsp;<A NAME="10139">
 </A>
Compass and corresponding Cadence figureGroup names.</P>
</TD>
</TR>
<TR>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableFirst">
<A NAME="pgfId=2045">
 </A>
<SPAN CLASS="TableHeads">
Compass name </SPAN>
</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableFirst">
<A NAME="pgfId=2047">
 </A>
<SPAN CLASS="TableHeads">
Cadence name</SPAN>
</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableFirst">
<A NAME="pgfId=25426">
 </A>
<SPAN CLASS="TableHeads">
Compass name </SPAN>
</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableFirst">
<A NAME="pgfId=25428">
 </A>
<SPAN CLASS="TableHeads">
Cadence name</SPAN>
</P>
</TD>
</TR>
<TR>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableLeft">
<A NAME="pgfId=2057">
 </A>
connector_FG</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableLeft">
<A NAME="pgfId=2059">
 </A>
pin</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableLeft">
<A NAME="pgfId=25450">
 </A>
net_FG</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableLeft">
<A NAME="pgfId=25452">
 </A>
wire</P>
</TD>
</TR>
<TR>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableLeft">
<A NAME="pgfId=2065">
 </A>
icon_FG</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableLeft">
<A NAME="pgfId=2067">
 </A>
device</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableLeft">
<A NAME="pgfId=25454">
 </A>
bus_FG</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableLeft">
<A NAME="pgfId=25456">
 </A>
not used</P>
</TD>
</TR>
<TR>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableLeft">
<A NAME="pgfId=2073">
 </A>
instance_FG</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableLeft">
<A NAME="pgfId=2075">
 </A>
instance</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableLeft">
<A NAME="pgfId=25438">
 </A>
&nbsp;</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableLeft">
<A NAME="pgfId=25440">
 </A>
&nbsp;</P>
</TD>
</TR>
</TABLE>
<P CLASS="Body">
<A NAME="pgfId=26537">
 </A>
Internal scaling differences lead to giant characters in the Cadence tools if we use the <SPAN CLASS="BodyComputer">
textHeight</SPAN>
 of 30 defined in the EDIF file. Reducing the <SPAN CLASS="BodyComputer">
textHeight</SPAN>
 to 5 results in a reasonable text height. </P>
<P CLASS="Body">
<A NAME="pgfId=4207">
 </A>
The EDIF <SPAN CLASS="BodyComputer">
numberDefinition</SPAN>
 construct, together with the <SPAN CLASS="BodyComputer">
scale</SPAN>
 construct, defines measurement scaling in an EDIF file. In a Cadence schematic EDIF file the <SPAN CLASS="BodyComputer">
numberDefinition</SPAN>
 and <SPAN CLASS="BodyComputer">
scale</SPAN>
 construct is determined by an entry in the associated library technology file that defines the <SPAN CLASS="BodyComputer">
edifUnit</SPAN>
 to <SPAN CLASS="BodyComputer">
userUnit</SPAN>
 ratio. This ratio affects the printed size of an icon.</P>
<P CLASS="Body">
<A NAME="pgfId=4211">
 </A>
For example, the distance defined by the following path construct is 10 EDIF units: </P>
<P CLASS="ComputerOneLine">
<A NAME="pgfId=4215">
 </A>
(path (pointlist (pt 0 0) (pt 0 10))) </P>
<P CLASS="Body">
<A NAME="pgfId=4225">
 </A>
What is the length of 10 EDIF units? The <SPAN CLASS="BodyComputer">
numberDefinition</SPAN>
 and <SPAN CLASS="BodyComputer">
scale</SPAN>
 construct associates EDIF units with a physical dimension. The following construct </P>
<P CLASS="ComputerOneLine">
<A NAME="pgfId=4229">
 </A>
(numberDefinition (scale 100 (e 25400 -6) unit DISTANCE))</P>
<P CLASS="BodyAfterHead">
<A NAME="pgfId=4231">
 </A>
specifies that 100 EDIF units equal 25400 <SPAN CLASS="Symbol">
&#165; </SPAN>
10<SUP CLASS="Superscript">
&#8211;6</SUP>
 m or <SPAN CLASS="Emphasis">
approximately</SPAN>
 1 inch. Cadence defines schematic measurements in inches by defining the <SPAN CLASS="BodyComputer">
userUnit</SPAN>
 property of the affected <SPAN CLASS="BodyComputer">
viewType</SPAN>
 or <SPAN CLASS="BodyComputer">
viewName</SPAN>
 as <SPAN CLASS="BodyComputer">
inch</SPAN>
 in the Cadence technology file. The Compass EDIF files do not provide values for the <SPAN CLASS="BodyComputer">
numberDefinition</SPAN>
 and <SPAN CLASS="BodyComputer">
scale</SPAN>
 construct, and the Cadence tools default to a value of 160 EDIF units to 1 user unit. We thus need to add a <SPAN CLASS="BodyComputer">
numberDefinition</SPAN>
 and <SPAN CLASS="BodyComputer">
scale</SPAN>
 construct to the Compass EDIF file to control the printed size of icons. </P>
<P CLASS="Body">
<A NAME="pgfId=26584">
 </A>
The EDIF file defines blank label placeholders for each cell using the EDIF <SPAN CLASS="BodyComputer">
property</SPAN>
 construct. Cadence EDIFIN does recognize and translate EDIF properties, but to attach a label property to a <SPAN CLASS="BodyComputer">
cellview</SPAN>
 object it must be defined (not blank) and identified as a property using the EDIF <SPAN CLASS="BodyComputer">
owner</SPAN>
 construct in the EDIF file. Since the intent of a placeholder is to hold an empty spot for later use and since Cadence Composer (the schematic-entry tool) supports label additions to instantiated icons, we can remove the EDIF <SPAN CLASS="BodyComputer">
label</SPAN>
 property construct in each cell and the associated <SPAN CLASS="BodyComputer">
propertyDisplay</SPAN>
 construct from the Compass file.</P>
<P CLASS="Body">
<A NAME="pgfId=26591">
 </A>
There is a problem that we need to resolve with naming. This is a problem that sooner or later everyone must tackle in ASIC design&#8212;<SPAN CLASS="Definition">
case sensitivity</SPAN>
<A NAME="marker=26599">
 </A>
.</P>
<P CLASS="Body">
<A NAME="pgfId=4505">
 </A>
In EDIF, input and output pins are called ports and they are identified using <SPAN CLASS="BodyComputer">
portImplementation</SPAN>
 constructs.  In order that the ports of a particular cell <SPAN CLASS="BodyComputer">
icon_view</SPAN>
 are correctly associated with the ports in the related functional, layout, and abstract views, they must all have the same name. The Cadence tools are case sensitive in this respect. The Verilog and CIF files corresponding to each cell in the Compass library use lowercase names for each port of a given cell, whereas the EDIF file uses uppercase. The EDIFIN translator allows the case of cell, view, and port names to be automatically changed on translation. Thus pin names such as '<SPAN CLASS="BodyComputer">
A1</SPAN>
' become '<SPAN CLASS="BodyComputer">
a1</SPAN>
' and the original view name '<SPAN CLASS="BodyComputer">
Icon_view</SPAN>
' becomes '<SPAN CLASS="BodyComputer">
icon_view</SPAN>
'. </P>
<P CLASS="Body">
<A NAME="pgfId=26608">
 </A>
The <SPAN CLASS="BodyComputer">
boundingBox</SPAN>
 construct defines a bounding box around a symbol (icon). Schematic-capture tools use this to implement various functions. The Cadence Composer tool, for example, uses the bounding box to control the wiring between cells and as a highlight box when selecting components of a schematic. Compass uses a large <SPAN CLASS="BodyComputer">
boundingBox</SPAN>
 definition for the cells to allow space for long hierarchical names. <A HREF="#37103" CLASS="XRef">
Figure&nbsp;9.10</A>
(a) shows the original <SPAN CLASS="BodyComputer">
an02d1</SPAN>
 cell bounding box that is larger than the cell icon. </P>
<TABLE>
<TR>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableFigure">
<A NAME="pgfId=7061">
 </A>
&nbsp;</P>
<DIV>
<IMG SRC="CH09-12.gif">
</DIV>
</TD>
</TR>
<TR>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableFigureTitle">
<A NAME="pgfId=7077">
 </A>
FIGURE&nbsp;9.10&nbsp;<A NAME="37103">
 </A>
The bounding box problem. (a)&nbsp;The original bounding box for the an02d1 icon. (b)&nbsp;Problems in Cadence Composer due to overlapping bounding boxes. (c)&nbsp;A &#8220;shrink-wrapped&#8221; bounding box created using SKILL.</P>
</TD>
</TR>
</TABLE>
<P CLASS="Body">
<A NAME="pgfId=4522">
 </A>
Icons with large bounding boxes create two problems in Composer. Highlighting all or part of a complex design consisting of many closely spaced cells results in a confusion of overlapped highlight boxes. Also, large boxes force strange wiring patterns between cells that are placed too closely together when Composer's automatic routing algorithm is used. <A HREF="#37103" CLASS="XRef">
Figure&nbsp;9.10</A>
(b) shows an example of this problem. </P>
<P CLASS="Body">
<A NAME="pgfId=4531">
 </A>
There are two solutions to the bounding-box problem. We could modify each <SPAN CLASS="BodyComputer">
boundingBox</SPAN>
 definition in the original EDIF file before translation to conform to the outline of the icon.  This involves identifying the outline of each icon in the EDIF file and is difficult. A simpler approach is to use the Cadence tool programming language, SKILL. SKILL provides direct access to the Cadence database, <SPAN CLASS="BodyComputer">
cdba</SPAN>
, in order to modify and create objects. Using SKILL you can use a batch file to call functions normally accessed interactively. The solution to the bounding box problem is:</P>
<OL>
<LI CLASS="NumberFirst">
<A NAME="pgfId=25561">
 </A>
Use EDIFIN to create the views in the Cadence database, <SPAN CLASS="BodyComputer">
cdba</SPAN>
.</LI>
<LI CLASS="NumberList">
<A NAME="pgfId=25566">
 </A>
Use the <SPAN CLASS="BodyComputer">
schCreateInstBox()</SPAN>
 command on each <SPAN CLASS="BodyComputer">
icon_view</SPAN>
 object to eliminate the original bounding box and create a new, minimum-sized, bounding box that is &#8220;shrink-wrapped&#8221; to each icon.</LI>
</OL>
<P CLASS="Body">
<A NAME="pgfId=25567">
 </A>
<A HREF="#37103" CLASS="XRef">
Figure&nbsp;9.10</A>
(c) shows the results of this process. This modification fixes the problems with highlighting and wiring in Cadence Composer. </P>
<P CLASS="Body">
<A NAME="pgfId=26656">
 </A>
This completes the steps required to translate the schematic icons from one set of tools to another. The process can be automated in three ways:</P>
<UL>
<LI CLASS="BulletFirst">
<A NAME="pgfId=26647">
 </A>
Write UNIX <SPAN CLASS="BodyComputer">
sed</SPAN>
 and <SPAN CLASS="BodyComputer">
awk</SPAN>
 scripts to make the changes to the EDIF file before using EDIFIN and SKILL.</LI>
<LI CLASS="BulletList">
<A NAME="pgfId=26648">
 </A>
Write custom C programs to make the changes to the EDIF file and then proceed as in the first option.</LI>
<LI CLASS="BulletLast">
<A NAME="pgfId=26649">
 </A>
Perform all the work using SKILL.</LI>
</UL>
<P CLASS="Body">
<A NAME="pgfId=26645">
 </A>
The last approach is the most elegant and most easily maintained but is the most difficult to implement (mostly because of the time required to learn SKILL). The whole project took several weeks (including the time it took to learn how to use each of the tools). This is typical of the problems you face when trying to convert data from one system to another.</P>
</DIV>
<HR><P>[&nbsp;<A HREF="CH09.htm">Chapter&nbsp;start</A>&nbsp;]&nbsp;[&nbsp;<A HREF="CH09.3.htm">Previous&nbsp;page</A>&nbsp;]&nbsp;[&nbsp;<A HREF="CH09.5.htm">Next&nbsp;page</A>&nbsp;]</P></BODY>

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