EDIF

La primera versión pública "real" de EDIF fue la versión 200, 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 tipos de vista definidos :

• COMPORTAMIENTO para describir el comportamiento de una célula
• DOCUMENTO para describir la documentación de una celda
• GRÁFICO para describir una representación gráfica y textual simple de información que se puede mostrar o imprimir.
• LOGICMODEL para describir el modelo de simulación lógica de la celda
• MASKLAYOUT para describir el diseño de un circuito integrado
• NETLIST para describir una lista de conexiones
• PCBLAYOUT para describir una placa de circuito impreso
• ESQUEMA para describir la representación esquemática y la conectividad de una célula.
• EXTRAÑO para describir una representación aún desconocida de una célula
• SIMBÓLICO para describir una disposición simbólica

La industria probó esta versión durante varios años, pero finalmente solo la vista NETLIST fue la más utilizada y algunas herramientas EDA todavía la admiten hoy en día para EDIF 200.

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

• Asociación de Industrias Electrónicas
  • Serie de monografías EDIF, Volumen 1, Introducción a EDIF , EIA/EDIF-1, septiembre de 1988
  • Serie de monografías EDIF, Volumen 2, Conectividad EDIF , EIA/EDIF-2, junio de 1989
  • Uso de EDIF 2 0 0 para la transferencia de esquemas , 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, tutorial introductorio , septiembre de 1989
  • Preguntas y respuestas de EDIF, volumen uno , noviembre de 1988
  • Preguntas y respuestas de EDIF, volumen dos , febrero de 1989
  • Preguntas y respuestas de EDIF, volumen tres , julio de 1989
  • Preguntas y respuestas de EDIF, volumen cuatro , noviembre de 1989
  • Preguntas y respuestas de EDIF, volumen cinco , junio de 1991

Estrenada el 15 de septiembre de 1992.

Debido a algunas deficiencias fundamentales en la versión 200, se lanzó una nueva versión no compatible, la 300, en septiembre de 1993, con la designación de estándar EIA -618. Posteriormente, obtuvo las certificaciones ANSI e ISO . Se publicó en 4 volúmenes. El enfoque principal de esta versión fueron los tipos de vista NETLIST y SCHEMATIC de la versión 200. MASKLAYOUT, PCBLAYOUT y otras vistas se eliminaron de esta versión y se incluyeron en versiones posteriores, ya que el trabajo para estas vistas no se había completado del todo.

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

EDIF 400 se lanzó a finales de agosto de 1996, principalmente para añadir extensiones de " Placa de Circuito Impreso " (la vista PCBLAYOUT original) a EDIF 300. Esto duplicó con creces el tamaño de EDIF 300 y se publica en formato HTML en CD. Su desarrollo se basó en la amplia colaboración de Robert Walker, un destacado especialista en diseño asistido por ordenador de placas de circuito impreso de Interconnection Systems, entonces líder europeo en la fabricación de placas de circuito impreso.

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

Para comprender los problemas que usuarios y proveedores encontraron con EDIF 200, primero hay que visualizar todos los elementos y la dinámica de la industria electrónica. Quienes 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 trabajaban principalmente con esquemas y listas de conexiones a finales de la década de 1980, y el gran impulso fue generar automáticamente las listas de conexiones a partir de los esquemas. Los primeros proveedores fueron empresas de automatización del diseño electrónico (por ejemplo, Daisy, Mentor y Valid conformaron el grupo predominante inicial). Estas empresas compitieron ferozmente por su cuota de mercado.

Una de las tácticas que estas empresas utilizaban para "captar" a sus clientes eran sus bases de datos propietarias. Cada una tenía características especiales que las demás no poseían. Una vez que se decidía usar el software de un proveedor específico para introducir un diseño, el cliente quedaba obligado a no usar ningún otro software. Migrar de los sistemas del proveedor A al proveedor B generalmente implicaba una costosa reintroducción manual de casi todos los datos de diseño en el nuevo sistema. Este gasto de "migración" era el factor principal que obligaba a los ingenieros de diseño a utilizar un único proveedor.

Pero los "clientes" tenían otro deseo. Enseguida se dieron cuenta de que, si bien el proveedor A podía tener un entorno de simulación analógica excelente, el proveedor B tenía un enrutador automático de diseño de PCB o silicio mucho mejor. Y deseaban poder elegir entre los diferentes proveedores.

El formato EDIF fue respaldado principalmente por los usuarios finales del diseño electrónico y sus empresas. Los proveedores de EDA también participaron, pero su motivación principal era no alienar a sus clientes. La mayoría de los proveedores de EDA producían traductores EDIF 200, pero sin duda estaban más interesados ​​en generar lectores EDIF de alta calidad y no tenían ningún incentivo para desarrollar software que generara EDIF (un escritor EDIF), más allá de las amenazas de los clientes de una migración masiva al software de otro proveedor.

