Dynamic Clearances for Tracks

[amphibious]

Hi all,

I have a problem similar to this post. I was hoping something might have changed in the last two years to make this possible.

Basically I have traces that should have wide clearances that end up being connected to a BGA chip. This will lead to DRC errors of course. I want to avoid fatal errors due to too many error messages and the ignorance that might come with it.

So:

• Is there a way to define track clearances conditionally to areas (within a zone surrounding the chip)?
• Are there workarounds? For example using a NetTie in the schematic defining two different nets for the same track (though I don’t like that idea)

Thanks for your input!
Cheers
ff

[der.ule]

Probably what you are looking for are custom rules, take a look at the examples in this thread:

Custom Design rules Examples

Clearance between via’s and tracks of the same net. (rule "via_not_in_pad" (condition "A.Type == 'via' && B.Type == 'pad'") (constraint physical_hole_clearance (min 0.01in)) )

And the documentation

| | | Documentation | KiCad

[paulvdh]

Just a few days ago I was experimenting with exactly this, and made some custom rules:

(rule clearance_U1
	( constraint clearance (min 0.2mm))
	( condition "A.insideCourtyard( 'U1')")
)
(rule clearance_J1
	( constraint clearance (min 0.14mm))
	( condition "A.insideCourtyard( 'J1')")
)

So you use the normal wide clearance in the netclass setup, and you reduce the clearance inside the courtyard of a footprint.

While experimenting with this, I encountered some big problems with the interactive router. It was not able to shove tracks properly if their clearance is modified this way, and I opened a bug report for this on gitlab:

Custom Design Rules for track clearance not properly integrated with...

The issue was picked up by James J · GitLab and fixed in less then an hour.

---

Edit: As I should have suspected, I was a bit overly optimistic, and it’s (probably?) not a complete fix. I guess the Interactive Router is a quite complicated section of the software with a bunch of known (and unknonw?) limiatations that are difficult to fix because of interactions between parts of it. I’ve seen it improving over the last few years, but I’ve also seen some unwanted behavior pop up every now and then.

[amphibious]

Thanks, Paul! I’ll check it out!

[JamesJ]

@paulvdh

The issue was picked up by James J · GitLab and fixed in less then an hour. As a result, this will probably be included in the next bug fix release of KiCad in a few weeks.

I fixed some issues with regards to the router selecting the correct track widths and clearances when starting to route a track. However, the router won’t interactively change track dimensions when routing across courtyard boundaries. Also, it seems to have issues picking up these rule changes if restarting routing of a track after a change of courtyard rule (i.e. starting outside, routing inside, and then re-starting routing). I’ll investigate that.

For @amphibious - I’ve just tested this ruleset for neckdowns and while the router needs a bit of manual help, the DRC checker works nicely with them:

(rule "OutCourtyard"
   (constraint track_width (opt 40mil) (min 40mil) (max 40mil))
	(condition "A.NetName == '/MyNet' && !A.intersectsCourtyard('U1')"))

(rule "InCourtyard"
   (constraint track_width (opt 20mil) (min 20mil) (max 20mil))
	(condition "A.NetName == '/MyNet' && A.intersectsCourtyard('U1')"))

[JamesJ]

I’ve just fixed changing the track settings while routing through these kinds of rules for v9. It won’t be back-ported for 8.0.5 but I’ll aim to get it in 8.0.6.

[amphibious]

@JamesJ @paulvdh You guys rock! Thanks for your everything you’re doing for this program and community!