EDIF (Electronic Design Interchange Format) is a vendor-neutral format based on S-expressions 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.
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:
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:
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 2 9 0
Released on 15 September 1992.
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 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
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.
EDIF was mainly supported by the electronics design end-users, and their companies. The EDA vendors were involved also, but their motivation was more along the lines of wanting to not alienate their customers. Most of the EDA vendors produced EDIF 2 0 0 translators, but they were definitely more interested in generating high-quality EDIF readers, and they had absolutely no motivation at all to write any software that generated EDIF (an EDIF Writer), beyond threats from customers of mass migration to another vendor's software.
The result was rather interesting. Hardly any software vendor wrote EDIF 2 0 0 output that did not have severe violations of syntax or semantics. The semantics were just loose enough that there might be several ways to describe the same data. This began to be known as "flavors" of EDIF. The vendor companies did not always feel it important to allocate many resources to EDIF products, even if they sold a large number of them. There were several stories of active products with virtually no-one to maintain them for years. User complaints were merely gathered and prioritized. The harder it became to export customer data to EDIF, the more the vendors seemed to like it. Those who did write EDIF translators found they spent a huge amount of time and effort on generating sufficiently powerful, forgiving, artificially intelligent readers, that could handle and piece together the poor-quality code produced by the extant EDIF 2 0 0 writers of the day.
In designing EDIF 3 0 0, the committees were well aware of the faults of the language, the calumny heaped on EDIF 2 0 0 by the vendors and the frustration of the end users. So, to tighten the semantics of the language, and provide a more formal description of the standard, the revolutionary approach was taken to provide an information model for EDIF, in the information modeling language EXPRESS. This helped to better document the standard, but was done more as an afterthought, as the syntax crafting was done independently of the model, instead of being generated from the model. Also, even though the standard says that if the syntax and model disagree, the model is the standard, this is not the case in practice. The BNF description of the syntax is the foundation of the language inasmuch as the software that does the day-to-day work of producing design descriptions is based on a fixed syntax. The information model also suffered from the fact that it was not (and is not) ideally suited to describing EDIF. It does not describe such concepts as name spaces very well at all, and the differences between a definition and a reference is not clearly describable either. Also, the constructs in EXPRESS for describing constraints might be formal, but constraint description is a fairly complicated matter at times. So, most constraints ended up just being described as comments. Most of the others became elaborate formal descriptions which most readers will never be able to decipher, and therefore may not stand up to automated debugging/compiling, just as a program might look good in review, but a compiler might find some interesting errors, and actually running the program written might find even more interesting errors. (Additionally, analogous EXPRESS compilers/executors didn't exist when the standard was written, and may not still exist today!)
Solutions to EDIF 2 0 0 problems
The solution to the "flavor" problem of EDIF 2 0 0 was to develop a more specific semantic description in EDIF 3 0 0 (1993). Indeed, reported results of people generating EDIF 3 0 0 translators was that the writers were now much more difficult to get right, due to the great number of semantic restrictions, and the readers are comparatively trivial to develop.
The solution to vendor "conflict of interest" was neutral third-party companies, who could provide EDIF products based on vendor interfaces. This separation of the EDIF products from direct vendor control was critical to providing the end-user community with tools that worked well. It formed naturally and without comment. Engineering DataXpress was perhaps the first such company in this realm, with Electronic Tools Company seeming to have captured the market in the mid to late 1990s. Another dynamic in this industry is EDIF itself. Since they have grown to a rather large size, generating readers and writers has become a very expensive proposition. Usually the third-party companies have congregated the necessary specialists and can use this expertise to more efficiently generate the software. They are also able to leverage code sharing and other techniques an individual vendor could not. By 2000, almost no major vendor produced its own EDIF tools, choosing instead to OEM third-party tools.
Since the release of EDIF 4 0 0, the entire EDIF standards organisation has essentially dissolved. There have been no published meetings of any of the technical subcommittees, the EDIF Experts group, etc. Most of the individuals involved have moved on to other companies or efforts. The newsletter was abandoned, and the Users' Group no longer holds yearly meetings. EDIF 3 0 0 and 4 0 0 are now ANSI, IEC and European (EN) standards. EDIF Version 3 0 0 is IEC/EN 61690-1, and EDIF Version 4 0 0 is IEC/EN 61690-2.
EDIF descendants
LKSoft took major concepts from EDIF 2 0 0 to create a proprietary data format with the default extension ".cam" for their CircuitCAM system offered originally by LPKF Laser & Electronics AG in Garbsen/Hannover, Germany and today owned by DCT Co., Ltd. in Tianjn, China. To efficiently work on EDIF like formats LKSoft has developed the EDIF Procedural Interface, an API for the C programming language.
Zuken, formerly Racal-Redac Ltd., took concepts from the early EDIF 4 0 0 development to create a new proprietary format called CADIF for their Visula PCB-CAD system. This format is also widely used by 3rd party vendors.
STEP-AP210, a part of ISO 10303, practically inherited all of the EDIF 4 0 0 functionality except for schematics.
See also
STEP (file format)– A widely used CAD 3D data exchange file formatPages displaying short descriptions of redirect targets
Gerber format– Standard file format used for designing printed circuit boards
BYU EDIF ToolsArchived 2006-12-05 at the Wayback Machine A Java framework for parsing/manipulating EDIF files, developed and maintained by BYU's Configurable Computing Lab
Torc Open-source C++ API for reconfigurable computing, including parsing and manipulation of EDIF 2 0 0, from ISI's Reconfigurable Computing Group
In computer engineering, a hardware description language (HDL) is a specialized computer language used to describe the structure and behavior of electronic circuits, usually to design application-specific integrated circuits (ASICs) and to program field-programmable gate arrays (FPGAs).
Electronic design automation (EDA), also referred to as electronic computer-aided design (ECAD), is a category of software tools for designing electronic systems such as integrated circuits and printed circuit boards. The tools work together in a design flow that chip designers use to design and analyze entire semiconductor chips. Since a modern semiconductor chip can have billions of components, EDA tools are essential for their design; this article in particular describes EDA specifically with respect to integrated circuits (ICs).
Standard Delay Format (SDF) is an IEEE standard for the representation and interpretation of timing data for use at any stage of an electronic design process. It finds wide applicability in design flows, and forms an efficient bridge between dynamic timing analysis and static timing analysis.
The Gerber format is an open, ASCII, vector format for printed circuit board (PCB) designs. It is the de facto standard used by PCB industry software to describe the printed circuit board images: copper layers, solder mask, legend, drill data, etc. The standard file extension is .GBR or .gbr though other extensions like .GB, .geb or .gerber are also used. It is documented by The Gerber Layer Format Specification and some related extensions such as XNC drill files and GerberJob to convey information about the entire PCB, as opposed to single layers.
A schematic editor is a tool for schematic capture of electrical circuits or electronic circuits.
Place and route is a stage in the design of printed circuit boards, integrated circuits, and field-programmable gate arrays. As implied by the name, it is composed of two steps, placement and routing. The first step, placement, involves deciding where to place all electronic components, circuitry, and logic elements in a generally limited amount of space. This is followed by routing, which decides the exact design of all the wires needed to connect the placed components. This step must implement all the desired connections while following the rules and limitations of the manufacturing process.
In electronic design, a semiconductor intellectual property core, IP core or IP block is a reusable unit of logic, cell, or integrated circuit layout design that is the intellectual property of one party. IP cores can be licensed to another party or owned and used by a single party. The term comes from the licensing of the patent or source code copyright that exists in the design. Designers of system on chip (SoC), application-specific integrated circuits (ASIC) and systems of field-programmable gate array (FPGA) logic can use IP cores as building blocks.
In semiconductor design, standard-cell methodology is a method of designing application-specific integrated circuits (ASICs) with mostly digital-logic features. Standard-cell methodology is an example of design abstraction, whereby a low-level very-large-scale integration (VLSI) layout is encapsulated into an abstract logic representation.
OrCAD Systems Corporation was a software company that made OrCAD, a proprietary software tool suite used primarily for electronic design automation (EDA). The software is used mainly by electronic design engineers and electronic technicians to create electronic schematics, and perform mixed-signal simulation and electronic prints for manufacturing printed circuit boards (PCBs). OrCAD was taken over by Cadence Design Systems in 1999 and was integrated with Cadence Allegro in 2005.
Input/output Buffer Information Specification (IBIS) is a specification of a method for integrated circuit vendors to provide information about the input/output buffers of their product to their prospective customers without revealing the intellectual property of their implementation and without requiring proprietary encryption keys. From version 5.0, specification contains two separate types of models, "traditional IBIS" and "IBIS-AMI." The traditional model is generated in text format and consists of a number of tables that captures current vs. voltage (IV) and voltage vs. time (Vt) characteristics of the buffer, as well as the values of certain parasitic components. It is a standard data exchange format for exchanging modeling information among semiconductor device suppliers, simulation software suppliers, and end users.
XCircuit is a schematic capture program for drawing publication-quality VLSI electrical circuit schematic diagrams and related figures. It's part of the Open Circuit Design tools. It's primarily intended for ULSI/VLSI IC design and not for PCB design, the latter though is still possible. XCircuit regards circuits as inherently hierarchical and can save circuits both in PostScript (.ps) and Ngspice (.cir) netlists file formats for further processing. The program compiles PostScript files from special template-labels specified by user.
The layout versus schematic (LVS) is the class of electronic design automation (EDA) verification software that determines whether a particular integrated circuit layout corresponds to the original schematic or circuit diagram of the design.
Quite Universal Circuit Simulator (Qucs) is a free-software electronics circuit simulator software application released under GPL. It offers the ability to set up a circuit with a graphical user interface and simulate the large-signal, small-signal and noise behaviour of the circuit. Pure digital simulations are also supported using VHDL and/or Verilog. Only a small set of digital devices like flip flops and logic gates can be used with analog circuits. Qucs uses its own SPICE-incompatible backend simulator Qucsator, however the Qucs-S fork supports some SPICE backends.
Icarus Verilog is an implementation of the Verilog hardware description language compiler that generates netlists in the desired format (EDIF) and a simulator. It supports the 1995, 2001 and 2005 versions of the standard, portions of SystemVerilog, and some extensions.
Aldec, Inc. is a privately owned electronic design automation company based in Henderson, Nevada, providing software and hardware used in creation and verification of digital designs targeting FPGA and ASIC technologies.
LTspice is a SPICE-based analog electronic circuit simulator computer software, produced by semiconductor manufacturer Analog Devices. It is the most widely distributed and used SPICE software in the industry. Though it is freeware, it is not artificially restricted to limit its abilities. It ships with a library of SPICE models from Analog Devices, Linear Technology, Maxim Integrated, and third-party sources.
DipTrace is a proprietary software suite for electronic design automation (EDA) used for electronic schematic capture and printed circuit board layouts. DipTrace has four applications: schematic editor, PCB editor with built-in shape-based autorouter and 3D preview, component editor, and pattern editor.
ODB++ is a proprietary CAD-to-CAM data exchange format used in the design and manufacture of electronic devices. Its purpose is to exchange printed circuit board design information between design and manufacturing and between design tools from different EDA/ECAD vendors. It was originally developed by Valor Computerized Systems, Ltd. as the job description format for their CAM system.
Pulsonix is an electronic design automation (EDA) software suite for schematic capture and PCB design. It is produced by WestDev, which is headquartered in Gloucestershire, England, with additional sales and distribution offices overseas. It was first released in 2001, and runs on Windows.
EasyEDA is a web-based electronic design automation (EDA) tool suite that enables hardware engineers to design, simulate, share and discuss schematics, simulations and printed circuit boards, and to create a bill of materials, Gerber files, pick and place files and documentary outputs in the file formats PDF, PNG, and SVG.
This page is based on this Wikipedia article Text is available under the CC BY-SA 4.0 license; additional terms may apply. Images, videos and audio are available under their respective licenses.
