Noob Questions (hidden pin mystery, ERC and net ID)

richardmcclellan · November 17, 2016, 7:17pm

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.

Thanks

Joan_Sparky · November 18, 2016, 10:22am

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?

PS: EEschema is being worked on to get better (10+ months away afaik) and enable some stuff everyone using it wanted for years… stick around I’d say

keruseykaryu · November 18, 2016, 5:06pm

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.

It’s a seriuos bug, and need to be reported ASAP. I think nobody find this bug until today because no one setup ERC options like that.

You can commit new ones to remove their stupidity via Github.

1.21Gigawatts · November 18, 2016, 5:38pm

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.

richardmcclellan · November 18, 2016, 6:11pm

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.

keruseykaryu · November 18, 2016, 6:53pm

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.

1.21Gigawatts · November 18, 2016, 7:05pm

That is absolutely false!

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.

richardmcclellan · November 18, 2016, 7:29pm

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.

GND should also have a Power Flag?

keruseykaryu · November 18, 2016, 8:59pm

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.

davidsrsb · November 19, 2016, 2:06am

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

1.21Gigawatts · November 19, 2016, 5:52am

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.

davidsrsb · November 19, 2016, 6:08am

Giving ERC enough information is laborious for a small benefit. DRC should be giving no errors before a PCB is fit to make

1.21Gigawatts · November 19, 2016, 7:32am

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.

keruseykaryu · November 19, 2016, 8:03am

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.

1.21Gigawatts · November 19, 2016, 8:24am

That would be an extremely naive approach.

The current EESchema approach is broken.

davidsrsb · November 19, 2016, 10:27am

Hopefully the Eeschema rewrite will support the concept of a single power block and multiple interchangeable logic functions

keruseykaryu · November 19, 2016, 4:26pm

According to this part definition:

# This is an example of a dual input NAND gate A of a 7400.
(part "dual_input_nand_a"
  (reference "U")
  (arc (pos 100 0) (radius 20) (start 100 -200) (start_angle -90) (end 100 200)
    (end_angle 90) (line_width 0) (fill none))
  (polyline (xy 100 200) (xy -300 200) (xy -300 -200) (xy 100 -200)
    (line_width 0) (fill none))
  (pin input line (at -600 100 180)
    (name "" (font (size 60 60)) (visible yes))
    (number "1" (font (size 60 60)) (visible yes))
    (visible yes))
  (pin input line (at -600 -100 180)
    (name "" (font (size 60 60)) (visible yes))
    (number "2" (font (size 60 60)) (visible yes))
    (visible yes))
  (pin output line (at -600 0)
    (name "" (font (size 60 60)) (visible yes))
    (number "3" (font (size 60 60)) (visible yes))
    (visible yes))
  (pin power_in none (at -200 -200 90)
    (name "GND" (font (size 60 60)) (visible no))
    (number "7" (font (size 60 60)) (visible no))
    (visible no))
  (pin power_in none (at -200 200 90)
    (name "VCC" (font (size 60 60)) (visible no))
    (number "7" (font (size 60 60)) (visible no))
    (visible no))
  (route_pin_swap "1" "2")
)

# All LPIDs below this point assume that the base part is located in the same
# library as the parts that are derived from them.  See the “Distributed Library
# & EESchema Parts List Design Documentation” in the Kicad source for more
# information on LPIDs.

# This is the B gate of a 7400.
(part "dual_input_nand_b" inherits "dual_in_nand_a/rev1"
  (pin_del 7)
  (pin_del 14)
  (pin_renum 1 4)
  (pin_renum 2 5)
  (pin_renum 3 6)
)

# This is the C gate of a 7400.
(part "dual_input_nand_c" inherits "dual_in_nand_a/rev1"
  (pin_del 7)
  (pin_del 14)
  (pin_renum 8 4)
  (pin_renum 9 5)
  (pin_renum 10 6)
)

# This is the D gate of a 7400.
(part "dual_input_nand_b" inherits "dual_in_nand_a/rev1"
  (pin_del 7)
  (pin_del 14)
  (pin_renum 1 11)
  (pin_renum 2 12)
  (pin_renum 3 13)
)

