> I'd like to note that we have a serious power tool in gnetlist,
Yup. I had hoped to move some of the "heavyifying" data into a
database or the layout (or whatever), and have gnetlist gather all the
attribute data from the schematic, the database, and the layout. It
can then combine the data in order to update the layout.
For example, to do pin swapping - you could set the pin numbers in the
schematic, or leave them unspecified. If unspecified, gnetlist would
see unassigned pins and allocate them based on some pin map database,
then give that to the layout. On the next iteration, the pin numbers
would be provided by the layout so gnetlist would know not to change
them. Either way, gnetlist gathers the pin information from wherever
it is available, and doles it out to whoever needs it.
On a simpler scale, I expected gnetlist to read my "partdb" that maps
light symbols and design rules to heavy symbols. At least, for those
attributes not already specified in the schematic. No need to have
hundreds of symbols, when you could have hundreds of rows in a
database instead.
Thus, schematics need only concern themselves with schematics - the
symbolic connections of the design. Design-specific component
attributes would be managed by gnetlist and gattrib. Physical layout,
simulation, or other "final" target information would be managed by
their respective tools.
But yes, this means gnetlist would have to take on much more
responsibility for managing the project.
With your workflow, for example, your "heavy" symbols might be "heavy"
only by having a manufacturer's part number in them, or some keyword
that says that it "is" ("purpose=bypass-cap" for example), with all
the other information added by gnetlist.
_______________________________________________
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
