EDIF

EDIF (Electronic Design Interchange Format) é um formato neutro de fornecedor baseado em S-Expressions para armazenar netlists e esquemas eletrônicos. Foi uma das primeiras tentativas de estabelecer um formato neutro de troca de dados para a indústria de automação de design eletrônico (EDA). O objetivo era estabelecer um formato comum a partir do qual os formatos proprietários dos sistemas EDA pudessem ser derivados. Quando os clientes precisavam transferir dados de um sistema para outro, era necessário escrever tradutores de um formato para outro. À medida que o número de formatos (N) se multiplicou, o problema do tradutor tornou-se um problema de N quadrados. A expectativa era que com o EDIF o número de tradutores pudesse ser reduzido ao número de sistemas envolvidos.

Representantes das empresas EDA Daisy Systems, Mentor Graphics, Motorola, National Semiconductor, Tektronix, Texas Instruments e da Universidade da Califórnia, Berkeley estabeleceram o EDIF Steering Committee em novembro de 1983. Mais tarde, Hilary Kahn, um professor de ciência da computação na Universidade de Manchester, juntou-se à equipe e liderou o desenvolvimento da versão EDIF 2 0 0 até a versão final 4 0 0.

Sintaxe

O formato geral do EDIF envolve o uso de parênteses para delimitar as definições de dados e, dessa forma, assemelha-se superficialmente ao Lisp. Os tokens básicos do EDIF 2.0.0 eram palavras-chave (como biblioteca, célula, instância etc.), strings (delimitadas por aspas duplas), números inteiros, constantes simbólicas (por exemplo, GENERIC, TIE, RIPPER para tipos de células) e "Identificadores", que são rótulos de referência formados por um conjunto muito restrito de caracteres. EDIF 3.0.0 e 4.0.0 descartaram totalmente as constantes simbólicas, usando palavras-chave. Portanto, a sintaxe do EDIF tem uma base bastante simples. Um arquivo EDIF típico se parece com isso:

