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 <j...@noqsi.com> 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
