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]" 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: References: X-Mailer: Sylpheed 3.5.0beta1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 Precedence: bulk 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 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