Constraint set up layer wise in differential pair for 90 and 100 ohm impedance

I am using 10 layer board and i am using Kicad version 6.0.4

In differential pair i want to use Track width and Track spacing in each layer separately so how could i can assign custom rule for differential pair 90 and 100 ohm impedance class and 50 ohm impedance.

  1. create the class for differential 90 and 100 ohm and assign this class to nets
  2. But not able to set rule layer wise.
  3. And if we are setting the rule layer wise then how to create custom rule for differentiate 90 and 100 ohm rule.

Version: 6.0.4-6f826c9f35~116~ubuntu20.04.1, release build

wxWidgets 3.0.4
libcurl/7.68.0 OpenSSL/1.1.1f zlib/1.2.11 brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.2.0) libssh/0.9.3/openssl/zlib nghttp2/1.40.0 librtmp/2.3

Platform: Linux 5.13.0-35-generic x86_64, 64 bit, Little endian, wxGTK, ubuntu, x11

1 Like

I am in the exact same situation so I went ahead and submitted a feature request over at the issue tracker. Looks like like it has been accepted for the 7.0 branch development

In the mean time I have set up several net classes, one for each width/spacing pair.
When routing on a specific layer I change the net class assignment of the diff pair to fit the corresponding net class.
Obviously the DRC is bound to complain a lot… which is where DRC exemptions come in handy

Can you use custom rules to make this more automatic?

I have not tried this but I think it should be possible based on the documentation.

I think you can use rules to change the diffpair width/spacing for the diff pair based on the layer you’re routing on.

something like this (have not tried this at all and I expect it needs work)

(rule my_diffpair_rule_fcu
    (layer F.Cu) # or (layer outer)
    (condition inDiffPair('/your_diff_pair_base_name')
    (constraint diff_pair_gap (min <min>) (opt <opt>) (max <max>))
    (constraint track_width (opt <opt>))
    # ...any other constraints you want for this diffpair...

and then repeat for any other layers. You could probably be reasonably smart about it and collapse it for layers that have the same diffpair parameters and/or diffpairs that have the same impedance requirements.

I was under the impression that these rules would only affect the design rule checker…
So does it also dictate actually routing behavior?

The rules are meant to work on the fly when you route. If some rule doesn’t work that way it should be reported as a bug.

They affect routing behavior as well.

Very nice!
The following seems to work for me:

(rule "USB_inner"
    (layer inner)
    (condition "A.inDiffPair('*HOST*') && !AB.isCoupledDiffPair()")
    (constraint diff_pair_gap (min 0.2539mm) (opt 0.2540mm) (max 0.2541mm))
    (constraint track_width (min 0.1019mm) (opt 0.1020mm) (max 0.1021mm)))


Why do you have the isCoupledDiffPair condition? That would seem to apply the rule only to pairs of traces that aren’t diff pairs?

You are right, I could probably loose && !AB.isCoupledDiffPair()" and it would still work just fine.

Now, if there were only some way to automatically calculate the track width based upon a set imedance value, diff. pair gap and the layer stack geometry and apply this on-the fly, then routing would be sooo much more easy… :grin:

For anyone (@darshit_chhatrala) out there that wants to set up layer wise DP design rules, here is what I ended up with today:

(rule "USB_inner"
    (layer inner)
    (condition "A.NetClass == 'USB_DP'")
    (constraint diff_pair_gap (min 0.2539mm) (opt 0.2540mm) (max 0.2541mm))
    (constraint track_width (min 0.1019mm) (opt 0.1020mm) (max 0.1021mm)))

I set the condition to grab my USB traces by referring to the net class “USB_DP” that I already had established. The net class is set up for routing on the outer layers by default and now this new design rule takes precedence over the net class every time I move onto one of the inner layers… works like a charm!
DP routing just became 200% less of a headache - YAY!

I noticed that if I set the min, opt & max to the same value then the DRC checker gets angry which is why I had to spread the values… I wonder if this is a bug.

that sounds like a bug to me, I would expect that you could set them all to the same value and DRC would be happy.

Just out of curiosity, if you take out min/max and just leave opt, what happens if you manually change the trace width or gap to something else? Does DRC care when there’s only an opt value?

As per the documentation, if you take out the max and min values then DRC does not care.
In brief summary, min & max is for the DRC and opt is for routing apparently there are exceptions to this:

From the documentation:

Many constraints take arguments that specify a physical measurement or quantity. These constraints support minimum, optimal, and maximum value specification (abbreviated “min/opt/max”). The minimum and maximum values are used for design rule checking: if the actual value is less than the minimum or is greater than the maximum value in the constraint, a DRC error is created. The optimal value is only used for some constraints, and informs KiCad of a “best” value to use by default. For example, the optimal diff_pair_gap is used by the router when placing new differential pairs. No errors will be created if the differential pair is later modified such that the gap between the pair is different from the optimal value, as long as the gap is between the minimum and maximum values (if these are specified). In all cases where a min/opt/max value is accepted, any or all of the minimum, optimal, and maximum value can be specified.

Min/opt/max values are specified as (min <value>), (opt <value>), and (max <value>). For example, a track width constraint may be written as (constraint track_width (min 0.5mm) (opt 0.5mm) (max 1.0mm)) or simply (constraint track_width (min 0.5mm)) if only the minimum width is to be constrained.

That’s what I expected, but I can’t remember if I’ve tried it. I haven’t used the custom rules in a real project yet, just for playing around.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.