gEDA-user: Schematic reuse and BOM centricity

[John Doty <jpd-atMUNGEDwispertel_dot_net>]

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:

DACtoClock.pdf

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




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