kicad-developers team mailing list archive

[Jon Evans <jon@xxxxxxxxxxxxx>]

That has yet to be determined, IIRC.  Jeff expressed a preference for
keeping around the current "basic rules" GUI we have, but that doesn't
answer whether those rules are internally represented in the new rules
engine or via a different path.

I think it makes sense to express them as part of the new rules engine
internally so that we don't have two parallel paths of tests.  I don't
think it's a good idea to express them that way externally (i.e. put
them in a rules file as a template).

For one, putting them in the file would break the proposed priority
system Jeff and I were talking about earlier, where netclass rules
beat/combine with basic rules and file rules beat netclass rules.
This would open back up that whole can of worms which I'd rather not
at this point :)

So, I think what I'm suggesting is:

- A way to assign a severity to each of the basic and netclass rules
(and also adding severity to the custom rules syntax)
- Decoupling severity from DRC error code
- Simplifying and consolidating DRC error codes as much as possible,
since now they will mostly just be categories for grouping things in
reports.

I can handle these three things as part of the project settings branch
I'm working on now.  I do not want to try to tackle moving the basic
rules over to a new engine as part of that, but it could happen
afterwards.

-Jon


On Thu, Jun 11, 2020 at 2:25 PM Ian McInerney <Ian.S.McInerney@xxxxxxxx> wrote:
>
> I might have missed something, but how are the basic rules being specified? Are we going to ship them as pre-built selectors that run through the same DRC engine as the custom rules (so we only have one engine to worry about), or are they being done differently? It would seem better to ship them as pre-built selectors and use the same mechanisms for specifying the severity of them as custom rules would. I think that is also nicer, because it essentially provides an example rules file.
>
> -Ian
>
> On Thu, Jun 11, 2020 at 6:40 PM Jon Evans <jon@xxxxxxxxxxxxx> wrote:
>>
>> Yeah I like this.
>>
>> For the basic rules, we could still make it so that each basic rule had independent severity while generating common error codes, although that increases complexity. It might be better to keep one error code per "basic" rule, except for the ones we are already in agreement can be consolidated.
>>
>> Then for net class and custom rules, we can just have the severity be a rule property, not an error code property.
>>
>> -Jon
>>
>> On Thu, Jun 11, 2020, 13:36 Ian McInerney <Ian.S.McInerney@xxxxxxxx> wrote:
>>>
>>> Another example I just thought of (not involving costs): differential pair rules. We could have a category "Trace length mismatch" (or some other name...), and then someone could define rules such that:
>>> Rule 1) If mismatch > x, flag the "Trace length mismatch" as an error
>>> Rule 2) If mismatch > y, flag the "Trace length mismatch" as a warning
>>>
>>> When x > y and rule 1 is a higher priority, this can then basically allow for a zone for the DRC to flag the length mismatch where the design will still work, but is not ideal as a warning, and any larger values where the design would fail as an error.
>>>
>>> -Ian
>>>
>>> On Thu, Jun 11, 2020 at 6:25 PM Ian McInerney <Ian.S.McInerney@xxxxxxxx> wrote:
>>>>>
>>>>> On Thu, Jun 11, 2020 at 1:13 PM Jeff Young <jeff@xxxxxxxxx> wrote:
>>>>> >
>>>>> > Imagine that violating the micro-via min bumps me up a classification but violating the through-via min drops me out of pooling.  There’s a big cost difference between those two.
>>>>> >
>>>>
>>>>
>>>> This is why I think switching to the severities coming from the rules would be a better way than defining them by the category of the violation. By doing that we can limit the need for a lot of categories of violations. We can for instance have a single code for "Minimum drill violated", and then have two different rules for the minimum u-via drill and the minimum through-via drill. Then those rules can treat the code "Minimum drill violated" as either a warning or an error as they see fit.
>>>>
>>>> -Ian
>>>>