ASIC and Custom IC Cell Information Representation:EDIF

EDIF

Electronic Design Interchange Format (EDIF) is a text format used to convey information between different EDA tools. The purpose of EDIF is to provide a solution for data transfer problem by defining a neutral intermediate format. EDIF was first developed in 1985. The first real public release of EDIF was EDIF version 2 0 0, which was published in 1987 and adopted as an ANSI/EIA standard in 1988 [6]. To handle busses, bus rippers, and busses across multipage schematics, EDIF version 3 0 0 was developed and approved in 1993. EDIF version 4 0 0 was developed in 1996 to transfer PCB/MCM layouts between EDA tools.

EDIF Structure

Since most of EDA tools use EDIF 2 0 0, instead of other more recent versions of EDIF, in this section we deal with the fundamentals of EDIF 2 0 0. EDIF is a LISP-like format including several constructs each of which is surrounded in a pair of parenthesis. The regularity of the EDIF format makes parsing the file very simple.

The overall structure of an EDIF file is shown in Figure 93.8. As shown in this figure, an EDIF file has a hierarchical nature and may include one or more library elements. Each library element consists of a technology section and one or more cell descriptions. The technology section of a library includes the information about the specified technology used for the related cells of that library. Each cell has a number of views used to specify different aspects or representations of that cell. The specification covers all aspects of electronic design including schematic, netlist, mask layout, PCB layout, documentation, etc. A view consists of an interface section and possibly a contents section where the interface section deals with port definitions of the corresponding cell and the contents section pertains to the internal structure of that cell [5].

EDIF Syntax

EDIF defines three different levels of complexity, named as level 0, level 1, and level 2. Level 0 is the basic level of EDIF description and is more restricted than other levels. In this level only literal constants are permitted. Level 1 supports level 0 constructs as well as parameters, expressions, and frames while level 2 adds control flow constructs to level 1. The level of an EDIF file that includes several libraries is considered to be the maximum level of the corresponding libraries [6].

As discussed above an EDIF file includes a number of constructs each of which is surrounded in a pair of parenthesis. Each construct is composed of an EDIF keyword followed by a list of items. The items can be other constructs, identifiers, or data items, where a construct can be a nested construct.

The ability of keyword definition and abbreviation has been provided in EDIF files using keywordMap construct, where keyword level 0 construct specifies that no keyword definition and abbreviation is supported.

Identifiers are used to define objects in EDIF files. Each identifier is a string of up to 255 characters consisting of alphanumeric and the underscore characters. A string must be preceded with an ampersand unless its first character is an alphabetic character or underscore. This ampersand is not considered as a part of the object name. Identifiers and keywords are not case sensitive. Thus &a1, &A1, A1, and a1 strings are identical.

Numbers can be used to represent different aspects in EDIF files such as path widths, gate delays, etc. EDIF supports 32-bit signed integer numbers. To represent real numbers or integers, which cannot be specified by a 32-bit number, a scale factor is used. The triple (e mantissa exponent) format is used to represent an exponential number that is equal to mantissa X10exponent. For example (e 8-2) represents 0.08.

The strings in EDIF structures are a sequence of legal characters enclosed in a pair of double-quote characters.

To represent the general location of a specified point in EDIF, the triple (pt x y) is used, where x and y are the x and y locations of the corresponding point.

As discussed above, EDIF can handle different representations of a design. Of these representations, netlist is the most common view used in HDLs. To give a general introduction to the syntax and semantics of EDIF language, we will present the netlist view of a T-type flip-flop in the following section.

An EDIF Netlist Example

Figure 93.9 shows an EDIF netlist for a T-type flip-flop composed of a D-type flip-flop and an inverter. As shown in this figure, each EDIF file is composed of a number of constructs surrounded in a pair of parentheses.

An EDIF file starts with the edif keyword, which marks the highest level of hierarchy in a design and is followed by the design name (line 1, Figure 93.9). edifVersion, edifLevel, and keywordMap constructs which were discussed above follow the design name (lines 2–4, Figure 93.9).

An optional construct (status) may be included in an EDIF file to present additional information about the creation date, creating program, and author of the current EDIF file. This is shown in lines 5–9 of Figure 93.9.

To describe a design in EDIF, the referenced library as well as the design library must be identified. To declare a library in an EDIF file, the library (external) construct is used. The library (external) construct describes a library that is internal (external) to the EDIF data. Line 10 of Figure 93.9 introduces the external library cub as the reference library.

Scaling information in an EDIF file is presented by using numberDefinition construct (line 12, Figure 93.9). This construct is included in each EDIF file but it is not applicabale and not utilized in netlist structures.

Lines 13–25 of Figure 93.9 show that the cub library contains a number of cells to be used in our design. This library includes DFF and INV cells (lines13–25, Figure 93.9).

The netlist view of the DFF cell has three inputs and two output ports (lines 15–20, Figure 93.9), while the netlist view of the INV cell has one input and one output port (lines 23–25, Figure 93.9).

To describe our complete design (Tflipflop) the same constructs used for DFF and INV are used. Lines 26–34 of Figure 93.9 introduce the design library (work), and its interface. In this example the design (Tflipflop) has Reset, and Clk input ports and Dataout output ports (lines 31–34, Figure 93.9).

After the instantiated cells of a referenced library are identified, ports of the design must be mapped to the ports of these cells. The contents construct shown in line 35 of Figure 93.9 is used to give instance names ix44 and ix45 to DFF and INV cells. The cellref constructs (lines 36 and 38, Figure 93.9) links the cell instances ix44 and ix45 to DFF and INV cells in library cub.

The net construct links the design nets with the input/output ports of the library cells. Lines 40–43 of Figure 93.9 show that the Reset port of this design has been tied to the port A of the ix45 instantiated cell. The remainder of this code specifies the links between other design ports and input/output ports of the instantiated cells.

The EDIF file terminates with the design construct (line 60, Figure 93.9). This construct introduces the design name (Tflipflop) and places the design in the working library (work).

Our Coverage of EDIF

The description of EDIF presented here was an introduction to this format. We tried to cover the basics of this format and familiarize the reader with the overall structure of this language and its applications. For this purpose we used a small example. EDIF is a complete format and includes many constructs for design description. Dealing with all of these constructs is beyond the scope of this chapter. For a complete description of this format, readers are encouraged to see the references at the end of this chapter [5,6].