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. As a result, few software vendors wrote EDIF 2.0.0 output that did not contain violations of the syntax or semantics. The semantics were loose enough that the same data may often be described in multiple ways. This resulted in companies having their own "flavors" of EDIF. The vendor companies often didn't allocate many resources to EDIF products, even if large quantities were sold. Those who did write EDIF translators found they spent large amounts of time and effort 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 ==