Optionally connected pads, yay or nay?

It would be great if there would be a way to specify that a pad may be connected to a net, but omitting that connection is not deemed an error or warning. MP pins in specific would benefit from this status, as for many parts there would be no issue at all if these would not be connected to a net (as long as the pad is there).

In similar fashion a lot of ICs have NC pads which are explicitly described as “not internally connected” in their datasheets. Sometimes you’d want to be able to connect those to, for example, GND if this suits the board, without triggering a DRC error if one is left unconnected.

Eeschema could use the ‘dotted’ line view and a toggle option to show such an optional connection?

Visually this is already possible:

I’ve also posted this feature request at gitlab: https://gitlab.com/kicad/code/kicad/-/issues/6465

Would there be any reason not to want a feature like this?

“NC” is ambiguous.
Sometimes it means “No internal connection” do as you wish.
Sometimes it means “Do not connect” anything. Some IC’s have connection to internal test points.

Usually it is not worth in advance to bother with it in advance, and when I see dotted lines on a schematic I would be confused and go asking around what they mean if I did not make the schematic myself.

A simple way with the current capabilities of KiCad would be to simply use a “No Connection” cross, and maybe add a text note to indicate these pins can be used for routing if needed.

The Idea has some merit, but overall I’d think it would be too much hassle for not enough profit. There are many, many more important issues to improve KiCad. But I’m curious what others think about this. Is there any PCB program thad does something similar?

2 Likes

“NC” is ambiguous.

Currently this is solved by hard-assigning NC pins. Often by editing the symbol to untangle the (hidden) ones. Lot’s of manual labour and pins.

A simple way with the current capabilities of KiCad would be to simply use a “No Connection” cross, and maybe add a text note to indicate these pins can be used for routing if needed.

One would still need to keep updating the schematic to allow pcbnew to even connect the pad.

Once the schematic is finalised in the current situation there’s no way, besides writing it out, to know why certain NC pins are routed and some not, besides guessing from the PCB design.

100% with you here. This kind of practice is risky. It might even be, that different suppliers of the same part have differing NC practises. Not good design.

I would add to that different revisions of a chip from the same manufacturer, and the small print that “things may change without notice”.

And I am of opinion they should be. The schematic is the reference of a design, and it should always be unambiguous on the schematic which connections are made on the PCB. For this same reason I also do not like “hidden” power pins and stacked pins. But these are part of the KiCad default libraries, so some folks think otherwise :slight_smile:

1 Like

This would be a perfect case of alternative pins in V6

NC is ambiguous but the datasheet should say whether the pin should be left floating or can be connected to anything (which helps with routing). For a properly reviewed part, these alt pins could be GND or NC

No. This would only cover the current version of a certain supplier’s datasheet, which might change next week.
The safe way to do a design is to treat NC as “Do Not Connect” or “Leave Open”.

Your option is OK for a one-off amateur design, but unacceptable to a professional engineer with product liability.

While this is true it would also be totally unprofessional of a company to change the function of a pin if they themselves stated if their NC can be tied to GND

If a company ever did that they would be blacklisted by any professional company for doing such a thing, not providing a different part number for a part that is not form fit and functional for the same part number AND if the part is Q200 classified they would loose such an accreditation.

For the record I personally would not tie a NC to anything but the option is there

In that case, the manufacturer would normally not specify NC, but GND (or any other voltage). At the most, they’d provide a subnote saying “can be tied to… (GND, VCC, whatever)”. This is so rare that it makes no sense to take it into consideration for KiCAD.

This discussion is moving towards fringe issues.

That’s utter (unprofessional) nonsense, as the safest way would be to consult the datasheet. In doubt contact the manufacturer (and they do reply to these requests, as I’ve done this several times). Basing your design on an unfounded assumption -instead of verifying- just because it feels conservative is exactly what an amateur without a sense of liability would do. Then making the next assumption that you know better than the datasheet because pin assignments in a datasheet might change on a weekly basis (which I’ve never seen for any part whatsoever) is just plain bizarre. Please don’t propagate the idea that ‘professional’ designers should act like they know better than the manufacturer without verifying that they are correct.

Nearly all MEMS sensors with unused pins provide connection hints to the designer. Like here, here and here. Not exactly ‘fringe’ parts.

KiCAD currently does not have an explicit way of capturing in a schematic why one NC pin is connected to ground and another unconnected (or even to VDD as some parts require).

Another example are FPGA’s from Microsemi ( ie Igloo2: M2GL060T(S)-FG484

Unused Condition What to do if the pin is not being used
DNC Do Not Connect, reserved, leave floating. These pins are physically connected to the die. But the designer must leave floating to avoid unwanted leakages
NC No Connection - No connection to die. These pins be used for board level signal routing by the designer.

So, yes, this is viable and it would be an unprofessional chipmaker that changes the intent without marking it as a new device, let alone silently.
Thus v6 alternative pins is a viable option for this

More useful pins connected together internally to a part should not create an error if not connected externally. Ground comes to mind here (sometimes it matters, for RF for example but many times it does not)

I’m in this camp.
The OPs workflow makes only sense to me if KiCAD had the option of spinning several versions of layouts from one schematic and one needs to track the different designs via the schematic… but that’s not how I use KiCAD (or how I understand others do it).
If I need another layout I copy the project and give it a revision number.
The schematic is the reference for the layout.

You can add text next to the pin in the schematic if you need this information?!
I honestly don’t understand how optional wires would help with this as it still wouldn’t tell you why a pin got connected to a net or not.

Don’t get me wrong, I understand your position (and Paul’s). For recreating a PCB layout the current schematics are usable (the ‘what’ aspect of design). Incomplete though: I wouldn’t be able to produce a good layout from a moderately complex board schematic without also having to consult datasheets to fill in the missing layout information, pick any published ‘professional’ schematic. The whole ‘the schematic should be unambiguous’ ideal clearly doesn’t hold in reality already, as schematics don’t capture enough information to achieve that goal and one that would is going to be unbearable. They’re meant to be an abstraction to be used alongside other design documentation.

For design review, collaboration and debugging… eeschema (and electronics schematics in general) is severely lacking in the standardized documentation and communication of design decisions (the ‘why’ and ‘how’), leaving it up to ‘hand written’ notes, datasheet digging and implied knowledge (‘this cap should really be close to that pin’). Yes, that’s flexible, but industries prove over and over that this kind of flexibility doesn’t improve results in the long term or as a whole.

I for one was hoping (with this feature) to enable some small steps in documenting the ‘why’ part more, without preventing others from sticking to their standards. Btw, it should be programmatically perfectly doable to retrieve from pcbnew which pads ultimately got connected and generate an output schematic (pdf?) where the dotted lines of those are replaced by normal solid lines (and maybe even omit the dotted lines).

I can’t imagine what the use for this would be? Are you trying to create schematics for documentation/eduction purposes, to introduce optionality for other people who actually do the layout?

It would seem to me, that when doing the PCB layout, having an “optional” net connection introduces all kinds of problems and complexities. Your DRC would be “maybe” correct, depends. Why would you want to create a situation like that?

Also the notion of somehow future-proofing a design against pin assignment changes for NC pins seems more than a little strange to me. When you do a design, you base it on the current version of the chip (or at least, the version you plan to buy), and match it to the correct datasheet for that version. Then you do the pin assignments to match, and things are either NC or GND, as you design them. Why introduce ambiguity, that you would immediately have to resolve when doing the layout anyway?

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.