====== 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.
A gEDA schematic stores a circuit, and in the [[.|proposed format]] a circuit will be represented as a module. Using Verilog this gives us
(* S0_vflip=-1, S0_scale=.0000254 *)
module myschematic( [ports go here] );
[parameters..]
[instances..]
endmodule
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.
Letters are used to indicate the section type, the letters discussed here are C, T and N respectively.
===== Symbol files =====
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.
===== 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.
"Component" in gEDA means "symbol instance", unlike in Gnucap, where COMPONENT is the name of the base class for devices.
Inspection of the symbol file is required to determine the type of the component. If the symbol file has ports in it and a "device" attribute, is is very likely a device. A symbol can also be a drawing, and some devices lack a device attribute.
A C line can be followed by additional data enclosed by lines containing "{" and "}" only, respectively. Additional data consists of attributes much like those inside symbol files. Component attributes can extend or override data in the symbol file.
A component that represents a device has an attribute "device" attribute "refdes", these are translated to the device type and instance label respectively.
Other attributes are translated to attribute strings, with the exception of "value". Attribute names are translated by prefixing "geda_" or "S0_geda_", their values are stored literally, i.e. within double quotes, and the usual escape rules.
In order to assign port values, we need to assign a name to each node. In gEDA, nodes are identified by their coordinates, so stringified coordinates or just enumeration yield useful identifiers. Component port names are declared in the symbol file.
Example
C 44100 48900 1 0 0 resistor-1.sym
{
T 44400 49300 5 10 0 0 0 0 1
device=RESISTOR
T 44300 49200 5 10 1 1 0 0 1
refdes=R1
T 44100 48900 5 10 1 1 0 0 1
value=2k
}
becomes
''(* 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 ====
'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 43800 49000 44100 49000 5
becomes
(* geda_color=5, S0_x1=43800, S0_y1=49000, S0_x2=44100, S0_y2=49000 *) net #() net2 (.a1(x_cn_0),.b2(x_cn_2));
Note that in "N" lines, gEDA stores coordinates literally.
===== 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
C resistor-1.sym [..]
[..] device=resistor [..] refdes=r1 [..]
T 1 2 3 4 [..]
value=r=1k tnom=17 tc0=3
is represented as
resistor #(.r(1k), .tnom(17), .tc0(3)) r1( [..] );
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
some_device #() my_refdes(.B(A), .C(A), .D(A), [..] .other(n17),[..]);.
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
net #() myground0(.\1 (n42), .rail(GND));.
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.