(edif Fibex (edifVersão 2 0 0) (Edifícil 0) (palavra-chave (palavra-chave Nível 0) (status (escrito por escrito (Tempo padrão 1995 1 1 1 1 1) (programa "xxx" (versão "v1")) (biblioteca ? (Edifícil 0) (tecnologia (númeroDefinição (escala 1 (e 1 - 6) (unidade distância)) (célula Dff_4 (célula Tipo genérico) (vista Ver pontos de vista (vista Tipo Lista de produtos) (interface (porto aset (Direcção INP) (porto Manteiga (Direcção INP) ... (célula Sim. (célula Tipo genérico) (vista Schematic_ (vista Tipo Lista de produtos) (interface (porto CURSO (Direcção INP) (porto CLORO (Direcção INP) ... ) (conteúdo (instância I-36_1 (VisualizaçãoRef Ver pontos de vista (célula Refiro-me Dff_4) (instância (renomear I-36_3 "I$3") (VisualizaçãoRef Ver pontos de vista (célula Refiro-me Adicionar ao cesto) ... (Rede líquida CURSO (se juntar (portRef CURSO) (portRef aset (instância Refiro-me I-36_1) (portRef aset (instância Refiro-me I-36_3)) ...

Versões

A versão 1 0 0 do EDIF foi feita em 1985.

EDIF 2 0 0

O primeiro "real" O lançamento público do EDIF foi a versão 2 0 0, que foi aprovada em março de 1988 como o padrão ANSI/EIA-548-1988. É publicado em um único volume. Esta versão não possui uma declaração de escopo formal, mas o que ela tenta capturar é coberto pelos viewTypes definidos:

• BEHAVIOR para descrever o comportamento de uma célula
• DOCUMENTO para descrever a documentação de uma célula
• GRAPHIC para descrever um burro representação gráfica e de texto de informações visíveis ou imprimíveis
• LOGICMODEL para descrever o modelo de simulação lógica da célula
• MASKLAYOUT para descrever um layout de circuito integrado
• NETLIST para descrever uma lista de redes
• PCBLAYOUT para descrever uma placa de circuito impresso
• SCHEMATIC para descrever a representação e conectividade esquemática de uma célula
• STRANGER para descrever uma representação ainda desconhecida de uma célula
• SYMBOLIC para descrever um layout simbólico

A indústria testou esta versão por vários anos, mas finalmente apenas a visualização NETLIST foi amplamente usada e algumas ferramentas EDA ainda a suportam hoje para EDIF 2 0 0.

Para superar problemas com o padrão 2 0 0 principal, vários outros documentos foram lançados:

• Associação de Indústrias Eletrônicas
  • Série Monograph EDIF, Volume 1, Introdução ao EDIF, EIA/EDIF-1, Sept. 1988
  • Série de Monogramas EDIF, Volume 2, Conectividade EDIF, EIA/EDIF-2, Junho de 1989
  • Usando EDIF 2 0 0 para transferência esquemática, EIA/EDIF/AG-1, Julho 1989
• Documentação de Hilary J. Kahn, Departamento de Ciência da Computação, Universidade de Manchester
  • EDIF 2 0 0 0, Um Tutorial Introdutório, Setembro de 1989
  • EDIF Perguntas e respostas, volume um, Novembro de 1988
  • EDIF Perguntas e respostas, volume dois, Fevereiro de 1989
  • EDIF Perguntas e respostas, volume três, Julho de 1989
  • EDIF Perguntas e respostas, volume quatro, Novembro de 1989
  • EDIF Perguntas e respostas, volume cinco, Junho de 1991

EDIF 3 0 0

Devido a algumas falhas fundamentais na versão 2 0 0, uma nova versão não compatível 3 0 0 foi lançada em setembro de 1993, dada a designação do padrão EIA EIA-618. Posteriormente, obteve as designações ANSI e ISO. É publicado em 4 volumes. O foco principal desta versão foram os viewTypes NETLIST e SCHEMATIC de 2 0 0. MASKLAYOUT, PCBLAYOUT e algumas outras visualizações foram retiradas desta versão e alteradas para versões posteriores porque o trabalho para essas visualizações não foi totalmente concluído.

EDIF 3 0 0 está disponível na Comissão Eletrotécnica Internacional como IEC 61690-1

EDIF 4 0 0

EDIF 4 0 0 foi lançado no final de agosto de 1996, principalmente para adicionar "Placa de circuito impresso" extensões (a exibição PCBLAYOUT original) para EDIF 3 0 0. Isso mais que dobrou o tamanho de EDIF 3 0 0 e é publicado em formato HTML em CD.

EDIF 4 0 0 está disponível na Comissão Eletrotécnica Internacional como IEC 61690-2

Evolução

Problemas com 2 0 0

Para entender os problemas que os usuários e fornecedores encontram com o EDIF 2 0 0, primeiro é preciso imaginar todos os elementos e a dinâmica da indústria eletrônica. As pessoas que precisavam desse padrão eram principalmente engenheiros de projeto, que trabalhavam para empresas cujo tamanho variava de uma garagem residencial a instalações multibilionárias com milhares de engenheiros. Esses engenheiros trabalharam principalmente com esquemas e netlists no final dos anos 1980, e o grande impulso foi gerar automaticamente as netlists a partir dos esquemas. Os primeiros fornecedores foram fornecedores de Electronic Design Automation (por exemplo, Daisy, Mentor e Valid formaram o primeiro conjunto predominante). Essas empresas competiram vigorosamente por suas participações nesse mercado.

Uma das táticas usadas por essas empresas para "capturar" seus clientes eram seus bancos de dados proprietários. Cada um tinha características especiais que os outros não tinham. Uma vez tomada a decisão de usar o software de um determinado fornecedor para inserir um projeto, o cliente sempre foi obrigado a não usar nenhum outro software. Mudar dos sistemas do fornecedor A para o fornecedor B geralmente significava uma reentrada muito cara de quase todos os dados de projeto manualmente no novo sistema. Essa despesa de "migração" foi o principal fator que impediu os engenheiros de projeto de usar um único fornecedor.

Mas os "clientes" tinha um desejo diferente. Eles viram imediatamente que, embora o fornecedor A pudesse ter um ambiente de simulação analógica muito bom, o fornecedor B tinha um PCB ou roteador automático de layout de silício muito melhor. E eles gostariam de poder escolher entre os diferentes fornecedores.

EDIF foi apoiado principalmente pelos usuários finais de design eletrônico e suas empresas. Os fornecedores de EDA também estavam envolvidos, mas sua motivação era mais na linha de querer não alienar seus clientes. A maioria dos fornecedores de EDA produziu tradutores EDIF 2 0 0, mas eles estavam definitivamente mais interessados em gerar leitores EDIF de alta qualidade e não tinham absolutamente nenhuma motivação para escrever qualquer software que gerasse EDIF (um EDIF Writer), além de ameaças de clientes de migração em massa para software de outro fornecedor.

O resultado foi bastante interessante. Dificilmente algum fornecedor de software escreveu uma saída EDIF 2 0 0 que não tivesse graves violações de sintaxe ou semântica. A semântica era vaga o suficiente para que houvesse várias maneiras de descrever os mesmos dados. Isso começou a ser conhecido como "sabores" do EDIF. As empresas fornecedoras nem sempre consideraram importante alocar muitos recursos aos produtos EDIF, mesmo que vendessem um grande número deles. Houve várias histórias de produtos ativos com praticamente ninguém para mantê-los por anos. As reclamações dos usuários eram apenas coletadas e priorizadas. Quanto mais difícil se tornava exportar dados de clientes para EDIF, mais os fornecedores pareciam gostar. Aqueles que escreveram tradutores EDIF descobriram que gastaram uma quantidade enorme de tempo e esforço em gerar leitores suficientemente poderosos, tolerantes e artificialmente inteligentes, que pudessem lidar e juntar o código de baixa qualidade produzido pelos escritores EDIF 2 0 0 existentes da época.

Ao projetar o EDIF 3 0 0, os comitês estavam cientes das falhas de linguagem, das calúnias lançadas sobre o EDIF 2 0 0 pelos fornecedores e da frustração dos usuários finais. Assim, para restringir a semântica da linguagem e fornecer uma descrição mais formal do padrão, foi adotada a abordagem revolucionária de fornecer um modelo de informação para EDIF, na linguagem de modelagem de informação EXPRESS. Isso ajudou a documentar melhor o padrão, mas foi feito mais como uma reflexão tardia, pois a elaboração da sintaxe foi feita independentemente do modelo, em vez de ser gerada a partir do modelo. Além disso, embora o padrão diga que se a sintaxe e o modelo discordarem, o modelo é o padrão, na prática não é esse o caso. A descrição BNF da sintaxe é a base da linguagem, visto que o software que faz o trabalho diário de produção de descrições de projeto é baseado em uma sintaxe fixa. O modelo de informação também sofria do fato de que não era (e não é) ideal para descrever EDIF. Ele não descreve muito bem tais conceitos como namespaces, e as diferenças entre uma definição e uma referência também não são claramente descritíveis. Além disso, as construções no EXPRESS para descrever restrições podem ser formais, mas a descrição de restrições às vezes é um assunto bastante complicado. Assim, a maioria das restrições acabou sendo descrita apenas como comentários. A maioria dos outros tornou-se descrições formais elaboradas que a maioria dos leitores nunca será capaz de decifrar e, portanto, pode não resistir à depuração/compilação automatizada, assim como um programa pode parecer bom na revisão, mas um compilador pode encontrar alguns erros interessantes e realmente executar o programa escrito pode encontrar erros ainda mais interessantes. (Além disso, compiladores/executores EXPRESS análogos não existiam quando o padrão foi escrito e podem não existir ainda hoje!)

Soluções para problemas EDIF 2 0 0

A solução para o "sabor" O problema de EDIF 2 0 0 era desenvolver uma descrição semântica mais específica em EDIF 3 0 0 (1993). De fato, os resultados relatados de pessoas que geraram tradutores EDIF 3 0 0 foram que os escritores agora eram muito mais difíceis de acertar, devido ao grande número de restrições semânticas, e os leitores são comparativamente triviais de desenvolver.

A solução para o "conflito de interesses" eram empresas terceirizadas neutras, que poderiam fornecer produtos EDIF com base em interfaces de fornecedores. Essa separação dos produtos EDIF do controle direto do fornecedor foi fundamental para fornecer à comunidade de usuários finais ferramentas que funcionassem bem. Formou-se naturalmente e sem comentários. A Engineering DataXpress foi talvez a primeira empresa desse tipo neste domínio, com a Electronic Tools Company parecendo ter conquistado o mercado em meados da década de 1990. Outra dinâmica neste setor é o próprio EDIF. Como eles cresceram bastante, gerar leitores e escritores tornou-se uma proposta muito cara. Normalmente, as empresas terceirizadas reuniram os especialistas necessários e podem usar esse conhecimento para gerar o software com mais eficiência. Eles também são capazes de aproveitar o compartilhamento de código e outras técnicas que um fornecedor individual não poderia. Em 2000, quase nenhum grande fornecedor produzia suas próprias ferramentas EDIF, optando por ferramentas OEM de terceiros.

Desde o lançamento do EDIF 4 0 0, toda a organização de padrões EDIF foi essencialmente dissolvida. Não houve reuniões publicadas de nenhum dos subcomitês técnicos, do grupo de especialistas EDIF, etc. A maioria dos indivíduos envolvidos mudou-se para outras empresas ou esforços. A newsletter foi abandonada e os Usuários' Grupo não realiza mais reuniões anuais. EDIF 3 0 0 e 4 0 0 são agora padrões ANSI, IEC e europeus (EN). EDIF versão 3 0 0 é IEC/EN 61690-1 e EDIF versão 4 0 0 é IEC/EN 61690-2.

Descendentes de EDIF

• LKSoft levou grandes conceitos da EDIF 2 0 para criar um formato de dados proprietário com a extensão padrão ".cam" para o seu sistema CircuitCAM oferecido originalmente pela LPKF Laser & Electronics AG em Garbsen/Hannover, Alemanha e hoje de propriedade da DCT Co., Ltd. em Tianjn, China. Para trabalhar eficientemente em EDIF como formatos LKSoft desenvolveu o Interface processual EDIF, uma API para a linguagem de programação C.
• Zuken, anteriormente Racal-Redac Ltd., tomou conceitos do início do desenvolvimento EDIF 4 0 0 para criar um novo formato proprietário chamado CADIF para o seu Visula Sistema PCB-CAD. Este formato também é amplamente utilizado por fornecedores de terceiros.
• STEP-AP210, uma parte da ISO 10303, praticamente herdou toda a funcionalidade EDIF 4 0 0, exceto para esquemas.