EDIF

редактировать

EDIF (Формат обмена электронными проектами ) - это формат, не зависящий от поставщика, основанный на S -Выражения для хранения электронных списков соединений и схем. Это была одна из первых попыток установить нейтральный формат обмена данными для индустрии автоматизации проектирования электроники (EDA). Цель состояла в том, чтобы установить общий формат, из которого можно было бы извлечь собственные форматы систем EDA. Когда клиентам требовалось перенести данные из одной системы в другую, приходилось писать переводчики из одного формата в другой. По мере того как количество форматов (N) увеличивалось, проблема с переводчиком превратилась в проблему с N-квадратом. Ожидалось, что с помощью EDIF количество переводчиков может быть сокращено до количества задействованных систем.

Представители компаний EDA Daisy Systems, Mentor Graphics, Motorola, National Semiconductor, Tektronix, Texas Instruments и Калифорнийский университет в Беркли учредили Руководящий комитет EDIF в ноябре 1983 года. Позже Хилари Кан, профессор компьютерных наук в Манчестерский университет присоединился к команде и руководил разработкой от версии EDIF 2 0 0 до финальной версии 4 0 0.

Содержание
  • 1 Синтаксис
  • 2 Версии
    • 2.1 EDIF 2 0 0
    • 2.2 EDIF 3 0 0
    • 2.3 EDIF 4 0 0
  • 3 Evolution
    • 3.1 Проблемы с 2 0 0
    • 3.2 Решение проблем EDIF 2 0 0
    • 3.3 Потомки EDIF
  • 4 Внешние ссылки
Синтаксис

Общий формат EDIF включает использование скобок для ограничения определений данных, и в этом смысле он внешне напоминает Lisp. Основными токенами EDIF 2.0.0 были ключевые слова (например, библиотека, ячейка, экземпляр и т. Д.), Строки (разделенные двойными кавычками), целые числа, символьные константы (например, GENERIC, TIE, RIPPER для типов ячеек) и «идентификаторы», которые являются ссылочными метками, сформированными из очень ограниченного набора символов. В EDIF 3.0.0 и 4.0.0 символические константы полностью исключены, вместо них используются ключевые слова. Итак, синтаксис EDIF имеет довольно простую основу. Типичный файл EDIF выглядит так:

