EDIF

Last updated

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.

Contents

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 Hilary Kahn, a computer science professor at the University of Manchester, joined the team and led the development from version EDIF 2 0 0 till the final version 4 0 0.

Syntax

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:

(ediffibex(edifVersion200)(edifLevel0)(keywordMap(keywordLevel0))(status(written(timeStamp199511111)(program"xxx"(version"v1"))))(libraryxxx(edifLevel0)(technology(numberDefinition(scale1(e1-6)(unitdistance))))(celldff_4(cellTypegeneric)(viewview1(viewTypenetlist)(interface(portaset(directionINPUT))(portclok(directionINPUT))...(cellyyy(cellTypegeneric)(viewschematic_(viewTypenetlist)(interface(portCLEAR(directionINPUT))(portCLOCK(directionINPUT))...)(contents(instanceI_36_1(viewRefview1(cellRefdff_4)))(instance(renameI_36_3"I$3")(viewRefview1(cellRefaddsub_4)))...(netCLEAR(joined(portRefCLEAR)(portRefaset(instanceRefI_36_1))(portRefaset(instanceRefI_36_3))))...

Versions

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:

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 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

Evolution

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.

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

See also

Related Research Articles

In computer engineering, a hardware description language (HDL) is a specialized computer language used to describe the structure and behavior of electronic circuits, and most commonly, digital logic circuits.

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 verification and static timing analysis.

<span class="mw-page-title-main">Gerber format</span> Standard file format used for designing printed circuit boards

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.

A schematic editor is a tool for schematic capture of electrical circuits or electronic circuits.

<span class="mw-page-title-main">GDSII</span> Database file format for data exchange of integrated circuit layout artwork

GDSII stream format (GDSII), is a binary database file format which is the de facto industry standard for Electronic Design Automation data exchange of integrated circuit or IC layout artwork. It is a binary file format representing planar geometric shapes, text labels, and other information about the layout in hierarchical form. The data can be used to reconstruct all or part of the artwork to be used in sharing layouts, transferring artwork between different tools, or creating photomasks.

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 application-specific integrated circuits (ASIC) and systems of field-programmable gate array (FPGA) logic can use IP cores as building blocks.

<span class="mw-page-title-main">Standard cell</span>

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.

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.

<span class="mw-page-title-main">XCircuit</span> Electrical circuit design software

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.

gEDA

The term gEDA refers to two things:

  1. A set of software applications used for electronic design released under the GPL. As such, gEDA is an ECAD or EDA application suite. gEDA is mostly oriented towards printed circuit board design. The gEDA applications are often referred to collectively as "the gEDA Suite".
  2. The collaboration of free software/open-source developers who work to develop and maintain the gEDA toolkit. The developers communicate via gEDA mailing lists, and have participated in the annual "Google Summer of Code" event as a single project. This collaboration is often referred to as "the gEDA Project".

An EDA database is a database specialized for the purpose of electronic design automation. These application specific databases are required because general purpose databases have historically not provided enough performance for EDA applications.

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.

<span class="mw-page-title-main">Quite Universal Circuit Simulator</span>

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.

<span class="mw-page-title-main">Icarus Verilog</span>

Icarus Verilog is an implementation of the Verilog hardware description language compiler that generates netlists in the desired format (EDIF). 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 that provides software and hardware used in creation and verification of digital designs targeting FPGA and ASIC technologies.

<span class="mw-page-title-main">ODB++</span> Proprietary CAD-to-CAM data exchange format

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.

<span class="mw-page-title-main">Pulsonix</span>

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 EDA tool suite that enables hardware engineers to design, simulate, share - publicly and privately - and discuss schematics, simulations and printed circuit boards. Other features include the creation of a bill of materials, Gerber files and pick and place files and documentary outputs in PDF, PNG and SVG formats.