Some thoughts on the underlying data model (symbols)

Disclaimer: Been a happy user of KiCad and appreciate this user forum very much!

When you create/use a symbol in KiCad, notice that:

I also see a new user grappling with a related issue here:

The fundamental reason for such confusion (incuding “upside down NMOS FET” – yes!) is that symbols include pin numbers – right, or wrong?

That makes me think that the Data Model needs improvement. What if the symbol were to capture only the names of the terminals (G,D,S) for example, and a “pin mapping” be used to tie each pin of the symbol to one or more pad in the footprint?

That would mean fewer symbols (e.g. only two or three NMOS FET symbols would suffice, ie no symbol named 2N7000 etc), and fewer footprints and of course, a definitions of the “pin mapping” only at the point of use (which can be the schematic).

To be compatible with the current way of working, pin numbers (if they exist) can be taken as providing this pin mapping by default (the pin mapping at the point-of-use could override the default pin mapping).

[I am aware that pin numbers can be non-numeric, that is beside the point]

Does that make sense?

The symbol file format will be completely rewritten for v6. Check the mailing list for details including the draft of the file format specification.

1 Like

Thanks Rene for pointing to v6. I searched the mailing list (it’s like churning the ocean) and got to the draft at https://docs.google.com/document/d/1lyL_8FWZRouMkwqLiIt84rd2Htg4v1vz8_2MzRKHRkc/edit

I skimmed through it, but not sure how the changes would make it better or worse for use of generic symbols and generic footprints. The “fully defined” or “atomic” parts certainly works fine, no doubt… but associated with that is a combinatorial explosion of atomic symbol-footprint combinations, right?

The generic workflow will always stay a bit more dangerous and work intensive at the design stage. (What you save in lib management must be paid at some other stage.)
Your suggestion would not change that as you will still need to remember to connect the footprint correctly. (At some point you need to make the connection. Right now you do that when assigning the pin numbers as the footprints use the ones from some standard example JEDEC.)


One way around that is what we do with audio connectors where we use the pin name also as the pin number for both symbol and footprint. (Something similar is possible with relays and switches.)
This is not an option for generic packages that are used not only for mosfets but also for diodes, voltage regulators and many more. (So either the symbol defines the connection in the library like now or you need to do it when assigning the footprint. To be honest the later just introduces more places to screw up.)


What the new format brings is a way to share the same symbol graphics with different definitions via the inheritance stuff. I am however not sure this will even be in the first iteration so this might be a bit further down the road (possibly v7).

When I first started using KiCad, many symbols still used names rather than numbers on pins and this caused some issues, so the standard changed to numbers only.
For a start it leads to a proliferation of footprints rather than symbols and these make bigger files

I do this approach currently for my person lib - So far it much easier for me to ensure they are on the right polarity for diodes by using letter name for pin on both footprint and symbol.

I understand that you propose that after placing symbol at schematic you will also decide which pin (by name) to connect to which pad (by footprint pad number).
If I understand you well my answer is: That has no sense.

I assume that when making symbol and footprint I have to be careful to not make any mistake and thanks to that later when designing schematic and PCB I can be thinking at higher level of abstraction not worrying myself with such things like pin numbers and assignments.

I don’t think “standard” of everything number going to cut for may generic , well defined function part like FET, BJT, DIOE, polarized cap, battery etc…

Also - new V6 pin mapping would be great (I do need it some non-generic atomic part) - but should not be use for the generic well define function part case. Because this just make design way harder to get pin correctly. It cancel out the idea of make it simple to design a PCB.

I am not so sure we are on the same page here. Lets just look at mosfets in SOT-23 packages. Lets make it even simpler and ignore the fact that some manufacturers refer to the same lead with a different number and use the current kicad SOT-23 footprint as our reference.

You still have 6 possible permutations of how to assign the function to the leads. (And sadly i fear you will be able to find a part for everyone of these permutations. Some will of course be more common than others.)


At some stage you will need to tell kicad how your intended part is build (which of the 6 permutations does it use). If you want this to be done on the library side then you will either need 6 symbols (like we now have in the device library of the official lib) or you need 6 footprints (the symbol could than use pin numbers G, D, S but you need all possible permutations of the assignment on the footprint side.)

In other words some asset must define the connection and you either select the correct assignment when placing the symbol or when assigning the footprint. I would say the former is the better choice as going the route of having 6 footprints will automatically also mean you need many more SOT-23 footprints for other devices (diodes, bipolar, …)

