Re: gEDA-user: Resistor values…

[John Doty <jpd@xxxxxxxxx>]

On Dec 29, 2010, at 6:23 AM, Stephan Boettcher wrote:

> 
> John Doty <jpd@xxxxxxxxx> writes:
> 
>> A better netlister for simulation is difficult as long as the gnetlist
>> front end has hard-coded semantics, especially for hierarchy and
>> slotting.
> 
> Last year (June 2009) LWN published a very nice series by Neil Brown
> about successful design pattern in the Linux kernel.  A lot of that is
> applicable to any sizeable project.
> 
> One pattern is to define (midlayer) interfaces like the gnetlist backend
> interface in terms of library functions.
> 
> http://lwn.net/Articles/336262/
> 
> To fix gnetlist, the hardcoded semantics shall not be pushed to the
> backend, but offered as a library function, to be pulled in by the
> backend.  The infrastructure provided by the library shall offer various
> levels to access the netlist data.  The toplevel shall provide the
> current hardcoded semantics to the existing backends, but future backends
> may choose to use replace the top level call by copies where some
> critical second level calls are replaced. Such copies, when universally
> usefull, can be moved from the backend to the library at some point.
> 
> Somebody who (unlike me) actually knows how that interface looks like
> right now, may comment on how much actually needs to change.

Well, a typical net-centric flat netlist back end may conveniently grab a list of the nets it needs to process from the variable all-unique-nets, defined in gnetlist-post.scm. That's great, but in fact it's just a trivial extract from the primitive (gnetlist:get-all-unique-nets). Then, there's the primitive (gnetlist:get-all-nets) that doesn't check for uniqueness. 

So, while there's a bit of incipient pattern like you describe, it's not very deep, and it's strangely tangled. Why have *two* primitives here? *Neither* of them is really a primitive operation. At the very least (gnetlist:get-all-unique-nets) could be defined in terms of (gnetlist:get-all-nets). 

Then, why always invoke (gnetlist:get-all-unique-nets) to construct all-unique-nets whether it's needed or not? One answer here is that the front end has already done the heavy work beforehand, so it costs very little, but shouldn't the front end only be doing this on demand?

>  I can
> imagine that it's not a lot, since this is really a classical case for
> said design pattern.

The real difficulty here is the complexity of the Guile<->C interface. The functions and data on the C side are accessible to the midlayer only to the extent that somebody does the (difficult) work of exporting them. The C front end is very procedural, performing much semantic processing regardless of whether the back end ever requests the results. Not a good match to the factored, functional approach.

The existing API, despite all this chaos, is truly excellent for small-scale flat printed circuit board netlisting, and unusually extensible beyond that. But it falls down in places where it inappropriately inflicts the semantics of small-scale flat printed circuit board netlisting on different flows, especially DRC and simulation. I cannot think of *any* semantic processing of schematics that is universally appropriate for all flows.

A truly well-factored gnetlist would thus have only one primitive function for processing schematics: parse a schematic file. The schematic semantics would all be in midlayer functions. The back end and other plugins could use these (or not) as needed. But that's a fair amount of work. At Noqsi, we're playing around with the beginnings of something like this at https://github.com/xcthulhu/lambda-geda.

John Doty              Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd@xxxxxxxxx




_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user