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

#34

@overthere You may have no success because you’ve added the “priority” token to rules, it should go into the selectors instead. I did this initially too and it did not work either. The rest looks good to me.

#35

@JeffYoung It works great now! Thanks for implementing this :slight_smile:

image
image1291×757 117 KB

#36

Just to be clear I’m only implementing part of it. Jon Evans and Tom Wlostowski are doing the other bits.

The selector syntax in the prototype is going to be replaced by an expression language. This should make rule inversion, etc. easier.

You can already click on an error marker and see the violation, the violation amount, and the constraint source. (All are in the status bar at the bottom of the window.)

The rule editor will get syntax checking, code completion, etc. in time.

I’ve run into the quotes thing as well. Not sure what the plan will be there yet.

The

(selector (match_layer POWER3) (match_layer Edge.Cuts) (rule innertwo))

won’t work because when checking clearances the edges are copied to the copper layer.

However,

(selector (match_layer POWER3) (match_type board_edge) (rule innertwo))

should work.

Is this for neckdown? If so we’ll be implementing “areas” where you can assign different clearance values. These are often used under BGAs and the like.

#37

Yes, this will be nice on power electronic designs.

#38

Starting to test it now…

About the Design Rules >> Constraints. I like the icons, very intuitive.

The zone fill option should be a option box (as Design Rules >> Violation Severity), not a check box.

I would like some import/export (JSON or INF format for example) of the Design Rules >> Constraints. This will be nice to easy define the manufacture specifications (also the limitation of the university drill machine).

It could also include the a checkbox for “Allow vias under components” (default ON with a ballon tip: it may make DRC lower when OFF). This check for vias inside the parts contours (interesting for home and university hand-made PCBs).

I have linked the Gitlab reports in this comment revision.

#39

Yes, a link for the syntax will be nice.
But nicer some kind of autocomplete by the language when we type, if this design of text view will be the final user intended.

@JeffYoung could we expect (in future v6) some like this comment mine of a graphical way to link net and rules direct on Eeschema? Do you want that I split this request on Gitlab?

#40

We are planning to support defining net class membership, diff pairs, and other things like that on the schematic side. The details are still being discussed.

2 Likes
#41

Yes, this is on the roadmap (once we switch to expressions).

#42

Thanks for working on this very welcome feature.

First thing I tried was to add “TrackToPad” 0.5mm rule that is greater than usual clearance 0.2mm rule:

(selector (match_type track) (match_type pad) (rule "TrackToPad"))
(rule "TrackToPad" (clearance 0.5))

It works! However it can’t be used as-is, because It needs not to work at the points where the track is connected to the pad.

clearance-pad-to-track
clearance-pad-to-track1074×1074 331 KB

I imagine the upcoming feature to have areas with relaxed rules would help.
I would then need to add areas around all the footprint pads in the design for this exception.

It is hard to put into words this requirement if I wanted this to be done automatically. The simplest thing I can think of in terms of possible rules is “do not apply this rule around the pads of the track’s net”.

#43

@Nercury, see https://gitlab.com/kicad/code/kicad/-/issues/4279.

#44

Thanks, I should have realized this must not be a new idea, since this is the first thing I tried and failed. Waiting for local area rules then!

#45

Thanks for your proposals:

I tried the following:

(version 1)
(selector (match_layer GND2) (rule inner))
(selector (match_layer POWER3) (rule inner) (priority 1))
(selector (match_layer POWER3) (match_type board_edge) (rule innertwo) (priority 2))
(rule inner (clearance 0.3) (track_width 0.3) )
(rule innertwo (clearance 1.3) (track_width 0.3) )

does not work.
(I’m still using the same KiCad verison.)

#46

I’m about to push an update that hopefully addresses some of the issues.

Main changes:

  1. Priority is gone. Selectors are evaluated in order; last one that matches wins.
  2. Distances need to be categorised as min, max or opt.
  3. Disallow constraints are now implemented. (They’re easiest to use with keepout zones, but they will work with any zone they match against.)
  4. Improved parse error reporting which puts your cursor at the error.
  5. Autocomplete for rule syntax.
  6. Syntax help.
    NB: the help is for the new syntax which will replace separate selector statements with condition statements within the rules. This is not yet implemented, so you still need to use selector statements for now.

Some examples:

(version 1)
(selector (match_netclass "Default") (rule "Big Gap"))
(selector (match_layer "In1.Cu") (rule "Big Edge"))
(selector (match_type track) (rule "Big Gap"))
(rule "Big Gap" (constraint clearance (min 0.5)))
(rule "Small Edge" (constraint clearance (min 2)))
(rule "Big Edge" (constraint clearance (min 3)))
(selector (match_netclass "Default") (rule "exclude"))
(rule "exclude" (disallow via))
3 Likes
#47

I’ve played around with this a bit since I downloaded one of the earlier builds. I understand things have changed and they will continue to change.

