On component databases: Not sure that I have a lot to add, except that when I read it I was looking specifically for the proposed database hookup and found the right answer :) I already have a SQL database for parts, so I'd like to be able to write a quick lib.so in C that hooks up to gschem providing the part lookup function, which results in sensible menus and drop-down lists generated on the fly from current database information. I suspect many people are in the same place. My database will probably need to be extended because it doesn't capture all the physical information at this point, but it would be worth updating my database to get the functionality.
On pin def's: Yes, we've been missing that intermediate layer. Your proposal captures anything I've had to say about it in the past. Power/gnd pins, or to generalized: 'infrastructure pins shared across slots', are the knotty part of the problem. They break encapsulation for slots, or in nomenclature of your proposal, swappable groups. Aside from the 'infrastructure pin' problem, your syntax seems reasonable to me. I'm trying to picture how symbols for slotted parts are going to work. When I started with gEDA, I put implied power/ground connections into my symbols so that they would automagically appear in the net list. I've since concluded that is a Bad Idea, but I'm sure some people will want to do that for some things in the future just because they like that methodology, and if it works for them, it should be supported. My current methodology is to have a symbol for the slotted function, and a symbol for the infrastructure. So, for your example of the 74x00 part, I would have three symbols: a positive-logic NAND symbol that maps to 4 slots, a negative-logic NOR symbol that maps to 4 slots, and an infrastructure symbol that brings out power/ground. My current methodology is to put all the power/ground symbols on some sheet(s) in the back of the stack where they don't clutter up the rest of the design. So, it would be nice if there was some way a rule checker could say that 'package X is missing required infrastructure connections' if I forget to add the pwr/gnd symbol for package or h0rk up the package assignment attribute. Maybe this falls out of the netlister messages, but I suspect the messages will be pretty cryptic unless the netlister has some information to help it along. (*) And if you are going this far, I would want to be able to add two more symbols for my 74x00's, that being inverters in both representations. Those symbols would tie the two input pins together, and map the symbol to a slot in the 74x00. In this case, I would want both pin numbers to be back-annotated onto the input pin in the schematic. Of course, bubble-gum logic is little used any more, but I think some of these concepts would apply to gate-array and FPGA design. Your proposed enhancements would certainly move gEDA in the direction of scalability, and there is a potential to make it more turn-key as well. -dave (*) I'm imagining an attribute that is an assertion that can be checked by the netlister. The assertion should be able to provide it's own error message. At first blush, this sounds like a lot of work. On Dec 26, 2009, at 7:11 PM, DJ Delorie wrote: > > I took the time to document my ideas about heavy vs light symbols and > the pin mapping problem: > > http://www.delorie.com/pcb/component-dbs.html > http://www.delorie.com/pcb/pin-mapping.html > > I got tired of looking it up in the mail archives or referencing it as > "some time in the past...". > > If you remember me saying more about these than I wrote down, and can > find it in the mail archives, let me know so I can add to them. > > DJ > > > _______________________________________________ > geda-user mailing list > [email protected] > http://www.seul.org/cgi-bin/mailman/listinfo/geda-user > _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
