EDIF (Electronic Design Interchange Format) is a vendor neutral format in which to store Electronic netlists and schematics. It was one of the first attempts to establish a neutral data exchange format for the electronic design automation (EDA) industry. The goal was to establish a common format from which the proprietary formats of the EDA systems could be derived. When customers needed to transfer data from one system to another, it was necessary to write translators from one format to other. As the number of formats (N) multiplied, the translator issue became an N-squared problem. The expectation was that with EDIF the number of translators could be reduced to the number of involved systems.
Representatives of the EDA companies Daisy Systems, Mentor Graphics, Motorola, National Semiconductor, Tektronix, Texas Instruments and the University of California, Berkeley established the EDIF Steering Committee in November 1983. Later Professor Hilary Kahn (1943-2007) from the University of Manchester joined the team and lead the development from version EDIF 2 0 0 till the final version 4 0 0.
The general format of EDIF involves using parentheses to delimit data definitions, and in this way it superficially resembles Lisp. The basic tokens of EDIF 2.0.0 were keywords (like library, cell, instance, etc), strings (delimited with double quotes), integer numbers, symbolic constants (e.g. GENERIC, TIE, RIPPER for cell types) and "Identifiers", which are reference labels formed from a very restricted set of characters. EDIF 3.0.0 and 4.0.0 dropped the symbolic constants entirely, using keywords instead. So, the syntax of EDIF has a fairly simple foundation. A typical EDIF file looks like this:
(edif fibex (edifVersion 2 0 0)
(edifLevel 0) (keywordMap (keywordLevel 0))
(status (written (timeStamp 1995 1 1 1 1 1) (program "xxx" (version "v1"))))
(library xxx (edifLevel 0)
(technology (numberDefinition (scale 1 (e 1 -6) (unit distance))))
(cell dff_4 (cellType generic)
(view view1 (viewType netlist)
(port aset (direction INPUT))
(port clok (direction INPUT))
(cell yyy (cellType generic)
(view schematic_ (viewType netlist)
(port CLEAR (direction INPUT))
(port CLOCK (direction INPUT)) ... )
(instance I_36_1 (viewRef view1 (cellRef dff_4)))
(instance (rename I_36_3 "I$3") (viewRef view1 (cellRef addsub_4)))
(portRef aset (instanceRef I_36_1))
(portRef aset (instanceRef I_36_3))))
The 1 0 0 release of EDIF was made in 1985.
 EDIF 2 0 0
The first "real" public release of EDIF was version 2 0 0, which was approved in March 1988 as the standard ANSI/EIA-548-1988. It is published in a single volume. This version has no formal scope statement but what it tries to capture is covered by the defined viewTypes:
- BEHAVIOR to describe the behavior of a cell
- DOCUMENT to describe the documentation of a cell
- GRAPHIC to describe a dumb graphics and text representation of displayable or printable information
- LOGICMODEL to describe the logic-simulation model of the cell
- MASKLAYOUT to describe an integrated circuit layout
- NETLIST to describe a netlist
- PCBLAYOUT to describe a printed circuit board
- SCHEMATIC to describe the schematic representation and connectivity of a cell
- STRANGER to describe an as yet unknown representation of a cell
- SYMBOLIC to describe a symbolic layout
The industry tested this release for several years, but finally only the NETLIST view was the one widely used and some EDA tools are still supporting it today for EDIF 2 0 0.
To overcome problems with the main 2 0 0 standard several further documents got released:
- Electronic Industries Association
- EDIF Monograph Series, Volume 1, Introduction to EDIF, EIA/EDIF-1, Sept. 1988
- EDIF Monograph Series, Volume 2, EDIF Connectivity, EIA/EDIF-2, June 1989
- Using EDIF 2 0 0 for schematic transfer, EIA/EDIF/AG-1, July 1989
- Documentation from Hilary J. Kahn, Department of Computer Science, University of Manchester
- EDIF 2 0 0, An Introductory Tutorial", September 1989
- EDIF Questions and answers, volume one, November 1988
- EDIF Questions and answers, volume two, February 1989
- EDIF Questions and answers, volume three, July 1989
- EDIF Questions and answers, volume four, November 1989
- EDIF Questions and answers, volume five, June 1991
 EDIF 3 0 0
Because of some fundamental weaknesses in the 2 0 0 release a new not compatible release 3 0 0 was released in September 1993, given the designation of EIA standard EIA-618. It later achieved ANSI and ISO designations. It is published in 4 volumes. The main focus of this version were the viewTypes NETLIST and SCHEMATIC from 2 0 0. MASKLAYOUT, PCBLAYOUT and some other views were dropped from this release and shifted for later releases because the work for these views was not fully completed.
EDIF 3 0 0 is available from the International Electrotechnical Commission as IEC 61690-1
 EDIF 4 0 0
EDIF 4 0 0 was released in late August 1996, mainly to add "Printed Circuit Board" extensions (the original PCBLAYOUT view) to EDIF 3 0 0. This more than doubled the size of EDIF 3 0 0, and is published in HTML format on CD.
EDIF 4 0 0 is available from the International Electrotechnical Commission as IEC 61690-2
 Problems with 2 0 0
To understand the problems users and vendors encountered with EDIF 2 0 0, one first has to picture all the elements and dynamics of the electronics industry. The people who needed this standard were mainly design engineers, who worked for companies whose size ranged from a house garage to multi-billion dollar facilities with thousands of engineers. These engineers worked mainly from schematics and netlists in the late 1980s, and the big push was to generate the netlists from the schematics automatically. The first suppliers were Electronic Design Automation vendors (e.g., Daisy, Mentor, and Valid formed the earliest predominating set). These companies competed vigorously for their shares of this market.
One of the tactics used by these companies to "capture" their customers was their proprietary databases. Each had special features that the others did not. Once a decision was made to use a particular vendor's software to enter a design, the customer was ever after constrained to use no other software. To move from vendor A's to vendor B's systems usually meant a very expensive re-entry of almost all design data by hand into the new system. This expense of "migration" was the main factor that locked design engineers into using a single vendor.
But the "customers" had a different desire. They saw immediately that while vendor A might have a really nice analog simulation environment, vendor B had a much better PCB or silicon layout auto-router. And they wished that they could pick and choose amongst the different vendors.
Full article ▸