kicad-developers team mailing list archive

[Jon Evans <jon@xxxxxxxxxxxxx>]

OK.  I think since we agreed to not remove the "basic" rules system,
it doesn't make sense to try to shoehorn it into the new rules engine.
The basic system makes some decisions that are pretty hard to undo
without blowing it up, so if we have the goal of preserving "classic"
behavior we should probably just accept that will mean a bit of extra
code complexity.

On Thu, Jun 11, 2020 at 4:27 PM Jeff Young <jeff@xxxxxxxxx> wrote:
>
> I had also originally planned on “compiling” the classic system into behind-the-scenes rules, but I don’t think that’s going to work out.  It’s pretty easy to agree on priority of all the edge case (pad override, footprint overrides, netclasses vs. board settings, etc.), but there’s nothing uniform about them.
>
> > On 11 Jun 2020, at 19:35, Jon Evans <jon@xxxxxxxxxxxxx> wrote:
> >
> > 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
> >>>>>
>