X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Mon, 26 Sep 2016 13:46:24 +0200 (CEST)
From: Roland Lutz <rlutz AT hedmen DOT org>
To: "Frank Miles (fpm AT u DOT washington DOT edu) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
Subject: Re: [geda-user] Possible paths of gnetlist development
In-Reply-To: <alpine.LRH.2.01.1609230805300.4835@homer03.u.washington.edu>
Message-ID: <alpine.DEB.2.11.1609261315370.2553@nimbus>
References: <alpine DOT DEB DOT 2 DOT 11 DOT 1609221743230 DOT 2817 AT nimbus> <alpine DOT LRH DOT 2 DOT 01 DOT 1609230805300 DOT 4835 AT homer03 DOT u DOT washington DOT edu>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
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

On Fri, 23 Sep 2016, Frank Miles (fpm AT u DOT washington DOT edu) [via 
geda-user AT delorie DOT com] wrote:
> * How does DRC work with these?

IMHO, a separate DRC should be made as unnecessary as possible by 
improving the "normal" netlister warnings.  Of course, the netlister 
doesn't have (and shouldn't have) all the information necessary to do a 
full DRC, but it *should* warn about any inconsistencies it occurs.

(For the most part, my policy has been that a condition which is likely to 
result in an incorrect netlist should be considered a netlisting error. 
As an exception to this, I deliberately re-introduced the attribute 
censorship bug as this seems to be the consensus on this list.  Instead of 
using an arbitrary attribute based on the order of the objects in the 
file, though, I changed the behavior so it doesn't return an attribute 
value at all if there are conflicting definitions.)

As to 1.), it would be possible to introduce DRC as an additional 
netlisting stage which is automatically run with every netlisting process.

As to 2.), the DRC backend would be able to read the intermediate netlist 
file.  This would mean that even for a large design, running the DRC 
backend wouldn't induce significant additional processing time.

As to 4.), running the DRC could be made simple by providing a "Run DRC" 
button, and the DRC results could be presented in a visually appealing 
form.

> * Would #2 allow on-the-fly schematic alteration, perhaps for 
> multiple-format netlisting (spice, kicad,...)?

What do you mean with "on-the-fly schematic alteration"?

Not considering the usual problems with using one schematic for both 
simulation and layout, you would be able to create an intermediate netlist 
file from the schematic file(s) and then print out the spice/kicad/... 
netlists from this file.

> * Would #3 be interoperable with a part database?  So that a DB-key 
> could be inserted into the schematic, but that more detailed part 
> information could be available to subsequent BOM generation and the 
> like?

It would; but it wouldn't provide you any benefit over implementing a part 
database any other way.

Thinking about that, I should probably have added a part database as 
option 5.) since this, too, seems to be a recurring wishlist item.