7.0 precedence of net classes of hierarchical sheets

[v923z]

Hi all,

Is it possible to set some sort of precedence for the net classes, if they’re defined in hiearchical sheets. The problem is the following: I have a number of LVDS lanes, which are labelled LDVS1_N/P, LDVS2_N/P etc. These lanes are connected on one end to a chip, on the other end to a card edge connector like so

(Differential signals are red.) The connector and the chip are parts of two different sheets.

As soon as I connect the connector pins to the differential lines, the net class is overriden, and defaults to the net class of the connector pins, which is not set. This can be seen in the change of colour, too.

In this paricular application, there is a very pressing reason for calling the connector pins ST47, ST49, etc., so I can’t really attach the differential subscripts there. On the other hand, in the layout, it would be really important to carry out differential routing, which requires the subscripts.

What would be the canonical way of achieving what I would like?

[craftyjon]

Place a local label on those wires with the desired net name.

[v923z]

That works, thanks for the suggestion! However, I think that that can’t be the solution, because that basically creates two sources of truth.

The example that I described above is not a contrived pathological scenario. The chip has some pins that are differencial lines, so it makes perfect sense to set the net class in the chip’s sheet.

The connector has no idea what it is connected to, but the connector’s pins (ST47, ST49 etc.) define the physical connection and the geometrical layout. I don’t want to assign electrical properties to connector pins. This is, e.g., why ST47/ST49 have input/output labels, while LVDS1_P/N are clearly outputs.

To add some context, this circuit is a card that can inserted into a slot. ST47/ST49 are the pins of the slot. But the slot is universal, and that’s why I can’t just call those pins LVDS1 etc. In another application, I might not even have a dfferential signal on those pins.

Besides, apart from the particular problem, I feel that this issue is somewhat more general: even if you don’t want to assign any rules to nets, it might be confusing that you don’t find a specific net in the layout if you connect two hierarchical sheets, because KiCAD takes the net names from the sheet that is logically less relevant. Even more problematic is the issue, if you have two sheets with the same connector, each having pins ST47/ST49. If you see ST47 in the layout, which sheet does that refer to?

[craftyjon]

@v923z

that basically creates two sources of truth.

Not quite – there is a ranking of labels, and local labels override your hierarchical sheet ports. If local labels are absent, the only thing left is the hierarchical sheet ports, so they have to be used.

See Schematic Editor | master | English | Documentation | KiCad section “net name assignment rules” for details.

[paulvdh]

I agree with craftyjon, If net names are important, then put labels on it. If multiple labels are put on a net, then KiCad also has rules in place to determine which name to pick for the net. See: https://docs.kicad.org/6.0/en/eeschema/eeschema.html#net-name-assignment

But it does not mean I particularly like these rules or that they can’t be improved…
I just had an idea about somehow marking pins (either from a symbol or hierarchical sheet) to tell KiCad to derive a net name from the pin name. Using it would be similar to placing the “No connect” flags, but of course with the meaning of naming the net.

I have not thought much about what they should look like. KiCad already has small circles and squares for open ends, and crosses for the no connect flags.

Would this be worth a feature request?
Any idea’s of what it could look like?

[davidsrsb]

I always want at least a warning that there has been a net name conflict. The rules of precedence are not easy to remember and way too often it’s actually a mistake.

[paulvdh]

Yes of course, but that is already implemented:

[mf_ibfeew]

@paulvdh

Yes of course, but that is already implemented:

The current “two labels on same net”-ERC.check doesn’t cover the case of net-name-conflicts of hierarchical labels (as shown in the opening text).
Different hierarchical labels on same net are not marked as warning/error.

In my opinion this behaviour is correct, because it’s a common use-case to connect subsheets where the hierarchical labels are differently named. Marking all these cases as warning/error would cause much noise.
But I admit that others could see it different and want a warning for different hierarchical labels on same net.

[daemonburrito]

I don’t know if this helps at all; it’s just a personal experience which may or may not map with yours. But since 6, I have developed the habit of labeling nets; even those that aren’t particularly special, and clutter can be mitigated in the “art phase” where I make the schematic pretty. So all nets are labeled, essentially, and I can see the table of nets, etc.

Reason 1 this added value to the workflow: as mentioned, the ERC warning. This has become a clue that I either had a wiring problem, a brain problem, or both. Occasionally, nothing was wrong but I did clean up the name, but the times that something was wrong, a subtle defect was discovered which may have been a major head-scratcher at the end.

Reason 2: again as mentioned, was organization. Labeling sets you up for easily picking a number of favorable options, instead of having to implement this after most of your circuit is already done, and you have to zoom down/change font sizes, etc. etc., and go through the process of doing it anyway, only this time with an already complex circuit.

Reason 3 is when you move over to pcbnew: All the warning advantages apply, making sense during the rat’s nest phase is easier, etc. And of course ngspice spice simulation, if you’ve gone down the road of acquiring or writing models for your components. Output of tools generally make a lot more sense.

Habitually naming local nets from my point of view instead of KiCad’s limited PoV (because it doesn’t know what I want yet) has made me more confident and I think it’s a habit that will stick. @craftyjon’s very helpful suggestion is the way to go, IMHO, for your problem and more generally, though I admit that I’m not sure what remains unsolved about your problem.

[davidsrsb]

Yesterdays V7rc2++ on Windows
The AA-CC clash CC wins
The BB-BB net with a DD label, DD wins

No warnings at all.
To me this is dangerous. I wasted a board once with a hard to see wire on the top sheet shorting two hierarchical labels.

[craftyjon]

Why should there be a warning in this case? This is common usage.

[v923z]

