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