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

We may thinking about programmable in python DRC instead. This would allow design to turn on/off, or event redefine new DRC rules base on the condition that dynamically.
https://www.mentor.com/products/ic_nanometer_design/multimedia/overview/scaling-photonic-design-with-automation-1330cb9c-fe5c-47bd-afb1-7b38f59efc77

Sorry @JeffYoung, it seems that I am unable to do it.

I updated the rules with the following expression:

(version 1)
(selector (match_layer “TOP1”) (rule “default”))
(rule “default” (constraint clearance (min 0.1mm)))
(selector (match_layer “GND2”) (rule “two”))
(rule “two” (constraint clearance (min 5.0mm)))

So there should be a large clearance on the orange layer (“GND2”). However, I get this. Does not look right to me. If you want to have my boards for experiments, I can share it with you privately.

EDIT: It seems to me, that the clearance conditions are swaped.

So it looks like you’re getting the nice wide circles in the GND2 plane around the through vias. The circled SMD pads are on a different layer, so there’s no clearance between them and the GND2 plane at all.

Or am I misinterpreting what I’m looking at?

(Which could be. I’m on a lot of painkillers for a broken ankle. :frowning: )

Probaby.
If you look at the bottom right corner of the screenshot:
image
You see that the centers of the circles are at 2 vertical rows, and the only logical origin is if it is a clearance for the pads of the IC.

I once broke both wrists, and I got zero painkillers. As long as I did not move my wrists or put any load on it in any way it did not hurt, which was a good reason to not stress the broken bones.

Oh, you mean the clearance lines, not the actual zone knock-outs? (I never have those on, so I thought those were just your ratsnest.)

The clearance lines can only show the owning object’s rules (not any other objects it interacts with). So I’m not sure how useful they are in a rule-based system…

@JeffYoung, sorry for my late reply and my clearification. So let me try to be extra precise.

My layer stack looks like this:
grafik
where GND2 and POWER3 are internal layers.

My rules look the following:

(version 1)
(selector (match_layer “TOP1”) (rule “default”))
(rule “default” (constraint clearance (min 0.1mm)))
(selector (match_layer “GND2”) (rule “two”))
(rule “two” (constraint clearance (min 5.0mm)))

So on all layers there should be a clearance of on TOP 0.1mm, except for layer GND2, which is orange.
If you look now on the postet screenshot you can notice several problems:

  • The pad clearance as @paulvdh mentioned, is incorrect. It is set by the rule “two”.
  • The clearance of the filling in the GND2 layer(orange) should be 5mm, which is far too little.

@JeffYoung: I can send you the board files by email, so you can reproduce that problem.

Yeah, why don’t you send me the board files at “jeff@rokeby.ie”. It’s hard to tell the scale from the screenshots.

@JeffYoung: I send you the boardfiles. Thanks again for implementing the DRC.

There’s an error in the selector logic: it only looks for system layer names, not user layer names. Fix is on the way.

In the meantime you should be able to test it by changing the selectors to referencing "F.Cu" and "In1.Cu" (the quotes aren’t required but if you do use them make sure they’re standard double-quotes, not curly ones).

2 Likes

@JeffYoung: Thanks, that seems to solve it. I will test in detail soon.

Feature Request: How about some error messages, if a rule parameter/variable cannot be understood.
"E.G. Could not find Layer “TOP1"”. That would make debugging easier.

First test impression: I would like to see the pad clearance only for padclearance, not for inner layers. E.g. here.
grafik

There is nothing on GND2, however it shows the pad clearance. I find that confusing.

Maybe also some warning at the DRC if there is some rule (apparently well written) but never used at the layout.

1 Like

@JeffYoung: I tried with the pad clearance and the pad clearance still shows up. Maybe you could work on that?

Then I tried to modify the pad rule
grafik

If you want to copy it:

(version 1)
(selector (match_type “pad”) (rule “padclearance”))
(rule “padclearance” (constraint clearance (min 0.1mm)))
(selector (match_layer “TOP1”) (rule “default”))
(rule “default” (constraint clearance (min 0.1mm)))
(selector (match_layer “GND2”) (rule “two”))
(rule “two” (constraint clearance (min 1.0mm)))

Why does rule two define the pad clearance? I do not understand.
@JeffYoung: You should have my boardfiles, so it should be easy to diagnose.

EDIT after playing around: It seems to me, that it’s a match_type issue.

@JeffYoung: Are there any news? Ping =)

I got sucked in to Eeschema netclasses and undo. I hope to get back to this shortly…

2 Likes

@overthere, I just merged an update which brings in the new expression syntax. Your rules would look something like:

(version 1)
(rule "default"
    (constraint clearance (min 0.1mm))
    (condition "A.onLayer('TOP1')")
)
(rule "two"
    (constraint clearance (min 5.0mm))
    (condition "A.onLayer('GND2')")
)
(rule "padclearance"
    (constraint clearance (min 0.1mm))
    (condition "A.type == 'pad'")
)

I’m not sure when the nightlies are built, so if they’ve already started it won’t make it in tonight’s.

He he… and you’ll need to use the standard layer name instead of ‘GND2’ for now because the new code doesn’t handle user layer names either…

[It was easier to fix than I thought so it’s in now too.]

I’m looking at this example and the Syntax Help. Except for these examples I don’t have an idea where the properties or functions in the expressions come from. I would like to see some reference to a place where I can find them, unless they can be put into the Syntax Help.

@JeffYoung:

  • If i use the padclearance and fill with b, Kicad crashes.
  • If i use a wrong user-netname, kicad crashes.
  • If i reopen the project in pcbnow, kicad crashes as a subsequent error. If you save with a wrong rule (that cannot be read, there should be a warning wether i want to save the project).

Tested version:

Application: KiCad

Version: (5.99.0-2364-g42a2f1346), release build

Libraries:
wxWidgets 3.0.4
libcurl/7.66.0 OpenSSL/1.1.1d (Schannel) zlib/1.2.11 brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.1.1) nghttp2/1.39.2

Platform: Windows 8 (build 9200), 64-bit edition, 64 bit, Little endian, wxMSW

Build Info:
Date: Jul 21 2020 23:00:28
wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8)
Boost: 1.71.0
OCE: 6.9.1
Curl: 7.66.0
ngspice: 31
Compiler: GCC 9.2.0 with C++ ABI 1013

Build settings:
KICAD_SCRIPTING=ON
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_PYTHON3=OFF
KICAD_SCRIPTING_WXPYTHON=ON
KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
KICAD_SCRIPTING_ACTION_MENU=ON
BUILD_GITHUB_PLUGIN=ON
KICAD_USE_OCE=ON
KICAD_SPICE=ON

I used now another PCB version, and I get random results for the filling.

First:


Second:

Third…
grafik

In the third (which is basically only the GND2 rule copied, obvious filling errors in the clearance are present:
grafik

I propose that you play a little bit with the PCB file that I send with you. Than you can probabbly reproduce my encountered errors.

We have a test-suite for the DRC engine that we’re building out; the purpose of the guinea pigs is more to find out what people try to do with it (so that we can see if the expressivity is sufficient). To that end I’m fixing bugs that keep people from trying it out, but there’s no expectation at present that it’s anywhere near stable.

The crashers should be fixed; I haven’t had a chance to look at the random zone filling yet…