<!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>
distrib
>
Mageia
>
7
>
i586
>
media
>
core-release
>
by-pkgid
>
7470e5ba72ba56f1e2ffc81f92c36e65
>
files
>
72
