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.mciner...@ieee.org> 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 <j...@craftyjon.com> 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.mciner...@ieee.org> 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.mciner...@ieee.org> >>> wrote: >>>>> >>>>> On Thu, Jun 11, 2020 at 1:13 PM Jeff Young <j...@rokeby.ie> 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 >>>> _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
