docs/wiki/geda-format_translation.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   <title></title>
   6   <link rel="stylesheet" media="screen" type="text/css" href="./style.css" />
   7   <link rel="stylesheet" media="screen" type="text/css" href="./design.css" />
   8   <link rel="stylesheet" media="print" type="text/css" href="./print.css" />
   9
  10   <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  11 </head>
  12 <body>
  13
  14
  15 <h1 class="sectionedit754"><a name="file_format_translation" id="file_format_translation">File format translation</a></h1>
  16 <div class="level1">
  17
  18 <p>
  19
  20 We need a universal translator system that can translate in all directions between gEDA tools, possible future gEDA tools, and outside tools that are likely to be used with gEDA tools.
  21 </p>
  22
  23 </div>
  24 <!-- EDIT754 SECTION "File format translation" [1-225] -->
  25 <h2 class="sectionedit755"><a name="scope" id="scope">Scope</a></h2>
  26 <div class="level2">
  27
  28 <p>
  29
  30 Of course, everything to everything is not reasonable.  So, set a limit of gEDA tools, possible future gEDA tools, and outside tools that are likely to be used with gEDA tools.  Of course, tool formats where translation doesn&#039;t make sense don&#039;t need to be supported.
  31 </p>
  32
  33 <p>
  34 The idea is to have an intermediate format.  First translate to the intermediate format, then translate out.  The intermediate format should be sufficiently expressive that there can be a lossless round trip from any gEDA tool format to the intermediate format and back.
  35 </p>
  36
  37 <p>
  38 Lossless means that the resultant file is equivalent in how it works.  It is not necessary to preserve formatting and other things that don&#039;t matter.
  39 </p>
  40
  41 <p>
  42 All of the formats needing translation presently consist of lists of objects, with some kind of encapsulation.  Each object has connections and attributes.
  43 </p>
  44
  45 <p>
  46 This suggests the possible of a standard netlist format as the intermediate format.
  47 </p>
  48
  49 <p>
  50 Further discussion related only to formats that fit this model.
  51 </p>
  52
  53 <p>
  54 If possible, the format chosen should have a history of use for at least part of this, and have a published specification that is externally controlled and freely available.
  55 </p>
  56
  57 <p>
  58 There needs to be a way to merge changes from any target/source without messing up other parts.
  59 </p>
  60
  61 </div>
  62 <!-- EDIT755 SECTION "Scope" [226-1514] -->
  63 <h3 class="sectionedit756"><a name="tool_types_needing_support" id="tool_types_needing_support">Tool types needing support</a></h3>
  64 <div class="level3">
  65 <ul>
  66 <li class="level1"><div class="li"> schematic</div>
  67 </li>
  68 <li class="level1"><div class="li"> layout</div>
  69 </li>
  70 <li class="level1"><div class="li"> simulation</div>
  71 </li>
  72 </ul>
  73
  74 </div>
  75 <!-- EDIT756 SECTION "Tool types needing support" [1515-1592] -->
  76 <h3 class="sectionedit757"><a name="geda_tools" id="geda_tools">gEDA tools</a></h3>
  77 <div class="level3">
  78
  79 <p>
  80 Lossless round trip is required, so archival storage can use the intermediate format.
  81 </p>
  82 <ul>
  83 <li class="level1"><div class="li"> gschem</div>
  84 </li>
  85 <li class="level1"><div class="li"> pcb</div>
  86 </li>
  87 <li class="level1"><div class="li"> gnucap</div>
  88 </li>
  89 <li class="level1"><div class="li"> Icarus Verilog</div>
  90 </li>
  91 </ul>
  92
  93 </div>
  94 <!-- EDIT757 SECTION "gEDA tools" [1593-1749] -->
  95 <h3 class="sectionedit758"><a name="other_free_tools_that_should_be_well_supported" id="other_free_tools_that_should_be_well_supported">Other free tools that should be well supported</a></h3>
  96 <div class="level3">
  97
  98 <p>
  99 These tools are free, too.  The standard needs to support them on an equal basis with gEDA.
 100 </p>
 101 <ul>
 102 <li class="level1"><div class="li"> NGspice</div>
 103 </li>
 104 <li class="level1"><div class="li"> Qucs</div>
 105 </li>
 106 <li class="level1"><div class="li"> Kicad</div>
 107 </li>
 108 <li class="level1"><div class="li"> Magic</div>
 109 </li>
 110 <li class="level1"><div class="li"> Electric</div>
 111 </li>
 112 <li class="level1"><div class="li"> Xcircuit</div>
 113 </li>
 114 <li class="level1"><div class="li"> Fritzing</div>
 115 </li>
 116 </ul>
 117
 118 </div>
 119 <!-- EDIT758 SECTION "Other free tools that should be well supported" [1750-1980] -->
 120 <h3 class="sectionedit759"><a name="non-free_import_and_export" id="non-free_import_and_export">Non-free import and export</a></h3>
 121 <div class="level3">
 122
 123 <p>
 124 Support for these will allow gEDA tools to play nice with the commercial world.  Basic functionality is needed, but it doesn&#039;t need to be lossless.  Lossless should be possible, but it is not a high priority to actually implement it.
 125 </p>
 126 <ul>
 127 <li class="level1"><div class="li"> Eagle</div>
 128 </li>
 129 <li class="level1"><div class="li"> Orcad</div>
 130 </li>
 131 <li class="level1"><div class="li"> LTspice</div>
 132 </li>
 133 <li class="level1"><div class="li"> Pads</div>
 134 </li>
 135 </ul>
 136
 137 </div>
 138 <!-- EDIT759 SECTION "Non-free import and export" [1981-2293] -->
 139 <h3 class="sectionedit760"><a name="geda_missing_functionality" id="geda_missing_functionality">gEDA missing functionality</a></h3>
 140 <div class="level3">
 141
 142 <p>
 143 Hopefully having a translator system will provide a seed so these can be done.
 144 </p>
 145 <ul>
 146 <li class="level1"><div class="li"> Back annotation from layout or simulation to schematic</div>
 147 </li>
 148 <li class="level1"><div class="li"> Static timing analysis</div>
 149 </li>
 150 <li class="level1"><div class="li"> Post-layout signal integrity simulation.</div>
 151 </li>
 152 <li class="level1"><div class="li"> Layout - schematic comparison</div>
 153 </li>
 154 <li class="level1"><div class="li"> Use of the same schematic for the whole project.</div>
 155 </li>
 156 </ul>
 157
 158 </div>
 159 <!-- EDIT760 SECTION "gEDA missing functionality" [2294-2628] -->
 160 <h3 class="sectionedit761"><a name="explicitly_not_supported" id="explicitly_not_supported">Explicitly not supported</a></h3>
 161 <div class="level3">
 162 <ul>
 163 <li class="level1"><div class="li"> Plotting</div>
 164 </li>
 165 <li class="level1"><div class="li"> Commands</div>
 166 </li>
 167 <li class="level1"><div class="li"> Behavioral modeling</div>
 168 </li>
 169 </ul>
 170
 171 </div>
 172 <!-- EDIT761 SECTION "Explicitly not supported" [2629-2714] -->
 173 <h2 class="sectionedit762"><a name="concepts" id="concepts">Concepts</a></h2>
 174 <div class="level2">
 175
 176 <p>
 177
 178 All of these consist of lists of objects, with connections and attributes.
 179 </p>
 180
 181 <p>
 182 It is tradition that a netlist is used for interchange, but the traditional approach only goes one way, because information is lost in the translation.
 183 </p>
 184
 185 <p>
 186 The format must convey the meaning, not necessarily in the same way as the tool&#039;s native format or internal storage.
 187 </p>
 188
 189 <p>
 190 It is not necessary to translate parts that are usually in libraries, and are tool specific, such as models, symbols, or footprints.
 191 </p>
 192
 193 <p>
 194 All contenders for possible formats must support a loss round-trip to any other.
 195 </p>
 196
 197 </div>
 198 <!-- EDIT762 SECTION "Concepts" [2715-3299] -->
 199 <h3 class="sectionedit763"><a name="some_possible_formats" id="some_possible_formats">Some possible formats</a></h3>
 200 <div class="level3">
 201
 202 </div>
 203
 204 <h4><a name="spice" id="spice">Spice</a></h4>
 205 <div class="level4">
 206
 207 <p>
 208
 209 A popular netlist format.  It has a history of use for interchange, but not yet for physical placement.  Problems: irregular syntax, not sufficiently expressive.  These problems have been a major hassle for years for developers.  It is well accepted, but not by people who know it well.
 210 </p>
 211
 212 </div>
 213
 214 <h4><a name="verilog" id="verilog">Verilog</a></h4>
 215 <div class="level4">
 216
 217 <p>
 218
 219 The structural subset is a good netlist format.  It is regular, sufficiently expressive, and has a published standard.  It has a history of use for interchange, but not yet for physical placement.
 220 </p>
 221
 222 </div>
 223
 224 <h4><a name="vhdl" id="vhdl">VHDL</a></h4>
 225 <div class="level4">
 226
 227 <p>
 228
 229 The structural subset is a good netlist format.  It is regular, sufficiently expressive, and has a published standard.  It has a history of use for interchange, but not yet for physical placement.
 230 </p>
 231
 232 </div>
 233
 234 <h4><a name="spectre" id="spectre">Spectre</a></h4>
 235 <div class="level4">
 236
 237 <p>
 238
 239 The structural subset is a good netlist format.  It is regular, sufficiently expressive, but belongs to one company (Cadence), so rule it out.  It has a history of use for simulation only.
 240 </p>
 241
 242 </div>
 243
 244 <h4><a name="xml" id="xml">XML</a></h4>
 245 <div class="level4">
 246
 247 <p>
 248
 249 <acronym title="Extensible Markup Language">XML</acronym> is not really a format but a syntax.  A good format can easily be made based on <acronym title="Extensible Markup Language">XML</acronym>, but has no history of use in a similar context.  The syntax is well documented but there is no outside documentation of application in any related use.
 250 </p>
 251
 252 </div>
 253 <!-- EDIT763 SECTION "Some possible formats" [3300-4524] -->
 254 <h3 class="sectionedit764"><a name="representation_of_physical_placement" id="representation_of_physical_placement">Representation of physical placement</a></h3>
 255 <div class="level3">
 256
 257 <p>
 258
 259 This part is the only part where there is not a strong history of use for VHDL and Verilog.
 260 </p>
 261
 262 <p>
 263 Ideas:
 264
 265 </p>
 266 <ul>
 267 <li class="level1"><div class="li"> Nets are also objects with connections and attributes.  Nets have meaning in all contexts.</div>
 268 </li>
 269 <li class="level1"><div class="li"> A place on a schematic can be considered to be an object, with connections and attributes.</div>
 270 </li>
 271 <li class="level1"><div class="li"> Pads, connectors, thermals, vias .. are also objects, with connections and attributes.</div>
 272 </li>
 273 <li class="level1"><div class="li"> Use `define (assuming Verilog format) to set aside sections that have meaning in one context but not another.</div>
 274 </li>
 275 <li class="level1"><div class="li"> This is a high level description.  Take a high level view across all.  It&#039;s not lines, boxes, and circles.</div>
 276 </li>
 277 <li class="level1"><div class="li"> If you must, lines, boxes, and circles can be objects too, but not translatable because they have no meaning in other contexts.</div>
 278 </li>
 279 <li class="level1"><div class="li"> Attributes that have no meaning are silently ignored.  Attributes that have meaning in one context but not in another context are ignored where they have no meaning.</div>
 280 </li>
 281 </ul>
 282
 283 </div>
 284 <!-- EDIT764 SECTION "Representation of physical placement" [4525-5482] -->
 285 <h2 class="sectionedit765"><a name="applications" id="applications">Applications</a></h2>
 286 <div class="level2">
 287
 288 <p>
 289
 290 Choosing the Verilog format as one possibility.
 291 </p>
 292
 293 <p>
 294 The unit of encapsulation is the “module”:
 295
 296 </p>
 297 <pre class="code">module my-module(connections);
 298 // contents
 299 endmodule</pre>
 300
 301 <p>
 302
 303 Each object in the list has a consistent syntax:
 304
 305 </p>
 306 <pre class="code">type #(attributes) name (connections);</pre>
 307
 308 <p>
 309
 310 Example:
 311
 312 </p>
 313 <pre class="code">resistor #(.r(1k)) r123 (a, b);
 314 resistor #(.r(1k)) r234 (.p(b), .n(c));</pre>
 315
 316 <p>
 317
 318 “r” is the name of an attribute.  “1k” is the value (a string).
 319 </p>
 320
 321 <p>
 322 In the first example, connections are determined by order.  In the second, they are mapped by name.  Node “b” connects to pin “p” and node “c” connects to pin “n”.
 323 </p>
 324
 325 <p>
 326 A “net” is also an object.
 327 </p>
 328
 329 <p>
 330 In the above example, both connect to node b directly.  In a schematic representation the connection would not be direct, but through a “net”
 331
 332 </p>
 333 <pre class="code">resistor #(.r(1k)) r123 (.p(a1), .n(b1));
 334 resistor #(.r(1k)) r125 (.p(b2), .n(c2));
 335 net b (.1(b1), .2(b2));</pre>
 336
 337 <p>
 338
 339 The name of the net is “b”.  It has no attributes.
 340 </p>
 341
 342 <p>
 343 For schematic, you can now place the nodes:
 344
 345 </p>
 346 <pre class="code">place #(.x(1222), .y(3438)) place11333 (b1);
 347 place #(.x(4334), .y(8433)) place34894 (b2);
 348 place #(.x(9393), .y(4232)) place49334 (a1);
 349 place #(.x(2932), .y(2384)) place34983 (c2);</pre>
 350
 351 <p>
 352
 353 Portions that apply in only certain contexts can be selectively included with &#039;ifdef:
 354
 355 </p>
 356 <pre class="code">module my_circuit;
 357   `ifdef SCHEMATIC
 358     place ...
 359     place ...
 360   `endif
 361    res ...
 362    res ...
 363    net ...
 364 endmodule</pre>
 365
 366 <p>
 367
 368 Complex nets can be encapsulated:
 369
 370 </p>
 371 <pre class="code">module net23842 (1,2,3);
 372   net n23482 (1,2);
 373   net n84333 (2,3);
 374   `ifdef SCHEMATIC
 375     place ...
 376     place ...
 377     place ...
 378   `endif
 379 endmodule</pre>
 380 <pre class="code">module net9393 (1,2);
 381   net #(.color(blue), .thickness(thin)) n38423 (1,2);
 382 endmodule</pre>
 383
 384 </div>
 385 <!-- EDIT765 SECTION "Applications" [5483-] --></body>
 386 </html>