Simple net labels vs sheets

Hello !

I have two sheets, each with a net “ABC” defined by a “simple label” (non-hierachic, non-global). The netlist exported from eeschema lists them separately (with code 1 and code 2). So in pcbnew they are separated from each other too.

Is that intention ?

BTW: I’m running version 4.0.5 so the issue might be ironed out already.

Eeschema manual, section 6.3:

“Local labels are connecting signals only within a sheet. Hierarchical labels are connecting signals only within a sheet and to a hierarchical pin placed in the parent sheet.”

“Global labels are connecting signals across all the hierarchy. Power pins invisible are like global labels because they are seen as connected between them across all the hierarchy”

3 Likes

Thanks for clarification. That confirms my assumption.
I’m used to the iron rule, that a net in the schematic has the same name in the layout. With kicad the name of a local net in the schematic changes to /sheet_name/net_name in the layout. Unless one looks at the title block in the schematic sheet it’s a bit confusing to reason the full name of a “local” net.

How else should local nets work? They need to include the identifier of the scope where they are valid. (or in other terms: the namespace where the net is valid must be given.)

As I said, I’m still used to other CAE tools like EAGLE. If you assign a net name somewhere in the schematic (regardless if local, hierarchic or global) it connects with other nets bearing the same name. In EAGLE net names are not automatically “prefixed”. Their scope is across the whole design.

That makes them global labels though. A local label by definition only connects to things within its scope
For kicad the scope of local labels is within the same sheet. Or more precisely within the same instance of the sheet (This applies if you have multiple instances of the same sheet within your design.)

Eagle has no local labels!
If you want that type of label in kicad you need to use some sort of global label. (Either global labels them selves or power symbols)

1 Like

That is probably the reason why EAGLE had such trouble with hierarchic designs in the past…
The fact newbies to KiCad have to get used to is that the net “foo” in instance yxz renders to xyz/foo in the layout. A sound concept !

2 Likes

Yes, I find that KiCad is treating hierarchy in a conceptually more sound way. Users may have to unlearn the “idiosyncrazies” of other tools but in the long run this is better. We can build re-usable / modular / composable designs this way.