Bill Gatliff wrote: > Dave N6NZ wrote: > >> I believe this style leads to the most readable schematics, and scales >> up well to larger designs. >> > > Agreed. At least until you do like me, and forget to put down the power > symbol once (or twice). :)
Well, the netlist checker or some other DRC should whine about missing power. I always verify netlist connectivity manually anyway -- these days I do few designs that are so large I can't do it manually (although I recognize they exist.) > > At the risk of going OT, I'll add that as I get better at following the > above strategy--- which is particularly helpful with more complex parts > like microcontrollers--- I get really frustrated at gschem's strong > association between pin numbers on the symbol, and pin numbers on the > footprint. That's just... wrong. It would be nice if there was an > additional "layer of abstraction" somewhere between the symbol and > footprint, such that actual pin assignments weren't made until the > footprint (and slot, if necessary) were specified. Agreed. I've felt that way since the beginning -- for the same reason that you mentioned: changing package. For me, it's pretty annoying to have to replace the schematic symbol to go from through-hole to surface mount just because the pin numbers are different. > As a "mostly software" guy, Most of my opinions about schematic editing were formed as a logic designer on very large projects -- 30 to 60 logic designers (not counting circuit designers, techs, and CAD support). As a logic designer on large CPU projects, I never once thought about how to hook up power (except to keep under my budget of (say) 200A of -4.5V), and as far as clocks go, only the functionality, not distribution. (Although once I was assigned to the clock distribution team for a few weeks, and *all* I thought about was clocks.) Your comments about abstraction are right on -- correct partitioning and abstraction makes the design more manageable, both for a lone designer and for a large team. Adding an extra layer of pin mapping to gEDA, though, would be pretty difficult to do in an upward compatible way. While that's the "right" way, I'm not convinced enough of the ROI to make everyone redo their libraries. -dave _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user