EDIF

EDIF (Formato de intercambio de diseño electrónico) es un formato independiente del proveedor basado en S-Expressions en el que se almacenan esquemas y listas de conexiones electrónicas. Fue uno de los primeros intentos de establecer un formato neutral de intercambio de datos para la industria de la automatización del diseño electrónico (EDA). El objetivo era establecer un formato común del que pudieran derivarse los formatos propietarios de los sistemas EDA. Cuando los clientes necesitaban transferir datos de un sistema a otro, era necesario escribir traductores de un formato a otro. A medida que se multiplicaba la cantidad de formatos (N), el problema del traductor se convirtió en un problema de N cuadrados. La expectativa era que con EDIF la cantidad de traductores pudiera reducirse a la cantidad de sistemas involucrados.

Representantes de las empresas EDA Daisy Systems, Mentor Graphics, Motorola, National Semiconductor, Tektronix, Texas Instruments y la Universidad de California, Berkeley establecieron el Comité Directivo de EDIF en noviembre de 1983. Posteriormente, Hilary Kahn, profesor de ciencias de la computación en la Universidad de Manchester, se unió al equipo y lideró el desarrollo desde la versión EDIF 2 0 0 hasta la versión final 4 0 0.

Sintaxis

El formato general de EDIF implica el uso de paréntesis para delimitar las definiciones de datos y, de esta manera, se parece superficialmente a Lisp. Los tokens básicos de EDIF 2.0.0 eran palabras clave (como biblioteca, celda, instancia, etc.), cadenas (delimitadas con comillas dobles), números enteros, constantes simbólicas (por ejemplo, GENERIC, TIE, RIPPER para tipos de celdas) e "Identificadores", que son etiquetas de referencia formadas por un conjunto muy restringido de caracteres. EDIF 3.0.0 y 4.0.0 eliminaron las constantes simbólicas por completo, utilizando palabras clave en su lugar. Entonces, la sintaxis de EDIF tiene una base bastante simple. Un archivo EDIF típico se ve así:

()edif fibex ()edifVersion 2 0 0) ()edifLevel 0) ()keywordMap ()palabra clave Nivel 0) ()Situación ()escrito ()timeStamp 1995 1 1 1 1 1) ()programa "xx" ()versión "v1"))) ()biblioteca xxxx ()edifLevel 0) ()tecnología ()NúmeroDefinición ()escala 1 ()e 1 -6) ()unidad distancia))) ()célula Dff_4 ()célula Tipo genérico genérico) ()vista vista1 ()vista Tipo netlist) ()interfaz ()puerto aset ()dirección INPUT) ()puerto clok ()dirección INPUT) ... ()célula Sí. ()célula Tipo genérico genérico) ()vista schematic_ ()vista Tipo netlist) ()interfaz ()puerto CLEAR ()dirección INPUT) ()puerto CLOCK ()dirección INPUT) ... ) ()contenidos ()ejemplo I_36_1 ()viewRef vista1 ()célula Ref. Dff_4)) ()ejemplo ()rename I_36_3 "I$3") ()viewRef vista1 ()célula Ref. addsub_4)) ... ()neto CLEAR ()unidos ()portRef CLEAR) ()portRef aset ()ejemplo Ref. I_36_1) ()portRef aset ()ejemplo Ref. I_36_3))) ...

Versiones

La versión 1 0 0 de EDIF se realizó en 1985.

EDIF 2 0 0

El primer "real" El lanzamiento público de EDIF fue la versión 2 0 0, que fue aprobada en marzo de 1988 como el estándar ANSI/EIA-548-1988. Se publica en un solo volumen. Esta versión no tiene una declaración de alcance formal, pero lo que intenta capturar está cubierto por los viewType definidos:

• BEHAVIOR para describir el comportamiento de una célula
• DOCUMENTO para describir la documentación de una célula
• Grafico para describir un tonto gráfica y representación de texto de información visible o imprimible
• LOGICMODEL para describir el modelo de lógica-imulación de la célula
• MASKLAYOUT para describir un diseño de circuito integrado
• NETLIST para describir una lista net
• PCBLAYOUT para describir un circuito impreso
• SCHEMATIC para describir la representación esquemática y la conectividad de una célula
• STRANGER para describir una representación aún desconocida de una célula
• SYMBOLIC para describir un diseño simbólico

La industria probó esta versión durante varios años, pero finalmente solo la vista NETLIST fue la que se usó ampliamente y algunas herramientas EDA todavía la admiten hoy en día para EDIF 2 0 0.

Para superar los problemas con el estándar principal 2 0 0, se publicaron varios documentos adicionales:

• Electronic Industries Association
  • EDIF Monograph Series, Volumen 1, Introducción a EDIF, EIA/EDIF-1, Sept. 1988
  • EDIF Monograph Series, Volumen 2, EDIF Connectivity, EIA/EDIF-2, junio de 1989
  • Utilizando EDIF 2 0 para transferencia esquemática, EIA/EDIF/AG-1, julio de 1989