Fair warnings:

Here are some thoughts and observations:

  1. Rules don’t capture multiple layers
    If the clearance is different on different layers, which is almost surely will be, this requires multiple rules.
    And if those multiple rules together form one meta-rule, each of the rules needs to capture that commonality but yet have a difference.
    This results in rules something like “30V_internal” and “30V_external”.
    Would be better to allow one rule to capture many layers (and just a specific layer, too, of course) based on location and type:
  • All outer
  • All inner
  • All signal
  • All power plane
  • All mixed
  • All jumper
    Naturally, if this is handled with a GUI it’s not so painful to have to type out each rule but any UX would be better with a single rule name.

  1. Net class groups
    In offline power supply circuits with a primary and secondary domain, all nets in those domains must be kept apart.
    This currently requires a huge mess of constraints, encompassing every net class to be sure no nets are missed.
    If one of more net classes could be captured in a group then the groups could be constrainted with far fewer rules.
    Could have a single ‘primary’ net class group, single ‘secondary’ net class group, and one rule setting constraint between the groups.
    Another example would be grouping of nets on each side of a board-board connector or wires that need to be constrained the same.

  2. Pins and tracks/zones are distinct
    IPC-2221A has different columns for copper on internal layers, copper on external layers under mask, exposed leads, etc.
    Different clearance rules are needed for each of those three locations, and it’s messy to do right now.
    #1 above captures some part of it, but rather than having loads and loads of rules it would be easier to have a single smart rule.
    Could have a single rule named “30V” with different spacings for different elements: track-track, track-zone, pin-pin, etc.

  3. Clearance line around pads is generally wrong
    There is a clearance line around pads that indicates the clearance for the net.
    As there used to be a single value for the net this was a valid line.
    But it no longer applies across the entire board because the clearance between a pad and another other object can vary.
    The clearance line therefore is confusing, at best, and should be removed or somehow consider there can be many clearances to each pad.

@JeffYoung
If I should try a newer version, you’d like me to create an issue or issues on Gitlab for any of the above, or anything else, please let me know. And thank you!!

Application: KiCad
Version: (5.99.0-1730-g52ae0df7a), 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:
Build date: May 20 2020 06:59:36
wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8)
Boost: 1.71.0
OpenCASCADE Community Edition: 6.9.1
Curl: 7.66.0
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_USE_OCC=OFF
KICAD_SPICE=ON

2 Likes
#48

Thank you guys(@JeffYoung) for implementing my requests.
Some additonal feedback from my side:

  • Delete Key does not work
  • A comment function would be nice to quickly test rules
  • I find “A” and “B” not clear in the new syntax. I would propose to rename the variables to “self” and (“meet” or “contact”)

The following syntax does not work.

(version 1)

(rule HV
(constraint clearance (min 5mm))
(condition “A.netclass == 500V”))

Maybe a dev-version i got from nightly?

Application: Pcbnew
Version: 5.99.0-unknown-eae0c14~101~ubuntu20.04.1, release build
Libraries:
wxWidgets 3.0.4
libcurl/7.68.0 OpenSSL/1.1.1f zlib/1.2.11 brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.2.0) libssh/0.9.3/openssl/zlib nghttp2/1.40.0 librtmp/2.3
Platform: Linux 5.4.0-31-generic x86_64, 64 bit, Little endian, wxGTK
Build Info:
Build date: Jun 1 2020 15:18:37
wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.24
Boost: 1.71.0
OCE: 6.9.1
Curl: 7.68.0
Compiler: GCC 9.3.0 with C++ ABI 1013

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

#49

The rules that involve two objects should be interchangeable (i.e. it should not matter which is “self” and which is “other”). So you could call them A and B, First and Second, etc.

#50

@overthere, the new expression evaluator is not yet in the code. So no condition clauses will be read at present.

@Evan_Shultz, when we do have the expression evaluator, I think it will address many of your issues (or at least allow us to address them more easily).

You could imagine, for instance:

(condition "A.layer.name == In*.Cu && A.netclass == 30V")
(condition "A.layer.type == 'power plane' && A.netclass == 30V")

The clearance lines are definitely an issue, but they can be useful for simpler systems, and those using the rules can turn them off.

#51

@JeffYoung
Yes. That would address #1 for sure. Thank you. If an element (‘A’, ‘B’, etc.) can be a track or pad or whatever, then yes, #3 should be addressed too.

I don’t see how expression help #2, but perhaps I’m not grasping it.

#52

Yes, A and B are the two elements in question. They can be pretty much any item, although at present we only run the rules on copper items and edge cuts items.

They would help 2 by allowing A.netclass.group == blah, although such a construct would also need us to have netclass groups defined somewhere.

#53

@craftyjon Yeah, I agree, that they should be interchangeable.

@JeffYoung please update us, when we may experiment with the condition clauses.