KLC does not specify logical vs physical symbol design

[evanshultz]

There are two approaches to symbol design with respect to multiple pins of the same net/functionality: logical vs physical.

For a physical symbol, each pin on the package gets a pin in the symbol.

For a logical symbol, there is one pin on the symbol which then connects to multiple package pins.

KLC is mum on this topic. @jkriege2 mentioned a few ways to handle it in response to my question at https://github.com/KiCad/kicad-library/issues/849, and I think it would be an excellent point of clarification for those designing symbols and footprints. I could make an argument for both methods above, and if a logical symbol is selected I could further argue regarding implementation methods, so perhaps a consensus can be reached and KLC updated to give clarity to librarians and contributors?

[jkriege2]

see discussion and draft here:

https://github.com/KiCad/kicad-library/issues/879 https://github.com/SchrodingersGat/kicad-library/wiki/KLC

Best, JAN

[evanshultz]

Thanks @jkriege2. All pins should be shown so that the pin number filter in CvPcb works. That's clear.

But what about stacking the pins on top of each other so the schematic symbol appears to have just a single pin. That's the root of my question. Is there a rule or suggestion for this situation?

[JoanTheSpark]

stacking depends on the piece of software that accepts pins over each other as being connected. You really want to bet the library on that? I'd rather push for some organized way within eeschema/KiCAD that would allow to have one symbol pin stand for several physical pins. Like the way when you print pages out of a large document were you can say print page(s) [1,3-5,11-16,34,98], you know?

[SchrodingersGat]

@JoanTheSpark I would love to see this too.

Check out the proposed specification for the .sweet file format - this functionality exists! Well, it exists in the future. And isn't that just as good?

For now, I do not like stacking pins. There are a few symbols in the libs that rely on this "functionality" (hack, really) but I would advise against adding new symbols that rely on this.

I think this needs to be specified in the updated KLC.

Regarding the suggestions in https://github.com/KiCad/kicad-library/issues/879

1. Having specialized footprints for connecting multiple physical pins to a single logical pin is a bad idea. The footprints are designed to be separated from the schematic and agnostic to the intended function.
2. Overlaying multiple pins is feasible (it works, at least for now), but I would not recommend it.
3. The best bet (for now) is to add each individual pin to the schematic.
4. This will be "fixed" when the .sweet format is released (oh what a day that will be)

[jkriege2]

If you stack all the NC-pins, they get all connected to each other in the current KiCAD-versions!

[SchrodingersGat]

And it looks like this behaviour is here to stay. I pushed a patch to fix this but there was no love.

In general the KiCad libs should heavily discourage pin stacking as it is non obvious to the user and in the worst case can cause failures such as your example here.

[poeschlr]

@SchrodingersGat, @jkriege2 Is it a good idea to have invisible pins at all? They get connected if you either have a junction or a device placed at the wrong place. Yes one gets an erc error if this happens.

[SchrodingersGat]

Personally, I do not think they are a good idea. The only purpose they serve is to match the pin count of a symbol with the pad count of a footprint.

If we can think of a better way to associate pin count then we can outlaw invisible and NC pins in the KLC completely.

[SchrodingersGat]

@evanshultz @jkriege2 @poeschlr ok we are on the home stretch for KLC 2.0

Time to make a decision about invisible pins! Do we:

a) Allow them for NC pins only b) Don't allow any invisible pins (NC must be visible) c) Disallow NC pins entirely (breaking associate-by-pin-count)

[evanshultz]

Well, I suppose the issue should be driven by what's best for KiCad rather than what's easiest.

a) CvPcb does its thing and matches up symbol and footprint by pin count. We only see connectable pins. b) Sounds ugly and cluttered on the schematic canvas to me. c) To match up footprints we'd need to replace virtually all F3 and FPFilter fields with the exact footprint name. And for small variations _Handsoldering we'd have to list each variation individually.

The first option seems the best to me. It continues to use the existing infrastructure of CvPcb and the libraries while giving great flexibility for variations in footprints. I could make a minor argument for the last option so that footprints are explicitly assigned, but that goes away once all symbols have appropriate FPFilters (which may never happen...). For the user I think it works well, and also a bonus that it's similar to the existing library design, I vote for only allowing NC pins to be invisible.

And what about pin stacking? Never allowed?

[SchrodingersGat]

Perhaps we should allow pin stacking but only if:

• Pins are not of type "No Connect"
• Pin names are all the same
• All but one of the pins is set to invisible

This stays in line with all current requirements (and functionality of Kicad code)

[jkriege2]

I vote also for NC visible.

About stacking: I would allow stacking, if

• pins are not NC
• pins are connected internally
• if pins are stacked: they have to have the same name

Best, JAN

[SchrodingersGat]

KLC 3.3 -> https://github.com/SchrodingersGat/kicad-library/wiki/KLC

[evanshultz]

@poeschlr @jkriege2 @SchrodingersGat I think this issue can be closed, right? This is settled by KLC 2.0, I believe.

[SchrodingersGat]

Yes, please close :)