This shows you the differences between two versions of the page.
|
gnucap:user:netlist_import_and_export [2025/06/28 02:01] felixs fix reference to r2 (was: p2) |
gnucap:user:netlist_import_and_export [2025/08/18 09:41] (current) felixs extend introduction, some context |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== File format translation ====== | ====== File format translation ====== | ||
| - | We need a universal translator system that can translate in all directions between Free EDA tools, possible future free EDA tools, and outside tools that are likely to be used with free EDA tools. | + | We need a universal translator system that can translate in all directions between Free EDA tools, possible future free EDA tools, and outside tools that are likely to be used with free EDA tools. Most existing EDA tools, both free and commercial, do not permit or implement export functionality needed to access user data, needlessly or intentionally locking in users. |
| + | |||
| + | A starting point is the representation of circuit models in a neutral way. Circuits are processed by various tools, such as by schematic editors or simulators. To enable advanced applications, these tools need to share the user data that describes a circuit. For example, two schematic editors should store schematic circuit data in much the same way as two text editors share text files. A properly designed circuit analysis tool will read circuits created with a schematic editor supporting the interchange format. Similarly, a compiler reads code following certain language rules but created with any text editor. | ||
| ===== Scope ===== | ===== Scope ===== | ||
| Of course, everything to everything is not reasonable. So, set a limit of circuit oriented free EDA tools, possible future tools, and outside tools that are likely to be used them. Of course, tool formats where translation doesn't make sense don't need to be supported. | Of course, everything to everything is not reasonable. So, set a limit of circuit oriented free EDA tools, possible future tools, and outside tools that are likely to be used them. Of course, tool formats where translation doesn't make sense don't need to be supported. | ||
| - | Most tools use a format much like a netlist, often with some special information. So, use a netlist based 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 the tool format to the intermediate format and back. | + | Many tools use a format much like a netlist, often with some special information. Some tools use data in a format resembling a drawing with some metadata no other tool can interpret. A netlist based intermediate format is the better choice, because netlists describe circuits and EDA is about circuits. 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 the tool format to the intermediate format and back. |
| Lossless means that the resultant file is equivalent in how it works. It is not necessary to preserve formatting and other things that don't matter. | Lossless means that the resultant file is equivalent in how it works. It is not necessary to preserve formatting and other things that don't matter. | ||
| Line 247: | Line 250: | ||
| We add a third dimension "z", and a third flip "zflip". We shorten xposition to x, yposition to y, and add a number to have multiple positions. The "z" may indicate a layer name instead of a dimension, depending on the application. | We add a third dimension "z", and a third flip "zflip". We shorten xposition to x, yposition to y, and add a number to have multiple positions. The "z" may indicate a layer name instead of a dimension, depending on the application. | ||
| - | ==== Adding physical position ==== | + | ==== Adding screen position ==== |
| Now we use the attributes to specify the location. We need to locate the various objects in a suitable [[gnucap:user:schematic_geometry|coordinate system]]. In most cases, we need to specify some point of every object that will identify its location. Some programs use some notion of a "center", which is ambiguous. We will use the electrical connection points, often called "pins", as the location points for things that have an electrical connection. For objects that do not have electrical connections, reference points can be used. | Now we use the attributes to specify the location. We need to locate the various objects in a suitable [[gnucap:user:schematic_geometry|coordinate system]]. In most cases, we need to specify some point of every object that will identify its location. Some programs use some notion of a "center", which is ambiguous. We will use the electrical connection points, often called "pins", as the location points for things that have an electrical connection. For objects that do not have electrical connections, reference points can be used. | ||
| Line 415: | Line 418: | ||
| This method could apply to chip layout too, but requires more study, because the symbol/footprint concept is not used in chip layout, and what you can do is more tied to process specifics. | This method could apply to chip layout too, but requires more study, because the symbol/footprint concept is not used in chip layout, and what you can do is more tied to process specifics. | ||
| - | ==== Examples ==== | + | ===== Applications ===== |
| - [[gnucap:user:netlist_import_and_export:geda|gEDA/Lepton schematics]] | - [[gnucap:user:netlist_import_and_export:geda|gEDA/Lepton schematics]] | ||