Rule evaluation order - priorities compared to the Board Setup "Constraints and netclasses"

Layout
1

ver K8:RC2
Are the CUSTOM CONSTRAINTS in the file evaluated before the other ones that are GUI selected?
That is - if I set the default clearance to 100mm in Design Rules - Constraints AND/OR Design Rules - NetClasses.
I would expect the CUSTOM constraints to be interpreted at a higher priority
otherwise you could never override anything.
—IE those “GUI rules” should be evaluated last, not first.

If indeed it is this way, I cannot make heads of tails of it.

if I have two traces Net A and Net B next to eachother, with this rule below in the file , I should be able to override the ‘default’ rules.
(rule “trace to trace clearance example”
(condition "A.NetName == ‘A’ && B.NetName==‘B’ ")
(constraint physical_clearance (min 1.5mm)))
But, it does not.
Any suggestions ?

2

Custom rules override the GUI rules, when they apply.

Use the clearance inspector to get an idea of why the clearance isn’t what you expect. Select both traces, then hit inspect → clearance resolution.

P.s. for copper you can use clearance rather than physical_clearance

1 Like
3

Hi . thanks for the pointers.
There seems to be a big difference to using clearance and physical_clearance.
So the inspector now indicates these clearances using clearance rather than physical_clearance.
Right… alright then that clears that up. ! doesnt quite work the way I expected it,
(See physical_clearance if you wish to specify clearance between objects regardless of net.)"
that’s fine, moving on :

Now my rule at the top of my DRU file works:

(rule "override clearance"
(condition "A.NetName == '*'")
(constraint clearance (min 0.125mm)))

I’ve got an example below where I have a rule for spacing of these nets

Rule :

(rule "trace to trace clearance example1"
(condition "A.NetName == 'A' && B.NetName=='B'")
(constraint clearance (min 1.5mm)))

Checking rule ‘trace to trace clearance example1’ clearance: 1.5000 mm.
Checking rule condition “A.NetName == ‘A’ && B.NetName==‘B’”.
Condition not satisfied; rule ignored.

Why did it not satisfy the condition ?. I thought it would catch all objects on all nets with netnames A and B ?

When I added an object check- it did work
(condition "A.Type == 'track'")
so I need to specify an object, so default object is not (star), it needs to be specified. OK.
So if I want a catch all between those nets I need to impose an additional condition
(condition "A.Type == '*'")

another example :

(rule "trace to trace clearance example2"
(condition "A.Type == 'Track' && B.Type == 'Track'")
(constraint clearance (min 1.7mm)))

Checking rule ‘trace to trace clearance example2’ clearance: 1.7000 mm.
Checking rule condition “A.Type == ‘Track’ && B.Type == ‘Track’”.
Rule applied; overrides previous constraints.

That was for any track, but it still showing as OK on the PCB .
How come when I inserted that rule, the continuous DRC checker did not flag all the traces on the board that failed that ?
OK I see it flags it if I try to do anything like drag.
But it does not prevent me moving the trace close. The behaviour I expected is to stop my moving the trace close, not allow me to push right over it.
Stopping me getting close enables quick minimum clearance setup. otherwise its a careful push until the trace flags green, and with fine grids (0.1mm) you can end up not quite at minimum clearance when you back off a bit from the flagged error.

Is there any way I can get using a single keypress, an DRC run that shows in highlighting (not arrows) all the online DRC errors ? IE if I change a rule for trace clearance, I could immediately get all the traces that are violating highlighted in the violation color…?

regards,

4

I have edited your latest post to use “Preformatted text” formatting for the rule lines. It makes them easier to read, and without it the forum SW messes up the characters and copying/pasting the rules doesn’t work because it copies wrong characters. Preformatted text is correct for displaying and copypasting.

1 Like
5

thanks, yes that is much better !

6

If you can upload a test project it might be easier to check. Off the top of my head, make sure your nets are actually called A and B (i.e. global labels) and not /A and /B (local labels).

For online DRC, when you move traces are you using D (drag, which uses the router) or M (move, which does not)? You will get online DRC that takes the design rules into consideration with D, but M doesn’t care.

P.S. for your first example rule, you can delete the wildcard net name condition, I think. A rule without a condition clause applies universally which is equivalent to that wildcard.

7

Hi
For the moment, I will leave explicit wild card conditions in , if anything, to make to completely obvious when reading , editing and rearranging rules. I have set all the gui rules to 0, so everything is a custom rule.
As for nets, it is just one schematic for 10 identical resistors.
They are all local nets. there is one sheet. I would only ever use global nets for POWER nets, otherwise always strictly hierarchical and no rule exceptions .Global nets are dangerous. …Big designs mean lots of organisation otherwise nothing will work.

