Kai-Martin Knaak wrote: > > 1) gnetlist should look for a footprint in every instance of a refdes >
Agreed. I use multiple symbols per part as well, but tend to put the footprint= in just the power symbol. I also tend to group all my power symbols onto one or two pages by themselves. > 2) add a known attribute "parts" that lists all symbols of a component > (should the entries in the list be separated by space, or something > more sophisticated?) > I have an alternative suggestion, see below. > 3) gnetlist should complain if the lists of attributes are inconsistent. > > 4) gnetlist should complain if there are different footprints present > Agreed. > 5) gnetlist should complain if a component is not complete (part missing). > That won't work for me. Many of my multi-symbol parts are microcontrollers, broken down by functionality e.g. timer/counter 0, gpio, etc. in addition to just power. If I'm not using a portion of a microcontroller's functionality, then that symbol won't be present. And pins might appear in multiple symbols, due to pin multiplexing in the physical part. It would almost certainly be an error if a pin were actually used in two different places in a project, however ,because that would suggest that you were trying to use the pin for both its GPIO functionality and it's timer/counter function. That doesn't tend to work. But if I have an 8-bit GPIO port symbol and one page uses only three pins, then that same symbol might appear again in several other pages as I allocate the remaining pins. Finally, a design might have two or more microcontrollers or other multi-symbol parts. Maybe what you need instead of a complete parts list is a depends-on specification, to indicate that "if this symbol is present, then the symbols it depends on must also be present and have the same refdes". In my case, my timer/counter and gpio symbols would indicate that they depended only on the microcontroller's power symbol. > 6) gschem should read the parts list and insert all parts at once. > I don't see the point in this, especially since my symbols get spread out across multiple pages. Perhaps what you really mean is that if something is parsing a set of schematic pages, when it encounters a multi-part symbol (detected as a duplicated refdes but without any other conflicting information) then it should merge the information from all those symbols together and emit the result all at once in the output? That's always been my mental model of how multi-symbol parts worked. > 7) auto number of gschem should keep multi-part symbols with the same refdes. > Totally agree, but I have no idea how you would actually implement the ability to auto-assign them in my use case--- where the symbols would be on different pages, and/or you might have two or more parts each with multiple symbols. But at that point I think it's ok to require manual refdes assignment. > Next step would be to treat slotted components like multi-part symbols. > I've always thought that slotting was just a special case of multi-symbol, where the two symbols were visually identical. If slot changes were to allow the symbol to change, then the two are equivalent. Note that I'm not suggesting this, I'd rather we get away from slotting because that's been a source of more symbol entry errors than anything else I've done with gschem. > Any comments? > A few. :) b.g. -- Bill Gatliff b...@billgatliff.com _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user