I want to check for skew between Nets in Net Class ‘BUS’.
But I also want to check for skew between wires of any diff pairs, which are in Net Class ‘BUS’ as well.
Hmm, this might not actually be possible right now. I think we take the last matching constraint for any given condition, meaning only one of those skews will be tested. I’ll have a play and see.
This version works … but I can only call one diff pair in the Net Class ‘BUS’.
As soon as I call for a second diff_pair, it does not report the match length of 100mil
I think the Rules should be all treated, with the most restrictive one having precedence on another one of the same type, not the way it is right now.
Else, I don’t know how I can achieve my goal for checking Match Length of a Net Class as well as the skew between the wires of all the diff pairs in that same Net Class.
Yes, that’s because of what I thought was going on - we only use the last-defined matching skew condition for a given object. This is a current limitation of the DRC system. So, for your diff pair in /DP-2, as that is the last matching condition, that is the only skew constraint that is analysed.
It gets very hard to work out how to implement this when you take in to account the length tuning tools are also driven by DRC rules. So how to know which skew to use? There are some heuristics here that we have discussed within the developer community to allow this kind of tuning, but we haven’t yet implemented anything. It’s a big piece of work!
As a workaround, you could use a length constraint (based on a measurement of the longest routed trace, if you can identify that first) for the bus, and a skew constraint for the diff pairs. That way, the length constraint becomes an implicit skew as you can calculate in advance the min and max lengths for your 100mil skew limit.
Yes, that bit is obvious. But if you are then using the skew tuning tool while routing, which skew constraint should be used? These things (DRC, routing, etc) are more tightly coupled than might appear on first inspection.
(It’s a rhetorical question - we have various ideas how this should work, and how the tooling should or should not be differentiated).
I don’t see any issue.
The skew for wire-to-wire of a differential pair is one thing, while the other skew is for a bunch of nets.
They can be skewed independently.
One will control how the 2 wires of the pair is tuned, while the other one will control how the pairs are tuned between each other.
Altium and PADS Professionnal is achieving this easily.
If you take that approach, you are not concurrently considering both constraints. Given that the differential traces are a sub-set of the bunch-of-nets, depending on which skew constraint is chosen, you could violate the other constraint.
‘easily’ is doing some heavy lifting here. As above [see: It’s a rhetorical question - we have various ideas how this should work, and how the tooling should or should not be differentiated], there are various heuristics that can be applied to decide which skew should dominate at any given time when tuning tracks, depending on how we differentiate the tooling to enable this.
I’m not saying it’s impossible. I’m saying we want to make it work, but we have some design decisions to make.