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

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

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

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

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.

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

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.)

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?

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

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

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

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.

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

Report back.

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.

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

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”?)

I’ll check the severity settings.

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

Can you post the project here?

(Or if it’s confidential can you email it to jeff@rokeby.ie?)

For everyone who is testing the new custom rules system in 5.99, I have started writing the documentation for it. There is still a lot of work left to do on the manual, but I’m posting a link early because even the incomplete state may be useful to those doing testing. https://docs.kicad.org/master/en/pcbnew/pcbnew.html#custom_design_rules

I’ll be continuing to fill out the missing info in the coming days and weeks.

8 Likes

Nice, understanding now some missing points.

I saw that you most use two characters to represent the measurement units. But could be possible to use “mil”, “rad” and “deg” instead? It make a better SI match.