delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2016/09/22/12:03:55

X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Thu, 22 Sep 2016 17:59:30 +0200 (CEST)
From: Roland Lutz <rlutz AT hedmen DOT org>
To: geda-user AT delorie DOT com
Subject: [geda-user] Possible paths of gnetlist development
Message-ID: <alpine.DEB.2.11.1609221743230.2817@nimbus>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Reply-To: geda-user AT delorie DOT com

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 -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019