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

[Steven Michalske <smichalske@xxxxxxxxx>]

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 <jpd@xxxxxxxxx> 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/
> jpd@xxxxxxxxx
>
>
>
>
> _______________________________________________
> geda-user mailing list
> geda-user@xxxxxxxxxxxxxx
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
>


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