I have been trying to create a rule that will set the minimum clearance between each set of differential pairs.
All pairs are in the same net class.
I’ve just started messing about with custom rules.
I have managed to set custom track widths and gaps depending on which layer the differential pairs are on, just having issues making a rule to set the clearance between differential pair pairs.
Just in case it may be a bug I am using V 8.0.5.
Ive tried various combinations such as the one below.
# Specify an optimal gap for a particular differential pair
(rule "Clock gap"
(condition "A.inDiffPair('/CLK')")
(constraint diff_pair_gap (opt 0.8mm)))
I have used that to create the required gap between the tracks in each individual differential pair, what I am looking for is clearance between each set of differential pairs.
This one?
‘# Specify a larger clearance between differential pairs and anything else
(rule “Differential pair clearance”
(condition "A.inDiffPair(’*') && !AB.isCoupledDiffPair()")
(constraint clearance (min 1.5mm)))
I tried a modified version of that, changing to: (condition “A.inDiffPair(‘*’) && AB.isCoupledDiffPair()”),
and it didnt appear to work.
I am wondering if the rule was correct but something else was wrong, as it didnt show any errors, just didnt draw any tracks when clicking on either the P or N of the pair.
I will try again but with a test pcb just in case its the pins in the connector being too close to another set of differential pairs.
Without the rule it does draw the pairs, but with it just highlights both of the pads and doesnt draw anything.
Well I tried the altered version that I thought would work, and it kind of worked but wouldn’t allow me to terminate it at the next connector.
However using the unaltered version it seems to work with no issues.
With 8.0.4, then tried 8.0.5 ( the version I am currently using at work) also seems to work ok.
Tried 8.0.8 just to be thorough, and it works as well.
What I am now thinking is its the size of the clearance that is the issue, as the connector at work is a 37 way high density TE part, the pads might be too close for that clearance.
Looks like that may be the issue, I will just have to set the clearance for the LVDS netclass to the desired amount, and work around the clearance issue.
As I have a few layers to play with, for DP that are close to each other I can switch layers if required.
Yes, it’s the connector pitch that is the problem - the highlighting that you see when you try to route from the connector is indicating that there’s a DRC violation.
You could edit the condition on the rule so that it doesn’t apply when you’re inside a connector courtyard.
Didn’t think of that, that does sound like a good solution.
Still learning about the Custom Rules.
Just to confirm, it was the clearance being too large, the clearance given was 0.508mm and the distance between pad edges is 0.5mm, so absolutely no chance anything could be routed from the connector.
Well after some experimenting I appear to have a working solution.
Using your suggestion of checking if it was inside a courtyard, I created one rule that would change the clearance to 0.1mm if inside a courtyard for the LVDS nets:
I was also causing myself issues when I was using AB.isCoupledDIffPair() rather than !AB.isCoupledDiffPair() as that was trying to set the constraint between the same differential pair pairs.
For this second rule, I have a couple of comments:
I don’t think AB.insideCourtyard('*') does anything here; the AB prefix is only meaningful for condition functions that simultaneously apply to both the A and B objects. I think isCoupledDiffPair() is currently the only function that behaves like that. Other functions are like insideCourtyard where they check if a single object is inside the specified courtyard. The reason why it seems to work is that AB.insideCourtyard('*') is always false, so the negated version is always true. I think you remove that whole && !insideCourtyard() clause from the general rule, so long as you keep in mind the second point…
Rules later in the file override rules earlier in the file, so you generally should put general rules first and more specific rules later. You could put your general clearance rule first, and your inside-courtyard rule second. In doing this, you could remove any insideCourtyard() business from the general rule.
So I have a working set of rules now, though I should go through them and put them in a better order, as I have noticed how they are implemented seems to depend on where the tracks start from.
I think that those rules with multiple condition clauses won’t work - if I remember correctly it will only look at the first condition clause. So you probably want to AND (presumably not OR) those netclass conditions with the layer conditions. You can use parentheses for grouping.
Looking at it I think you are right.
Looks like there can be only one condition but multiple constraints.
That is maybe what is causing a couple of issues I have noticed.
According to the manual:
Each rule must have a name and one or more constraint clauses. The name can be any string and is used to refer to the rule in DRC reports. The constraint defines the behavior of the rule. Rules may also have a condition clause that determines which objects should have the rule applied, an optional layer clause which specifies which board layers the rule applies to, and an optional severity clause which specifies the severity of the resulting DRC violation.
Also none of the examples have more than one condition.