Re: gEDA-user: uEDA .. was .. Re: Heavy Symbols and such

[Dave N6NZ <n6nz@xxxxxxxx>]

This problem was solved in the last millennium, and the tools have been 
written. It's called a relational database.

You can't do a CPU design project involving hundreds of engineers with a 
schematic system that doesn't scale.  In the last century I worked on 
several CPU's where the schematics, when printed out, would be as stack 
of B-size sheets 12 feet high.  But I don't think I've ever actually 
seen schematics printed out in full for any CPU design in the last ten 
years...

One of the several refrigerated, walk-in, CPU's that I helped design was 
the Amdahl 5995.  Amdahl's CAD system had a very nice way of dealing 
with attributes.  All the attributes were in a separate data base from 
the schematics.  The attribute database was kept in a relational 
database -- Amdahl used Oracle on a mainframe.

In geda's terminology, imagine a database table with these columns: 
refdes, attrfile, attrfile_revision, attrname, attrvalue.  You joined a 
schematic to an attribute "file" of a particular "revision" based on 
refdes, and *whoosh* you have a full design file.  It was very easy to 
do various placement experiments by keeping two or three placements in 
different attribute files, and you could easily try each one in the 
autorouter and timing analyzer to see which one gave you the best gate 
array.

In the geda world, I think this makes just as much sense.  The above 5 
column table would work perfectly fine in mySQL or pick your favorite 
database.  A tool that connected to an attribute database and updated a 
.sch file accordingly would be a generalized way to attack a lot of the 
problems being discussed in this thread.

I'm not advocating making a relational database part of the required 
geda tool set -- part of the beauty of geda is that for piddly little 8 
sheet projects like I'm doing now, it doesn't have a lot of heavyweight 
baggage that needs to be learned and dealt with.  But I think using the 
existing tools and computer science that the database world makes 
available would go a long way to making gschem attribute management more 
scalable.  Especially as we start talking about BOM driven attribute 
updates, attributes derived from other attributes, bulk updates of 
attributes, etc.

-dave

DJ Delorie wrote:
> Hey, a thought...
> 
> What if gattrib could accept a *.bom on the command line in addition
> to the *.sch ?  We'd have to color code the cells to say which
> attributes go to the schematics and which to the bom, and figure out
> the logistics, but it might fit what we're trying to accomplish.


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