Нам нужна универсальная система преобразования форматов для трансляции изменений между всеми современными и возможно будущими средствами gEDA, а также сторонними программами, которые, вероятно, могут использоваться вместе с программами gEDA.

Поддерживать все возможные преобразования, безусловно, смысла нет. Поэтому ограничимся современными и возможно будущими составляющими gEDA и сторонними программами, которые, вероятно, могут использоваться вместе с программами gEDA. Разумеется, для ряда программ преобразование форматов не имеет смысла и поддерживаться не должно.

Идея состоит в использовании промежуточного формата. Сначала транслировать в него, затем — из него. Промежуточный формат должен быть достаточно выразительным, чтобы его можно было без потерь транслировать в формат любой программы gEDA и обратно.

“Без потерь” значит, что файл, полученный в результате трансляции должен работать так же, как и исходный. Не обязательно сохранять форматирование и прочие незначительные вещи.

Все форматы для трансляции в настоящее время состоят из списков объектов с некоторого рода структурированием. Каждый из объектов имеет подключения и атрибуты.

Это наводит на мысль об использовании в качестве промежуточного одного из возможных стандартных форматов списков соединений.

Ниже рассматриваются только те форматы, что соответствуют указанной модели.

Если возможно, хорошо бы, чтобы выбранный формат уже применялся когда-либо по крайней мере для некоторых из указанных целей, а также имел стороннюю, опубликованную и свободно доступную спецификацию.

Должны быть способы включения изменений из любого источника/назначения без смешения различных частей.

• принципиальные схемы
• топологические схемы
• моделирование

Для форматов файлов данных программ нужно преобразование без потерь, поэтому может потребоваться промежуточный формат хранения данных.

• gschem
• pcb
• gnucap
• Icarus Verilog

Эти программы тоже свободные. Нужен стандарт для их поддержки на равных правах с программами gEDA.

• NGspice
• Qucs
• Kicad
• Magic
• Electric
• Xcircuit
• Fritzing

Поддержка форматов данных программ позволит программам gEDA наилучшим образом взаимодействовать с коммерческими средствами. Нужна базовая функциональность, но преобразование не обязательно должно быть без потерь. Преобразование без потерь должно быть возможным, но не является главным приоритетом для фактической реализации средств трансляции.

• Eagle
• Orcad
• LTspice
• Pads

Надеемся, при наличии системы преобразования форматов у нас появится база для решения следующих вопросов:

• Обратная трансляция изменений топологических схем и файлов моделирования в принципиальные схемы.
• Анализ статических временных диаграмм.
• Моделирование целостности сигналов после формирования топологии платы.
• Сравнение топологической и принципиальной схем.
• Использование одной и той же схемы для всего проекта целиком.

• Построение графиков
• Команды
• Поведенческое моделирование

Все форматы состоят из списков объектов с подключениями и атрибутами.

Традиционно для обмена данными использовались списки соединений, но традиционный подход подразумевает одностороннее преобразование, поскольку при этом теряется информация.

Формат должен передавать сущность содержимого не обязательно таким же образом, как родной формат программы или её внутреннее представление.

Не обязательно транслировать те части, что обычно уже имеются в библиотеках или специфичны для данной программы, такие как модели, символы или посадочные места.

Каждый из претендентов на роль возможного формата должен поддерживать преобразование в любой другой и обратно без потерь.

Популярный формат списка соединений. Использовался для обмена данными, но пока не применялся для описания физического расположения. Проблемы: неправильный синтаксис, недостаточно выразителен. Эти проблемы годами не давали покоя разработчикам. Формат нравится почти всем, за исключением тех, кто хорошо его знает.

Структурное подмножество представляет собой хороший формат списка соединений. Он правилен, достаточно выразителен и для него опубликован стандарт. Использовался для обмена данными, но пока не применялся для описания физического расположения.

Структурное подмножество представляет собой хороший формат списка соединений. Он правилен, достаточно выразителен и для него опубликован стандарт. Использовался для обмена данными, но пока не применялся для описания физического расположения.

Структурное подмножество представляет собой хороший формат списка соединений. Он правилен, достаточно выразителен, но принадлежит одной компании (Cadence), поэтому его исключаем. Использовался только для моделирования.

XML — это на самом деле не формат, а синтаксис. На основе XML можно сделать хороший формат, но примеров такого в подобном контексте пока не наблюдалось. Синтаксис хорошо документирован, но никакой сторонней документации по его применению для похожих целей нет.

Это единственный вид применения, для которого ни Verilog, ни VHDL серьёзно не использовались.

Идеи:

• Соединения тоже являются объектами с подключениями и атрибутами. Соединения имеют значение в любом контексте.
• Положение в схеме может рассматриваться как объект с подключениями и атрибутами (place).
• Контактные площадки, соединители, термоплощадки, переходы, … — всё это тоже объекты с подключениями и атрибутами.
• Чтобы отделить разделы, имеющие значение только в определённом контексте, можно использовать директиву 'define (для формата Verilog)
• Формат должен быть описанием высокого уровня. Такое представление должно быть повсюду. То есть речь не должна идти о линиях, прямоугольниках и окружностях.
• Если нужно, линии, прямоугольники и окружности тоже могут быть объектами, но не транслируемыми, так как они не имеют значения в других ситуациях.
• Атрибуты, не имеющие значения, молча игнорируются. Имеющие значение в одном контексте, но не имеющие в другом, игнорируются там, где не имеют смысла.

Как один из возможных вариантов рассмотрим формат Verilog.

Самостоятельной единицей будет модуль (module):

module my-module(connections);
// contents
endmodule

Каждый объект в списке имеет совместимый синтаксис:

type #(attributes) name (connections);

Пример:

resistor #(.r(1k)) r123 (a, b);
resistor #(.r(1k)) r234 (.p(b), .n(c));

“r” представляет собой имя атрибута. “1k” — это значение (строка).

В первом примере соединения определяются по порядку. Во втором их соответствие выводам определяется посредством имён. Узел “b” подключен к выводу “p”, а узел “c” — к выводу “n”.

Соединение (“net”) тоже является объектом.

В вышеприведённом примере оба резистора непосредственно подключены к узлу “b”. Подключение в принципиальной схеме непосредственно не задаётся, для этого используется соединение (“net”):

resistor #(.r(1k)) r123 (.p(a1), .n(b1));
resistor #(.r(1k)) r125 (.p(b2), .n(c2));
net b (.1(b1), .2(b2));

Имя соединения — “b”. Атрибутов соединение не имеет.

Теперь для схемы нужно добавить узлы:

place #(.x(1222), .y(3438)) place11333 (b1);
place #(.x(4334), .y(8433)) place34894 (b2);
place #(.x(9393), .y(4232)) place49334 (a1);
place #(.x(2932), .y(2384)) place34983 (c2);

Части, применяемые только в определённом контексте, могут включаться селективно посредством 'ifdef:

module my_circuit;
  'ifdef SCHEMATIC
    place ...
    place ...
  'endif
   res ...
   res ...
   net ...
endmodule

Сложные соединения могут группироваться в самостоятельные элементы:

module net23842 (1,2,3);
  net n23482 (1,2);
  net n84333 (2,3);
  'ifdef SCHEMATIC
    place ...
    place ...
    place ...
  'endif
endmodule

module net9393 (1,2);
  net #(.color(blue), .thickness(thin)) n38423 (1,2);
endmodule