Folks,I'd like to present another point of view for our parts discussion. And since I prefer to keep things concrete, let me show a schematic of an actual building block:
Attachment:
DACtoClock.pdf
Description: Adobe PDF document
Now, consider that the project that this is a part of will go through 3-4 versions, each with different parts selection criteria. I very likely will want to use this block for at least one other project, too. For each use, the parts selection requirements will be different: sometimes I want easy procurement, sometimes I want minimum size, sometimes I want space qualification, etc. Maybe I'll need to adjust gain, time constants, etc. also.
It would be really nice if I could use this schematic as a library building block for all of these uses. But that requires a separation of the parts descriptions from the schematic. It's like separating functions and header files in programming. The schematic should stay the same (and it is nice to have defaults in it), but we need to be able to override attributes from something outside.
Right now, we have a BOM that's produced by "gnetlist -g bom", but that's not the BOM *source*: it's a product analogous to the PDF file above. Having the BOM source be the schematic slows down editing and inhibits reuse. Gattrib only solves ~30% of the editing problem: try to change the footprint on a 100 slot device in gattrib, you'll see that the paradigm is broken.
Back annotation is a problem for reuse: the back annotated schematic might be right for one project, but wrong for others.
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