• Documentación de Hilary J. Kahn, Departamento de Ciencias de la Computación, Universidad de Manchester
  • EDIF 2 0 0, Un Tutorial Introductor, septiembre de 1989
  • EDIF Preguntas y respuestas, volumen uno, noviembre de 1988
  • EDIF Preguntas y respuestas, volumen dos, febrero de 1989
  • EDIF Preguntas y respuestas, volumen tres, julio de 1989
  • EDIF Preguntas y respuestas, volumen cuatro, noviembre de 1989
  • EDIF Preguntas y respuestas, volumen cinco, junio de 1991

EDIF 3 0 0

Debido a algunas debilidades fundamentales en la versión 2 0 0, se lanzó una nueva versión no compatible 3 0 0 en septiembre de 1993, con la designación de estándar EIA EIA-618. Más tarde logró las designaciones ANSI e ISO. Se publica en 4 tomos. El enfoque principal de esta versión fueron los tipos de vista NETLIST y SCHEMATIC de 2 0 0. MASKLAYOUT, PCBLAYOUT y algunas otras vistas se eliminaron de esta versión y se cambiaron para versiones posteriores porque el trabajo para estas vistas no se completó por completo.

EDIF 3 0 0 está disponible en la Comisión Electrotécnica Internacional como IEC 61690-1

EDIF 4 0 0

EDIF 4 0 0 se publicó a fines de agosto de 1996, principalmente para agregar "Placa de circuito impreso" extensiones (la vista PCBLAYOUT original) a EDIF 3 0 0. Esto más que duplicó el tamaño de EDIF 3 0 0, y está publicado en formato HTML en CD.

EDIF 4 0 0 está disponible en la Comisión Electrotécnica Internacional como IEC 61690-2

Evolución

Problemas con 2 0 0

Para entender los problemas que los usuarios y proveedores encontraron con EDIF 2 0 0, primero hay que imaginarse todos los elementos y la dinámica de la industria electrónica. Las personas que necesitaban este estándar eran principalmente ingenieros de diseño, que trabajaban para empresas cuyo tamaño variaba desde un garaje doméstico hasta instalaciones multimillonarias con miles de ingenieros. Estos ingenieros trabajaron principalmente a partir de esquemas y netlists a fines de la década de 1980, y el gran impulso fue generar automáticamente netlists a partir de los esquemas. Los primeros proveedores fueron proveedores de automatización de diseño electrónico (por ejemplo, Daisy, Mentor y Valid formaron el primer conjunto predominante). Estas empresas competían vigorosamente por su participación en este mercado.

Una de las tácticas utilizadas por estas empresas para "capturar" sus clientes eran sus bases de datos propietarias. Cada uno tenía características especiales que los demás no tenían. Una vez que se tomó la decisión de usar el software de un proveedor en particular para ingresar un diseño, el cliente se vio obligado a no usar ningún otro software. Pasar de los sistemas del proveedor A a los del proveedor B generalmente significaba un reingreso muy costoso de casi todos los datos de diseño a mano en el nuevo sistema. Este gasto de "migración" fue el factor principal que obligó a los ingenieros de diseño a utilizar un solo proveedor.

Pero los "clientes" tenía un deseo diferente. Inmediatamente vieron que, si bien el proveedor A podría tener un entorno de simulación analógica muy agradable, el proveedor B tenía un enrutador automático de PCB o diseño de silicio mucho mejor. Y deseaban poder elegir entre los diferentes proveedores.

EDIF fue apoyado principalmente por los usuarios finales de diseño electrónico y sus empresas. Los vendedores de EDA también estaban involucrados, pero su motivación era más en la línea de querer no alienar a sus clientes. La mayoría de los proveedores de EDA producían traductores EDIF 2 0 0, pero definitivamente estaban más interesados en generar lectores EDIF de alta calidad, y no tenían absolutamente ninguna motivación para escribir ningún software que generara EDIF (un EDIF Writer), más allá de las amenazas de clientes de migración masiva al software de otro proveedor.

El resultado fue bastante interesante. Casi ningún proveedor de software escribió una salida EDIF 2 0 0 que no tuviera violaciones graves de sintaxis o semántica. La semántica era lo suficientemente flexible como para que pudiera haber varias formas de describir los mismos datos. Esto comenzó a conocerse como "sabores" de EDIF. Las empresas proveedoras no siempre consideraron importante asignar muchos recursos a los productos EDIF, incluso si vendieron una gran cantidad de ellos. Hubo varias historias de productos activos con prácticamente nadie para mantenerlos durante años. Las quejas de los usuarios simplemente se recopilaron y priorizaron. Cuanto más difícil se volvía exportar datos de clientes a EDIF, más parecía gustarles a los proveedores. Aquellos que escribieron traductores EDIF descubrieron que dedicaron una gran cantidad de tiempo y esfuerzo a generar lectores artificialmente inteligentes, comprensivos y suficientemente poderosos, que pudieran manejar y ensamblar el código de baja calidad producido por los escritores EDIF 2 0 0 existentes en ese momento..

