kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #44022
Re: Granularity of DRC error code
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
>>>
>>>
Follow ups
References
-
Granularity of DRC error code
From: Jon Evans, 2020-06-11
-
Re: Granularity of DRC error code
From: Greg Smith, 2020-06-11
-
Re: Granularity of DRC error code
From: Jeff Young, 2020-06-11
-
Re: Granularity of DRC error code
From: Jon Evans, 2020-06-11
-
Re: Granularity of DRC error code
From: Wayne Stambaugh, 2020-06-11
-
Re: Granularity of DRC error code
From: Jon Evans, 2020-06-11
-
Re: Granularity of DRC error code
From: Ian McInerney, 2020-06-11
-
Re: Granularity of DRC error code
From: Jeff Young, 2020-06-11
-
Re: Granularity of DRC error code
From: Jeff Young, 2020-06-11
-
Re: Granularity of DRC error code
From: Jon Evans, 2020-06-11
-
Re: Granularity of DRC error code
From: Jeff Young, 2020-06-11
-
Re: Granularity of DRC error code
From: Jon Evans, 2020-06-11
-
Re: Granularity of DRC error code
From: Jeff Young, 2020-06-11
-
Re: Granularity of DRC error code
From: Jon Evans, 2020-06-11
-
Re: Granularity of DRC error code
From: Jeff Young, 2020-06-11
-
Re: Granularity of DRC error code
From: Jon Evans, 2020-06-11
-
Re: Granularity of DRC error code
From: Ian McInerney, 2020-06-11
-
Re: Granularity of DRC error code
From: Ian McInerney, 2020-06-11
-
Re: Granularity of DRC error code
From: Jon Evans, 2020-06-11