This shows you the differences between two versions of the page.
|
gnucap:user:netlist_import_and_export:geda [2025/04/09 14:02] felixs created |
gnucap:user:netlist_import_and_export:geda [2025/05/14 05:54] (current) felixs describe net override handling |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | === Import and export: gEDA schematics === | + | ====== Import and export: gEDA schematics ====== |
| The gEDA file format is well known and flexible. Today it is used in Lepton, which provides an editor similar to gschem. | The gEDA file format is well known and flexible. Today it is used in Lepton, which provides an editor similar to gschem. | ||
| - | A gEDA schematic stores a circuit, and a circuit will be represented as a module. It will be represented as such, using Verilog this gives us | + | A gEDA schematic stores a circuit, and in the [[.|proposed format]] a circuit will be represented as a module. Using Verilog this gives us |
| - | <code>(* S0_vflip=-1 *) | + | <code>(* S0_vflip=-1, S0_scale=.0000254 *) |
| module myschematic( [ports go here] ); | module myschematic( [ports go here] ); | ||
| [parameters..] | [parameters..] | ||
| Line 13: | Line 13: | ||
| - | The attribute ''S0_vflip'' indicates that the y axis points down. Port connections, parameters and instances will be filled in as follows. | + | The attribute ''S0_vflip'' indicates that the y axis points down. The ''S0_scale'' value accounts for gEDA coordinates in 1/1000 inch units. |
| + | Port connections, parameters and instances will be filled in as follows. | ||
| A schematic file is essentially composed of sections for components all of which need to be imported into a Verilog based schematic. | A schematic file is essentially composed of sections for components all of which need to be imported into a Verilog based schematic. | ||
| Letters are used to indicate the section type, the letters discussed here are C, T and N respectively. | Letters are used to indicate the section type, the letters discussed here are C, T and N respectively. | ||
| - | == A symbol file == | + | ===== Symbol files ===== |
| - | a Symbol file contains attributes, and attributes are "name=value" strings stored inside Text blocks. | + | A Symbol file contains the drawing that shows a device, and also attributes, and attributes are "name=value" strings |
| + | stored inside Text blocks. | ||
| + | Symbols take the role of device prototypes in a schematic. In gEDA, a device instance carries a ''basename'' | ||
| + | attribute indicating the file name of the symbol used, akin to a type. But this is not the type, so we use an attribute named | ||
| + | ''S0_geda_basename'' to store this file name. | ||
| - | == Translating C lines, the basics == | + | ===== Schematics ===== |
| + | |||
| + | ==== Translating C lines, the basics ==== | ||
| A component instance starts with a line like "C 45300 48100 1 90 0 symbol-1.sym", where "symbol-1.sym" refers to a symbol file. | A component instance starts with a line like "C 45300 48100 1 90 0 symbol-1.sym", where "symbol-1.sym" refers to a symbol file. | ||
| Line 53: | Line 60: | ||
| ''(* S0_geda_symbol="resistor-1.sym", S0_x_1=44100, S0_y_1=49000, S0_x_2=45000, S0_y_2=49000 *) RESISTOR #(2k) R1 (.\1 (x_cn_2),.\2 (x_cn_3));''. | ''(* S0_geda_symbol="resistor-1.sym", S0_x_1=44100, S0_y_1=49000, S0_x_2=45000, S0_y_2=49000 *) RESISTOR #(2k) R1 (.\1 (x_cn_2),.\2 (x_cn_3));''. | ||
| - | == Translating N lines == | + | ==== Translating N lines ==== |
| 'N' mostly works like 'C', but has no symbol or device name underneath. We store them as devices of type "net" and create a label if "refdes" is not supplied by the user. For example, | 'N' mostly works like 'C', but has no symbol or device name underneath. We store them as devices of type "net" and create a label if "refdes" is not supplied by the user. For example, | ||
| Line 65: | Line 72: | ||
| Note that in "N" lines, gEDA stores coordinates literally. | Note that in "N" lines, gEDA stores coordinates literally. | ||
| - | == The value attribute == | + | ===== Parameters ===== |
| + | |||
| + | ==== Parameter declarations ==== | ||
| + | |||
| + | A parameter in a schematic may be declared using an instance of parameter-1.sym, which carries the ''symbol=schematic-parameter'' attribute. It corresponds to a parameter declaration in a Verilog module. | ||
| + | |||
| + | ==== The value attribute ==== | ||
| + | |||
| + | The value attribute in gEDA translates to parameter assignments. For example | ||
| + | <code>C resistor-1.sym [..] | ||
| + | [..] device=resistor [..] refdes=r1 [..] | ||
| + | T 1 2 3 4 [..] | ||
| + | value=r=1k tnom=17 tc0=3</code> | ||
| + | |||
| + | is represented as | ||
| + | |||
| + | <code> | ||
| + | resistor #(.r(1k), .tnom(17), .tc0(3)) r1( [..] ); | ||
| + | </code> | ||
| + | |||
| + | A value string that lacks parameter names is assigned by position, e.g. ''value=1 2 3'' will be turned into ''#(1,2,3)''. | ||
| + | |||
| + | ===== Connectivity ===== | ||
| + | |||
| + | Connectivity in a Verilog-AMS netlist is simple: A connection is made by connecting a node or a (slice of a) signal to a port. In a gEDA schematic, a | ||
| + | connection is made by drawing or by attribute assignments. | ||
| + | |||
| + | ==== Connections by drawing ==== | ||
| + | |||
| + | Following the "basename" attribute of a component instance reveals the geometric pins positions. There is also also a pin at each end of a net object (see ''N'' line). Pins are connected when they share the position on the screen. In addition, pins that are in between the endpoints of a net spawn an additional connection to the net. But only if the net is vertical of horizontal. For example | ||
| + | |||
| + | N 27100 72900 22600 66700 4 | ||
| + | N 22500 72900 30800 72900 4 | ||
| + | |||
| + | means | ||
| + | |||
| + | (* geda_color=4, S0_x1=27100, S0_y1=72900, S0_x2=22600, S0_y2=66700 *) net #() net0 (x_nn_0,x_nn_1); | ||
| + | (* geda_color=4, S0_x1=22500, S0_y1=72900, S0_x2=30800, S0_y2=72900 *) net #() net1 (x_nn_2,x_nn_3,x_nn_0); | ||
| + | |||
| + | ==== Connections by attribute ==== | ||
| + | |||
| + | === Base case === | ||
| + | |||
| + | A symbol instance that represents a device may have multiple ''net'' attributes with a value like ''A:B,C,D'', see [[https://lepton-eda.github.io/lepton-manual.html/net_003d-attribute-mini_002dHOWTO.html|Lepton manual]]. | ||
| + | These are translated to port assignments, and mix with other port assignments. For example | ||
| + | <code>some_device #() my_refdes(.B(A), .C(A), .D(A), [..] .other(n17),[..]);.</code> | ||
| + | |||
| + | This reflects that ''A:B,C,D'' is actually a contrived short hand syntax for 3 individual assignments. | ||
| + | |||
| + | === net overrides === | ||
| + | |||
| + | Some situations require untangling identify the intent as illustrated as follows. | ||
| + | For example, the data | ||
| + | |||
| + | net=A:B,C // in the symbol | ||
| + | net=A:X,Y // in the instance | ||
| + | net=B:C // in the instance | ||
| + | net=C:X // in the instance | ||
| + | |||
| + | would be interpreted as | ||
| + | |||
| + | .B(A) .C(A) .X(A) .Y(A) .C(B) .X(C) // untangled assignments in order | ||
| + | .B(A) .C(B) .X(C) .Y(A) // effective port assignment (rightmost wins) | ||
| + | |||
| + | Note that the instance value of "net" does not replace the value assigned in the instance as usual. | ||
| + | |||
| + | === Already visible case === | ||
| + | |||
| + | Sometimes those "net" connections correspond to named visible pins inside the symbol. The Lepton manual addresses the situation as follows. | ||
| + | //Creating a ‘net=’ attribute which associates a signal name with a pin which is already visible on the symbol, is probably a bad idea. This does work, but all the ramifications have not been explored yet.// | ||
| + | |||
| + | The "bad idea" finds use in "rail" devices that //specify power, ground, and/or arbitrary nets//. For example, | ||
| + | a gnd-1.sym instance has a port named "1" and a "net=GND:1" attribute. If port "1" is connected to a (positioned) node ''n42'', we represent the instance as | ||
| + | <code>net #() myground0(.\1 (n42), .rail(GND));.</code> | ||
| + | Using a "net" special device to represent the rail device instance is consistent with use in gEDA/Lepton, since ''gnd-1.sym'' is not meant to carry a "device" attribute that would require otherwise. | ||
| + | Following our translation, the additional "GND" node connects all gnd-1.sym instances, implementing the "net" logic, as intended. The name of the second port, "rail", is made up, for now. | ||
| + | ==== Port declarations ==== | ||
| + | |||
| + | A schematic essentially defines a "module" and may have ports. Lepton supplies a symbol with a single pin and a ''symbol=schematic-port'' attribute. Instances of such symbols should be used to declare ports in a schematic. The ''refdes'' attribute sets the port name. | ||
| + | |||
| + | In older schematics ad-hoc solutions and workarounds indicating port connections can be found. For example the ''device=spice-IO'' attribute has been in wide use. Some heuristics cover some of these, but they should not be relied on. | ||
| - | TODO | ||