Elgris Technologies, Inc. - Elgris
EDIF Overview

Edif 200
Edif 300
Making your Own Tools


EDIF Overview


EDIF (Electronic Design Interchange Format) is a neutral format used for exchanging electronic design data. There are three versions of EDIF: EDIF 2 0 0, EDIF 3 0 0 and EDIF 4 0 0. EDIF was designed to help solve the problem of integration, migration and archiving of electronic design data.

Its primary use was as a CAD-to-CAD data transfer format. Recently it has been enhanced to include all aspects of CAD-to-CAM data transfer. This work was done by a US government-funded project called ECCE. The beauty of EDIF is that a complete Design can be represented in one file that includes schematic, Netlist and PCB/MCM

EDIF 2 0 0

The most widely used version is EDIF 2 0 0. It is found on practically every EDA platform. EDIF 2 0 0 was released in 1987 and became an ANSI standard in 1988. Its specification covers all aspects of electronic design: schematics, Netlist, mask layout, PCB layout, documentation, simulation models, etc. It has been successfully used for exchanging schematic and connectivity data since 1987. In its early years, it acquired a terrible reputation, among its users, for not being a reliable and effective interchange format. This was due to EDIF 2 0 0 having some severe shortcomings in its definition and as it looked simple enough, many companies implemented quick and dirty translators that were indeed very quick but hardly conformant. In addition the incompatibility between concepts used by various EDA is very real and it takes a lot of hard work to find a satisfactory mapping.

Some of the EDIF 2 0 0 shortcomings are summarized below:

The representation of busses is ambiguous and incomplete.
The rippers are very difficult to understand and use.
View-wide connectivity is not specified for schematics.
There is no specific support for special schematic objects like Page Borders, Title Blocks, and on-page connectors.
The support for pin spacing, grids, text representation is non-existent or insufficient.
There are no constructs for multiple symbols per view or for shared symbols.
Lots of constructs are too overloaded: example, a cell can be generic, ripper or tie.
Some aspects of instantiation are very confused.
The semantics of arrayed objects are not very clear.
Some objects are just not defined: example, Mentor frames cannot be directly represented in
EDIF 2 0 0.

Some of the notorious incompatibilities between EDA vendors’ concepts are listed below:

  • Naming conventions for cells, instances, properties, nets, bundles and busses: names with overbars, multidimensional indexing, prefix repeat operators, suffix repeat operators, descending or ascending order bus names, bit skipping in bus names, embedding indexing in the middle of a bus name, etc.
  • Dangling nets
  • Connectivity by name
  • Presence or absence of a bundle concept or a ripper concept
  • Implicit rippers
  • Point rippers
  • Connections across multiple sheets
  • Arrayed instances also called wide instances
  • Frames
  • Pin-to-Pin Connectivity
  • Parameterized designs
  • Properties
  • Illegal names that require mapping out certain characters
  • Connecting two nets with different names
  • Zero-length wires

After a lot of hard labor, we are happy to report that EDIF 2 0 0 does work now. However, it requires a lot of support and there are still a lot of little EDIF 2 0 0 tools that do not work and they generate EDIF files that we constantly need to watch for.

EDIF 3 0 0

EDIF 3 0 0 was released in December 1993 and it has been accepted as EIA/ANSI 618/IEC 1690 international standard. EDIF 3 0 0 covers schematics and connectivity only. EDIF 2 0 0 is not upward compatible with EDIF 3 0 0, so we cannot just enhance existing EDIF 2 0 0 translators, new ones had to be written. EDIF 3 0 0 has addressed and solved most of EDIF 2 0 0 problems in the area of schematics and connectivity. Some of the mechanisms used to achieve this are:

In the EDIF 3 0 0 syntax, use of domain specific constructs for more focused semantics and more explicit keyword structure eliminates context dependency and allow semantic checks to be done automatically by the syntax parser
Generic constructs such as array have been replaced by specific constructs with clarified semantics
Explicit support for bus constructs
Explicit definition of view-wide connectivity called logicalConnectivity
Rippers have been simplified and their use clarified
Specific constructs for special objects such as Page Borders, Title Blocks, on-page connectors
Multiple symbols per interface are fully supported
Better support for aligning lines and symbol pins
EDIF 3 0 0 has eliminated overloading of constructs as much as possible
The instantiation mechanism has been clarified
The concept of a view is now reserved to design-related diagrams
All other diagrams are grouped in a category called templates
Symbolic constants are no longer used
Added previously missing constructs such as frames


Quick and dirty implementations of EDIF 3 0 0 have been heavily discouraged: the language itself is very big and there is a learning curve; a compliance verification process and a set of standard verification tools (syntax and semantics checkers), test suites and test methodology were put in place.

