Re: gEDA-user: gnetlist (was: Perl)
On Jun 1, 2011, at 2:05 AM, DJ Delorie wrote: > >> 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? > > I never said the core had to be C, but given we already have an > official "how to read a .sch" in C, Not really. We have code to read a .sch that's tangled with other core code. > it makes sense to use that library > - somehow. Who's volunteering to make this usable? > For the PCB case, I suspect PCB will produce a scheme > script that the backend can just run to "load" its data. Perhaps a > sch2scm helper program is in order? Can't be written using the present core, because the required raw data is inaccessible. > > By "The Core" I meant "the program called gnetlist, which loads the > design files and runs the backend". Even if you turn that around and > have "the core" be some library that handles the overhead of > initializing a netlister, it's still some minimum amount of overhead > that needs to be done every time. > > Basic housekeeping - parsing the command line, loading the .config and > finding the backend/library locations, reading design files, etc. - > always need to be done. gnetlist's command line parsing is thoroughly encrusted with barnacles: it gets in the way more than it helps. The other stuff is scripted in Scheme, and it seems to me that it would be much cleaner and simpler if it wasn't dependent on the core C 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
Re: gEDA-user: gnetlist (was: Perl)
> 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? I never said the core had to be C, but given we already have an official "how to read a .sch" in C, it makes sense to use that library - somehow. For the PCB case, I suspect PCB will produce a scheme script that the backend can just run to "load" its data. Perhaps a sch2scm helper program is in order? By "The Core" I meant "the program called gnetlist, which loads the design files and runs the backend". Even if you turn that around and have "the core" be some library that handles the overhead of initializing a netlister, it's still some minimum amount of overhead that needs to be done every time. Basic housekeeping - parsing the command line, loading the .config and finding the backend/library locations, reading design files, etc. - always need to be done. > This is already present, in shallow form, in gnetlist.scm and > gnetlist-post.scm, but much of the digestion happens unconditionally Right. Gnetlist calls "that function" before running the backend, but IMHO the backend should call "that function" - if that's what the backend wants. I suspect a small handful of "that functions" would suffice for the netlisters we already have. > OK, I think we now have a nice creative rivalry between Schemers and > Pythonians. Let's see some code! If you wait for me to write code, it won't be in scheme :-) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gnetlist (was: Perl)
I was thinking of how to represent all of the connections and relationships. Then thought of sqlite3, as a database of connections. a table of symbols, a table of pins This table maps the pins to a net and a symbol. a table of nets This is a rather simple database, of connections. To compensate for complexities we want to add. a table of symbol attributes, a table of pin attributes. a table of net attributes to extend the ability of buses a table of busses a table of bus taps - This would contain a bus, bus net, and the individual net. The making a net list (no busses) would be something of the sort. In pseudo code. for each net in the sql query "select net from net_table" do print "net: " for each pin and symbol in sql query "select pin_number, refdes from net_table join symbol_table using symbol_id where net_table.net = net" do print refdes and pin_number end loop print "\n" end loop aliasing nets would be similarly simple, with it's own table. that would map the nets together. Since the data structure is a sqlite3 database any programming language. The database can be held in either memory or in file. Steve On Mon, May 30, 2011 at 6:13 PM, John Doty wrote: > > 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 > ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gnetlist (was: Perl)
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
Re: gEDA-user: gnetlist (was: Perl)
One thought I had for gnetlist backends, is to recode gnetlist as a set of libraries. 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". 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. 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. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: gnetlist (was: Perl)
On 05/30/2011 01:50 AM, John Doty wrote: > But who's volunteering? On 05/30/2011 01:50 AM, John Doty wrote: So, one way or another, we're looking at a new tool, I think. Maybe we keep the old gnetlist around and feed it modified/annotated schematics. > >There will always be people who don't like a particular choice. That's > true of anything. All changing it will accomplish is changing who is pleased and who is disgusted. I'm with DJ here: contributions will decide. The language doesn't matter so much to me. > The big issue here is that our tool, gnetlist, hides much of the design data behind its API. This makes > general-purpose design translation tricky, and annotation impossible. So, the first challenge > to the various language advocates here is to prototype a fundamental API that reveals all, > in a way convenient for higher level factors to exploit. I would like to separate out some API functions and code them if it could be one day's worth at a time. I won't be able to volunteer more than a day every other week. I can see learning what's needed, getting little chunks done, then with the promise of future completion, and maybe merit badges, enlist others to help with little chunks. One problem gettingmovement on code like gEDA is tha magnitude scares away certain kinds of volunteers - they won't start something they can't see finishing, or anything that is weeks long. What does an API prototype look like? An outline? A list of paired commands and descriptions of what they do? John -- Ecosensory ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
