Mitch Bradley wrote: > I disagree with the premise that there aren't a lot of similar things to > worry about.
Ah, now we're getting to the bottom of the matter :-) For your FPGAs, wouldn't this be just a case of first selecting the part, and then picking a representation that suits your needs ? But, if I may disgress for a moment, perhaps the problem is actually more complex. Given that many chips don't have a single "ideal" representation, be this pin arrangements (e.g., by pin number/position or by function) or fragmentation of the part, could perhaps another layer be useful, where the "generic chip" is defined, and the actual symbol(s) to use in the schematic are then constructed case by case from this template ? (In fact, this wouldn't have to be hierarchical - just a reference to the template as a data source would be sufficient.) The template would indicate which pins are there for assignment, and it would provide the name-of-pin and type-of-pin information. And, unlike a simple copy, it would provide a channel for passing updates. > On top of that, many parts these days have multifunction pins, leading > to a desire to name the pins according to their actual use, for > readability. And if you care about design rule checking, for production > designs you will probably want to make variant symbols in which some of > the configurable pins have their I/O direction and type specified > according to the use in the design. Yes, perhaps the pin type should also become a visible property. I like the concept of Kicad that no important information is hidden from view. > Standard part families like the 74xx series are barely even interesting > these days, so making any decisions based on their characteristics is > the wrong optimization. Agreed, they're far from being the main issue. > I have been involved with CAD systems over a span of 25 years, in the > roles of hardware designer, CAD software developer/maintainer, and > library maintainer. You beat me there hands down :-) > My experience has been that library maintenance, > while it may appear to be a trivial issue, is really the hardest part, > because it is a moving target. Yes, and because you most likely don't have a comprehensive set of formal rules that the machine could help you check. > This is why I think that building CAD libraries on a powerful substrate > is the way to go. Well, so what would the database actually do ? I still see very much a hierarchy, where you make a different decision at each level. But perhaps we're not talking about the same thing. What would be the smallest indivisible object in your database ? A component (symbol) or module (footprint), or a pin/pad ? - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net/____________________________________________/ ------------------------ Yahoo! Groups Sponsor --------------------~--> See what's inside the new Yahoo! Groups email. http://us.click.yahoo.com/2pRQfA/bOaOAA/yQLSAA/W4wwlB/TM --------------------------------------------------------------------~-> Please read the Kicad FAQ in the group files section before posting your question. Please post your bug reports here. They will be picked up by the creator of Kicad. Please contribute your symbols/modules to the library folder in the group files section. For building Kicad from source and other development questions visit the kicad-devel group at http://groups.yahoo.com/group/kicad-devel Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/kicad-users/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