# This is a DeMorgan representation of a dual input NAND gate A.
(part "dual_input_nand_demorgan_a"
  (reference "U")
  (arc (pos -465 0) (radius 25.9) (start -300 200) (start_angle 50.4)
    (end -300 -200) (end_angle -50.4) (line_width 0) (fill none))
  (arc (pos -11 143) (radius 343) (start 0 -200) (start_angle -88.1) (end 300 0)
    (end_angle -24.6) (line_width 0) (fill none))
  (arc (pos -10 141) (radius 340) (start 300 0) (start_angle -24.4) (end 0 200)
    (end_angle 88.3) (line_width 0) (fill none))
  (polyline (xy -300 200) (xy 0 200) (xy 0 -200) (xy -300 -200)
    (line_width 0) (fill none))
  (pin input line (at -600 100 180) (length 300)
    (name "" (font (size 60 60)) (visible yes))
    (number "1" (font (size 60 60)) (visible yes))
    (visible yes))
  (pin input line (at -600 -100 180) (length 300)
    (name "" (font (size 60 60)) (visible yes))
    (number "2" (font (size 60 60)) (visible yes))
    (visible yes))
  (pin output line (at -600 0) (length 370)
    (name "" (font (size 60 60)) (visible yes))
    (number "3" (font (size 60 60)) (visible yes))
    (visible yes))
  (pin power_in none (at -200 -200 90) (length 0)
    (name "GND" (font (size 60 60)) (visible no))
    (number "7" (font (size 60 60)) (visible no))
    (visible no))
  (pin power_in none (at -200 200 90) (length 0)
    (name "VCC" (font (size 60 60)) (visible no))
    (number "7" (font (size 60 60)) (visible no))
    (visible no))
  (route_pin_swap 1 2)
)

# This is the DeMorgan representation of gate B of a 7400.
(part "dual_input_nand_demorgan_b"
  inherits "dual_in_nand_demorgan_a/rev1"
  (pin_del 7)
  (pin_del 14)
  (pin_renum 1 4)
  (pin_renum 2 5)
  (pin_renum 3 6)
  (pin_rename 1 "D")
  (pin_rename 2 "E")
  (pin_rename 3 "F")
)

# This is the DeMorgan representation of gate C of a 7400.
(part "dual_input_nand_demorgan_c"
  inherits "dual_in_nand_demorgan_a/rev1"
  (pin_del 7)
  (pin_del 14)
  (pin_renum 1 8)
  (pin_renum 2 9)
  (pin_renum 3 10)
)

# This is the DeMorgan representation of gate D of a 7400.
(part "dual_input_nand_demorgan_d"
  inherits "dual_in_nand_demorgan_a/rev1"
  (pin_del 7)
  (pin_del 14)
  (pin_renum 1 11)
  (pin_renum 2 12)
  (pin_renum 3 13)
)

# An example of putting it all together to create a 7400.
(part "7400"
  (value "7400")
  (alternates
    "dual_in_nand_a/rev1"
    "dual_in_nand_b/rev1"
    "dual_in_nand_c/rev1"
    "dual_in_nand_d/rev1"
  )
  (alternates
    "dual_in_nand_demorgan_a/rev1"
    "dual_in_nand_demorgan_b/rev1"
    "dual_in_nand_demorgan_c/rev1"
    "dual_in_nand_demorgan_d/rev1"
  )
  (route_alt_swap
    "dual_in_nand_a/rev1"
    "dual_in_nand_b/rev1"
    "dual_in_nand_c/rev1"
    "dual_in_nand_d/rev1"
  )
)

# A 74LS00 is as simple as this.
(part "74LS00" inherits "7400/rev1" (value "74LS00"))

# This is a so called heavy weight part definition of a Texas Instruments
# part number SN74HCT00NSR.
(part "SN74HCT00NSR" inherits "7400/rev1"
  (value "SN74HCT00NSR")
  (footprint "Housings_SOIC:SOIC-14_3.9x8.7mm_Pitch1.27mm")
  (datasheet "http://focus.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=sn74hct00&fileType=pdf")
  (keywords "LOGIC" "NAND")
  (property "Description" "IC GATE POS-NAND QD 2IN 14-SOP")
  (property "Manufacturer" "Texas Instruments")
  (property "Vendor" "Digikey")
  (property "Vendor Part Number" "SN74HCT00NSR-ND")
)

Seems that section route_alt_swap can define which parts could be interchanged. So, I think the new format is ready for that.

Joan_Sparky · November 20, 2016, 4:04am

@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:

(part "SN74HCT00NSR" inherits "7400/rev1"
  (value "SN74HCT00NSR")
  (footprint "Housings_SOIC:SOIC-14_3.9x8.7mm_Pitch1.27mm")
  (datasheet "http://focus.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=sn74hct00&fileType=pdf")
  (keywords "LOGIC" "NAND")
  (property "Description" "IC GATE POS-NAND QD 2IN 14-SOP")
  (property "Manufacturer" "Texas Instruments")
  (property "Vendor" "Digikey")
  (property "Vendor Part Number" "SN74HCT00NSR-ND")
)

keruseykaryu · November 20, 2016, 7:16am

Sorry @Joan_Sparky. I have no information.
Maybe someone closer to devs could answer. My digging into the dev mailing list has been marginalised.

jkriege2 · November 23, 2016, 6:46am

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!

Link: https://github.com/KiCad/kicad-library/issues/605

Best,
JAN