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

Software
1

First the small text: the rule syntax WILL CHANGE. What’s there today is a PROTOTYPE. There will be NO TOOLS for migrating today’s rules to later rules. Think of it as a sandbox, not a work-in-progress.

But I’d still like to get some feedback on what it does well, what it does poorly, and what is missing.

If you’ve never use a nightly, our built from scratch, this probably isn’t for you. But if you have…

The rules go in a file in your project named “drc-rules”. You can edit them there in your favourite text editor, or you can edit them in Board Setup > Design Rules > Rules and let Kicad worry about the name, location, etc.

The rule file is in sexpr. The top level is a list; the first expression must be (version x) followed by any number of (selector…) and (rule…) expressions.

Selectors determine what to apply rules to; rules enforce minimums.

 Match tokens:
     match_netclass
     match_type
     match_layer
     match_all
     match_area  (not yet implemented with the exception of “$board”, which matches everything)

     (selector (match_area "$board") (rule "OSHParkClass3") (priority 100))

     (selector (match_netclass "HV") (rule "HV_internal"))
     (selector (match_netclass "HV") (match_layer "F_Cu") (rule "HV_external"))
     (selector (match_netclass "HV") (match_layer "B_Cu") (rule "HV_external"))

     (selector (match_netclass "HV") (match_netclass "HV") (rule "HV2HV"))
     (selector (match_netclass "HV") (match_netclass "HV") (match_layer "F_Cu") (rule "HV2HV_external"))
      (selector (match_netclass "HV") (match_netclass "HV") (match_layer "B_Cu") (rule "HV2HV_external"))

   TODO: pads for connector pins or wire pads have even larger required creepage clearances.  How to encode?
   User attributes on parent footprint?

     (selector (match_netclass "HV") (match_type "pad") (match_netclass "HV") (match_type "pad") (rule "pad2PadHV"))

     (selector (match_netclass "signal") (match_area "BGA") (rule "neckdown"))

 Type tokens:
     track
     via
     micro_via
     blind_via
     pad
     zone
     text
     graphic
     board_edge
     hole
     npth
     pth

 Rule tokens:
     allow  (not yet implemented)
     clearance
     annulus_width
     track_width
     hole

 Rule modifiers:
     relaxed

     (rule "HV" (clearance 200))
     (rule "HV_external" (clearance 400))
     (rule "HV2HV" (clearance 200))
     (rule "HV2HV_external" (clearance 500))
     (rule "pad2padHV" (clearance 500))

     (rule "signal" (clearance 20))
     (rule "neckdown" (clearance relaxed 15))

     (rule "allowMicrovias" (allow microvia))
1 Like
2
3

A question came up elsewhere “why do some of the selectors specify a match twice and others only once?”

A selector that specifies match-netclass "HV" once will match a HV item with any other item.

A selector that specifies match-netclass "HV" twice will match a HV item only with another HV item.

4

Here’s Jeff’s initial post in the dev mailing list: https://lists.launchpad.net/kicad-developers/msg43846.html. It gives some more details.

5

I’m interested to try it out, I’m not sure which version of KiCad should I be using for this, if you can lay down some basic instructions for the setup requirements.

6

The absolutely latest nightly build - for Windows: https://kicad-downloads.s3.cern.ch/index.html?prefix=windows/nightly/

7

@eelik For Linux, I just need to clone the master branch of the Git repo and build?

8

Depends on your distro. They are packaged for some distros.

9

What about Ubuntu 18.04?

10

If I add rules content to the editor, try DRC, delete the content and click OK of the dialog, I get a warning message:

image
image734×395 5.89 KB

EDIT: yes, it was a nightly build and is fixed later.

11

If that’s a nightly then it’s already fixed.

If it’s a fresh build then there must be something else going on…

12

If your Linux doesn’t have a package available, cloning the git repo and building will definitely do the trick.

13

