Conflicts with components with hidden power pins

Schematic
#1

Hi

I’m using some components like 74LVC1G04 form the standard kicad library.

But I have some which are powered with 5V (VCC in my circuit) and some with 3.3V (VDD in my circuit)

The hidden power pin is VCC which is effectively connected to the corresponding global power label.

I tried to display the power pins and connect it to VDD thinking it would override some sort of default value.
But no, the debugger complains about power flags being connected together, and it effectively connects VCC and VDD together.

How can I differenciate between the 2 power nets ?
For the moment, the only solution I found is to create copies of the component replacing the power pin name with another label but I feel it unsatisfying.)
Is there a cleaner solution to this problem ?

#2

The cleaner solution is to make your own symbol with visible power pins. Hidden connections to power are a thing of the past and would be done away with in the official library if there was enough manpower.

4 Likes
#3

are all hidden power pins automatically connected to a power net of the same name or does it need a special flag in the component description to do so ?

#4

They’re all automatically connected.
As noted on the bottom here: https://kicad.org/libraries/klc/S4.3/

#5

KiCad’s libraries are of quite good quality, and for a big part this is because of the uniform and high quality standards mandated by the KLC.

However, I do disagree with the whole pin stacking idea.
For me, each and every pin must always be visible on the schematic.
For example If I have a PCB for repair and I want to check pin 43 of a 100 pin QFP, then I want to be able to find it in the schematic.

If I see an unconnected pin on the PCB, then I want to be able to verify in the schematic that it should be unconnected.

Fortunately it is very easy to copy standard symbols (which are read-only) to a project specific library and then edit them to fit your personal needs.

#6

@paulvdh

I come from a different angle. I generally want to move as much responsibility from the circuit designer to the library maintainers. So if the datasheet says two pads must be connected then ensuring this in the symbol makes perfect sense to me. In the current stable version of kicad the only option available is to stack such pins.

It is also the only option to use doubled up output pins with ERC working. If you do not stack them then you have two options

  • Have both pins set to output which will result in a false positive ERC message
  • Have only one of them set to output which means ERC can not protect you against wrongly connecting the second pin (you get a false negative here)

And from my general philosophy of reducing responsibility i argue working ERC has a high priority so at least for output pins i am forced to use stacked pins.

However, pin stacking is a workaround that is definitely missing some features. For a start it is not easy to see which pins are part of a stack just from the schematic alone (one really needs to have access to the board view in parallel) — I would hope that some future version of kicad will have a better option here (i have not played with current nightly enough to say if there is already something available)

I always use the schematic/pcb cross highlight feature to find pins on the board for debugging so i never missed seeing what pins are part of a stack. Of course if one relies on printouts for debugging then this is a different story. I am not really tempted to use printouts as making a printable design is just too restricting to me (for starters using hierarchical design is not really an option for printable designs – at least not for deep hierarchies like i typically design)

@pcdwarf

KiCad for legacy reasons uses invisible power input pins as global labels. This allows having power symbols defined without a special pin type and also enforce that any net with a power symbol needs to be driven.

The logic symbols are made with such invisible power input pins also for legacy reasons. In the past when a PCB was a collection of a huge number of logic chips one typically had a single power supply line for all of them which made it seem sensible to have the symbols made such that they automatically connect to power.

However, times have changed. A lot of currently designed boards have multiple power supply systems. This is sadly not supported with the old symbols. Additionally, it is quite hard to convey which decoupling cap should belong to a given IC (and as soon as you place it nearby the IC you already loose the benefits of having the power pins hidden).

Further reading Electrical type of schematic symbol pins (KiCad 4 and KiCad 5) and the power symbol section of Tutorial: How to make a symbol (KiCad v5.1.x) and a very old tutorial (from version 4 times) of how to convert a symbol from hidden power input pins over to having a separate unit for them IC footprint VCC+GND (The symbol editor is now a bit different but the general process is the same)

#7

Pin stacking I can live with, all the pins are and are meant to be on the same net.
It might be better if the stacked pin was displayed “bold” so that there was a visual clue that something was unusual

#8

The funny thing is, I have one schematic with three 74LSxxx IEEE symbols ('241 and '368 x 2), and the schematic has the VCC / ground pins connected on the '241 only. ERC has never complained about my not explicitly connecting VCC and ground on the '368s, and the connections for power and ground showed up just fine when sending the data into PCBNew.

Kinda weird when you realize the '241 is a 20-pin package and the '368 is 16. I have operated under the ‘It’s a feature’ assumption.

#9

The other way round, the 241 has hidden pins, the 368 has visible pins that need to be connected?

#10

I already knew that.

…Then I want to be able to visually verify that on the schematic.

I also do not agree with this:

High quality libraries are a great resource, but in the end it is the circuit designer who is responsible for a working schematic. There simply is no way to delegate that. If a faulty schematic leads to a EUR100.000 claim for damages, the chance of recouping that from KiCad’s Library team is negligible. I would not even try it if it had a chance. But the result is the circuit designer has to check all the connections, whether they are visible or not, and making them invisible just makes verification more difficult.
Therefore I have defaulted to de-stacking all pins in library symbols, making them visible, and set the pin types back before I use it.

Which is a useful verification step, but it needs the PCB to verify the schematic. With pin stacking it is not possible to verify the schematic with the highlighting function in Eeschema.

I respect your vision, and applaud all the effort you (and others) have put in the libraries, but as long as the schematic can not be verified on it’s own while using pin stacking I will keep on un-stacking them and making them visible.

Even when you look at a symbol in the Symbol Editor it’s difficult to see what pins are stacked:

image
image861×466 85.5 KB

You can try to select a pin, and then KiCad tells you it found 4 pins and asks you which one you meant:

image
image861×466 93.1 KB

Also, setting the stacked pins to passive is another ugly workaround to cope with a limitation in KiCad. But it’s just an extra little step to change the input type after un-stacking and making them visible (The menu is open at that point anyway).

Making pins bold would indeed show there is “something” going on, but it looks to much like a bus. (which it sort of is, hmm…) But it still does not solve the visible pin numbers, which is simply a no compromise hard demand for me.

1 Like
#11

If one has a verification process for symbols and part of the verification is that pins are correctly stacked, is it then really necessary to check this again on the schematic level? After all this is the idea of introducing layers of abstraction. It reduces knowledge domains and therefore should make higher level checks faster (as the lower level checks already give you the guarantees).

Similarly if one uses highly hierarchical design then i check the sub sheets on their own and then only verify that they are connected correctly on the outside (at the higher level check i no longer care about the inside – especially useful for multiple instantiated stuff as it massively reduces the checks to be done)

And yes this requires a different approach to proof of correctness. It would then be a hierarchical proof instead of a linear (or flat) one. But well software engineers use such proofs for quite some time now (unittest are the example for this) so why should it not also work in electrical engineering?

#12

Here’s a screenshot of the portion of my schematic in question.

IC connections
IC connections1131×840 12 KB

#13

As the pcb designer having the stacked pins is not such an issue once you know about it. For me the issue comes when the board has been made and put into production and possibly many months later we get a faulty one, it is generally not me that will be fault finding the circuit.
When one of my engineers then looks at the board and the schematic they do not match and can cause queries as to if the boards are correct or if the schematic is correct.
I always de-stack the pins and then save into my own libraries to save the above confusion.

2 Likes
#14

I had to think about about Rene’s remark about different levels of abstraction.

In principle I agree with this.
When designs get over a certain level of abstraction, then adding yet more complexity by dividing a design into different abstraction levels can indeed be a useful tool.

Hiding a few GND pins of a single sheet microcontroller design is just obfuscation however. It does not add clarity. For the designer himself it is indeed not so difficult to adapt, and verify by comparing schematic & PCB, or in the schematic symbol editor. But even that is an ugly workaround. The schematic itself should have all the information. It’s also the long term view. Rework, repair and modifications by other people years later (may be unfamiliar with KiCad). Just nonchalantly posting one of your simple schematic on some forum and having obfuscated pins leads to confusion and questions.

Using a hierarchy to put different levels of detail on different levels in the hierarchy is also something different from removing pins from the schematic.

Hiding a few GND & power pins does not add an “abstraction level”. If you’re looking at some schematic symbol, you are looking at pin level at a schematic, and all pins are equally important. Even all N.C pins. If confusion arises whether some open pins really should be open, then that pin should be represented in the schematic.

Schematics in either .pdf or .svg format go into documentation of a project, and should therefore be complete and have no hidden pins. I’ve seen too many projects (made by others) with only a (hopefully searchable) .pdf as documentation.

So therefore, I will continue to unstack all pins, make them visible, and set the pin types to their proper value as long as KiCad does not have a better way of grouping pins and making all pin numbers visible in the schematic.

3 Likes
#15

Yeah, I always de-stack the pins having experience troubleshooting. I want to know all the pins that are connected to ground (or VCC, or some named signal) so I know if one of them is close enough to where I’m probing for troubleshooting.

I guess this wouldn’t be a problem if we could make our own symbols… Oh, wait… :wink:

1 Like
#16

It is always recommended to create your own symbols with visible pins and mark them as power inputs. The below image shows an example inverter symbol with visible pins.

Kicad 9-3

1 Like
#17

By “stacked pins” I gather that you refer to wires connected to symbols that are shorted together at some other place in the schematic hierarchy other than the schematic you are looking at now.
For example, maybe the wire labeled +5V and the one labeled Vdd might be shorted together on some other page. Am I wrong?

#18

In kicad a single pin can not be assigned to multiple footprint pads. As a workaround one can stack multiple pin on top of each other to get something similar. Typically, one has then all but one of these pins hidden. Such a full stack is what this discussion is about.

1 Like
#19

Not exactly.
It can be assigned to multiple pads as long as those pads have the same pad number.
It can’t be assigned to multiple pads with different pad numbers.

1 Like
#22

Wrong thread here I believe