|
|||||||
|
|
|
||||||||||||||||||||||||||||
|
[ Chapter start ] [ Previous page ] [ Next page ] 9.4 EDIFAn ASIC designer spends an increasing amount of time forcing different tools to communicate. One standard for exchanging information between EDA tools is the electronic design interchange format ( EDIF ). We will describe EDIF version 2 0 0. The most important features added in EDIF 3 0 0 were to handle buses, bus rippers, and buses across schematic pages. EDIF 4 0 0 includes new extensions for PCB and multichip module (MCM) data. The Library of Parameterized Modules ( LPM ) standard is also based on EDIF. The newer versions of EDIF have a richer feature set, but the ASIC industry seems to have standardized on EDIF 2 0 0. Most EDA companies now support EDIF. The FPGA companies Altera and Actel use EDIF as their netlist format, and Xilinx has announced its intention to switch from its own XNF format to EDIF. We only have room for a brief description of the EDIF format here. A complete description of the EDIF standard is contained in the Electronic Industries Association ( EIA ) publication, Electronic Design Interchange Format Version 2 0 0 ( ANSI/EIA Standard 548-1988) [ EDIF, 1988]. 9.4.1 EDIF SyntaxThe structure of EDIF is similar to the Lisp programming language or the Postscript printer language. This makes EDIF a very hard language to read and almost impossible to write by hand. EDIF is intended as an exchange format between tools, not as a design-entry language. Since EDIF is so flexible each company reads and writes different “flavors” of EDIF. Inevitably EDIF from one company does not quite work when we try and use it with a tool from another company, though this situation is improving with the gradual adoption of EDIF 3 0 0. We need to know just enough about EDIF to be able to fix these problems. Figure 9.8 illustrates the hierarchy of the EDIF file. Within an EDIF file are one or more libraries of cell descriptions. Each library contains technology information that is used in describing the characteristics of the cells it contains. Each cell description contains one or more user-named views of the cell. Each view is defined as a particular viewType and contains an interface description that identifies where the cell may be connected to and, possibly, a contents description that identifies the components and related interconnections that make up the cell. The EDIF syntax consists of a series of statements in the following format: A left parenthesis (round bracket) is always followed by a keyword name , followed by one or more EDIF forms (a form is a sequence of identifiers, primitive data, symbolic constants, or EDIF statements), ending with a right parenthesis. If you have programmed in Lisp or Postscript, you may understand that EDIF uses a “define it before you use it” approach and why there are so many parentheses in an EDIF file. The semantics of EDIF are defined by the EDIF keywords . Keywords are the only types of name that can immediately follow a left parenthesis. Case is not significant in keywords. An EDIF identifier represents the name of an object or group of data. Identifiers are used for name definition, name reference, keywords, and symbolic constants. Valid EDIF identifiers consist of alphanumeric or underscore characters and must be preceded by an ampersand ( &) if the first character is not alphabetic. The ampersand is not considered part of the name. The length of an identifier is from 1 to 255 characters and case is not significant. Thus &clock , Clock , and clock all represent the same EDIF name (very confusing). Numbers in EDIF are 32-bit signed integers. Real numbers use a special EDIF format. For example, the real number 1.4 is represented as (e 14 -1) . The e form requires a mantissa ( 14 ) and an exponent ( -1 ). Reals are restricted to the range ± 1 ¥ 10 ± 35 . Numbers in EDIF are dimensionless and the units are determined according to where the number occurs in the file. Coordinates and line widths are units of distance and must be related to meters. Each coordinate value is converted to meters by applying a scale factor . Each EDIF library has a technology section that contains a required numberDefinition . The scale keyword is used with the numberDefinition to relate EDIF numbers to physical units. Valid EDIF strings consist of sequences of ASCII characters enclosed in double quotes. Any alphanumeric character is allowed as well as any of the following characters: ! # $ & ' () * + , - . / : ; < = > ? @ [ \ ] ^ _ ` { | } ~ . Special characters, such as " and % are entered as escape sequences: %number% , where number is the integer value of the ASCII character. For example, "A quote is % 34 %" is a string with an embedded double-quote character. Blank, tab, line feed, and carriage-return characters (white space) are used as delimiters in EDIF. Blank and tab characters are also significant when they appear in strings. The rename keyword can be used to create a new EDIF identifier as follows: (cell (rename TEST_1 "test$1") ... In this example the EDIF string contains the original name, test$1, and a new name, TEST_1 , is created as an EDIF identifier. 9.4.2 An EDIF Netlist ExampleTable 9.11 shows an EDIF netlist. This EDIF description corresponds to the halfgate example in Chapter 8 and describes an inverter. We shall explain the functions of the EDIF in Table 9.11 by showing a piece of the code at a time followed by an explanation.
(edifVersion 2 0 0) (edifLevel 0) (keywordMap (keywordLevel 0)) (status (written (timeStamp 1996 7 10 22 5 10) (program "COMPASS Design Automation -- EDIF Interface" (version "v9r1.2 last updated 26-Mar-96")) (author "mikes"))) Every EDIF file must have an edif form. The edif form must have a name , an edifVersion , an edifLevel , and a keywordMap . The edifVersion consists of three integers describing the major (first number) and minor version of EDIF. The keywordMap must have a keywordLevel . The optional status can contain a written form that must have a timeStamp and, optionally, author or program forms. (library xc4000d (edifLevel 0) (technology (The unbalanced parentheses are deliberate since we are showing segments of the EDIF code.) The library form must have a name , edifLevel and technology . The edifLevel is normally 0. The xc4000d library contains the cells we are using in our schematic. (numberDefinition ) (simulationInfo (logicValue H) (logicValue L))) The simulationInfo form is used by simulation tools; we do not need that information for netlist purposes for this cell. We shall discuss numberDefinition in the next example. It is not needed in a netlist. (cell (rename INV "inv") (cellType GENERIC) This cell form defines the name and type of a cell inv that we are going to use in the schematic. (view COMPASS_mde_view (viewType NETLIST) (interface (port I (direction INPUT)) (port O (direction OUTPUT)) The NETLIST view of this inverter cell has an input port I and an output port O . There is also a place holder "@@Label" for the instance name of the cell. This begins the description of our schematic that is in our library working. The lines that follow this library form are similar to the preamble for the cell library xc4000d that we just explained. (cell (rename HALFGATE_P "halfgate_p")(cellType GENERIC) (view COMPASS_nls_view (viewType NETLIST) This cell form is for our schematic named halfgate_p. (interface (port myInput (direction INPUT)) (port myOutput (direction OUTPUT)) The interface form defines the names of the ports that were used in our schematic, myInput and myOutput. At this point we have not associated these ports with the ports of the cell INV in the cell library. (designator "@@Label")) (contents (instance B1_i1 This gives an instance name B1_i1 to the cell in our schematic. (viewRef COMPASS_mde_view (cellRef INV (libraryRef xc4000d)))) The cellRef form links the cell instance name B1_i1 in our schematic to the cell INV in the library xc4000d. (net myInput (joined (portRef myInput) (portRef I (instanceRef B1_i1)))) The net form for myInput (and the one that follows it for myOutput) ties the net names in our schematic to the ports I and O of the library cell INV . (net VDD (joined )) (net VSS (joined )))))) These forms for the global VDD and VSS nets are often handled differently by different tools (one company might call the negative supply GND instead of VSS , for example). This section is where you most often have to edit the EDIF. (design HALFGATE_P (cellRef HALFGATE_P (libraryRef working)))) The design form names and places our design in library working, and completes the EDIF description. 9.4.3 An EDIF Schematic IconEDIF is capable of handling many different representations. The next EDIF example is another view of an inverter that describes how to draw the icon (the picture that appears on the printed schematic or on the screen) shown in Figure 9.9 . We shall examine the EDIF created by the CAD/CAM Group’s Engineering Capture System ( ECS) schematic editor.
This time we shall give more detailed explanations after each piece of EDIF code. We shall also maintain balanced parentheses to make the structure easier to follow. To shorten the often lengthy EDIF code, we shall use an ellipsis ( ... ) to indicate any code that has been left out. (program "CAD/CAM Group, Inc. ECS" (Version "1")))) This preamble is virtually identical to the previous netlist example (and demonstrates that EDIF is useful to store design information as software tools come and go over many years). The first line of the file defines the name of the file. This is followed by lines that identify the version of EDIF being used and the highest EDIF level used in the file (each library may use its own level up to this maximum). EDIF level 0 supports only literal constants and basic constructs. Higher EDIF levels support parameters, expressions, and flow control constructs. EDIF keywords may be mapped to aliases, and keyword macros may be defined within the keywordMap form. These features are not often used in ASIC design because of a lack of standardization. The keywordLevel 0 indicates these capabilities are not used here. The status construct is used for administration: when the file was created, the software used to create the file, and so on. Following this preamble is the main section of the file, which contains design information. (scale 4 (e 254 -5) (unit distance))) The technology form has a numberDefinition that defines the scaling information (we did not use this form for a netlist, but the form must be present). The first numberValue after scale represents EDIF numbers and the second numberValue represents the units specified by the unit form. The EDIF unit for distance is the meter. The numberValue can be an integer or an exponential number. The e form has a mantissa and an exponent. In this example, within the USER library, a distance of 4 EDIF units equals 254 ¥ 10 –5 meters (or 4 EDIF units equals 0.1 inch). After the numberDefinition in the technology form there are one or more figureGroup definitions. A figureGroup defines drawing information such as pathWidth , borderWidth , color , fillPattern , borderPattern , and textHeight . The figureGroup form must have a name, which will be used later in the library to refer back to these definitions. In this example the USER library has one figureGroup (NORMAL) for lines and paths of zero width (the actual width will be implementation dependent) and another figureGroup (WIDE) that will be used for buses with a wider width (for bold lines). The borderWidth is used for drawing filled areas such as rectangles, circles, and polygons. The pathWidth is used for open figures such as lines (paths) and open arcs. Following the technology section the cell forms each represent a symbol. The cell form has a name that will appear in the names of any files produced. The cellType form GENERIC type is required by this schematic editor. The property form is used to list properties of the cell. (property SymbolType (string "GATE")) (view PCB_Symbol (viewType SCHEMATIC) The SymbolType property is used to distinguish between purely graphical symbols that do not occur in the parts list (a ground connection, for example), gate or component symbols, and block or cell symbols (for hierarchical schematics). The SymbolType property is a string that may be COMPONENT , GATE , CELL , BLOCK , or GRAPHIC . Each cell may contain view forms and each view must have a name. Following the name of the view must be a viewType that is either GRAPHIC or SCHEMATIC . Following the viewType is the interface form, which contains the symbol and terminal information. The interface form contains the actual symbol data. If the symbol has terminals, they are listed before the symbol form. The port form defines each terminal. The required port name is used later in the symbol form to refer back to the port. Since this example is from a PCB design, the terminals have pin numbers that correspond to the IC package leads. The pin numbers are defined in the designator form with the pin number as a string. The polarity of the pin is indicated by the direction form, which may be INPUT , OUTPUT , or INOUT . If the pin is an output pin, its Drive can be represented by dcMaxFanout and if it is an input pin its Load can be represented by dcFanoutLoad . The port form can also contain forms unused , dcMaxFanin , dcFaninLoad , acLoad , and portDelay . All other attributes for pins besides PinNumber , Polarity , Load , and Drive are contained in the property form. An attribute string follows the name of the property in the string form. In this example port Pin_2 has a property Cap whose value is 22. This is the input capacitance of the inverter, but the interpretation and use of this value depends on the tools. In ASIC design pins do not have pin numbers, so designator is not used. Instead, the pin names use the property form. So (property NetName (string "1")) would replace the (designator "1") in this example on Pin_2 . The interface form may also contain attributes of the symbol. Symbol attributes are similar to pin attributes. In this example the property name Value has an attribute string "45" . The names occurring in the property form may be referenced later in the interface under the symbol form to refer back to the property . (boundingBox (rectangle (pt 0 0) (pt 76 -32))) (connectLocation (figure NORMAL (dot (pt 60 -16))))) (justify LOWERCENTER) (origin (pt 60 -14))))) (connectLocation (figure NORMAL (dot (pt 0 -16))))) (justify LOWERCENTER) (origin (pt 0 -14))))) (display NORMAL (justify CENTERLEFT) (origin (pt 25 -5)))) (justify CENTERLEFT) (origin (pt 36 -28)))) (display (figureGroupOverride NORMAL (textHeight 7)) (justify CENTERLEFT) (origin (pt 13 -16)))) (display (figureGroupOverride NORMAL (textHeight 9)) (justify CENTERRIGHT) (origin (pt 76 -24)))) The interface contains a symbol that contains the pin locations and graphical information about the icon. The optional boundingBox form encloses all the graphical data. The x- and y-locations of two opposite corners of the bounding rectangle use the pt form. The scale section of the numberDefinition from the technology section of the library determines the units of these coordinates. The pt construct is used to specify coordinate locations in EDIF. The keyword pt must be followed by the x-location and the y-location. For example: (pt 100 200) is at x = 100, y = 200.
(path (pointList (pt 12 0) (pt 12 -32))) (path (pointList (pt 12 -32) (pt 44 -16))) (path (pointList (pt 12 0) (pt 44 -16)))) (path (pointList (pt 48 -16) (pt 60 -16))) (circle (pt 44 -16) (pt 48 -16)) (path (pointList (pt 0 -16) (pt 12 -16)))) (justify CENTERLEFT) (origin (pt 12 -12))))) The figure form has either a name, previously defined as a figureGroup in the technology section, or a figureGroupOverride form. The figure has all the attributes ( pathWidth , borderWidth , and so on) that were defined in the figureGroup unless they are specifically overridden with a figureGroupOverride . Other objects that may appear in a figure are: circle , openShape , path , polygon , rectangle , and shape . Most schematic editors use a grid, and the pins are only allowed to occur on grid . A portImplementation can contain a keywordDisplay or a propertyDisplay for the location to display the pin number or pin name. For a GATE or COMPONENT , keywordDisplay will display the designator (pin number), and designator is the only keyword that can be displayed. For a BLOCK or CELL , propertyDisplay will display the NetName . The display form displays text in the same way that the figure displays graphics. The display must have either a name previously defined as a figureGroup in the technology section or a figureGroupOverride form. The display will have all the attributes ( textHeight for example) defined in the figureGroup unless they are overridden with a figureGroupOverride . A symbolic constant is an EDIF name with a predefined meaning. For example, LOWERLEFT is used to specify text justification. The display form can contain a justify to override the default LOWERLEFT . The display can also contain an orientation that overrides the default R0 (zero rotation). The choices for orientation are rotations ( R0, R90, R180, R270 ), mirror about axis ( MX, MY ), and mirror with rotation ( MXR90, MYR90 ). The display can contain an origin to override the default (pt 0 0) . The symbol itself can have either keywordDisplay or propertyDisplay forms such as the ones in the portImplementation . The choices for keywordDisplay are: cell for attribute Type , instance for attribute InstName , and designator for attribute RefDes . In the preceding example an attribute window currently mapped to attribute Value is displayed at location (76, –24) using right-justified text, and a font size is set with (textHeight 9) . The graphical data in the symbol are contained in figure forms. The path form must contain pointList with two or more points. The figure may also contain a rectangle or circle . Two points in a rectangle define the opposite corners. Two points in a circle represent opposite ends of the diameter. In this example a figure from figureGroup WIDE has three lines representing the triangle of the inverter symbol. Arcs use the openShape form. The openShape must contain a curve that contains an arc with three points. The three points in an arc correspond to the starting point, any point on the arc, and the end point. For example, (openShape (curve (arc (pt - 5 0) (pt 0 5 ) (pt 5 0)))) is an arc with a radius of 5, centered at the origin. Arcs and lines use the pathWidth from the figureGroup or figureGroupOverride ; circles and rectangles use borderWidth . The fixed text for a symbol uses annotate forms. The stringDisplay in annotate contains the text as a string. The stringDisplay contains a display with the textHeight , justification , and location . The symbol form can contain multiple figure and annotate forms. 9.4.4 An EDIF ExampleIn this section we shall illustrate the use of EDIF in translating a cell library from one set of tools to another—from a Compass Design Automation cell library to the Cadence schematic-entry tools. The code in Table 9.12 shows the EDIF description of the symbol for a two-input AND gate, an02d1, from the Compass cell library.
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, cdba . The original Compass EDIF file contains a figureGroup for each of the following four EDIF cell symbols: connector_FG icon_FG instance_FG net_FG bus_FG The EDIFIN application translates each figureGroup to a Cadence layer–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 figureGroup names. This results in non-Cadence layer names in the Cadence database. First then, we need to modify the EDIF file to use the standard Cadence layer names shown in Table 9.13 . These layer names and their associated purposes and properties are defined in the default Cadence technology file, default.tf . There is one more layer name in the Compass files ( bus_FG figureGroup ), but since this is not used in the library we can remove this definition from the EDIF input file.
Internal scaling differences lead to giant characters in the Cadence tools if we use the textHeight of 30 defined in the EDIF file. Reducing the textHeight to 5 results in a reasonable text height. The EDIF numberDefinition construct, together with the scale construct, defines measurement scaling in an EDIF file. In a Cadence schematic EDIF file the numberDefinition and scale construct is determined by an entry in the associated library technology file that defines the edifUnit to userUnit ratio. This ratio affects the printed size of an icon. For example, the distance defined by the following path construct is 10 EDIF units: (path (pointlist (pt 0 0) (pt 0 10))) What is the length of 10 EDIF units? The numberDefinition and scale construct associates EDIF units with a physical dimension. The following construct (numberDefinition (scale 100 (e 25400 -6) unit DISTANCE)) specifies that 100 EDIF units equal 25400 ¥ 10 –6 m or approximately 1 inch. Cadence defines schematic measurements in inches by defining the userUnit property of the affected viewType or viewName as inch in the Cadence technology file. The Compass EDIF files do not provide values for the numberDefinition and scale construct, and the Cadence tools default to a value of 160 EDIF units to 1 user unit. We thus need to add a numberDefinition and scale construct to the Compass EDIF file to control the printed size of icons. The EDIF file defines blank label placeholders for each cell using the EDIF property construct. Cadence EDIFIN does recognize and translate EDIF properties, but to attach a label property to a cellview object it must be defined (not blank) and identified as a property using the EDIF owner 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 label property construct in each cell and the associated propertyDisplay construct from the Compass file. 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— case sensitivity . In EDIF, input and output pins are called ports and they are identified using portImplementation constructs. In order that the ports of a particular cell icon_view 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 ' A1 ' become ' a1 ' and the original view name ' Icon_view ' becomes ' icon_view '. The boundingBox 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 boundingBox definition for the cells to allow space for long hierarchical names. Figure 9.10 (a) shows the original an02d1 cell bounding box that is larger than the cell icon. 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. Figure 9.10 (b) shows an example of this problem. There are two solutions to the bounding-box problem. We could modify each boundingBox 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, cdba , 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:
Figure 9.10 (c) shows the results of this process. This modification fixes the problems with highlighting and wiring in Cadence Composer. 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:
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. [ Chapter start ] [ Previous page ] [ Next page ] | ||||||||||||||||||||||||||||
