I am doing a simple layout on KiCad to evaluate transitioning from DipTrace. So far, I like it overall, but am having some issues with EEschemay.
Some issues/questions:
I am using the library symbol for the CD4013—4000 series CMOS dual D-type. It has hidden power and ground–which I agree are the invention of the devil. I have two of parts on my schematic U1 & U2. U1 an error flag on pin 14–power. If I display the hidden pins, it shows pin 14 and pin7- gnd on both A and B parts. If I connect the hidden pin to VDD, the ERC seems happy. If I don’t, it throws an error on the “B” part, but not the “A”, nor on GND on either A or B. On U2. it throws no errors period. ???
When I go to “options” on the ERC, it seems to have no effect. I checked everything green and it made no difference on the ERC flags. How do I get this (useful) feature to take effect? Rather than flagging all the unused outputs “NC”, at least at first, simply disabling on the ERC seems useful. Then, later, go back and flag the ones thar are really NC. For example.
Finding out the name of a net seems to be harder than it should be. I can label a net and if I run the net list report, it seems to come through. But, there seems no way to find out what the net ID is, nor to highlight a net at the schematic level. Running a net list report that you then have to look at with a text editor seems clunky, at best.
I think KiCad is great and I like the feature list. I know I could make a 4013 symbol with no hidden pins, but I prefer to force my way through a new package and understand it before I get into work arounds.
Did you check the part with the symbol editor?
I don’t have the github libs loaded… so I grabbed it from the repo and had a look.
the VSS/VDD pins are there just once (common to all units - A&B in this case), this explains why ERC only complains once. Pin 14 in unit A is the same pin as in unit B.
Also, when you placed the symbols, did you grab part B for U1 as well, or did you drop U1A and U2A only?
The hidden power pins are necessary and should not be disposed of the places where they are useful.
You didn’t share your schematic, so we can’t check what is really wrong. I suppose you have problem which could be solved by special component: PWR_FLAG. Most of newbies forgets that sometimes place this flag is necessary in their schematics.
For example, below schematic report no ERC errors. Even if the power pins are hidden and have no explicit connections.
While I realize the above schematic is simply a minimal example intended to show the use of power flags to appease DRC, it nonetheless demonstrates the improper use of power flags.
Thanks, I think it has to do with “PWR_Flag”. My schematic looks like your U116A/B. One of them gets flagged.
Thanks for the help. So far, I like KiCad, open source programs are/can be dynamic and much better than proprietary stuff. I take my hat off to those with the time and talent to contribute. They are doing great work and, as a bystander/user, I hesitate to be too critical.
Having said that and with the stipulation that I am not really familiar with EESchema, it is the clunkiest schematic capture program I have worked with of late. I am willing to deal with it–there are no perfect solutions–but it could use some work. Glad to hear that it may be forthcoming.
Sometime this is the only way. Why? Because a lot of components which should provide power (eg. linear regulators, power modules) are designed like logic blocks. They have Input pins and Output pins but not Power Input pins neither Power Output pins.
That is precisely the purpose of the power flag, to flag a pin that is the “power source” as a power output.
Connecting the power flag directly to the power port symbol can hide errors that would otherwise be detected by DRC. That’s the very reason why power port symbols aren’t defined as power outputs in the first place.
OK, I didn’t mean to start a controversy, and I absolutely admit I don’t totally grok the power flag concept. So–suppose I have a n unregulated 12V input to a linear regulator which knocks it down to 5V. Which is VDD for my circuitry. I have those now infamous 4013’s with a hidden power pin labelled VDD. So, I should label the linear regulator output VDD and tag it with a Power Flag? This tells KiCad to connect the output of the linear regulator to the VDD pin on the 4013? What if I had chosen to call my linear reg output VCC? Then it doesn’t hook up? Can I also label it 5V?
As I said, I am learning how this all works and don’t want to get into work arounds. In previous worlds, this hidden pin concept didn’t exist. In the future, I likely will make my own symbols with non-hidden power pins. Separate unit, perhaps. I screw up enough without hidden stuff to trip me up.
Thanks again, guys. Any new product always his its not-so obvious things. Appreciate the help. The more I work with KiCad, the more I like it. I doubt I will become a big fan of EEschema in its current incarnation, however.
In my point of view: Yes, if your regulator was/is poor designed as a symbol (pin properties), No, if your regulator is good designed and the output VDD is a power source itself.
No. This tell the ERC that you treat this net as a power source when there are no other power sources at this net. Hidden power pins are connected “trought name” to the power ports and other hidden power pins which have the same name.
BTW. The power ports are global, you can not use VCC as a 5V source for TTL on one sheet, and VCC as a 12V for other things on another sheet.
I assume you talking about the pin name not about wire label. This doesn’t matter if this pin won’t be hidden power pin. You can assign any name to the visible pin. In this case will be relevant to which power port this pin will be tied to - if you like to use them.
I mention about the wire label for some reason. If you put the wire label “VDD” on some net then all hidden VDD pins will be hooked to this net on this sheet! And throught these hidden pins this wire label become global (Normally, the wire labels are local - for particular sheet).
The U1 is on the second hierarchical sheet.
Even if a regulator has its pins correctly defined, a couple of ferrite beads on the I/P and O/P are enough to mess up ERC. Schematic ERC will never be as reliable as Pcbnew DRC
Yes, it takes a proper understanding of power flags to know when you need to use them, and how to use them correctly.
I think it is currently the other way around. ERC seems quite reliable when it is given enough information. DRC however can be inconsistent at times as it attempts to analyse geometric features and compare them to the design rules.
I’m not sure what you are referring to here, perhaps you could clarify? By “enough information” I was referring to correctly identifying the electrical type of a component’s pins and the proper use of power flags. In some cases I think it would even be handy to have a “power input flag” to indicate that a net, that doesn’t have any power input pins, is intended to be driven by a power source. This may be considered laborious but I think it is essential especially if you want to have any confidence in the ERC report.
Having a “happy” DRC is the starting point of checking that a board is ready for manufacture. But by itself a happy DRC is not a sufficient indication that a board is “fit to make”. DRC can’t indicate that you chose/created the wrong footprint for a component. It won’t let you know that your clearance settings are not sufficient for your high voltage section. It has no idea that the thermal management for a component is inadequate. Or that the length tuned tracks are no longer the correct length. Or that the lengths of a differential pair no longer match, or are not symmetrical. Or that you forgot to tune the impedance of a controlled impedance track. Or that the decoupling caps are ineffective. … The list goes on.
When DRC stops complaining, then it is time to really start checking the board.
However, to get back on topic, hidden pins of any type are not only unnecessary they can be a source of hard to find errors, some of which are not even detected by ERC. Hidden pins become connectable by name, this not only forces you to use a particular name in order to connect to them, it also means that all similar named hidden pins are connected together. If you have one 4000 series part that is powered from 5V and another that is powered from 12V you end up with 5V and 12V shorted together and the ERC arrows will identify the power source pins of those nets (often power flags) as the source of the error. Not only can this error be difficult to find it’s also hard to fix. The names VDD, VSS, VCC, VEE, etc are names used to identify power pins for a component based on the technology used in that component but are otherwise meaningless. Multiple components with power pins named VDD are not necessarily connected to the same power supply. It makes no sense to use these names on a schematic. We certainly shouldn’t be forced to use them.
Hidden pins also reduce the readability of a printed schematic.
The best advise on how to use components with hidden power pins is don’t use them! Simply edit the existing parts and make the pins visible and save them to your own library. Hopefully the future EESchema will no longer support them.
Can you imagine a device logic using logic gates, flip-flops, each of which would have led out the power pins? Do you think that such a schematic would be easy readable? The hidden pins should stay but should be used reasonably.
And yes. We can create separate symbol parts for power pins, but in the current Eeschema approach we lost the parts auto interchangeability during annotation.
@keruseykaryu
Do you know if those property fields can be referenced in the layout/footprints in the future, like we are able with the Value/Reference fields?
I’m referring to this part of the example from above:
There is an ongoing discussion (lthough somewhat sleepy on the logic power pin usse … maybe you can contribute there … or even propose a fix? … In the end this is an OpenSource Project that relies on contributions from its users … I think especially for the libs!