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/ j...@noqsi.com _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user