Having duplicate footprints for the same package has another massive downside. If you ever switch manufacturer and need different pad sizes (to optimize yield or to get it produced in the first place) then you need to change the same thing at more than one location (quite easy to forget one.) So it really creates more work than is worth in my mind.


This does not even change much if you do not want the assignment to be handled in the library (so if there would be a way to make this assignment independent of the library symbol and footprint).

You would still need to make the connection at some point in time. (I would guess there are still the two options of “while selecting the symbol” or “while selecting the footprint”. Here we would in theory have a third time instance of “while importing the netlist”.)


To be honest the safest option will always be the use of a fully defined symbol that you check and double check for correct connection. The main benefit here comes from the fact that you then can easily reuse the same (verified) symbol later on with the same footprint and know it will work.

And regarding the different pin numbering styles of manufacturers. Well i would suggest to simply ignore their numbers and go with what JEDEC or some other standards body defines (for the footprint. Will then simply mean your symbol mapping needs to take this into account)

1 Like

Adding to the above, a non standard pin numbering is going to confuse the assembler, who will normally assume JEDEC

2 Likes

I think you are try to optimize the number of storage here. Then I understand what you coming from.

If you try to think toward the designer use case. I would not care 6 symbols vs 6 footprints. I do care not to have it map wrong. So with the pin naming G,D,S and one symbol can basically guarantee for me no mater which part I’m going to select later my board still going to work. When selecting part, I can quick verify the footprint drawing vs the actual datasheet of the part. And/Or having a naming system on the footprint in such away it easy to tell me.

In the other hand, when I have 6 symbol to chose for 1 footprint. It is a reverse workflow for me. Because at the time I start to pick the part, I need to change all my symbols! This isn’t sound put for me. If have have about 100 of these, I’m sure I will be easily miss one or two of them.

Also, 1 symbol, and 6 footprint is because only current Kicad limitation. With V6 as people telling, we can archiving 1 symbol, and 1 footprint with either number or letter style. But I still stay with letter style for symbol. Because it is truthfully giving be the quick way of verify if I pick to right footprint for the part. Instead of go through 100 symbols and remap pins or replace symbols. It event work fine, if footprint have numbers, and symbol have letter too.

What about when you go to use your schematic to troubleshoot the circuit to find the part that failed after being in use for months/years? Wouldn’t it be better for the schematic to tell you which pin the (for example) gate is on instead of having to dig through datasheets for every component on the signal path that is being traced? This information had to be referenced once at the schematic to PCB stage, why force having to reference it again, which may involve finding the datasheet for what might by then be an obsolete part? Seems to me using pin numbers is a conservation of effort in the hazy future.

1 Like

Um… Everything are are record in within the PCB and Schematic file. So What is to problem here?

It may be better for other people cases which V6 will allow it. But I would think when you are using generic symbol vs. atomic - this risk allays been there. For me the letter of the functional match is the most easy think to help trouble shooting. And how is it with the number matching the number help you trouble shooting your issue without look into the datasheet if you make incorrect choice in the 1st place? Where I try to minimize the incorrect choice in the 1st place by clearly see the pin function from symbol map to footprint?

And what if you found 100 of your customized pin mapping symbol are incorrect in schematic vs. remap PCBNew replace footprint feature, or the CvPCB script?
In my opinion the PCBNEW and CvPCB is the best.

Further more, if I actually need to modify filed of 100+ symbols - I would use my or other people BOM extaction, edit the csv BOM file, and reimport it back. Instead of find and edit one by one on the GUI.
Oh may the new BOM table introduction can also do. But I would still feel simple VIM editor is my best tool for this.

This, in my experienced opinion, is the best option.

Any good technician should be able to identify the “gate” of a 3 legged symbol. Having the schematic identify the “pin” number also is a good way to reduce the effort on the technician if the device package also has a standard pin layout.

1 Like

That doesn’t help in the field with either just paper schematics, or PDF files (no access to the design software) on a portable device.

If the pin mapping was incorrect in the first place, the board wouldn’t work and one would be troubleshooting the first run of boards on the bench… My point is to have the schematic provide sufficient documentation on its own for troubleshooting much later when a previously functional board stopped working.

So please help me how it is difference with numbering or lettering or whatever way without PDF datasheet? I would save everything relate to project including PDF and using relative path. Beside that, please help me to understand the difference here 6 symbol vs 6 footprint and letters vs. number for your question. Because I don’t know the answer , and see no thing differences.