Hi again. I’m setting out a layout with a pair of charge pump chips paralleled up to increase current. I have their output pins connected - correctly according to the datasheet, and I have their net labelled as [+18V> and designated with a PWR_FLAG. I am getting errors generated under “Error: Pins of type Power Output and Power Output are connected.” Kicad obviously feels uncomfortable joining those.
I have errors for the connected output pins and for each pin with the PWR_FLAG.
I have found and looked into Pin Stacking but it doesn’t seem to apply here. I have found and looked into making pins Passive but once again it doesn’t seem to apply. I may well be wrong but these two don’t seem to be relevant to just joining two chips’ outputs in parallel as I am doing.
Is there a way to correct this or should I just ignore the ERC errors. (I know sometimes that is offered as the necessary solution but I don’t like assuming that now I have been pointed to the ERC and seen what it can do.)
Whoever has made the symbol hasn’t thought that several output pins could be connected. These power output pins are cursed IMO. If the symbol is already in your personal library, edit the pin type to “passive” and leave the PWR_FLAG there as it is. If it’s in the official KiCad library, copy it to your personal library and then edit. Another option is to edit the pin type of one copy of the symbol and remove the PWR_FLAG, but I don’t recommend that.
The ERC check is “dummy”, it only checks whether there are several pins of type “power output” in one net, and if yes, throws an error. The PWR_FLAG actually has a power output pin to satisfy the requirement that any “power input” pin which has been attached to the same net requires one power output for the ERC check.
ERC doesn’t handle the case where several Power outputs are legitimately connected. This is where you apply your judgement and ignore the error or change the pin type so this doesn’t get flagged.
Yeah, unfortunately there’s no symbol pin type that encodes “this is a power output that generally shouldn’t be connected to other power outputs, but it’s OK to parallel this regulator with other regulators of the same type”.
That is a legitimate design consideration but not something that any ERC system I’ve encountered will understand. So you have to fudge it by either modifying some of the pin types to passive, so that there is no more than one power output pin on the net, or ignoring the error (and I would explicitly click ignore this violation, not pretend it doesn’t exist). If you decide to modify symbols, I would probably change all of the outputs to passive except for one that remains a power output.
@Bordonbert you definitely don’t need a PWR_FLAG attached to a power output. That will not fix the problem here and will actually make it worse.
A PWR_FLAG is a symbol with a single power output pin, which resolves the common situation where you have a power input that isn’t driven by a power output. The PWR_FLAG provides the missing power output, saying “trust me KiCad, there really is power on this net”. But in your situation, adding a PWR_FLAG is adding yet another power output to a net that already has too many power outputs.
Well, I dont think everything can be in the CAD package without the CAD packaging getting too bloated.
It’s hard to catch every single eventuality that might occur in schematic.
The designer has to have some responsibility to read the datasheet, I think.
When I do my own symbols I just make power pins passive types. The pin names have V or Vout etc on them so that’s pretty obvious … or set a custom ERC rule. One advantage about making all your own symbols I guess, u need to read the datasheet thoroughly.
Thanks fellas, that’s great advice as always and makes perfect sense. It’s good to know I am not missing something obvious which would solve it, easily done in my case.
I was fluffy about the use of PWR_FLAG and had it in my head that it would be needed simply because it was a power net and needed marked in that way. I’ll make sure to get that straight in my head.
I’m such a new user to Kicad, (up to now I used Proteus Ares/Isis 5.0 from WAY too long ago), I wasn’t even aware of the right click options in the ERC report. That’s a sensible piece of functionality as long as you don’t overuse it. I’m happy to simply, mark these two errors as “Exclude this violation”. Yes, I guess that’s the designer taking responsibility which is certainly a necessary facet of this job.
I’ll continue to look into the pin categorisation setup in Kicad as there are different possible approaches. I have already started my own series of personal libraries and have a couple of edited simple symbols which I have had to modify so the idea is already in place and working. It’s going to be a toss up whether to modify or ignore. I am working to work all errors out of the list no matter how basic so there shouldn’t be too many left with genuine concerns to decide upon.
Thanks to all. I can go forward from here with confidence I am not being totally stupid.
Instead of changing the symbol, you can insert a “Net_Tie” on each of the outputs. That should get rid of the ERC errors (you’ll need to add PWR_FLAGs).
Or you can leave one output without a Net_Tie, then you won’t need the PWR_FLAG.
Just note the error, understand that it is a false positive because paralleling is allowed and ignore it.
Even put some text on the schematic, to explain that this is a valid connection, for someone coming along later (including yourself in a few years time)
I do take your point David, I have been known to take that line in the past and it is a pragmatic solution. Nothing wrong in admitting its an issue which you can’t solve, or maybe is just not worth the time spent finding and implementing a solution. As long as I heed your second bit of advice and document it.
In the interest of education only I have looked into ML9104’s suggestion of Net_Ties. I got it working pretty much straight away so it can’t be considered too complex and it’s a practical way of getting round this problem. I’ve now got a small range of different track widths defined in one of my custom libraries for the future. It updated from the schematic including the net_tie oddities and the errors are now all gone.
Thanks again guys, your knowledge is an inspiration.