-
Notifications
You must be signed in to change notification settings - Fork 214
/
ROADMAP
36 lines (28 loc) · 1.72 KB
/
ROADMAP
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
ROADMAP for Qucs, after 0.0.20
We need to support a file format that allows data exchange to and from other
tools. The rest (and what's to come) will easily fall into place.
Traditionally, Qucs defines a schematic format and a flat netlist format. Both
are tied to a fixed component library, and don't work very well without it.
A new data format will replace the Qucs schematic format. It will be based on
the structural subset of Verilog, an established IEEE standard, after adding a
few conventions [1]. A lossless roundtrip from Qucs schematic to the new format
and back is envisaged and feasible. Among other things it will add
- explicit connectivity,
- port and parameter names,
- self-containedness,
- support for user defined models.
The Qucs flat netlist format only serves the purpose of simulating with
Qucsator, and netlists should be generated by a separate program. Generally,
other tools should aim to process data from new schematic files directly,
following the the standard interpretation.
It will be easy to add new devices or replace them as needed. Normal
Verilog-AMS rules apply. A device is identified by its name and its interface
with possible overloads aka binning.
Verilog-A models, such as the standard spice primitives [2], semiconductor
compact models [3] or (coupled) transmission lines [4] will become user input
and disentangled from the schematic editor. More on Verilog-AMS is on the way,
but will likely need a model compiler.
[1] http://gnucap.org/dokuwiki/doku.php/gnucap:user:netlist_import_and_export
[2] https://git.savannah.gnu.org/cgit/gnucap/gnucap-modelgen-verilog.git/tree/vams?h=develop
[3] e.g. CMC models
[4] https://git.savannah.gnu.org/cgit/gnucap/gnucap-modelgen-verilog.git/tree/examples?h=develop