EDIF

EDIF ( Electronic Design Interchange Format ) är ett leverantörsneutralt format baserat på S-Expressions för att lagra elektroniska nätlistor och scheman. Det var ett av de första försöken att etablera ett neutralt datautbyteformat för industrin för elektronisk designautomation ( EDA). Målet var att etablera ett gemensamt format från vilket EDA-systemens egenutvecklade format kunde härledas. När kunder behövde överföra data från ett system till ett annat var det nödvändigt att skriva översättare från ett format till ett annat. När antalet format ( N ) multiplicerades, blev översättarfrågan ett N -kvadratproblem. Förväntningen var att med EDIF skulle antalet översättare kunna reduceras till antalet involverade system.

Representanter för EDA-företagen Daisy Systems , Mentor Graphics , Motorola , National Semiconductor , Tektronix , Texas Instruments och University of California, Berkeley inrättade EDIF Steering Committee i november 1983. Senare Hilary Kahn , professor i datavetenskap vid University of Manchester , gick med i teamet och ledde utvecklingen från version EDIF 2 0 0 till den slutliga versionen 4 0 0.

Syntax

Det allmänna formatet för EDIF innebär att man använder parenteser för att avgränsa datadefinitioner, och på så sätt påminner det ytligt om Lisp . De grundläggande symbolerna för EDIF 2.0.0 var nyckelord (som bibliotek , cell , instans , etc.), strängar (avgränsade med dubbla citattecken), heltal, symboliska konstanter (t.ex. GENERIC , TIE , RIPPER för celltyper) och "Identifiers" , som är referensetiketter bildade av en mycket begränsad uppsättning tecken. EDIF 3.0.0 och 4.0.0 släppte de symboliska konstanterna helt, och använde istället nyckelord. Så syntaxen för EDIF har en ganska enkel grund. En typisk EDIF-fil ser ut så här: 

     0 0
   0   0
              
     0
            
       
         
        
             
             
    
       
         
        
             
               
        
                
                  
           
            
             
                
                    
                    
     (  edif  fibex  (  edifVersion  2  )  (  edifLevel  )  (  keywordMap  (  keywordLevel  ))  (  status  (  skriven  (  timeStamp  1995  1  1  1  1  1  )  (  programmet  "xxx"  (  version  "v1"  )))  (  bibliotek  xxx  (  edifLevel  )  (  teknologi  (  numberDefinition  (  skala  1  (  e  1  -6  )  (  enhetsavstånd  )  )))  (  cell  dff_4  (  cellType  generic  )  (  view  view1  (  viewType  netlist  )  (  gränssnitt  (  port  aset  (  riktning  INPUT  )  )  (  portklocka  (  riktning  INPUT  ) )  ...  (  cell  yyy  (  cellType  generic  )  (  visa  schematic_  (  viewType  netlist  )  (  gränssnitt  (  port  CLEAR  (  riktning  INPUT  ))  (  port  CLOCK  (  riktning  INPUT  ))  ...  )  (  innehåll  (  instans  I_36_1  (  viewRef  view1  (  cellRef )   dff_4  )))  (  instans  (  byt namn på  I_36_3  "I$3"  )  (  viewRef  view1  (  cellRef  addsub_4  )))  ...  (  net  CLEAR  (  joined  (  portRef  CLEAR  )  (  portRef  aset  (  instanceRef  I_36_1  ))  (  portRef  aset  (  instans_3  )  I_36  )))  ...

versioner

1 0 0-utgåvan av EDIF gjordes 1985.

EDIF 2 0 0

Den första "riktiga" offentliga utgåvan av EDIF var version 2 0 0, som godkändes i mars 1988 som standarden ANSI/EIA-548-1988. Den ges ut i en enda volym. Den här versionen har ingen formell omfattningsförklaring men det den försöker fånga täcks av de definierade viewType :erna:

  • BETEENDE för att beskriva en cells beteende
  • DOKUMENT för att beskriva dokumentationen för en cell
  • GRAFIK för att beskriva en dum grafik och textrepresentation av visningsbar eller utskrivbar information
  • LOGIKMODEL för att beskriva cellens logiksimuleringsmodell
  • MASKLAYOUT för att beskriva en integrerad kretslayout
  • NETLIST för att beskriva en nätlista
  • PCBLAYOUT för att beskriva ett kretskort
  • SCHEMATISK för att beskriva den schematiska representationen och anslutningen av en cell
  • STRANGER för att beskriva en ännu okänd representation av en cell
  • SYMBOLISK för att beskriva en symbolisk layout

Branschen testade den här utgåvan i flera år, men slutligen var det bara NETLIST-vyn som användes i stor utsträckning och vissa EDA-verktyg stöder den fortfarande idag för EDIF 2 0 0.

För att övervinna problem med den huvudsakliga 2 0 0-standarden släpptes flera ytterligare dokument:

  • Electronic Industries Association
    • EDIF Monograph Series, Volym 1, Introduktion till EDIF , EIA/EDIF-1, sept. 1988
    • EDIF Monograph Series, Volym 2, EDIF Connectivity , EIA/EDIF-2, juni 1989
    • Använder EDIF 2 0 0 för schematisk överföring , EIA/EDIF/AG-1, juli 1989
  • Dokumentation från Hilary J. Kahn, Institutionen för datavetenskap, University of Manchester
    • EDIF 2 0 0, An Introductory Tutorial , september 1989
    • EDIF Frågor och svar, volym ett, november 1988
    • EDIF Frågor och svar, volym två, februari 1989
    • EDIF Frågor och svar, volym tre, juli 1989
    • EDIF Frågor och svar, volym fyra, november 1989
    • EDIF Frågor och svar, volym fem, juni 1991

EDIF 3 0 0

På grund av några grundläggande svagheter i 2 0 0-utgåvan släpptes en ny icke-kompatibel utgåva 3 0 0 i september 1993, givet utnämningen av EIA -standarden EIA-618. Den uppnådde senare ANSI- och ISO- beteckningar. Den ges ut i 4 volymer. Huvudfokus för den här versionen var viewTypes NETLIST och SCHEMATIC från 2 0 0. MASKLAYOUT, PCBLAYOUT och några andra vyer togs bort från den här utgåvan och flyttades till senare utgåvor eftersom arbetet för dessa vyer inte var helt slutfört.

EDIF 3 0 0 är tillgänglig från International Electrotechnical Commission som IEC 61690-1

EDIF 4 0 0

EDIF 4 0 0 släpptes i slutet av augusti 1996, främst för att lägga till "Printed Circuit Board"-tillägg (den ursprungliga PCBLAYOUT-vyn) till EDIF 3 0 0. Detta mer än fördubblade storleken på EDIF 3 0 0 och publiceras i HTML-format på CD.

EDIF 4 0 0 är tillgänglig från International Electrotechnical Commission som IEC 61690-2

Evolution

Problem med 2 0 0

För att förstå de problem som användare och leverantörer stöter på med EDIF 2 0 0 måste man först föreställa sig alla element och dynamik inom elektronikindustrin. De människor som behövde denna standard var främst designingenjörer, som arbetade för företag vars storlek sträckte sig från ett husgarage till anläggningar för flera miljarder dollar med tusentals ingenjörer. Dessa ingenjörer arbetade huvudsakligen från scheman och nätlistor i slutet av 1980-talet, och det stora trycket var att generera nätlistorna från schemat automatiskt. De första leverantörerna var Electronic Design Automation-leverantörer (t.ex. Daisy, Mentor och Valid utgjorde den tidigaste dominerande uppsättningen). Dessa företag konkurrerade hårt om sina andelar av denna marknad.

En av de taktiker som dessa företag använde för att "fånga" sina kunder var deras egenutvecklade databaser. Var och en hade speciella egenskaper som de andra inte hade. När ett beslut togs att använda en viss leverantörs programvara för att ange en design, var kunden någonsin tvungen att inte använda någon annan programvara. Att gå från leverantör A:s till leverantör B:s system innebar vanligtvis ett mycket dyrt återinförande av nästan all designdata för hand i det nya systemet. Denna utgift för "migrering" var huvudfaktorn som låste designingenjörer till att använda en enda leverantör.

Men "kunderna" hade ett annat önskemål. De såg direkt att även om leverantör A kan ha en riktigt trevlig analog simuleringsmiljö, så hade leverantör B en mycket bättre PCB- eller kisellayout-autorouter. Och de önskade att de kunde välja och vraka bland de olika försäljarna.

EDIF stöddes främst av slutanvändarna inom elektronikdesign och deras företag. EDA-försäljarna var också inblandade, men deras motivation var mer i linje med att de ville inte alienera sina kunder. De flesta av EDA-leverantörerna producerade EDIF 2 0 0-översättare, men de var definitivt mer intresserade av att skapa högkvalitativa EDIF-läsare, och de hade absolut ingen motivation alls att skriva någon programvara som genererade EDIF (en EDIF Writer), bortom hot från kunder av massmigrering till en annan leverantörs programvara.

Resultatet var ganska intressant. Knappast någon mjukvaruleverantör skrev EDIF 2 0 0-utdata som inte hade allvarliga kränkningar av syntax eller semantik. Semantiken var precis tillräckligt lös för att det kunde finnas flera sätt att beskriva samma data. Detta började bli känt som "smaker" av EDIF. Säljarföretagen ansåg inte alltid att det var viktigt att lägga mycket resurser på EDIF-produkter, även om de sålde ett stort antal av dem. Det fanns flera historier om aktiva produkter med praktiskt taget ingen som kunde underhålla dem på flera år. Användarklagomål samlades bara in och prioriterades. Ju svårare det blev att exportera kunddata till EDIF, desto mer verkade leverantörerna gilla det. De som skrev EDIF-översättare fann att de spenderade en enorm mängd tid och ansträngning på att skapa tillräckligt kraftfulla, förlåtande, artificiellt intelligenta läsare, som kunde hantera och sätta ihop den dåliga koden som producerades av dagens EDIF 2 0 0-skribenter. .

Vid utformningen av EDIF 3 0 0 var kommittéerna väl medvetna om språkets fel, det förtal som EDIF 2 0 0 lades på av försäljarna och slutanvändarnas frustration. Så för att skärpa språkets semantik och ge en mer formell beskrivning av standarden, togs det revolutionära tillvägagångssättet för att tillhandahålla en informationsmodell för EDIF, på informationsmodelleringsspråket EXPRESS . Detta bidrog till att bättre dokumentera standarden, men gjordes mer som en eftertanke, eftersom syntaxarbetet gjordes oberoende av modellen, istället för att genereras från modellen. Även om standarden säger att om syntaxen och modellen inte överensstämmer är modellen standarden, så är det inte fallet i praktiken. BNF - beskrivningen av syntaxen är grunden för språket eftersom programvaran som gör det dagliga arbetet med att ta fram designbeskrivningar är baserad på en fast syntax. Informationsmodellen led också av att den inte var (och inte är) idealisk för att beskriva EDIF. Den beskriver inte alls sådana begrepp som namnutrymmen särskilt bra, och skillnaderna mellan en definition och en referens är inte heller tydligt beskrivbara. Dessutom kan konstruktionerna i EXPRESS för att beskriva begränsningar vara formella, men beskrivning av begränsningar är ibland en ganska komplicerad fråga. Så de flesta begränsningar slutade med att bara beskrivas som kommentarer. De flesta av de andra blev utarbetade formella beskrivningar som de flesta läsare aldrig kommer att kunna tyda och därför kanske inte står upp mot automatiserad felsökning/kompilering, precis som ett program kan se bra ut i granskning, men en kompilator kan hitta några intressanta fel, och Att faktiskt köra det skrivna programmet kan hitta ännu mer intressanta fel. (Dessutom existerade inte analoga EXPRESS-kompilatorer/exekutorer när standarden skrevs och kanske inte existerar än idag!)

Lösningar på EDIF 2 0 0 problem

Lösningen på "smak"-problemet med EDIF 2 0 0 var att utveckla en mer specifik semantisk beskrivning i EDIF 3 0 0 (1993). Faktum är att rapporterade resultat från personer som genererade EDIF 3 0 0-översättare var att skribenterna nu var mycket svårare att få rätt på grund av det stora antalet semantiska begränsningar, och att läsarna är jämförelsevis triviala att utveckla.

Lösningen på leverantörens "intressekonflikt" var neutrala tredjepartsföretag, som kunde tillhandahålla EDIF-produkter baserade på leverantörsgränssnitt. Denna separation av EDIF-produkterna från direkt leverantörskontroll var avgörande för att förse slutanvändargemenskapen med verktyg som fungerade bra. Det bildades naturligt och utan kommentarer. Engineering DataXpress var kanske det första sådana företaget i denna värld, med Electronic Tools Company som verkade ha erövrat marknaden i mitten till slutet av 1990-talet. En annan dynamik i denna bransch är EDIF själv. Eftersom de har vuxit till en ganska stor storlek, har generering av läsare och skribenter blivit ett mycket dyrt förslag. Vanligtvis har tredjepartsföretagen samlat de nödvändiga specialisterna och kan använda denna expertis för att mer effektivt generera programvaran. De kan också utnyttja koddelning och andra tekniker som en enskild leverantör inte kunde. År 2000 tillverkade nästan ingen större leverantör sina egna EDIF-verktyg, utan valde istället att OEM -verktyg från tredje part.

Sedan utgivningen av EDIF 4 0 0 har hela EDIFs standardiseringsorganisation i princip upplösts. Det har inte hållits några publicerade möten för någon av de tekniska underkommittéerna, EDIF:s expertgrupp etc. De flesta av de inblandade personerna har gått vidare till andra företag eller insatser. Nyhetsbrevet övergavs och Användargruppen håller inte längre årliga möten. EDIF 3 0 0 och 4 0 0 är nu ANSI , IEC och europeiska (EN) standarder. EDIF version 3 0 0 är IEC/EN 61690-1 och EDIF version 4 0 0 är IEC/EN 61690-2.

EDIF ättlingar

  • LKSoft tog stora koncept från EDIF 2 0 0 för att skapa ett proprietärt dataformat med standardtillägget ".cam" för deras CircuitCAM-system som ursprungligen erbjöds av LPKF Laser & Electronics AG i Garbsen/Hannover, Tyskland och idag ägs av DCT Co., Ltd. i Tianjn, Kina. För att effektivt arbeta med EDIF-liknande format har LKSoft utvecklat EDIF Procedural Interface , ett API för programmeringsspråket C.
  • Zuken , tidigare Racal-Redac Ltd., tog koncept från den tidiga utvecklingen av EDIF 4 0 0 för att skapa ett nytt proprietärt format som heter CADIF för deras Visula PCB-CAD-system. Detta format används också i stor utsträckning av tredjepartsleverantörer.
  • STEP-AP210, en del av ISO 10303 , ärvde praktiskt taget all EDIF 4 0 0-funktionalitet förutom scheman.

externa länkar

Hämtad från " https://en.wikipedia.org/w/index.php?title=EDIF&oldid=1128776598 "