Pin not driven when connected through inductor

[Deepak]

I'm having some trouble understanding this error in KiCad ERC:



I've connected it up according to the SAML21 datasheet (p41), and when I remove the inductor and connect a straight wire from pin 55 to pin 53 the warning disappears.

[ataradov]

This is because you are connecting a power pin to only passive pins. Your configuration is fine, so you can safely suppress or ignore the message.

KiCad does not take into account that a power pin may be driven from an internal switching power regulator.


Although this is strange, since driving a power pin though an inductor is a common practice.

Even VDDANA requires a series inductor if you want good analog performance. And I expect it to generate similar error message. Try and see if this happens.

[Deepak]

You're right, adding another inductor in the VDDANA path generated the same error. Manually adding a PWR_FLAG before the passive component obviously solves the problem.

Maybe I'm overestimating what the ERC should do - it seems like the behavior is to only check to the nearest node, and not to create a full tree then check all leaf nodes. Seems silly to not treat an inductor like a wire, but at least it makes some sense.

[ataradov]

Seems silly to not treat an inductor like a wire, but at least it makes some sense.

There is no way for it to know that this is an inductor, it is just a component with two passive pins. To implement that check, components would need to have additional attributes for ERC use.

[Deepak]

Wouldn't it be able to derive the device type from the symbol? That is have the ERC determine if one side of an inductor has a connection to a power input, and if so to add an implicit PWR_FLAG to the opposite side net.

The bigger problem I think is that the number of comparisons that need to happen for anything above and beyond a nearest neighbor ERC gets really complex really quickly.

[ataradov]

Wouldn't it be able to derive the device type from the symbol?

How? It is just 2 pins and 4 semicircles. It has no idea on what this represents. There is no way to specify that it is a short for ERC use.

I suspect the same will happen even with a simple jumper for current measurement.

[Deepak]

Well it knows when wires are connected, so the short answer would be to straighten out the semicircles

But seriously, I think that enum NETLIST_ITEM_T in netlist_object.h would need to be updated for definitions on passives that should be considered a connected net (ie, L, R, Jumper, etc), as well as additional checking in erc.cpp and removing this line:

Code: [Select]

        // We examine only a given net. We stop the search if the net changes
        if( ( netItemTst >= aList->size() ) // End of list
            || ( aList->GetItemNet( aNetItemRef ) !=
                 aList->GetItemNet( netItemTst ) ) ) // End of net
Then for any given node you check for all supernets. The problem is that a dysfunctional layout could have the ERC code testing until the heat-death of the universe using this approach.

[SiliconWizard]

This is far from trivial. I've worked on an ERC system a while ago and this exact question actually popped up...

The pin could be connected through a series of other parts to eventually a pin that would be a "driver" pin. But how would the ERC figure out that this pin is correctly driven as expected?
For instance, if it were connected via a diode or a transistor or whatever with the possibility of said pin to be undriven anyway? The ERC would have to issue a full circuit analysis, not just go through nodes, to actually be relevant. So it's just much easier to detect that it's not directly connected to a driver, and move on. This actually warns the user to check themselves the pin is correctly driven, which is not so bad.

A full analysis could be pretty complicated to be really relevant, and slippery.

The only thing I'd suggest here is that they call this kind of error a warning (a power in or input pin connected to a passive node), then add the possibility for the user to discard selected warnings so that these never appear again when they run ERC again.

[ataradov]

I think a good compromise would be if the net had a power port connector, even if there is no other corresponding power ports anywhere else. So put a power symbol named "VDDCORE", and ERC takes it as a sign that the pin is powered.

I'm not even sure, this may actually work.

[Deepak]

I think a good compromise would be if the net had a power port connector, even if there is no other corresponding power ports anywhere else. So put a power symbol named "VDDCORE", and ERC takes it as a sign that the pin is powered.

I'm not even sure, this may actually work.

I think that's effectively what PWR_FLAG does, so the ERC throws a warning saying 'hey this might not be connected' then you slap in the new symbol to confirm you looked at it and traced the net to confirm it is indeed connected.

[ataradov]

I think that's effectively what PWR_FLAG does, so the ERC throws a warning saying 'hey this might not be connected' then you slap in the new symbol to confirm you looked at it and traced the net to confirm it is indeed connected.

Yes, that's it. I think it is a good solution. This clearly conveys the designer's intent.

[Doctorandus_P]

I am more used to putting capacitors upright so the electrons don't fall out and having power flow downwards into a chip.
I also combine this with giving the PWR_FLAG's a logical place in the schematic.
This makes them look like they belong there, instead of being slapped on as an afterthought.
That's also the reason I put them on the same level as the +3.3V power supply symbol.
At least to me this makes the intention a lot clearer, but I'm biased here because I'm used to my own way of drawing things.
I also have a suspicion that Pin 8 "VDDana" is missing a decoupling cap.
100uF also seeems a bit big, ceramics are more common, but I don't know what chip you're using so can't comment too much about that.https://www.eevblog.com/forum/index.php?action=dlattach;topic=168629.0;attach=651450;image

[bson]

100uF also seeems a bit big,

Yeah, they should probably be 100nF, not 100µF.  Looks like basic supply decoupling.  Just a single 100µF cap on a supply pin - or multiple supply pins - makes little sense...

[Deepak]

Quote from: Doctorandus_P on February 14, 2019, 07:17:50 am

I am more used to putting capacitors upright so the electrons don't fall out and having power flow downwards into a chip.
I also combine this with giving the PWR_FLAG's a logical place in the schematic.
This makes them look like they belong there, instead of being slapped on as an afterthought.
That's also the reason I put them on the same level as the +3.3V power supply symbol.
At least to me this makes the intention a lot clearer, but I'm biased here because I'm used to my own way of drawing things.
I also have a suspicion that Pin 8 "VDDana" is missing a decoupling cap.
100uF also seeems a bit big, ceramics are more common, but I don't know what chip you're using so can't comment too much about that

.https://www.eevblog.com/forum/index.php?action=dlattach;topic=168629.0;attach=651450;image


Thanks for the tips, that does look a lot more eye pleasing. The component values were arbitrarily selected, I was trying to get a sense of the approximate size of the board, and still need to go through multiple datasheets.

[Doctorandus_P]

Thanks for the tips, that does look a lot more eye pleasing.

"Eye Pleasing" factor is not important. The goal of making your schematics look neat and organised is to be able to put more focus on the funcion.
From my modified schematic it is almost immediately clear that there are 3 power supply voltages, and this also probably means there is probably a decoupling capacitor missing.
Following a few simple conventions in schematic drawing also makes them easier for others to read,( ans spot such mistakes).
But you may also prefer this kind of wiring:
https://www.xkcd.com/730/