Re: gEDA-user: blue sky ideas - written down finally

[John Doty <jpd@xxxxxxxxx>]

> Component
> A specific instance of an physical part.

That's an instance of a component. There may be many instances of the  
same component in a project, e.g. your usual bypass capacitor, your  
medium power NPN, etc. It is important to capture this fact in the   
automation. The fact that we don't is the main problem with gattrib,  
making it a very inefficient tool when there are many instances of  
the same component.

> Symbol
> A graphical representation of the functionality of a component.  
> Note that there are global symbol files, which apply to all symbols  
> of that type, and specific symbol instances in a schematic, which  
> apply to a single component.  Where it matters, it will be  
> specified which is meant.
> Footprint
> A pattern of copper to which a component is soldered.
>

Missing concept: "package". A given electrical component may be  
available in multiple packages. The package only partly determines  
the footprint: design rules and manufacturing have their say, too. A  
given component may be available in several packages.

> So, the problem is... how heavy should a symbol be? If the symbol  
> is too light, the user must do extra work to associate a symbol  
> with a component accurately, and the risk of getting it wrong is  
> higher

Actually, the risk is lower, since if the user does it it is likely  
to be right, while there are so many variables that a heavy library  
symbol is almost certain to be wrong.

> (a common problem is getting the pinouts on transistors right -  
> hence the "transistor problem" name). If a symbol is too heavy,  
> making changes to the design becomes more complicated (for example,  
> to change an op-amp, you need to change the symbol in the schematic  
> - despite both symbols looking identical).

It's a symptom of a missing layer of abstraction: if your symbols are  
things like "bypass_capacitor", "low_power_opamp", etc. you change  
one symbol to change all instances. The gEDA tools do not encourage  
such factored design: you have to work at it a little bit up front  
(but it saves much time later). At least the tools don't prevent a  
factored approach yet, but I fear for the future, given the  
tremendous pressure to grease the skids to the low productivity path.

> My idea for the database is that it is a plug-in for gschem and  
> gattrib.

Ugh. That sounds like you intend a "hand-cranked" per-instance  
solution, massively inefficient for big projects. A minor clerical  
convenience, no more. Now, if to change all my bypass capacitors from  
0402 to 0603 I could change one line of text somewhere and type  
"make" to propagate, *that* would be a serious timesaving  
improvement. Of course, with some planning and a project symbol  
library, gEDA comes close here. But it would be nice if it was easier  
to refactor the design: it's not as easy as it should be to rebase an  
instance on a project component.

Design the bicycle first, then put on training wheels. Don't design  
the bicycle around the training wheels. If you think GUI from the  
start, you will *never* achieve effective automation.

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