The symbol does not need to change but the pin numbering might:
A drop down menu item to assign the pin-mapping would mean only 2 symbols. A second drop down menu item to assign the polarity would mean only one symbol in the library, with two (or more?) graphical elements assigned to it.
Another field could be inside the symbol, and that could be the part number. Then that part number could contain the previous entries and grey those out.
This idea is a little bit off-the-cuff and challenging to describe. With any luck members here will be able to figure out what I mean and describe and develop the idea further.
If the symbol pin name G1, D1, S1, G2, D2, S2 - I would able to present 6 pin parts of 2 FETs in just one symbol (with 2 parts) instead of 6! = 12345*6 = 720 symbols or an symbol (with 240 parts) for all possible 6 pin package out there. I do not think drop down menu for customize pin map of individual symbol like scale with project of 100 symbol. But It would scale with one line of BOM changed for part number, and pin map properties (As a specialize field in symbol)… The same go for spice simulation, one other specialize pin mapping properties for pspice.
All that would be needed to help you guys out would be to give the “edit symbol fields” tool the option to also change the symbol. Plus an easy way to select an alternative symbol with in both that tool and maybe even the right click menu. No need to add some stuff on the file format level. (Adding better user interface options will suffice.)
I would assume that this will all be aided by the new file format. I would assume that it allows the same symbol to define pin mappings for different footprints in some way. (This might be either done with the inheritance feature or could be something where the third entity idea by @Seth_h would help. A usecase i did not see when the latter was presented to us the first time round.)
I followed with interest these three threads and I wanted to add some information how this problem was solved in a very old CAD program I used under MS-DOS (and DR-DOS) since 1986. It was called EEDesigner I and III (last version 2.80 ) made by Visionics.
There were three libraries : schematic, layout and cross-reference.
When you made your decision of implementation in the schematic, you choose a cross-reference defined before in a mapping process shown below :
If you wanted to go from through-hole to SMD you had just to change the cross-reference in the schematic, and redo the layout .
In doing so, the size of the libraries were reduced to the minimum of all parts created and used by a customer, very important at the time hard disk space was measured in Megabytes not in Terabytes !
Of course this method will not give better results if you want to build universal libraries distributed with the CAD program.
I don’t know if other CAD programs use these method of three libraries ??
See - this is why I love classical stuff. It ugly, but work, and no complain from the developer about the complexity of the problem, or standards, or B.S. security problems.
Yes, of course! The “cross-reference” would correspond fairly to the “pin mapping table” in the ongoing discussion. I too believe that it should be a separate asset in its own right (an object you can put into a library for re-use).
Yes, that is what I meant when I referred to the combinatorial explosion we are having currently. That is, when "m" entities pair with “n” entities we have O(m . n) complexity which, simplified, is like square(n).
One may argue that disk space and bandwidth are plenty but the name space where these paired entities live is not. Or conversely a “shortage or scarcity or awkwardness” of such paired entities needlessly slows down design activities in the early stage, typically schematic-centric work e.g. schematic -> simulation -> schematic cycles, part selection, schematic-level refactoring etc.
I hope to add more to this intense discussion that’s shaping up here!
sorry I did not see this post why I started Alternate Symbols and other Symbol Arrangements with similar sight. I also know the trisectioned libraries from Veribest what was a Microstation (Bentley) based PCB editor written for Windows NT in 1997. The slot gates and its pin mapping information is strictly held in the 3rd library called Parts Data Base PDB. Footprints are similar but pads and holes are linked into a padstack library for more generic use
Assume all, new manufacturer part numbers can be introduced for BOM2Purchase matters without touching footprint and symbol library if another similar one exists. The diffrence is, that pin to gate mapping only consists of ASCII information without graphics what can be easily generated by script.
Wayne Starnbaugh seems responsible and working with the V6 library format issue. Regarding his comments in the dev list https://lists.launchpad.net/kicad-developers/msg42100.html he seems not very enthusiastic with your proposal. Once understood the concept of 3rd library part, there is a big benefit for reuse of grafical symbol information and ease of library maintenance. Existing symbol place is required further in coexistence and for the moment there is no need to change anything. Diffrence for schematic workflow is small. Generic Symbol place remains as usual and placement of atomic symbols is done from new library part with a new place command. Therefore generic and atomic symbols can be same. Pin numbers and pin names are overwritten by the 3rd library pin mapping when place command occurs wether they exist in symbol or not.
All we need for the V6 concept, is a unique pin identifier property. For generic use neither pin numbers nor pin names can be recommended becouse this limits later possible pin/gate/intercomponent swaps with backannotation to schematic. If touching this library format we should consider to put variable number of properties also to pins using the very same dialog than placing the general symbol properties. This could also eliminate the power flag issue some users hardly understand. Even PlacePowerPort command can be done by existing PlaceSymbol from the existing power symbol partition while the new Place Device/PlacePart/PlaceComponent or what ever is doing somewhat really diffrent: Symbols remain generic, BOM become purchasable and there is no more need for later footprint associations in workflow.
Possibly the discussion stucks becouse its painful to browse through Waynes code examples to understand library concept. Therefore I suggest to use EBNF diagramms for concept definition and discussion about. Later EBNF can be checked with diffrent use cases and user interface can be defined.
Another similar example using 7400 quad Nand contains some minor changes to design:
Rename DeviceNameList to AliasDeviceList what is more similar to the used AliasSymbol
Rename ViewStyle to PinMapTable what seems the better self explaining expression
Both PinMapTables have same size than QuadOP but redundant PinID columns were removed. First column is always PinID column and used commonly for all units if there is more than one.
In comparison to the Quad OP, the Quad Nand not only allows unit swap but also allows pin swap. Pin swap capability is defined with same (unvisible) pin name i and i for the two inputs.
Number and size of pin map tables are variable in this concept. A pin map table is added semi automatic when adding a symbol to the symbol list. Number of table rows is derived from number of pins in symbol graphics and pinID is inserted automatically. We only have to type in the number of required units. If there is a (unvisible) pin name defined in graphic symbol, the PinName colums contents is also automatically.
To stay on thread topic here is Mosfet FDG311N example what comes with four identical drain pins from the chip substrate. This case shows how to deal with one signal to more than one pin. We have that frequently for electromechanical components like relays, BNC sockets, battery holders what have one signal to several pads for save mechanical attachement or using PCB copper as heat sink.
Symbol N-Mosfet and footprint SC70 are very generic and we can start immediately to leash the purple goat FDG311 to our library without touching any graphics. If we want more detailed graphics identical to the data sheet symbol, we can add the FDG311 symbol with 4 drain pins somewhat later or instruct this job to any librarians as alternate choice mapping
The TTL buffer 74LS244 offers more possibilites how the all-in-one symbol can explode in diffrent choices to fractional symbols. The new pin mapping shows the opposite situation of FDG311. In case of using single buffer gate symbol, we need to map four schematic pin enable to one signal. This can be done by a signal wire or by power port signal in schematic. If not correct done, the forward annotation tool reports warnings while clustering symbols to footprints. Pin maps show several sophisticated swapping possibilies using the following symbols:
LS244 is a all in one 20 pin symbol with power and 2x4 buffers
Buf_En is a single buffer with enable 3 pin symbol, used together with PowerBox
4BufEn is a group of 4 buffers with common enable 8 pin symbil, used twice with one PowerBox
MapTable1 defines unit swap rules between single buffers of same enable while MapTable2 defines unit swap rules between both groups of 4 buffers e.g. to turn the footprint 180 degree in pcb without crossing 2x4 bus traces.
For high pin count BGA semiconductors or connectors we have to address more typical problems. Even if a huge all in one symbol fits to the drawing sheet, there is hardly space to connect peripheral circuit on same page. Therefore the schematics contains an average of only one or two huge components per page. Understanding such schematic circuit becomes similar painful for humans as we would only open the resulting netlist table with a hex editor.
The STM32F107 example shows how to explode the medium size mainstream uC to fractional symbols. WordPort, BytePort,Bitport what can be very generic and mixed in the schematic in any combination as long as the forward annotation tool can cluster all to the number of components intended by the circuit designer.
This is the end of examples for V6 experimental library concept what maps everything. If you see anything else what cannot mapped comfortable by this concept, pls post datasheet link
.