Al diseñar EDIF 3 0 0, los comités eran muy conscientes de las fallas del lenguaje, las calumnias acumuladas sobre EDIF 2 0 0 por parte de los proveedores y la frustración de los usuarios finales. Por lo tanto, para ajustar la semántica del lenguaje y proporcionar una descripción más formal del estándar, se adoptó el enfoque revolucionario para proporcionar un modelo de información para EDIF, en el lenguaje de modelado de información EXPRESS. Esto ayudó a documentar mejor el estándar, pero se hizo más como una ocurrencia tardía, ya que la elaboración de la sintaxis se realizó independientemente del modelo, en lugar de generarse a partir del modelo. Además, aunque el estándar dice que si la sintaxis y el modelo no están de acuerdo, el modelo es el estándar, este no es el caso en la práctica. La descripción BNF de la sintaxis es la base del lenguaje, ya que el software que realiza el trabajo diario de producir descripciones de diseño se basa en una sintaxis fija. El modelo de información también se vio afectado por el hecho de que no era (y no es) idealmente adecuado para describir EDIF. No describe muy bien conceptos tales como espacios de nombres, y las diferencias entre una definición y una referencia tampoco se pueden describir claramente. Además, las construcciones en EXPRESS para describir restricciones pueden ser formales, pero la descripción de restricciones es un asunto bastante complicado a veces. Entonces, la mayoría de las restricciones terminaron describiéndose simplemente como comentarios. La mayoría de los demás se convirtieron en descripciones formales elaboradas que la mayoría de los lectores nunca podrán descifrar y, por lo tanto, es posible que no resistan la depuración/compilación automática, al igual que un programa puede verse bien en la revisión, pero un compilador puede encontrar algunos errores interesantes y ejecutar realmente el programa escrito podría encontrar errores aún más interesantes. (Además, los compiladores/ejecutores EXPRESS análogos no existían cuando se escribió el estándar, ¡y es posible que aún no existan hoy!)

Soluciones a problemas EDIF 2 0 0

La solución al "sabor" El problema de EDIF 2 0 0 fue desarrollar una descripción semántica más específica en EDIF 3 0 0 (1993). De hecho, los resultados informados de personas que generaron traductores EDIF 3 0 0 fueron que los escritores ahora eran mucho más difíciles de acertar, debido a la gran cantidad de restricciones semánticas, y los lectores son comparativamente triviales de desarrollar.

La solución al "conflicto de intereses" eran empresas externas neutrales, que podían proporcionar productos EDIF basados en interfaces de proveedores. Esta separación de los productos EDIF del control directo del proveedor fue fundamental para proporcionar a la comunidad de usuarios finales herramientas que funcionaran bien. Se formó naturalmente y sin comentarios. Engineering DataXpress fue quizás la primera empresa de este tipo en este ámbito, y aparentemente Electronic Tools Company capturó el mercado a mediados o finales de la década de 1990. Otra dinámica en esta industria es el propio EDIF. Dado que han crecido hasta alcanzar un tamaño bastante grande, generar lectores y escritores se ha convertido en una propuesta muy costosa. Por lo general, las empresas de terceros han reunido a los especialistas necesarios y pueden utilizar esta experiencia para generar el software de manera más eficiente. También pueden aprovechar el código compartido y otras técnicas que un proveedor individual no podría. Para el año 2000, casi ningún proveedor importante producía sus propias herramientas EDIF, eligiendo en su lugar herramientas OEM de terceros.

Desde el lanzamiento de EDIF 4 0 0, toda la organización de estándares EDIF prácticamente se ha disuelto. No se han publicado reuniones de ninguno de los subcomités técnicos, el grupo de expertos de EDIF, etc. La mayoría de las personas involucradas se han trasladado a otras empresas o esfuerzos. El boletín fue abandonado y los Usuarios' El grupo ya no realiza reuniones anuales. EDIF 3 0 0 y 4 0 0 ahora son estándares ANSI, IEC y europeos (EN). La versión 3 0 0 de EDIF es IEC/EN 61690-1 y la versión 4 0 0 de EDIF es IEC/EN 61690-2.

Descendientes EDIF

• LKSoft tomó conceptos importantes de EDIF 2 0 para crear un formato de datos patentado con la extensión predeterminada ".cam" para su sistema CircuitCAM ofrecido originalmente por LPKF Laser & Electronics AG en Garbsen/Hannover, Alemania y hoy propiedad de DCT Co., Ltd. en Tianjn, China. Para trabajar eficientemente en EDIF como formatos LKSoft ha desarrollado el Interfaz de procedimiento EDIF, una API para el lenguaje de programación C.
• Zuken, anteriormente Racal-Redac Ltd., tomó conceptos desde el desarrollo temprano EDIF 4 0 para crear un nuevo formato patentado llamado CADIF para su desarrollo Visula Sistema PCB-CAD. Este formato también es ampliamente utilizado por los proveedores de terceros.
• STEP-AP210, una parte de ISO 10303, prácticamente heredó toda la funcionalidad EDIF 4 0 0 excepto para esquemas.