5.99: EEschema; which heirarchical sheet owns a bus / net?

Schematic
#1

I’ve got a heirarchical schematic, with a a number of busses with named (‘Bus Definitions’) members. These originate in one sheet, pass down through another, before popping up in another.

Some of the resulting netnames are prefixed by the original sheet (i.e. MySheet1/SubSheet1/Bus1.NetName1), some are prefixed by the intermediate sheet (i.e. MySheet1/Bus2.NetName1), and some are prefixed by the final sheet where I break the bus out again (i.e. MySheet2/Bus3.NetName1).

The naming is consistent within busses, but each bus has a different ‘owner’.

Is there any way to control which sheet is seen as the ‘owner’ of the bus? If not, is there any way to force it?

My use-case is I’m running length matching scripts which tally up nets before and after termination resistors, and to ensure it’s matching like-with-like, I’d like to ensure all the matched nets are in the same heirarchy.

#2

It would be best if you could post an issue about this on GitLab as this may be a bug or it may be intentional behavior depending on the details – I would have to take a look at your schematic to be sure.

#3

No worries - I will do. Thanks.

#4

@craftyjon could you follow-up here when you can? This is an interesting question that I wouldn’t want to leave dangling.

#5

Sure. A partial answer:

When I originally did this I had it take the highest-level sheet. This was an easy rule to understand and it didn’t really have many edge-cases. Unfortunately this broke some users’ workflows who were depending on old behavior of taking the lowest-level sheet, which can be important if you decide to label your buses in the lower level sheet but not in the higher level sheet.

So now what we try to do is only upgrade to a “shorter path” name for the bus if there’s an explicit label on the outer sheet. So, if you have a label in SubSheet1 but not MySheet1, you should get /MySheet1/SubSheet1/BusName, but if you have a label in MySheet1 you should get /MySheet1/BusName. But, there could be a bug here as this is new code, and the described behavior of handling some bus members differently than others is suspicious.

#6

OK, that’s starting to make sense. For reasons of ‘this schematic has evolved’, I had explicit bus labels at two levels: The 2-deep level, and the 1-deep level, with the buses dropping down and through the root level. It seems that dual-labelled busses at different heirarchy levels may be doing something here.

That said, if I delete all explicit bus labels (leaving only the named heirarchical pins), I again get a mixture of ownership. If I add explicit labels at only the highest heirarchy level, I again get a mixture of ownership.

It’s a reasonably hefty schematic, and I wouldn’t really want to attach it to a public gitlab issue. Happy to share it with the dev team directly though. Is that possible?

#7

You can check the “this issue is confidential” checkbox when creating a new issue and it will only be visible to the dev team, does that work?

#8

Happy with that. I’ll try and package everything up!

1 Like
#9

Done. Issue #7492.

#10

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

First, you need to understand drivers and driver priority. For this, I’ll just re-use one of the slides from my FOSDEM talk:

image
image1694×800 74 KB

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:

  1. If anything on the net is global, there is nothing to consider, as no sheet path will be included anyway.
  2. 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)
  3. If multiple strong drivers exist, prefer the one with the highest priority.
  4. If multiple strong drivers with the same highest priority exist, prefer the one with the shortest sheet path.
  5. 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.

3 Likes
#11

Please include that table in the new manual

1 Like