Mail Archives: geda-user/2016/09/22/12:03:55
With the refactored code, some of the features which have been on the
wishlist for gnetlist for quite some time but require more fundamental
changes to the code have become much easier to implement (or feasible at
all). Since Igor2's approach seems to have been somewhat successful, I'm
proposing the potential paths of development for gnetlist in the form of a
"poll"; please let me know in which of the options you are interested or
which you would like to use on a regular basis.
1.) More control over the netlisting stages
Currently, gnetlist runs a series of netlisting stages on one or more
schematic files which ultimately yield the formatted netlist. These are
roughly as follows:
- read the schematics passed on the command line including any referenced
symbols, optionally recursing into subschematics
- change pinnumbers of slotted components according to slot definition
- create "virtual" pins from net= attributes
- build a hierarchical netlist by instantiating the schematics as
appropriate
- group net fragments into nets and decide which name to use
- connect subschematics to the instantiating components
- remove components which have been set as graphical from the component
list
- group components sharing the same refdes into packages
- remove nets which are just an unconnected pin from the net list
- call a backend which prints out the formatted netlist
Depending on what gnetlist is used for, not all of these steps may be
useful. For example, cascade analysis doesn't have a notion of packages,
but a unique refdes= attribute is still required on components so the
netlisting process won't fail. In other cases, it may make sense to
preserve the hierarchical structure of the netlist instead of flattening
it.
The netlister could be restructured so that the stages can be individually
enabled or disabled, controlled by another program, or custom netlisting
stages be introduced.
2.) Saving a generated netlist in an intermediate format
gnetlist first creates a netlist from one or more schematics which is then
printed out by a backend. These two steps could be separated so the
netlist can be saved in an intermediate file which can be read and printed
out by a backend later. As a nice side effect, this would make it easier
to write stand-alone netlist backends in another programming language.
In a next step, a per-schematic, non-flattened version of the netlist
could be saved. This would resemble the way source code is compiled:
after changing one schematic in a multi-schematic project, only the
corresponding netlist file and the target files would have to be updated.
Taking this even further, parts of the netlist could be generated by other
means (e.g., Yosys) and included in a source= attribute like an ordinary
subschematic.
3.) Proper parameter substitution
The currently available patches for parameter substitution in
subschematics are relatively simple: they can only influence attributes
which are output by the backend, not anything which is used by the
netlister itself. In order to be able to use parameters in refdes=,
slot=, or net= attributes, a more sophisticated approach would be
necessary which allows for multiple versions of a schematic to co-exist.
4.) A netlister GUI
At the moment, gnetlist is typically invoked in the background (e.g. by
the PCB "Import Schematic" feature). Now that more useful error and
warning messages are available, it may be desireable to have more direct
control over the netlisting process via a GUI, in particular to be able to
select messages and jump to the corresponding object in the schematic
file.
If you have any other path of development in mind which I haven't listed
above, please let me know.
- Raw text -