=== 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 a circuit will be represented as a module. It will be represented as such, using Verilog this gives us (* S0_vflip=-1 *) module myschematic( [ports go here] ); [parameters..] [instances..] endmodule The attribute ''S0_vflip'' indicates that the y axis points down. 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 == a Symbol file contains attributes, and attributes are "name=value" strings stored inside Text blocks. == 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. == 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)''. == Implicit connections == 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), .B(A), .B(A), [..] .other(n17),[..]);. 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 referring 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 is consistent with use in gEDA, since ''gnd-1.sym'' is not meant to carry a "device" attribute. The additional "GND" node connects all gnd-1.sym instances, following the "net" logic, as intended. The name of the second port, "rail", is made up, for now.