After Kicon 2020, testing the new Design Rules, I realized that Design Rules are for DRC only. At least as I could understand.
There is one section there which is showing constraints. However there is no example there. Do you have any document explaining or showing more examples? Or maybe a sample of v6 project?
Also, I would like to make copper pours with standard clearance, let’s say 0.25 mm, but some tracks, for instance, high-speed tracks (100 MHz) I would like to have a bigger clearance, let’s say 1 mm.
I think “DRC” is doing the design rules scripting a disservice - first and foremost rules provide a language to describe attributes of a design. They are actionable and testable.
Actionable: the clearance resolutions of pairs of elements yields contours that inform zone filling and push&shove routing.
Testable: the more obvious case is that of design rule checking, but depending on how deeply the rules are evaluated, the design process should already be guided to a degree that avoids accidental rule violations.
I made a clearance rules design example which should be available tomorrow. Sounds like we’d also need some examples for higher dimensional clearance descriptions (clearances between net classes, individually on same and different layers).
This is weird…
DRC = Design Rule Check, and is for Checking Design Rules Indeed.
Each net can be in it’s own net class, with it’s own clearance setting, and those clearances are respected when filling zones. This is already implemented in KiCad V5, Probably also already for KiCad V4.
I can’t help but feel that I misinterpret the question in some way.
Another thing I found weird, was S-expression syntax for the design rules. I would have expected Python syntax.
I’m in doubt of posting this post.
Maybe it’s wizer to assume those people have thought longer, harder and better about this then I did.
I don’t know if there’s anything “weird” about it, but I don’t also wonder there’s some confusion.
In v5 (and even before) there was simple generic configuration for design rules minimum values and some generic clearances, and also clearance rule – i.e. minimum copper clearance – for each net class.
In 5.99 there’s that plus s-expression like language for adding many kinds of rules, for copper, other than copper, single nets, net classes, minimum, maximum, optimal, keepout, for different kinds of items, etc.
As for the choice of the language: it’s a language for constraints, not a programming language. Therefore python wouldn’t necessarily be optimal. S-expression is already used in KiCad, so why not use that, and it’s more suitable for these needs.
I think this hasn’t been very clear. Until now the new rule system has worked for the DRC check only. But the intent and plan has always been to “hook” it to the push’n’shove router, too. Indeed, it wouldn’t make much sense to define sophisticated checks for rules if you can’t obey those rules automatically in the design phase. Or at least it would be very cumbersome.
It is already hooked in to the zone filler (and has been for some time).
But yes, hookup to the router is coming…
(So why the DRC terminology? Just because we get so used to the ‘C’ following ‘DR’. It’s kind of like silk. When was the last time your board’s legend was actually painted with a silkscreen?)
Design Rules and Constraints are just two different terms for the same thing.
Like Jeff said, we often shorten the phrase “Design Rules System” or “Design Rules Engine” to “DRC system” / “DRC engine” despite the fact that design rules are not just used for the Design Rule Check, but also for the router / zone filler / etc
On that note: it’s funny to see that the previews in DRC workaround for high voltage clearance are inconsistent (hover to see correct links). Not 100% sure about the forum here ^^