(edif fibex (edifVersion 2 0 0) (edifLevel 0) (keywordMap (keywordLevel 0)) (status (написано (timeStamp 1995 1 1 1 1 1) (программа "xxx" ( версия "v1")))) (библиотека xxx (edifLevel 0) (технология (numberDefinition (scale 1 (e 1-6) (единичное расстояние)))) (ячейка dff_4 (cellType generic) (view view1 (viewType netlist) ( interface (порт aset (направление INPUT)) (port clok (направление INPUT))... (cell yyy (cellType generic) (view schematic_ (viewType netlist) (interface (port CLEAR (direction INPUT)) (port CLOCK (direction INPUT)))...) (содержимое (экземпляр I_36_1 (viewRef view1 (cellRef dff_4))) (экземпляр (переименовать I_36_3 "I $ 3") (viewRef view1 (cellRef addub_4)))... (net CLEAR (объединено (portRef CLEAR) (portRef aset (instanceRef I_36_1)) (portRef aset (instanceRef I_36_3))))...
Версии

Версия EDIF 10 0 была выпущена в 1985 году.

EDIF 2 0 0

Первым «настоящим» публичным выпуском EDIF была версия 2 0 0, которая была утверждена в марте 1988 г. как стандарт ANSI / EIA-548-1988. Издается в единственном томе. В этой версии нет формального оператора области действия, но то, что он пытается захватить, покрывается определенным viewType s:

  • BEHAVIOR для описания поведения ячейки
  • ДОКУМЕНТ для описания документации ячейки
  • ГРАФИЧЕСКИЙ для описания тупой графики и текстового представления отображаемой или печатаемой информации
  • LOGICMODEL для описания модели логического моделирования ячейки
  • MASKLAYOUT для описания компоновки интегральной схемы
  • NETLIST для описания списка соединений
  • PCBLAYOUT для описания печатной платы
  • SCHEMATIC для описания схематического представления и возможности подключения ячейки
  • STRANGER для описания пока неизвестного представления ячейки
  • SYMBOLIC для описания символьного макета

Промышленность тестировала этот выпуск в течение нескольких лет, но, наконец, только представление NETLIST было широко используется, и некоторые инструменты EDA все еще поддерживают его сегодня для EDIF 2 0 0.

Для решения проблем с основным стандартом 20 0 несколько были выпущены следующие документы:

  • Ассоциация электронной промышленности
    • Серия монографий EDIF, Том 1, Введение в EDIF, EIA / EDIF-1, сентябрь 1988 г.
    • Серия монографий EDIF, Том 2, EDIF Connectivity, EIA / EDIF-2, июнь 1989 г.
    • Использование EDIF 2 0 0 для передачи схем, EIA / EDIF / AG-1, июль 1989 г.
  • Документация от Хилари Дж. Кан, Департамент компьютерных наук, Манчестерский университет
    • EDIF 2 0 0, Вводное пособие ", сентябрь 1989 г.
    • EDIF Вопросы и ответы, том первый, ноябрь 1988 г.
    • EDIF Вопросы и ответы, том 2, февраль 1989 г.
    • Вопросы и ответы EDIF, том третий, июль 1989 г.
    • Вопросы и ответы EDIF, том 4, ноябрь 1989 г.
    • Вопросы и ответы EDIF, том 5, Июнь 1991 г.

EDIF 3 0 0

Из-за некоторых фундаментальных недостатков версии 2 0 0 в сентябре 1993 г. была выпущена новая несовместимая версия 3 0 0, получившая обозначение EIA стандарт EIA-618. Позже он получил обозначения ANSI и ISO. Издается в 4-х томах. Основное внимание в этой версии уделялось типам представлений NETLIST и SCHEMATIC из 20 0. MASKLAYOUT, PCBLAYOUT и некоторые другие представления были исключены из этого выпуска и перенесены на более поздние выпуски, поскольку работа с этими представлениями не была полностью завершена.

EDIF 3 0 0 доступен в Международной электротехнической комиссии как выпущен IEC 61690-1

EDIF 4 0 0

EDIF 4 0 0 в конце августа 1996 г., в основном для добавления расширений «Печатная плата» (исходное представление PCBLAYOUT) в EDIF 3 0 0. Это более чем удвоило размер EDIF 3 0 0 и опубликовано в формате HTML на компакт-диске.

EDIF 4 0 0 доступен в Международной электротехнической комиссии как

Evolution

Проблемы с 2 0 0

Чтобы понять проблемы, с которыми столкнулись пользователи и поставщики с EDIF 2 0 0 нужно сначала представить себе все элементы и динамику электронной промышленности. В этом стандарте нуждались в основном инженеры-проектировщики, работавшие в компаниях, размер которых варьировался от гаража до многомиллиардных предприятий с тысячами инженеров. Эти инженеры работали в основном со схемами и списками соединений в конце 1980-х, и большой толчок заключался в том, чтобы автоматически генерировать списки соединений из схем. Первыми поставщиками были поставщики средств автоматизации электронного проектирования (например, Daisy, Mentor и Valid составили самую раннюю преобладающую группу). Эти компании активно боролись за свои доли на этом рынке.

Одной из тактик, используемых этими компаниями для «захвата» своих клиентов, были их собственные базы данных. У каждого были особенности, которых не было у других. После того, как было принято решение использовать программное обеспечение конкретного поставщика для ввода в проект, заказчик никогда не был вынужден использовать никакое другое программное обеспечение. Переход от систем поставщика A к системам поставщика B обычно означал очень затратный повторный ввод почти всех проектных данных вручную в новую систему. Расходы на «миграцию» были основным фактором, который заставил инженеров-проектировщиков использовать одного поставщика.

Но у «заказчиков» было другое желание. Они сразу увидели, что в то время как поставщик A может иметь действительно хорошую среду аналогового моделирования, поставщик B имеет гораздо лучший автоматический маршрутизатор печатной платы или кремниевой схемы. И они хотели, чтобы у них была возможность выбирать среди различных поставщиков.

EDIF в основном поддерживался конечными пользователями электроники и их компаниями. Поставщики EDA также были вовлечены, но их мотивация была больше похожа на желание не оттолкнуть своих клиентов. Большинство поставщиков EDA производили переводчики EDIF 2 0 0, но они определенно были больше заинтересованы в создании высококачественных считывателей EDIF, и у них не было абсолютно никакой мотивации писать какое-либо программное обеспечение, генерирующее EDIF (устройство записи EDIF), помимо угроз со стороны заказчики массового перехода на ПО другого производителя.

Результат был довольно интересным. Вряд ли какой-либо поставщик программного обеспечения написал в формате EDIF 2 0 0 выходные данные, в которых не было бы серьезных нарушений синтаксиса или семантики. Семантика была достаточно свободной, чтобы можно было описать одни и те же данные несколькими способами. Это стали называть «ароматизаторами» EDIF. Компании-поставщики не всегда считали важным выделять много ресурсов на продукты EDIF, даже если они продавали их большое количество. Было несколько историй об активных продуктах, когда практически никто не обслуживал их в течение многих лет. Жалобы пользователей просто собирались и определялись по приоритетам. Чем сложнее становилось экспортировать данные клиентов в EDIF, тем больше это нравилось поставщикам. Те, кто написал переводчики EDIF, обнаружили, что они потратили огромное количество времени и усилий на создание достаточно мощных, прощающих ошибок, считывателей с искусственным интеллектом, которые могли бы обрабатывать и собирать воедино некачественный код, создаваемый существующими авторами EDIF 20 0 того времени..

При разработке EDIF 3 0 0 комитеты хорошо осознавали недостатки языка, клевету, обрушившуюся на EDIF 2 0 0 со стороны поставщиков, и разочарование конечных пользователей. Таким образом, чтобы ужесточить семантику языка и обеспечить более формальное описание стандарта, был применен революционный подход к предоставлению информационной модели для EDIF на языке информационного моделирования EXPRESS. Это помогло лучше задокументировать стандарт, но было сделано в большей степени с опозданием, поскольку создание синтаксиса выполнялось независимо от модели, а не генерировалось из модели. Кроме того, хотя в стандарте сказано, что если синтаксис и модель не совпадают, то модель является стандартной, на практике это не так. Описание синтаксиса BNF является основой языка, поскольку программное обеспечение, выполняющее повседневную работу по созданию описаний проекта, основано на фиксированном синтаксисе. Информационная модель также страдала от того, что она не была (и не подходит) идеально для описания EDIF. Он вообще не очень хорошо описывает такие концепции, как пространства имен, и различия между определением и ссылкой также не поддаются четкому описанию. Кроме того, конструкции в EXPRESS для описания ограничений могут быть формальными, но описание ограничений иногда бывает довольно сложным. Таким образом, большинство ограничений было просто описано как комментарии. Большинство других превратились в тщательно продуманные формальные описания, которые большинство читателей никогда не смогут расшифровать и, следовательно, могут не выдержать автоматической отладки / компиляции, точно так же, как программа может хорошо выглядеть в обзоре, но компилятор может обнаружить некоторые интересные ошибки и на самом деле запуск написанной программы может обнаружить еще более интересные ошибки. (Кроме того, аналогичные компиляторы / исполнители EXPRESS не существовали, когда был написан стандарт, и могут не существовать до сих пор!)

Решения проблем EDIF 2 0 0

Решение " вкус »проблема EDIF 2 0 0 заключалась в разработке более конкретного семантического описания в EDIF 3 0 0 (1993). Действительно, сообщенные результаты людей, генерирующих переводчики EDIF 3 0 0, заключаются в том, что составителей теперь было намного труднее получить правильно из-за большого количества семантических ограничений, а читателей сравнительно несложно развивать.

Решением «конфликта интересов» поставщика были нейтральные сторонние компании, которые могли предоставлять продукты EDIF на основе интерфейсов поставщика. Такое отделение продуктов EDIF от прямого контроля со стороны поставщиков было критически важно для обеспечения сообщества конечных пользователей инструментами, которые хорошо работают. Он сложился естественно и без комментариев. была, пожалуй, первой такой компанией в этой сфере, которая, казалось, захватила рынок в середине-конце 1990-х годов. Еще одна динамика в этой отрасли - это сам EDIF. Поскольку они выросли до довольно больших размеров, создание читателей и писателей стало очень дорогим делом. Обычно сторонние компании собирают необходимых специалистов и могут использовать эти знания для более эффективного создания программного обеспечения. Они также могут использовать совместное использование кода и другие методы, недоступные отдельным поставщикам. К 2000 году почти ни один крупный поставщик не производил свои собственные инструменты EDIF, предпочитая вместо этого OEM инструменты сторонних производителей.

С момента выпуска EDIF 4 0 0 вся организация стандартизации EDIF практически распалась. Не было опубликовано ни одного заседания какого-либо технического подкомитета, группы экспертов EDIF и т. Д. Большинство вовлеченных лиц перешли в другие компании или в другие компании. Рассылка новостей была прекращена, и группа пользователей больше не проводит ежегодные собрания. EDIF 3 0 0 и 4 0 0 теперь являются стандартами ANSI, IEC и европейскими (EN) стандартами. Версия EDIF 3 0 0 - это IEC / EN 61690-1, а EDIF Version 4 0 0 - это IEC / EN 61690-2.

Потомки EDIF

  • взяли основные концепции из EDIF 2 0 0, чтобы создать частный формат данных с расширением по умолчанию «.cam» для своей системы, первоначально предложенный компанией в Гарбсен / Ганновер, Германия, а сегодня принадлежащий компании. Для эффективной работы с форматами, подобными EDIF, LKSoft разработала процедурный интерфейс EDIF, API для языка программирования C.
  • Zuken, ранее называвшаяся Racal-Redac Ltd., взяла концепции из ранней разработки EDIF 4 0 0 создать новый частный формат под названием CADIF для своей системы Visula PCB-CAD. Этот формат также широко используется сторонними поставщиками.
  • STEP-AP210, часть ISO 10303, практически унаследовал все функции EDIF 4 0 0, кроме схем.
Внешние ссылки
Последняя правка сделана 2021-05-18 14:42:33
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте