OK, there was a small logic bug which is now fixed.
Here’s a fairly technical explanation of how this system works. Yes, I’ll write this up in a better and more user-friendly way in the user manual before 6.0 release
First, you need to understand drivers and driver priority. For this, I’ll just re-use one of the slides from my FOSDEM talk:
Drivers are potential sources for a net name. “Strong” drivers are hierarchical labels or above: basically, things where the user explicitly gave a name. “Weak” drivers are sheet pins and component pins: things that can drive a net name in “fall-back” situations where the user didn’t add a stronger label.
If there are multiple conflicting (meaning, same priority) drivers on a net, the “lowest” one alphabetically will win.
When a net (or bus) is used in multiple hierarchical sheets, we use the following algorithm to decide what name to use for the netlist:
- If anything on the net is global, there is nothing to consider, as no sheet path will be included anyway.
- Prefer strong drivers over weak drivers (this means that the hierarchical label on a subsheet will win over the hierarchical sheet pin on a parent sheet, if nothing else is present)
- If multiple strong drivers exist, prefer the one with the highest priority.
- If multiple strong drivers with the same highest priority exist, prefer the one with the shortest sheet path.
- If there are multiple ways to resolve the above, prefer the one that is alphabetically lowest
Knowing this, you can take care where you place labels in order to control the resulting net names that make it to the PCB. If you prefer “deep” net names, place local labels in your subsheets as these will win out over the hierarchical labels and pins in the parent sheets. If you prefer “shallow” net names, place local labels on your parent sheet, as they will win out over any other local labels on child sheets by having a shorter path.