EDIF
Overview
Introduction
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.
Services
Supporting
the standard
EDIF
Technical Centre
e-mail:
edif-support@edif.org
EDIF
Tool Custom-development
Elgris Technologies, Inc., Consulting services.
Conclusion
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.
References
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.
|