@JeffYoung Alright so I got the latest nightly build and trying the new DRC.

I added the drc-rules files with some selector and rules:

(selector (match_netclass “SPI”) (match_layer “F_Cu”) (rule “50-OHM_SING_OUTER”))
(selector (match_netclass “SPI”) (match_layer “In1_Cu”) (rule “50-OHM_SING_INNER”))
(selector (match_netclass “SPI”) (match_layer “In2_Cu”) (rule “50-OHM_SING_INNER”))
(selector (match_netclass “SPI”) (match_layer “B_Cu”) (rule “50-OHM_SING_OUTER”))

(rule “50-OHM_SING_OUTER” (clearance 0.3) (track_width 0.3) (priority 1))
(rule “50-OHM_SING_INNER” (clearance 0.3) (track_width 0.2) (priority 1))

And right off, I got this warning message opening my PCB file (it keeps on showing each time I close the Board Setup window):
image

Passed the message, I opened the Board Setup window and could see the file was loaded correctly:

image
image738×333 38.9 KB

I added the Netclass “SPI”, leaving default value for “clearance”, “track width”, etc. and added a net to the SPI class:

image
image1136×279 22.3 KB

But I’m not able to route this net with the rules defined above… it’s using the default “track width” specified in the Net Classes tab.

What am I doing wrong?
Should I define my net class in the drc-rules file? How?
How should I specify which net is part of this net class?

14

Two things:

  • Insert (version 1) on the first line of your rules file.
  • The rules aren’t hooked up to the PNS router yet. (And zone filling won’t be in till tonight’s build.) The main hookup at present is DRC.

Other than that it all looks correct. (Note that you don’t have to specify all the match tokens, just the ones you want to match on.)

15

@JeffYoung Ha no router connection yet, I got too excited sorry!

After adding (version 1) to the first line, I’m getting this other warning pop-up:
image

It is referring to the first rule line, it does have clearance and track_width tokens.

I’m not getting any DRC error on the net other than it is not connected on the other end (I’ve checked the “Report all errors for tracks (slower)” option):

image
image880×774 40 KB

Where can one see DRC errors/warnings related to those rules?

16

The error is complaining about priority. (That goes in the selector clause, not the rule clause.)

Once the parser encounters an error it throws out the clause. So they should show you DRC errors once you remove the priority clauses from the rules.

17

@JeffYoung I think you may want to update your initial post as there is the priority field in all the rule entries:

    (rule "HV" (clearance 200) (priority 200))
    (rule "HV_external" (clearance 400) (priority 200))
...

I have removed them and not getting warning messages anymore.

Running the DRC, I’m getting 2 markers:

  1. Pad too close

    image
    image761×808 46.4 KB

  2. Track too close

    image
    image1161×795 61.5 KB

I lowered the “clearance” value to 0.1mm:

(selector (match_netclass “SPI”) (match_layer “F_Cu”) (rule “50-OHM_SING_OUTER”))
(rule “50-OHM_SING_OUTER” (clearance 0.1) (track_width 0.3))

But still getting those errors.
Same thing after removing the “clearance” token from this rule.
However, if I remove the clearance token from the other rule too (inner layer), the DRC markers disappear.

I have yet to see a warning/error for the track width (rule says 0.3mm for outer layer and I routed it with 0.203mm).

18

Ha! No wonder a bunch of people were putting priority in the wrong place. :wink:

Note down in the status bar that the error message says where it’s coming from. In your second screenshot is says “50-OHM_SING_OUTER rule clearance 0.300mm”. When you reduce that to 0.1 does it still report that it’s 0.300mm?

Hmm… I suspect this might be because the pad is on all the layers, and it might not be smart enough to pick out the particular layer in question…

19

Yes, the layer test matches if either item is on the given layer. I need to change it to both items on the given layer.

20

Fixes pushed…
7d537e83ead84b06e7bb3190bb68be9456118a6a