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.
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.
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));.
'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.
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 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 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.
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);
A symbol instance that represents a device may have multiple net attributes with a value like A:B,C,D, see 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.
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.
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.
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.