X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
X-Original-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=gmail.com; s=20120113;
	h=date:from:to:subject:message-id:in-reply-to:references:mime-version
	:content-transfer-encoding;
	bh=G0js2yrEOpgarpot+pbaDrnP+kiOCEsXSOCs9u0PRRs=;
	b=pJnv1RRGlx7GSUAIKitEm6I39HCWFMBZB5Uso94yRvO/xuzWgZvhZqQphqFhyooPCt
	YfPB125iNIZFAMBJx8ZJWVsHwC+upPrNBGVblEVUBWJ9S8QdcO/grpmRuSdZuwNzXNms
	oE/XrI+qOe/xBnPsd5PJWyIvjrSTNUEDXjq0mRPtv87bsYxcHl9OoPZoEx5Nv/nKhP3W
	pe2ODG/10vh17YNxpukLzF9ca3bF4mQiwZqQ/fejlABX6ORFDdcTnMOlT/h4kEOTCGdy
	gWh1W4SD+5UUGTV2ao2zqxKrXnfW8aUkml5NqG1ug2WGkrRY3two5pGm5ckZOIdvgEy+
	PxNQ==
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:date:from:to:subject:message-id:in-reply-to
	:references:mime-version:content-transfer-encoding;
	bh=G0js2yrEOpgarpot+pbaDrnP+kiOCEsXSOCs9u0PRRs=;
	b=ISj3FNyz6JEG2o6TNwdo6G2nMPQ62n/6VyT7TQxu1mfjA+Kocdw7xr2bj7gZUvlURC
	kZrryXRqiGB2SMzqCllzApSCBiN9Yhqvx5aIjV3174OQHyreoF3AkDxiI8tf+axiGJkj
	UoLupMYOEswNnXpmi45/s8+uPsNJm7kSc27+CpDxjt+A2FaFc5SrtjGcVxz6YPP/kMO3
	2+9sxBqtbg8GlT7B3MKMSx7if3zM6p9oy6RISwBaENwc/7yeb/Fl/AUkbgZLj1CqCcGV
	BV2kixNnLI77oSzOdDZGEbZZQS3Mt1mMSZR1iVoR3pTgEwuEhXNWvLIYq0/b8cUFKGnm
	dCqQ==
X-Gm-Message-State:	AE9vXwMCgxlAz1bIi+UlC+yFPL0GDVE+ldDNVwUahJs2n+5rwUy0jvxbVB9MLVNzHEN4Ew==
X-Received:	by 10.28.209.76 with SMTP id i73mr9097135wmg.104.1474569242469;
	Thu, 22 Sep 2016 11:34:02 -0700 (PDT)
Date:	Thu, 22 Sep 2016 20:33:55 +0200
From:	"Nicklas Karlsson (nicklas DOT karlsson17 AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To:	geda-user AT delorie DOT com
Subject:	Re: [geda-user] Possible paths of gnetlist development
Message-Id:	<20160922203355.e6aeb1f6ffc0790bf0d3ea95@gmail.com>
In-Reply-To:	<alpine.DEB.2.11.1609221743230.2817@nimbus>
References:	<alpine DOT DEB DOT 2 DOT 11 DOT 1609221743230 DOT 2817 AT nimbus>
X-Mailer:	Sylpheed 3.5.0beta1 (GTK+ 2.24.25; x86_64-pc-linux-gnu)
Mime-Version:	1.0
Reply-To:	geda-user AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	geda-user AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

4.) A netlister GUI

It is common import schematics does fail without an error message and it is common to have local packages in a subdirecory.


On Thu, 22 Sep 2016 17:59:30 +0200 (CEST)
Roland Lutz <rlutz AT hedmen DOT org> wrote:

> 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.
> 


-- 
Nicklas Karlsson <nicklas DOT karlsson17 AT gmail DOT com>

- Raw text -