Re: gEDA-user: gnetlist (was: Perl)

[John Doty <jpd@xxxxxxxxx>]

On May 31, 2011, at 1:55 AM, DJ Delorie wrote:

> 
> One thought I had for gnetlist backends, is to recode gnetlist as a
> set of libraries.

Now you're talking.

>  The Core would only load the design files
> (schematics, spreadsheets, databases, back-annotation info, etc) as
> raw data; the backend would be required to call at least one library
> function that said "I want data in this format".

Why have a core at all? One of the issues with the current gnetlist is that it cannot be ported to a different Scheme implementation, because the core is Guile-specific. Why not start from Scheme functions for reading/writing .sch format?

>  The "formats" could
> be layered in the library, with each layer distilling the data even
> further, so that each backend could choose how much the data is
> pre-digested.

This is already present, in shallow form, in gnetlist.scm and gnetlist-post.scm, but much of the digestion happens unconditionally in the core. The foundation for the fix for the attribute censorship bug involved just a little refactoring, to move just a tiny bit of this digestion from the core to gnetlist.scm.

> 
> Something like PCB's current backend, for example, would ask for a
> fully flattened design with all connectivity resolved and reduced to
> pin-level netlists.  A Verilog backend might want busses not reduced
> to pin-level, or the heirarchy left intact.  A BOM might not bother
> with connectivity, but ask for additional attribute processing.  Etc.
> 
> This way, we can centralize a lot of the common tasks, without forcing
> those decisions on the backends.

Yes! Put plugins and back ends in control.

OK, I think we now have a nice creative rivalry between Schemers and Pythonians. Let's see some code!

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