Como resultado, pocos proveedores de software generaron salida EDIF 2.0.0 sin infracciones de sintaxis o semántica. La semántica era lo suficientemente flexible como para que los mismos datos pudieran describirse de múltiples maneras. Esto dio lugar a que las empresas tuvieran sus propias versiones de EDIF. Por lo general, los proveedores no destinaban muchos recursos a los productos EDIF, incluso si se vendían grandes cantidades. Quienes sí desarrollaron traductores EDIF descubrieron que invertían mucho tiempo y esfuerzo en generar lectores con inteligencia artificial lo suficientemente potentes, tolerantes y capaces de procesar y reconstruir el código deficiente producido por los desarrolladores de EDIF 2.0.0 existentes en aquel entonces.

Al diseñar EDIF 300, los comités eran plenamente conscientes de las deficiencias del lenguaje, las calumnias vertidas contra EDIF 200 por los proveedores y la frustración de los usuarios finales. Por ello, para perfeccionar la semántica del lenguaje y proporcionar una descripción más formal del estándar, se adoptó un enfoque revolucionario: un modelo de información para EDIF, en el lenguaje de modelado de información EXPRESS . Esto contribuyó a una mejor documentación del estándar, pero se implementó casi como una ocurrencia tardía, ya que la sintaxis se elaboró ​​independientemente del modelo, en lugar de generarse a partir de él. Además, si bien el estándar establece que, en caso de discrepancia entre la sintaxis y el modelo, prevalece el modelo, en la práctica esto no se cumple. La descripción BNF de la sintaxis constituye la base del lenguaje, dado que el software que realiza el trabajo diario de generar descripciones de diseño se basa en una sintaxis fija. El modelo de información también adolecía del hecho de que no era (ni es) ideal para describir EDIF. No describe bien conceptos como los espacios de nombres, y las diferencias entre una definición y una referencia tampoco se pueden describir con claridad. Además, si bien las construcciones en EXPRESS para describir restricciones pueden ser formales, la descripción de restricciones es a veces bastante compleja. Por lo tanto, la mayoría de las restricciones terminaron describiéndose simplemente como comentarios. La mayoría de las demás se convirtieron en elaboradas descripciones formales que la mayoría de los lectores nunca podrán descifrar y, por lo tanto, podrían no resistir la depuración/compilación automatizada, del mismo modo que un programa puede parecer correcto en revisión, pero un compilador podría encontrar errores interesantes, y la ejecución del programa podría revelar errores aún más interesantes. (Además, no existían compiladores/ejecutores análogos de EXPRESS cuando se redactó el estándar, ¡y puede que ni siquiera existan hoy!).

La solución al problema de la "sabor" de EDIF 200 fue desarrollar una descripción semántica más específica en EDIF 300 (1993). De hecho, los resultados reportados por personas que generaban traductores de EDIF 300 indicaban que los escritores eran ahora mucho más difíciles de lograr correctamente, debido a la gran cantidad de restricciones semánticas, y los lectores eran comparativamente triviales de desarrollar.

La solución al " conflicto de intereses " de los proveedores fue recurrir a empresas externas neutrales que pudieran ofrecer productos EDIF basados ​​en las interfaces de los 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 correctamente. Se desarrolló de forma natural y sin previo aviso. Engineering DataXpress fue quizás la primera empresa de este tipo en este ámbito, y Electronic Tools Company pareció dominar el mercado a mediados y finales de la década de 1990. Otro factor clave en esta industria es el propio EDIF. Dado su considerable crecimiento, la generación de lectores y escritores se ha convertido en una tarea muy costosa. Por lo general, las empresas externas han reunido a los especialistas necesarios y pueden utilizar esta experiencia para generar el software de forma más eficiente. También pueden aprovechar el intercambio de código 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, optando en su lugar por fabricar herramientas de terceros.

Desde el lanzamiento de EDIF 400, 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 proyectos. El boletín informativo se abandonó y el Grupo de Usuarios ya no celebra reuniones anuales. EDIF 300 y 400 son ahora estándares ANSI , IEC y europeos (EN). La versión 300 de EDIF es IEC/EN 61690-1, y la versión 400 es IEC/EN 61690-2.

• LKSoft tomó conceptos clave de EDIF 200 para crear un formato de datos propietario con la extensión predeterminada ".cam" para su sistema CircuitCAM, ofrecido originalmente por LPKF Laser & Electronics AG en Garbsen/Hannover, Alemania, y que actualmente pertenece a DCT Co., Ltd. en Tianjin, China . Para trabajar de manera eficiente con formatos similares a EDIF , LKSoft ha desarrollado la Interfaz de Procedimientos EDIF , una API para el lenguaje de programación C.
• Zuken , anteriormente conocida como Racal-Redac Ltd., tomó conceptos del desarrollo inicial de EDIF 400 para crear un nuevo formato propietario llamado CADIF para su sistema Visula PCB-CAD. Este formato también es ampliamente utilizado por proveedores externos.
• STEP-AP210, que forma parte de la norma ISO 10303 , heredó prácticamente toda la funcionalidad de EDIF 4 0 0, excepto los esquemas.