I am trying various stuff out right now, probably need about 3 months at 1 hour day worth to learn what I need, so I might actually try a design in Kicad in about 6 months. At the moment it doesnt have the functionality I need, so a number of bridges have to be crossed including substantial added functionality and productivity.
So, at them moment I am in evaluation stage- to see if I can use Kicad.

8

OK, so in that case your net names are actually /A and /B and that’s why your rule isn’t firing. If this seems weird, consider a local label A on a sheet named subsheet, which would result in a net named /subsheet/A. Your local label A is in the root sheet, hence a net name /A.

If in doubt, select your trace in the PCB editor and see what the message panel says in the bottom left:

image

You can do the same check in the schematic editor, too.

image

9

Hi gkeeth
Thanks for the clarification on net names.
** The rule is firing, but only if I use the object specifier.
(condition "A.Type == '*'")

10

What is the full rule that is firing?

11 
(rule "trace to trace clearance example"
(condition "A.NetName == 'A' && B.NetName=='B'")
(condition "A.Type == '*'") 
(constraint clearance (min 1.5mm)))

Using ‘track’ for type also works (for tracks, of course)

12

OK, so in my schematic I have two nets locally labeled D0+ and D0-. Therefore their net names are /D0+ and /D0-.

This rule fires and works correctly (I just checked):

(rule test_net_name
	(condition "A.NetName == '/D0+' && B.NetName == '/D0-'")
	(constraint clearance (min 1mm)))

For your case, you need to change your rule to this:

(rule "trace to trace clearance example"
(condition "A.NetName == '/A' && B.NetName=='/B'")
(constraint clearance (min 1.5mm)))

Note the slashes before the net names. Those are needed because they are part of the net name for the nets you care about.

I think you’ll find that your multiple conditions were being OR’d together. Your second condition on object type wasn’t fixing the problem, it was masking it by making your rule fire for all objects, whether or not they matched your desired net name.

One more tip - if you get the net names right, autocomplete will help you out and suggest nets for you. If you aren’t getting anything in autocomplete in the rules editor, you’ve probably made a mistake somewhere.

13

thanks
OK so multiple condition statements are not AND ?
I thought each condition statement needed to be resolved to True to proceed ?

Your suggestion

(rule "trace to trace clearance example"
(condition "A.NetName == '/A' && B.NetName=='/B'")
(constraint clearance (min 1.5mm)))

did not work for me . It did not capture…

I tried this, it didnt work.

(rule "net to net clearance example"
(condition "A.NetName == '/A' && B.NetName=='/B' && AB.Type=='*'" )
(constraint clearance (min 1.5mm)))

neither did this

(rule "net to net clearance example"
(condition "A.NetName == '/A' && B.NetName=='/B' && A.Type=='*' && B.Type=='*' " )
(constraint clearance (min 1.5mm)))
14

I don’t think you can use '*' for types. Types aren’t text, they are types, and '*' is meant for text.

15

I strongly suspect we still have an issue with the net names that I can’t diagnose remotely. If you can upload your sample or a screenshot, I can help with that.

As for condition clauses, yes, the rule fires if any of the condition clauses are true (so OR behavior). The documentation does not make this very clear, which I will fix.

16

You can. This rule will fire on any object (and make your board unroutable in the process):

(rule test_wildcard
	(condition "A.Type == '*'")
	(constraint clearance (min 5mm)))
17

Thanks very much for taking the time to help me out on this.

ok OR behaviour for multiple conditions,alright, good to know.

and I presume AND for (multiple ) constraints application?.

as for use of wild cards. But then I’d need to write an OR for all the Types.
But it has to be * in this case because traces and vias, traces and zones etc. It would end up HUGE covering all combinations. IE wildcard for something like this needs to be covered.

OK thanks for clarifying that in your most recent post (wildcard) .

18

yes, all the constraints will be applied, which I suppose is AND behavior if you want to think about it like that.

19

I archived the project, I guess that’s the easiest way- attached
test1.zip (14.3 KB)

20

I don’t see any sense in it. Logically A.Type == '*' is the same as not comparing for type at all, i.e. it matches all and could be left out, and NOT-ing it matches nothing which is not useful. You also can’t control type names like you can e.g. reference designators (“R*”) except by accident because type names aren’t chosen with any specific letters in mind.

Or have I missed something?