There is work in progress to replace the Qucs file format for more transparency, versatility and data exchange based on Verilog. See https://codeberg.org/qucs/gui/src/branch/develop/ROADMAP for the current status.

A Qucs schematic stores a circuit, and a circuit will be represented as a Verilog “module”.

(* qucs_this=42, qucs_that=17 ... *)
module myschematic( [ports go here] );
[parameters..]
[instances..]
endmodule

In a Verilog schematic, instances are explicitly parameterised, and connections are explicit too. This saves a lot of guesswork down the line, and schematics no longer break across Qucs versions. Qucs has a few “special” components which need additional treatment, as well as “simulation commands” and “plots”.

Qucs uses a pair of integers to specify a screen coordinate. Connectivity is based on these coordinates. For now, we use the coordinates as a basis for (unique) node names. When reading in a schematic, some checks are in place to spot discrepancies between the the actual connectivity and the apparent geometric connectivity.

In Qucs, a net has two ports at the endpoints. These are aligned vertically or horizontally. In a legacy schematic, a net is a line in the block enclosed by <Wires> and </Wires>. The net

<410 170 570 170 "dc_voltage" 560 130 117>.

will be translated to

(* S0_x1=410, S0_y1=170, S0_x2=570, S0_y2=170 *) net #() dc_voltage ( n_410_170, n_570_170 );

If the label is empty we insert a unique identifier.

A legacy Qucs schematic represents orientation flags in a device instantiation. For example two of the zeroes in

<GND * 1 830 270 0 0 0 0>

indicate no rotation or mirroring is to be applied when drawing the symbol. We store these values as integers in attributes called qucs_mirrored and qucs_rotated.

The Qucs term for name/value pairs attached to device instances is properties. Most properties translate to parameters or attributes. Modifications to the Qucs code are needed to distinguish attributes and parameters reliably.

We store the value of the Symbol property in an attribute named qucs_Symbol, and proceed similarly with “Type”, “File” etc.

Parameter values in Qucs may carry unit specifiers, which we will drop. For example, 1 uF is the scalar value 1.e-6.

Qucs defines a few components with a semi generic type, and a parameter hinting at the actual type. For example, a Sub instance, represented in a schematic as

<Sub "mysub" 0 1 2 3 4 "somedevice.sch" "x" "y" "z" "42">

is processed to look more like

Sub::somedevice mysub _net1 _net2 x=y z=42

When exporting into a netlist for Qucsator. We will store the (actual) type and label following the standard, and store Qucs specific data in attributes as follows.

(* qucs_Type="Sub", qucs_File="some.sch", .. *) somedevice #(.x(y), .z(42)) mysub (_net1, _net2);

The GND device with one pin connects a network to global ground. In Qucs it has no label, but we add a unique one. We translate an instance of GND, which may look like

<GND * 1 280 300 0 0 0 0>

to

(* qucs_label="*", qucs_mirrored=0, qucs_rotated=0, S0_x1=280, S0_y1=300 *) GND #() gnd__42 ( n_280_300 );

A Verilog implementation of GND may look like

module GND(x);
ground x;
endmodule

Eqn is a special device that is used to carry parameters of some sort. It also controls some postprocessing in Qucsator.

We need to extract the intended circuit related parameters from Eqn instances, and make the postprocessing explicit.

Graphics items are saved as objects of type S__graphics with various Qucs specific attributes.

Text is a special kind of graphics object in Qucs. It translates to S__text as described in the top level document.

The label of a graphics item is uniquely generated if not specified.

Some components in a Qucs circuit represent simulation commands. These will be saved and restored as text or graphics items.