Idea for Pin Mapping Hard Wired Items ie:MosFets


The idea stemmed from re-visiting these two(2) threads:

Continuing the discussion from Some thoughts on the underlying data model (symbols):

Continuing the discussion from P Channel Mosfet symbols and footprints:

CAUTION: What I know that I do not know is how simulation is done with KiCad.

As others have mentioned, any transistor can have as many as 6 pin-out configurations; and this can be seen in the screen-grab below:

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.

Thanks in advance!


Just Noticed:

Choose Symbol (14058 items loaded)


There are only about Fourty-Five(45) different Reference Designators; most having the same basic schematic symbol:

Reference designator

i know, i know, i know… the librarians are going to hate me now…


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.)


Hi all,

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 :wink: .

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 ??

Kind regards from France


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!