I think there are various issues at play here. Some are just cosmetic in nature, some are baffling, and some are confusing.

What you suggested at the beginning works, but it’s not ideal. The problem is that the connector is only a mechanical component, it has no notion of impedance control and the like. In my opinion, if a component requires such rules, then stipulating trace width and clearance should happen in the sheet, where this component can be found. One reason for doing so would be that I can later replace the connector (i.e., the complete sheet, where the connector can be found), and these rules should still be in place.

I think what @davidsrsb referred to is the fact that when hierarchical labels of different sheets are connected, there seems to be no clear rule as to which netclass will prevail, and that is confusing. And this connects (pun intended) to my earlier comment about the two sources of truth: you are right that only one truth will prevail, but not necessarily the one that you would expect, and there is no warning about this. So, if I set up the connections to be differential in one sheet, and connect to another, which has no rules, but prevails, then the lines that are supposed to be differential will take on the default values, and that might cause problems later on. The netclass definitions of the first sheet will be removed from the list, so there will be only one truth, but this removal happens behind the scenes. E.g., if the differential lines are supposed to have a width of 0.125 mm, and the default is 0.15, then you won’t even notice this in the layout.

Then there is the cosmetic issue: if I want to add a local label to a pin, then it’s got to be done on a wire, like so:

(Again, I don’t think that LVDS1_N/P should be part of the connector’s properties. The connector can be used for non-LVDS stuff.) The local label cannot be attached to the hierarchical label ST39/ST41 etc. There is actually the option to attach a netclass to the label

but that is not respected:

At this point, ST39 should be red, because the colour is set in the net class definitions:

This I would actually consider a bug.

[davidsrsb]

@craftyjon

Why should there be a warning in this case? This is common usage.

I can see where you are coming from with a repeated sub-sheet module, where you might want to be lazy and not rename internal net names

The issue for my work flow, is that my sub-sheets are unique and I continue the name through, so connecting AA to CC was a mistake, which ERC maybe should but does not warn me about

[craftyjon]

@v923z

when hierarchical labels of different sheets are connected, there seems to be no clear rule as to which netclass will prevail, and that is confusing

There is a clear rule: it’s done in alphabetical order. This is obviously unstable as you expand and rework a schematic, which is why it is best practice to always use explicit labels, rather than relying on hierarchical sheet pins or component pins, to identify nets with any importance (such as ones that go in a non-Default netclass).

@v923z

And this connects (pun intended) to my earlier comment about the two sources of truth: you are right that only one truth will prevail, but not necessarily the one that you would expect, and there is no warning about this.

There is intentionally no warning about this, because people commonly do this intentionally for low-priority nets where they do not care about netclass assignment. Nets named by sheet pins are implicit names, not explicit ones, and we do not warn about multiple implicit names by design.

@v923z

Then there is the cosmetic issue: if I want to add a local label to a pin, then it’s got to be done on a wire, like so:

In your screenshot you have both a hierarchical label and local label. Both of those are explicit and the local labels are not needed. The implicit ones are hierarchical sheet pins on a parent sheet, not the hierarchical labels on the child sheet.

@v923z

This I would actually consider a bug.

Yes, that looks like a bug, can you report it with the project attached?

[v923z]

@craftyjon

There is a clear rule: it’s done in alphabetical order. This is obviously unstable as you expand and rework a schematic, which is why it is best practice to always use explicit labels, rather than relying on hierarchical sheet pins or component pins, to identify nets with any importance (such as ones that go in a non-Default netclass).

I’m not against explicitly having to assign labels per se, I’m only saying that doing so clutters the schematics, at least, with the current tools. E.g., the hierarchical labels have to be pulled off the connector.

@craftyjon

In your screenshot you have both a hierarchical label and local label. Both of those are explicit and the local labels are not needed. The implicit ones are hierarchical sheet pins on a parent sheet, not the hierarchical labels on the child sheet.

That’s correct, and that was done on purpose, to highlight the issue. The problem with STxx is that it does not contain the _N/_P subscripts required for differential routing. I had those in the other sheet, whose net classes didn’t survive the connections (LVDS1_P/N in the original post). That is exactly what bugs me. I don’t want to label the connector with XX_N/XX_P symbols, because that is just a connector. If I decide to replace that with another connector (by swapping out the complete sheet), then the assignments will be gone.

@craftyjon

Yes, that looks like a bug, can you report it with the project attached?

Yes, I’ll do that.

[craftyjon]

@v923z

I don’t want to label the connector with XX_N/XX_P symbols, because that is just a connector. If I decide to replace that with another connector (by swapping out the complete sheet), then the assignments will be gone.

You shouldn’t label the connector. You should place explicit labels on the parent sheet with the diff pair suffix.

[v923z]

@craftyjon

You shouldn’t label the connector. You should place explicit labels on the parent sheet with the diff pair suffix.

That’s a good idea, thanks! This pretty much solves the problem.

[RRPollack]

@davidsrsb

I can see where you are coming from with a repeated sub-sheet module, where you might want to be lazy and not rename internal net names

I don’t understand what you mean about renaming internal net names.

I designed a board with KiCad v5 that included a vacuum fluorescent display. This required 12 anode driver circuits and 13 grid driver circuits. I implemented this using two sub-sheets, instantiated 12 and 13 times respectively, connected to the VFD on a parent sheet. I used net classes to set different characteristics for the logic inputs and the high-voltage ports on the sub-sheets.

How would I “rename” the internal net names on the sub-sheets?

[davidsrsb]

I meant customizing each sub-sheet.
You have a different need and workflow to mine, as I have never needed more than four repeated blocks of circuitry and chose to label each sub-sheet A,B,C & D internally.