This would be a bit shame. Since it knows the pin types, it could check them too. At least as an opt-in behavior.
But I’ve seen that there’s some differences between how hierarchical sheet and components pins are treated. Like the no-connect marker which has apparently been implemented for hierarchical only 3 months ago (How do i no-connect a pin on hierarchical sheet? - #5 by mf_ibfeew). Is the situation similar here?
Hierachical “pins” (no such thing) has no meaning.
ERC will “fold out” the complete schematic and check all electrical connections.
Your hierachical sheets are obviously empty. Put an inverter in each sheet connected to the “pins” and run ERC again.
You’ll get the same result as for the first schematic.
The sheets aren’t empty, the input and output are connected via a resistor, but I guess it doesn’t matter here. If ERC just unfolds the hierarchy for the purpose of the check, then the behavior is indeed understandable. The semantic information provided by the label type is apparently not used in this process.
And you’re right, I should’ve used the term “hierarchical label”, not pin, my bad.
I think my “mistake” is expecting hierarchical sheets to behave like parts. Because in practice, I find myself using them this way - as reusable components which I can e.g. copy multiple times or reuse across multiple projects. But perhaps they weren’t quite made with this use case in mind.
But looking at the source code, ERC doesn’t look extremely complicated. I’ll maybe give it a few evenings and see, if I can modify the checks for parts to also verify subsheets the same way. I’ll come back if my tinkering yields anything worth sharing thanks
Keep in mind, that if two parts are connected via a resistor, the resistor’s pin type is passive (it can be connected to either input or output). Because of this if you connect one output to one end of a resistor, then the other output to the 2nd end of the resistor, no ERC error will appear (since there are just output - passive connections, allowed by default)
Hierarchical labels are just that: labels. They aren’t sources of any signals, they aren’t inputs or outputs. They’re just a name for a net with a graphical element associated with it.
Still, in your case the ERC should still be sufficient - you have parts inside those hierarchical sheets, and those parts have pins with defined electrical types. ERC will see what is connected to what regardless of whether it is inside a hierarchical sheet or not.
I understand that. I think what I actually want is these labels to become more than what they’re now. Maybe in the resistor case it doesn’t make much sense, but in my bigger project I have subsheets where the label leads through a resistor to a base of a transistor. So, if I get it right, after unfolding ERC sees something like that:
Ofc, I don’t expect ERC to guess if that makes sense. Without any additional context, it could be a valid circuit. But I hoped it could use the additional information the label types provide. Just like it does for pin types on components. But apparently not (at least, not now).
The hierachical labels are just that: labels.
They are a nice method to get nets into and out of a hierachical sheet. They have no electrical attributes.
ERC is not very smart, but very helpful for catching “goofs”.
Conceptually, your idea of hierachical sheets as a “custom module” is OK, I think of it that way myself when designing/partitioning schematics. But it only goes so far.
As of now, it fulfills my needs. But I think others could find it useful too, so I’ll polish it a bit and try to upstream it. It can take a while though.
Did you check it for scenarios like, an IC within the hierarchical sheet has an output pin, connected to a hierarchical pin? If it’s an output on the outside of the sheet, will it still cause an ERC error, because there are two sheets on the same net?
Not yet. But I’m not sure if there’s a point in checking pins (hierarchical or not) against pins from different sheets at all. I believe the same can be achieved by analyzing all subgraphs (part of a net within a single sheet) separately. If additionally, you ensure that hierarchical pins on the outside have the same type/shape as their respective hierarchical labels on the inside, then you also know the signals will flow in the correct directions across the sheets boundaries.
In your example, it would mean:
ERC first checks only the inner sheet alone. It sees a connection between the IC pin and the hierarchical label. The IC pin is output, so the label must be output too. Otherwise, an error is reported.
Then, it goes to the outer sheet. It checks whether the hierarchical pin has the same type as the label inside the sub-sheet. Your label inside is output, so the pin outside must be output too.
It then checks the outer sheet alone. Hierarchical pins are treated like regular pins and checked for correctness in a usual way.
(order in actual implementation will likely be different, but it’s easier to explain this way)
Did I forget anything?
(btw, I’m using the term “hierarchical pin” as a synonym to “sheet pin”. Sorry if this causes a confusion. I Initially thought about the “sheet pins” and “hierarchical labels” as the same things, because they’re conceptually interconnected. Moreover, my idea above requires stronger interconnection between the two, the presented approach won’t work if their types/shapes aren’t checked for being equal)
It’d also be wise to get familiar with violation severity options for these. Both violation severitiy and Pin conflict map is available in the schematic setup window, in the top-left corner of the schematic editor window.
Both violation severitiy and Pin conflict map is available in the schematic setup window, in the top-left corner of the schematic editor window.
I know that and I’m going to use this map for checks between sheet pins in the outer sheet (it’s customizable, so the choice is on the user’s side). For conflicts between pins inside the sub-sheet and hierarchical labels, I’ll likely have to come up with a separate, although simpler map (12 types of pins against 5 shapes/types of labels).
It’ll also have to have its own, separate severity setting. Otherwise, existing projects would start to report issues.
thanks
