Need some guinea pigs for a rule-based DRC <<PROTOTYPE>>

Software
298

Please open an issue for this and attach your board if possible (you can mark it a confidential issue if you don’t want your board to be public).

299

Will do. Wasn’t sure it whether this was known or not, so I wanted to ask first before filing. :slight_smile:

300

It’s known that there are ways to use custom rules that will make things very expensive, however what you experience doesn’t sound normal at all, especially on a fast machine.

301

Issue submitted. Had to gzip the board; it’s a bit on the large side. :frowning:

302

why don’t you want to add to kicad v6 graphical interface for custom netclass rule (especially contain CLEARANCE MATRIX ) ? like altium, like eagle cad, like mentor pads, like orcad ? to click

303

Has someone said they don’t want to add it?

A matrix can be implemented on top of the custom rule system, but not vice versa. The rule system is much more powerful and flexible. As far as I have understood there were two options: either a matrix with a GUI and then a backend dealing with the router and DRC, where the backend is probably the more complex part; or a rule language and more complex backend. It was decided that the better rule system was needed anyway. Now we already have the backend. Adding a matrix means adding a GUI which creates simple rules for the existing backend. So, now when we already have the backend, implementing a matrix for ease of use is almost trivial compared to implementing a matrix GUI + a custom backend.

But this doesn’t happen for v6 because the major features have been planned and decided, the feature freeze has gone already. This is necessary to keep even remote resemblance of a release schedule – otherwise we would never see the final v6 release. So, it can happen in v7 at the earliest.

3 Likes
304

Yeah, it’s worth noting that the 6.0 DRC system runs only rules; all the existing netclass values and keepout settings are compiled into rules behind the scenes.

305

Also: it would be easy for people to prototype a matrix thing using Python or Javascript or whatever, and have it generate rules

1 Like
306

A couple of syntax changes for all you guinea pigs:

  1. isDiffPair() is no more. Use inDiffPair('*') instead.

  2. New AB token added. It should be used for AB.isCoupledDiffPair().

(In the interests of full disclosure I should mention that the expression evaluator knows what isCoupledDiffPair() means and ignores the object token so whether you call it with AB or A or B won’t actually matter.)

307

I have a rule defined as follows:

(rule "Reinforced PRIMARY to BOUNDARY"
	(constraint clearance (min 5.5mm))
	(condition "A.NetClass == 'PRIMARY*' && B.Layer == 'Margin'"))
(rule "Reinforced PRIMARY to BOUNDARY"
	(constraint clearance (min 5.5mm))
	(condition "B.NetClass == 'PRIMARY*' && A.Layer == 'Margin'"))

designed to keep copper of a certain net away from an area defined by a drawing on the “Margin” layer. During routing, the rule works fine however the DRC does not pick up violations if a pad with the PRIMARY netclass violates the rule. Do I need to use a different rule type of pads?

308

I think you want edge_clearance, not clearance (for the constraint type).

309

I may have tried that (including hole_clearance) but I will give it a go again.

What is the difference between “clearance” and “edge_clearance”?

I see the different constraint types are listed in the syntax help file. Would it be possible to update the syntax help file with a brief description of the different constraint types?

1 Like
310

clearance only checks items on the same layer. edge_clearance checks between items on any layer and items on Edge.Cuts and Margin.

311

Unfortunately using edge_clearance didn’t bring up DRC errors when I ran the check. As before, the rule is “active” as the constraint appears when attempting to route a trace from the pad but does not show a DRC error if the pad itself is too close.

312

Select the pad and the graphic object on the Margin layer. Go to the Inspect menu and select Clearance Resolution…

Report back.

313

I get this:

Edge clearance resolution for:


Through hole pad 1 of CON1 [netclass PRIMARY_AC]

Line on Margin


Checking board setup constraints; edge clearance: 0,6350 mm.
Unconditional constraint applied.

Checking rule Copper to Board Edge; edge clearance: 0,5080 mm.
Checking rule condition "A.Layer == '*.Cu' && B.Layer == 'Edge.Cuts'".
Condition not satisfied; rule ignored.

Checking rule Copper to Board Edge; edge clearance: 0,5080 mm.
Checking rule condition "B.Layer == '*.Cu' && A.Layer == 'Edge.Cuts'".
Condition not satisfied; rule ignored.

Checking rule Reinforced PRIMARY to BOUNDARY; edge clearance: 5,5000 mm.
Checking rule condition "A.NetClass == 'PRIMARY*' && B.Layer == 'Margin'".
Rule applied; overrides previous constraints.

Checking rule Reinforced PRIMARY to BOUNDARY; edge clearance: 5,5000 mm.
Checking rule condition "B.NetClass == 'PRIMARY*' && A.Layer == 'Margin'".
Rule applied; overrides previous constraints.

Resolved clearance: 5,5 mm.
314

Any suggestions? Is there something else I could try or perhaps I have an incorrect setting?

315

5.5mm is what you want, right?

So it’s come up with the right answer, but DRC isn’t reporting it? (Are you sure you don’t have that DRC violation severity set to “ignore”?)

316

I’ll check the severity settings.

317

I set every Severity setting to “Error” and it still doesn’t come up