A mapping of an EDA platform to EDIF, Mapping DesignArchitect concepts to EDIF 3 0 0:

  • Components become EDIF cells.
  • Symbols become EDIF schematicSymbols.
  • Interfaces become EDIF clusters.
  • Viewpoints drive the hierarchy traversal and their backannotation data is included in the design construct at the end of the EDIF file.
  • Schematic sheets become EDIF pages.
  • Hierarchical and off-page connectors become EDIF port, global and offPageConnector; they are defined as templates (Example: SchematicGlobalPortImplementation). They appear on sheets as implemention (Example: SchematicGlobalPortImplementation)
  • Rippers: their EDIF definitions appear in EDIF library as schematicRipperTemplate; rippers appear in EDIF pages as SchematicRipperImplementation.
  • Busses: are described in EDIF logicalConnectivity of SchematicViews first as scalar (signal) declarations, then grouped into signalGroup constructs; busses are referenced in EDIF pages from within schematicBus and SchematicSubBus constructs.
  • Bundles: are handled in the same manner as busses. The only difference is in the naming conventions. All relevant name information is collected into a correct by construction nameInformation construct.
  • Nets: are described in EDIF logicalConnectivity of SchematicViews as EDIF signal construct, then in EDIF page as schematicNet constructs, All junctions (solder dots) and terminators (dangling wire ends) are included or synthesized to meet all EDIF 300 rigorous semantic rules; EDIF Schematic subnets are split into subNets as demanded by EDIF300/EDIF400 specification.
  • Instances: in EDIF logicalConnectivity, they appear as EDIF instance constructs. In the EDIF page, they are graphically described in schematicInstanceImplementation constructs which reference previously described schematicSymbol constructs.
  • Arrayed instances: as EDIF logical items, arrayed instances are described by a construct (instance ... (instanceWidth n)); on the EDIF page, a single schematicInstanceImplementation is used to describe the appearance of the arrayed instance on the EDIF page.
  • Frames: are represented using Level 1 EDIF. In EDIF logicalConnectivity Frames are represented by ifFrame, forFrame and otherWiseFrame construct; on EDIF page, frames are represented by schematicForFrameImplementation, schematicIfFrameImplementation and schematicOtherwiseFrameImplementation.
  • Pins: in EDIF symbols, pins are represented as schematicSymbolPortImplementation constructs which reference SchematicSymbolPortTemplate.
  • BusPins: same representation as Pins except that they may have defined a (schematicPortStyle(widePort)) in the corresponding symbolPortTemplate construct.
  • Bundle Pins are handled in the same manner as busPins.
  • Properties: represented as EDIF properties; EDIF properties can be attached optionally to just about any EDIF object; supported values types are boolean, integer, MiNoMax (a triplet), number, point and strings. Expressions are not yet explicitly supported.
  • Graphical annotations and text annotations are represented as EDIF CommentGraphics on Pages and Symbols. CommentGraphics can contain text and several different kinds of figures including circle, arc, rectangle, line, etc.
  • Mentor Graphics has a set of EDIF 3 0 0 tools that work well. They were released in 1994, but for a long time there were very few other commercial EDIF 3 0 0 tools to play with. In 1999, many more EDIF 3 0 0 tools were released. EDIF 3 0 0 is  used in production for exchanging data between ConceptHDL, Design Architect and OrCAD Capture. A non-exhaustive list of EDA Platforms that have EDIF 3 0 0 commercial tools: Mentor Graphics DesignArchitect, Mentor Graphics Viewdraw, Cadence ConceptHDL, Cadence OrCAD Capture, PADS PowerLogic.

EDIF 4 0 0

EDIF 4 0 0 is upward compatible with EDIF 3 0 0, in fact EDIF 4 0 0 = EDIF 3 0 0 + PCB/MCM. As a superset of EDIF 3 0 0, an EDIF 4 0 0 file can contain schematic symbol libraries, schematic hierarchical or flat designs and it can contain the full connectivity of the design. The PCB/MCM extensions covers all aspects of PCB physical libraries of geometries, bare boards, assembled boards, technology rules, drill rules, aperture data, artwork data, PCB drawings, packaged and unpackaged components, various electrical connections to the components. Elgris EDIF 400 Tools for  Mentor Graphics implemented the following EDIF 4 0 0 concepts:

Material definitions
Bare Board technology: EDIF layers represent physical layers only, there are no logical layers. Mentor EDIF 4 0 0 writer attempts to keep logical layer information in the generated EDIF file. An EDIF layer represents real material on the physical board. It can be conducting (power or ground plane, signal layer) or non-conducting (laminate layer, dielectric layer). BoardStation artwork layers are mapped to EDIF layers. As many board designs do not have explicit laminate layers and they are required by EDIF 4 0 0 stack-up, we synthesize them and add them to the stack-up. Note: In EDIF physical ordering is explicit, if the artwork stack-up in BoardStation database looks arbitrary, a default ordering is attempted, if it is not satisfactory a mapping file may be required.
Board outline: EDIF Board outline is more restrictive than BoardStation outline
Representation of power planes and other filled areas
Part definition: electrical and connector
Pin and gate swapping
Sub-layout definitions: bare board, footprints, toe prints
Assembled board: includes electrical and assembled physical nets (including jumpers)
Different mounting methods: tabbing, flip-chip, wire bond, etc.
Drill rules
Design and Manufacturing Rules
Structured component netlist
Functional Netlist
Part function and gate allocation


All Mentor Schematic and Connectivity concepts are easily expressed in EDIF 4 0 0. Most Mentor PCB/MCM concepts are easily expressed in EDIF 4 0 0 with the exception of:

  • The hatch patterns are not easily represented.
  • The panel concept is not present in EDIF 4 0 0.
  • The concept of variants of a board is not present.

The ECCE program has added new concepts to EDIF 4 0 0 in order to facilitate CAD to CAM data transfer. The ECCE extensions have been covered in another paper. Some of these new concepts and new objects in EDIF 4 0 0 allow representation of BoardStation objects that were not easily represented by EDIF 4 0 0: panels and board variants.

EDIF 4 0 0 is available (beta status) on the following platforms:

  • Mentor Graphics, DesignArchitect (production) and BoardStation (beta)
  • Zuken-Redac (visula)
  • Cadence Design Systems (Allegro EDIF 4 0 0 Reader, UNICAD EDIF 4 0 0 writer)
  • Valor (EDIF 4 0 0 to ODB++ by Averstar)
  • Graphicode (EDIF 4 0 0 Reader)
  • Fabmaster (EDIF 4 0 0 Reader)
  • Orbotech (EDIF 4 0 0 Reader)
Making your own EDIF 3 0 0 or EDIF 4 0 0 Tool

Even though the EDIF300/400 language is huge and the learning curve very stiff, it is possible to create, in a fraction of the time and a fraction of the cost, a very good EDIF 3 0 0/4 0 0 tool. The secret is in leveraging the expertise and the know-how of existing independent EDIF technology suppliers. Here is a record of some of the resources available:

1. EDIF Tool Kits

2. Syntax and Semantic Checkers:

  • Elgris Technologies, Inc. (Elgris ) has very accurate  EDIF checkers.
  • University of Manchester has the only officially sanctioned verification tools. Their price is affordable. Some of the tools are free.

3. EDIF Visualization Tools:

  • Elgris Technologies, Inc. has a tool called E-studio Pro. E-studio Pro is very easy to use and very inexpensive. It can visualize EDIF 2 0 0/ EDIF 3 0 0/ EDIF 4 0 0 schematic and Netlist data. It will be extended to cover PCB as well.

Supporting the standard

EDIF Technical Centre

e-mail: edif-support@edif.org

EDIF Tool Custom-development

Elgris Technologies, Inc., Consulting services.


EDIF has reached a point where it is a hard-working standard used everyday around the world to achieve integration, migration or archive of electronic schematic and connectivity data. The ECCE improvements of EDIF 4 0 0 made it into an ideal standard for both CAD-to-CAD and CAD-to-CAM data transfer.

It seems fair to disclose that Elgris Technologies, Inc. is the world biggest supplier of EDIF Tools. Elgris' EDIF Tools are the standard EDIF tools found on the following platforms:

Mentor Graphics (DesignArchitect, Renoir, Tau, Viewdraw)

Cadence Design Systems (ConceptHDL)

EDIF tools for Cadence Capture (OrCAD) and PADS are included in E-studio Pro.


1. "Why EDIF 4 0 0 is Important", John Cofield, Mentor Graphics, in EDIF Newsletter, March 1996.

2. EDIF Version 4 0 0 Tutorial, presented by Prof. Hilary Kahn, Mike Church, Alan Williams, 1996.

3. 13th Annual Conference and Workshop Tutorial Programme, Prof. Hilary Kahn, Mark Lambert, Mike Church, Robin La Fontaine, EDIF World 1996, Monterey, CA.

4. EDIF Version Tutorial, Prof. Hilary Kahn, Olia Labunskaya, Robin La Fontaine, Antoine Bigirimana, San Jose, California, 28-29 July, 1994.


Copyright © 2005, Elgris Technologies, Inc.. All rights reserved.