docs/wiki/geda-format_translation.ru.html

   1 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
   2  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
   3 <html>
   4 <head>
   5   <link rel="stylesheet" media="screen" type="text/css" href="./style.css" />
   6   <link rel="stylesheet" media="screen" type="text/css" href="./design.css" />
   7   <link rel="stylesheet" media="print" type="text/css" href="./print.css" />
   8
   9   <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  10 </head>
  11 <body>
  12
  13 <p>
  14 <em>Эта страница доступна также на следующих языках:</em>
  15 <a href="geda-format_translation.html" class="wikilink1" title="geda-format_translation.html">English</a>
  16 </p>
  17
  18 <h1 id="преобразованиеразныхформатовфайловдругвдруга">Преобразование разных форматов файлов друг в друга</h1>
  19 <div class="level1">
  20
  21 <p>
  22 Нам нужна универсальная система преобразования форматов для трансляции
  23 изменений между всеми современными и возможно будущими средствами gEDA, а
  24 также сторонними программами, которые, вероятно, могут использоваться вместе
  25 с программами gEDA.
  26 </p>
  27
  28 </div>
  29
  30 <h2 id="ограничения">Ограничения</h2>
  31 <div class="level2">
  32
  33 <p>
  34 Поддерживать все возможные преобразования, безусловно, смысла нет.  Поэтому
  35 ограничимся современными и возможно будущими составляющими gEDA и сторонними
  36 программами, которые, вероятно, могут использоваться вместе с программами
  37 gEDA. Разумеется, для ряда программ преобразование форматов не имеет смысла
  38 и поддерживаться не должно.
  39 </p>
  40
  41 <p>
  42 Идея состоит в использовании промежуточного формата. Сначала транслировать в
  43 него, затем --- из него. Промежуточный формат должен быть достаточно
  44 выразительным, чтобы его можно было без потерь транслировать в формат любой
  45 программы gEDA и обратно.
  46 </p>
  47
  48 <p>
  49 «Без потерь» значит, что файл, полученный в результате трансляции должен
  50 работать так же, как и исходный. Не обязательно сохранять форматирование и
  51 прочие незначительные вещи.
  52 </p>
  53
  54 <p>
  55 Все форматы для трансляции в настоящее время состоят из списков объектов с
  56 некоторого рода структурированием. Каждый из объектов имеет подключения и
  57 атрибуты.
  58 </p>
  59
  60 <p>
  61 Это наводит на мысль об использовании в качестве промежуточного одного из
  62 возможных стандартных форматов списков соединений.
  63 </p>
  64
  65 <p>
  66 Ниже рассматриваются только те форматы, что соответствуют указанной модели.
  67 </p>
  68
  69 <p>
  70 Если возможно, хорошо бы, чтобы выбранный формат уже применялся когда-либо
  71 по крайней мере для некоторых из указанных целей, а также имел стороннюю,
  72 опубликованную и свободно доступную спецификацию.
  73 </p>
  74
  75 <p>
  76 Должны быть способы включения изменений из любого источника/назначения без
  77 смешения различных частей.
  78 </p>
  79
  80 </div>
  81
  82 <h3 id="инструментарийтребующийподдержки">Инструментарий, требующий поддержки</h3>
  83 <div class="level3">
  84 <ul>
  85 <li class="level1"><div class="li"> принципиальные схемы</div>
  86 </li>
  87 <li class="level1"><div class="li"> топологические схемы</div>
  88 </li>
  89 <li class="level1"><div class="li"> моделирование</div>
  90 </li>
  91 </ul>
  92
  93 </div>
  94
  95 <h3 id="программыgeda">Программы gEDA</h3>
  96 <div class="level3">
  97
  98 <p>
  99 Для форматов файлов данных программ нужно преобразование без потерь, поэтому может потребоваться промежуточный формат хранения данных.
 100 </p>
 101 <ul>
 102 <li class="level1"><div class="li"> gschem</div>
 103 </li>
 104 <li class="level1"><div class="li"> pcb</div>
 105 </li>
 106 <li class="level1"><div class="li"> gnucap</div>
 107 </li>
 108 <li class="level1"><div class="li"> Icarus Verilog</div>
 109 </li>
 110 </ul>
 111
 112 </div>
 113
 114 <h3 id="другиесвободныепрограммыкоторыедолжныполностьюподдерживаться">Другие свободные программы, которые должны полностью поддерживаться</h3>
 115 <div class="level3">
 116
 117 <p>
 118 Эти программы тоже свободные. Нужен стандарт для их поддержки на равных правах с программами gEDA.
 119 </p>
 120 <ul>
 121 <li class="level1"><div class="li"> NGspice</div>
 122 </li>
 123 <li class="level1"><div class="li"> Qucs</div>
 124 </li>
 125 <li class="level1"><div class="li"> Kicad</div>
 126 </li>
 127 <li class="level1"><div class="li"> Magic</div>
 128 </li>
 129 <li class="level1"><div class="li"> Electric</div>
 130 </li>
 131 <li class="level1"><div class="li"> Xcircuit</div>
 132 </li>
 133 <li class="level1"><div class="li"> Fritzing</div>
 134 </li>
 135 </ul>
 136
 137 </div>
 138
 139 <h3 id="импортиэкспортнесвободныхформатов">Импорт и экспорт несвободных форматов</h3>
 140 <div class="level3">
 141
 142 <p>
 143 Поддержка форматов данных программ позволит программам gEDA наилучшим образом взаимодействовать с коммерческими средствами. Нужна базовая функциональность, но преобразование не обязательно должно быть без потерь. Преобразование без потерь должно быть возможным, но не является главным приоритетом для фактической реализации средств трансляции.
 144 </p>
 145 <ul>
 146 <li class="level1"><div class="li"> Eagle</div>
 147 </li>
 148 <li class="level1"><div class="li"> Orcad</div>
 149 </li>
 150 <li class="level1"><div class="li"> LTspice</div>
 151 </li>
 152 <li class="level1"><div class="li"> Pads</div>
 153 </li>
 154 </ul>
 155
 156 </div>
 157
 158 <h3 id="отсутствующаяфункциональностьgeda">Отсутствующая функциональность gEDA</h3>
 159 <div class="level3">
 160
 161 <p>
 162 Надеемся, при наличии системы преобразования форматов у нас появится база для решения следующих вопросов:
 163 </p>
 164 <ul>
 165 <li class="level1"><div class="li"> Обратное аннотирование изменений, сделанных в топологических схемах и файлах моделирования, в принципиальные схемы.</div>
 166 </li>
 167 <li class="level1"><div class="li"> Анализ статических временных диаграмм.</div>
 168 </li>
 169 <li class="level1"><div class="li"> Моделирование целостности сигналов после формирования топологии платы.</div>
 170 </li>
 171 <li class="level1"><div class="li"> Сравнение топологической и принципиальной схем.</div>
 172 </li>
 173 <li class="level1"><div class="li"> Использование одной и той же схемы для всего проекта целиком.</div>
 174 </li>
 175 </ul>
 176
 177 </div>
 178
 179 <h3 id="явнонеподдерживаются">Явно не поддерживаются</h3>
 180 <div class="level3">
 181 <ul>
 182 <li class="level1"><div class="li"> Построение графиков</div>
 183 </li>
 184 <li class="level1"><div class="li"> Команды</div>
 185 </li>
 186 <li class="level1"><div class="li"> Поведенческое моделирование</div>
 187 </li>
 188 </ul>
 189
 190 </div>
 191
 192 <h2 id="общеепредставление">Общее представление</h2>
 193 <div class="level2">
 194
 195 <p>
 196 Все форматы состоят из списков объектов с подключениями и атрибутами.
 197 </p>
 198
 199 <p>
 200 Традиционно для обмена данными использовались списки соединений, но
 201 традиционный подход подразумевает одностороннее преобразование, поскольку
 202 при этом теряется информация.
 203 </p>
 204
 205 <p>
 206 Формат должен передавать сущность содержимого не обязательно таким же
 207 образом, как родной формат программы или её внутреннее представление.
 208 </p>
 209
 210 <p>
 211 Не обязательно транслировать те части, что обычно уже имеются в библиотеках
 212 или специфичны для данной программы, такие как модели, символы или
 213 посадочные места.
 214 </p>
 215
 216 <p>
 217 Каждый из претендентов на роль возможного формата должен поддерживать
 218 преобразование в любой другой и обратно без потерь.
 219 </p>
 220
 221 </div>
 222
 223 <h3 id="возможныеформаты">Возможные форматы</h3>
 224 <div class="level3">
 225
 226 </div>
 227
 228 <h4 id="spice">SPICE</h4>
 229 <div class="level4">
 230
 231 <p>
 232 Популярный формат списка соединений. Использовался для обмена данными, но
 233 пока не применялся для описания физического расположения. Проблемы:
 234 неправильный синтаксис, недостаточно выразителен. Эти проблемы годами не
 235 давали покоя разработчикам. Формат нравится почти всем, за исключением тех,
 236 кто хорошо его знает.
 237 </p>
 238
 239 </div>
 240
 241 <h4 id="verilog">Verilog</h4>
 242 <div class="level4">
 243
 244 <p>
 245 Структурное подмножество представляет собой хороший формат списка
 246 соединений.  Он правилен, достаточно выразителен и для него опубликован
 247 стандарт.  Использовался для обмена данными, но пока не применялся для
 248 описания физического расположения.
 249 </p>
 250
 251 </div>
 252
 253 <h4 id="vhdl">VHDL</h4>
 254 <div class="level4">
 255
 256 <p>
 257 Структурное подмножество представляет собой хороший формат списка
 258 соединений.  Он правилен, достаточно выразителен и для него опубликован
 259 стандарт.  Использовался для обмена данными, но пока не применялся для
 260 описания физического расположения.
 261 </p>
 262
 263 </div>
 264
 265 <h4 id="spectre">Spectre</h4>
 266 <div class="level4">
 267
 268 <p>
 269 Структурное подмножество представляет собой хороший формат списка
 270 соединений.  Он правилен, достаточно выразителен, но принадлежит одной
 271 компании (Cadence), поэтому его исключаем. Использовался только для
 272 моделирования.
 273 </p>
 274
 275 </div>
 276
 277 <h4 id="xml">XML</h4>
 278 <div class="level4">
 279
 280 <p>
 281 XML --- это на самом деле не формат, а синтаксис. На основе XML можно
 282 сделать хороший формат, но примеров такого в подобном контексте пока не
 283 наблюдалось.  Синтаксис хорошо документирован, но никакой сторонней
 284 документации по его применению для похожих целей нет.
 285 </p>
 286
 287 </div>
 288
 289 <h3 id="представлениефизическогорасположения">Представление физического расположения</h3>
 290 <div class="level3">
 291
 292 <p>
 293 Это единственный вид применения, для которого ни Verilog, ни VHDL серьёзно
 294 не использовались.
 295 </p>
 296
 297 <p>
 298 Идеи:
 299 </p>
 300 <ul>
 301 <li class="level1"><div class="li"> Соединения тоже являются объектами с подключениями и атрибутами. Соединения имеют значение в любом контексте.</div>
 302 </li>
 303 <li class="level1"><div class="li"> Положение в схеме может рассматриваться как объект с подключениями и атрибутами (<code>place</code>).</div>
 304 </li>
 305 <li class="level1"><div class="li"> Контактные площадки, соединители, термоплощадки, переходы, ... --- всё это тоже объекты с подключениями и атрибутами.</div>
 306 </li>
 307 <li class="level1"><div class="li"> Чтобы отделить разделы, имеющие значение только в определённом контексте, можно использовать директиву <code>&#039;define</code> (для формата Verilog).</div>
 308 </li>
 309 <li class="level1"><div class="li"> Формат должен быть описанием высокого уровня. Такое представление должно быть повсюду. То есть речь не должна идти о линиях, прямоугольниках и окружностях.</div>
 310 </li>
 311 <li class="level1"><div class="li"> Если нужно, линии, прямоугольники и окружности тоже могут быть объектами, но не транслируемыми, так как они не имеют значения в других ситуациях.</div>
 312 </li>
 313 <li class="level1"><div class="li"> Атрибуты, не имеющие значения, молча игнорируются. Имеющие значение в одном контексте, но не имеющие в другом, игнорируются там, где не имеют смысла.</div>
 314 </li>
 315 </ul>
 316
 317 </div>
 318
 319 <h2 id="приложения">Приложения</h2>
 320 <div class="level2">
 321
 322 <p>
 323 Как один из возможных вариантов рассмотрим формат Verilog.
 324 </p>
 325
 326 <p>
 327 Самостоятельной единицей будет модуль (<code>module</code>):
 328 </p>
 329 <pre class="code">module my-module(connections);
 330 // contents
 331 endmodule</pre>
 332
 333 <p>
 334 Каждый объект в списке имеет совместимый синтаксис:
 335 </p>
 336 <pre class="code">type #(attributes) name (connections);</pre>
 337
 338 <p>
 339 Пример:
 340 </p>
 341 <pre class="code">resistor #(.r(1k)) r123 (a, b);
 342 resistor #(.r(1k)) r234 (.p(b), .n(c));</pre>
 343
 344 <p>
 345 «r» представляет собой имя атрибута. «1k» --- это значение (строка).
 346 </p>
 347
 348 <p>
 349 В первом примере соединения определяются по порядку. Во втором их
 350 соответствие выводам определяется посредством имён. Узел «b» подключен к
 351 выводу «p», а узел «c» --- к выводу «n».
 352 </p>
 353
 354 <p>
 355 Соединение («net») тоже является объектом.
 356 </p>
 357
 358 <p>
 359 В вышеприведённом примере оба резистора непосредственно подключены к узлу
 360 «b». Подключение в принципиальной схеме непосредственно не задаётся, для
 361 этого используется соединение («net»):
 362 </p>
 363 <pre class="code">resistor #(.r(1k)) r123 (.p(a1), .n(b1));
 364 resistor #(.r(1k)) r125 (.p(b2), .n(c2));
 365 net b (.1(b1), .2(b2));</pre>
 366
 367 <p>
 368 Имя соединения --- «b». Атрибутов соединение не имеет.
 369 </p>
 370
 371 <p>
 372 Теперь для схемы нужно добавить узлы:
 373 </p>
 374 <pre class="code">place #(.x(1222), .y(3438)) place11333 (b1);
 375 place #(.x(4334), .y(8433)) place34894 (b2);
 376 place #(.x(9393), .y(4232)) place49334 (a1);
 377 place #(.x(2932), .y(2384)) place34983 (c2);</pre>
 378
 379 <p>
 380 Части, применяемые только в определённом контексте, могут включаться
 381 селективно посредством <code>&#039;ifdef</code>:
 382 </p>
 383 <pre class="code">module my_circuit;
 384   &#039;ifdef SCHEMATIC
 385     place ...
 386     place ...
 387   &#039;endif
 388    res ...
 389    res ...
 390    net ...
 391 endmodule</pre>
 392
 393 <p>
 394 Сложные соединения могут группироваться в самостоятельные элементы:
 395 </p>
 396 <pre class="code">module net23842 (1,2,3);
 397   net n23482 (1,2);
 398   net n84333 (2,3);
 399   &#039;ifdef SCHEMATIC
 400     place ...
 401     place ...
 402     place ...
 403   &#039;endif
 404 endmodule</pre>
 405 <pre class="code">module net9393 (1,2);
 406   net #(.color(blue), .thickness(thin)) n38423 (1,2);
 407 endmodule</pre>
 408
 409 </div>
 410 </body>
 411 </html>