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 [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
