<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html> <head> <title></title> <link rel="stylesheet" media="screen" type="text/css" href="./style.css" /> <link rel="stylesheet" media="screen" type="text/css" href="./design.css" /> <link rel="stylesheet" media="print" type="text/css" href="./print.css" /> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> </head> <body> <h1 class="sectionedit2208"><a name="преобразование_разных_форматов_файлов_друг_в_друга" id="преобразование_разных_форматов_файлов_друг_в_друга">Преобразование разных форматов файлов друг в друга</a></h1> <div class="level1"> <p> Нам нужна универсальная система преобразования форматов для трансляции изменений между всеми современными и возможно будущими средствами gEDA, а также сторонними программами, которые, вероятно, могут использоваться вместе с программами gEDA. </p> </div> <!-- EDIT2208 SECTION "Преобразование разных форматов файлов друг в друга" [1-555] --> <h2 class="sectionedit2209"><a name="ограничения" id="ограничения">Ограничения</a></h2> <div class="level2"> <p> Поддерживать все возможные преобразования, безусловно, смысла нет. Поэтому ограничимся современными и возможно будущими составляющими gEDA и сторонними программами, которые, вероятно, могут использоваться вместе с программами gEDA. Разумеется, для ряда программ преобразование форматов не имеет смысла и поддерживаться не должно. </p> <p> Идея состоит в использовании промежуточного формата. Сначала транслировать в него, затем — из него. Промежуточный формат должен быть достаточно выразительным, чтобы его можно было без потерь транслировать в формат любой программы gEDA и обратно. </p> <p> “Без потерь” значит, что файл, полученный в результате трансляции должен работать так же, как и исходный. Не обязательно сохранять форматирование и прочие незначительные вещи. </p> <p> Все форматы для трансляции в настоящее время состоят из списков объектов с некоторого рода структурированием. Каждый из объектов имеет подключения и атрибуты. </p> <p> Это наводит на мысль об использовании в качестве промежуточного одного из возможных стандартных форматов списков соединений. </p> <p> Ниже рассматриваются только те форматы, что соответствуют указанной модели. </p> <p> Если возможно, хорошо бы, чтобы выбранный формат уже применялся когда-либо по крайней мере для некоторых из указанных целей, а также имел стороннюю, опубликованную и свободно доступную спецификацию. </p> <p> Должны быть способы включения изменений из любого источника/назначения без смешения различных частей. </p> </div> <!-- EDIT2209 SECTION "Ограничения" [556-3197] --> <h3 class="sectionedit2210"><a name="инструментарий_требующий_поддержки" id="инструментарий_требующий_поддержки">Инструментарий, требующий поддержки</a></h3> <div class="level3"> <ul> <li class="level1"><div class="li"> принципиальные схемы</div> </li> <li class="level1"><div class="li"> топологические схемы</div> </li> <li class="level1"><div class="li"> моделирование</div> </li> </ul> </div> <!-- EDIT2210 SECTION "Инструментарий, требующий поддержки" [3198-3396] --> <h3 class="sectionedit2211"><a name="программы_geda" id="программы_geda">Программы gEDA</a></h3> <div class="level3"> <p> Для форматов файлов данных программ нужно преобразование без потерь, поэтому может потребоваться промежуточный формат хранения данных. </p> <ul> <li class="level1"><div class="li"> gschem</div> </li> <li class="level1"><div class="li"> pcb</div> </li> <li class="level1"><div class="li"> gnucap</div> </li> <li class="level1"><div class="li"> Icarus Verilog</div> </li> </ul> </div> <!-- EDIT2211 SECTION "Программы gEDA" [3397-3733] --> <h3 class="sectionedit2212"><a name="другие_свободные_программы_которые_должны_полностью_поддерживаться" id="другие_свободные_программы_которые_должны_полностью_поддерживаться">Другие свободные программы, которые должны полностью поддерживаться</a></h3> <div class="level3"> <p> Эти программы тоже свободные. Нужен стандарт для их поддержки на равных правах с программами gEDA. </p> <ul> <li class="level1"><div class="li"> NGspice</div> </li> <li class="level1"><div class="li"> Qucs</div> </li> <li class="level1"><div class="li"> Kicad</div> </li> <li class="level1"><div class="li"> Magic</div> </li> <li class="level1"><div class="li"> Electric</div> </li> <li class="level1"><div class="li"> Xcircuit</div> </li> <li class="level1"><div class="li"> Fritzing</div> </li> </ul> </div> <!-- EDIT2212 SECTION "Другие свободные программы, которые должны полностью поддерживаться" [3734-4130] --> <h3 class="sectionedit2213"><a name="импорт_и_экспорт_несвободных_форматов" id="импорт_и_экспорт_несвободных_форматов">Импорт и экспорт несвободных форматов</a></h3> <div class="level3"> <p> Поддержка форматов данных программ позволит программам gEDA наилучшим образом взаимодействовать с коммерческими средствами. Нужна базовая функциональность, но преобразование не обязательно должно быть без потерь. Преобразование без потерь должно быть возможным, но не является главным приоритетом для фактической реализации средств трансляции. </p> <ul> <li class="level1"><div class="li"> Eagle</div> </li> <li class="level1"><div class="li"> Orcad</div> </li> <li class="level1"><div class="li"> LTspice</div> </li> <li class="level1"><div class="li"> Pads</div> </li> </ul> </div> <!-- EDIT2213 SECTION "Импорт и экспорт несвободных форматов" [4131-4893] --> <h3 class="sectionedit2214"><a name="отсутствующая_функциональность_geda" id="отсутствующая_функциональность_geda">Отсутствующая функциональность gEDA</a></h3> <div class="level3"> <p> Надеемся, при наличии системы преобразования форматов у нас появится база для решения следующих вопросов: </p> <ul> <li class="level1"><div class="li"> Обратная трансляция изменений топологических схем и файлов моделирования в принципиальные схемы.</div> </li> <li class="level1"><div class="li"> Анализ статических временных диаграмм.</div> </li> <li class="level1"><div class="li"> Моделирование целостности сигналов после формирования топологии платы.</div> </li> <li class="level1"><div class="li"> Сравнение топологической и принципиальной схем.</div> </li> <li class="level1"><div class="li"> Использование одной и той же схемы для всего проекта целиком.</div> </li> </ul> </div> <!-- EDIT2214 SECTION "Отсутствующая функциональность gEDA" [4894-5778] --> <h3 class="sectionedit2215"><a name="явно_не_поддерживаются" id="явно_не_поддерживаются">Явно не поддерживаются</a></h3> <div class="level3"> <ul> <li class="level1"><div class="li"> Построение графиков</div> </li> <li class="level1"><div class="li"> Команды</div> </li> <li class="level1"><div class="li"> Поведенческое моделирование</div> </li> </ul> </div> <!-- EDIT2215 SECTION "Явно не поддерживаются" [5779-5952] --> <h2 class="sectionedit2216"><a name="общее_представление" id="общее_представление">Общее представление</a></h2> <div class="level2"> <p> Все форматы состоят из списков объектов с подключениями и атрибутами. </p> <p> Традиционно для обмена данными использовались списки соединений, но традиционный подход подразумевает одностороннее преобразование, поскольку при этом теряется информация. </p> <p> Формат должен передавать сущность содержимого не обязательно таким же образом, как родной формат программы или её внутреннее представление. </p> <p> Не обязательно транслировать те части, что обычно уже имеются в библиотеках или специфичны для данной программы, такие как модели, символы или посадочные места. </p> <p> Каждый из претендентов на роль возможного формата должен поддерживать преобразование в любой другой и обратно без потерь. </p> </div> <!-- EDIT2216 SECTION "Общее представление" [5953-7241] --> <h3 class="sectionedit2217"><a name="возможные_форматы" id="возможные_форматы">Возможные форматы</a></h3> <div class="level3"> </div> <h4><a name="spice" id="spice">SPICE</a></h4> <div class="level4"> <p> Популярный формат списка соединений. Использовался для обмена данными, но пока не применялся для описания физического расположения. Проблемы: неправильный синтаксис, недостаточно выразителен. Эти проблемы годами не давали покоя разработчикам. Формат нравится почти всем, за исключением тех, кто хорошо его знает. </p> </div> <h4><a name="verilog" id="verilog">Verilog</a></h4> <div class="level4"> <p> Структурное подмножество представляет собой хороший формат списка соединений. Он правилен, достаточно выразителен и для него опубликован стандарт. Использовался для обмена данными, но пока не применялся для описания физического расположения. </p> </div> <h4><a name="vhdl" id="vhdl">VHDL</a></h4> <div class="level4"> <p> Структурное подмножество представляет собой хороший формат списка соединений. Он правилен, достаточно выразителен и для него опубликован стандарт. Использовался для обмена данными, но пока не применялся для описания физического расположения. </p> </div> <h4><a name="spectre" id="spectre">Spectre</a></h4> <div class="level4"> <p> Структурное подмножество представляет собой хороший формат списка соединений. Он правилен, достаточно выразителен, но принадлежит одной компании (Cadence), поэтому его исключаем. Использовался только для моделирования. </p> </div> <h4><a name="xml" id="xml">XML</a></h4> <div class="level4"> <p> <acronym title="Extensible Markup Language">XML</acronym> — это на самом деле не формат, а синтаксис. На основе <acronym title="Extensible Markup Language">XML</acronym> можно сделать хороший формат, но примеров такого в подобном контексте пока не наблюдалось. Синтаксис хорошо документирован, но никакой сторонней документации по его применению для похожих целей нет. </p> </div> <!-- EDIT2217 SECTION "Возможные форматы" [7242-9713] --> <h3 class="sectionedit2218"><a name="представление_физического_расположения" id="представление_физического_расположения">Представление физического расположения</a></h3> <div class="level3"> <p> Это единственный вид применения, для которого ни Verilog, ни VHDL серьёзно не использовались. </p> <p> Идеи: </p> <ul> <li class="level1"><div class="li"> Соединения тоже являются объектами с подключениями и атрибутами. Соединения имеют значение в любом контексте.</div> </li> <li class="level1"><div class="li"> Положение в схеме может рассматриваться как объект с подключениями и атрибутами (<code>place</code>).</div> </li> <li class="level1"><div class="li"> Контактные площадки, соединители, термоплощадки, переходы, … — всё это тоже объекты с подключениями и атрибутами.</div> </li> <li class="level1"><div class="li"> Чтобы отделить разделы, имеющие значение только в определённом контексте, можно использовать директиву <code>'define</code> (для формата Verilog)</div> </li> <li class="level1"><div class="li"> Формат должен быть описанием высокого уровня. Такое представление должно быть повсюду. То есть речь не должна идти о линиях, прямоугольниках и окружностях.</div> </li> <li class="level1"><div class="li"> Если нужно, линии, прямоугольники и окружности тоже могут быть объектами, но не транслируемыми, так как они не имеют значения в других ситуациях.</div> </li> <li class="level1"><div class="li"> Атрибуты, не имеющие значения, молча игнорируются. Имеющие значение в одном контексте, но не имеющие в другом, игнорируются там, где не имеют смысла.</div> </li> </ul> </div> <!-- EDIT2218 SECTION "Представление физического расположения" [9714-11639] --> <h2 class="sectionedit2219"><a name="приложения" id="приложения">Приложения</a></h2> <div class="level2"> <p> Как один из возможных вариантов рассмотрим формат Verilog. </p> <p> Самостоятельной единицей будет модуль (<code>module</code>): </p> <pre class="code">module my-module(connections); // contents endmodule</pre> <p> Каждый объект в списке имеет совместимый синтаксис: </p> <pre class="code">type #(attributes) name (connections);</pre> <p> Пример: </p> <pre class="code">resistor #(.r(1k)) r123 (a, b); resistor #(.r(1k)) r234 (.p(b), .n(c));</pre> <p> “r” представляет собой имя атрибута. “1k” — это значение (строка). </p> <p> В первом примере соединения определяются по порядку. Во втором их соответствие выводам определяется посредством имён. Узел “b” подключен к выводу “p”, а узел “c” — к выводу “n”. </p> <p> Соединение (“net”) тоже является объектом. </p> <p> В вышеприведённом примере оба резистора непосредственно подключены к узлу “b”. Подключение в принципиальной схеме непосредственно не задаётся, для этого используется соединение (“net”): </p> <pre class="code">resistor #(.r(1k)) r123 (.p(a1), .n(b1)); resistor #(.r(1k)) r125 (.p(b2), .n(c2)); net b (.1(b1), .2(b2));</pre> <p> Имя соединения — “b”. Атрибутов соединение не имеет. </p> <p> Теперь для схемы нужно добавить узлы: </p> <pre class="code">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);</pre> <p> Части, применяемые только в определённом контексте, могут включаться селективно посредством <code>'ifdef</code>: </p> <pre class="code">module my_circuit; 'ifdef SCHEMATIC place ... place ... 'endif res ... res ... net ... endmodule</pre> <p> Сложные соединения могут группироваться в самостоятельные элементы: </p> <pre class="code">module net23842 (1,2,3); net n23482 (1,2); net n84333 (2,3); 'ifdef SCHEMATIC place ... place ... place ... 'endif endmodule</pre> <pre class="code">module net9393 (1,2); net #(.color(blue), .thickness(thin)) n38423 (1,2); endmodule</pre> </div> <!-- EDIT2219 SECTION "Приложения" [11640-] --></body> </html>