I think more grouping in general categories is good. I also think that it would be nice to exclude *specific* DRCs that once a designer checks the error, they can flag it to ignore in the future. The specific check could be identified by a unique id: a hash of specific information, like unique error and objects involved (identified by geometries and properties involved). If anything changes, then the rule violation reappears under a different unique id. I think this would help greatly on near-tapeout activities where sifting over the same DRC errors becomes tedious and prone to missing valid DRC violations in the midst of “designer checked and allowed” ones.
Greg S. > On Jun 10, 2020, at 7:59 PM, Jon Evans <[email protected]> wrote: > > Hi all, > > A DRC error code is something like "Via inside keepout area", or in > the code, DRCE_VIA_INSIDE_KEEPOUT. It describes a "type" of DRC > error. This type is used for organizing the errors in the DRC report, > and more recently, for letting you set a severity > (error/warning/ignore) for each code. > > Currently we have a lot of DRC violation types, probably because the > violation types match up to the underlying code that is doing the > checking. So, we also have a DRCE_MICROVIA_INSIDE_KEEPOUT and > DRCE_BBVIA_INSIDE_KEEPOUT, because a lot of KiCad code has separate > paths for those three types of vias. > > Do people find this useful? I think it is too specific: I would > rather see a single code DRCE_VIA_INSIDE_KEEPOUT to include all types > of vias. I could even see having a single code for any object inside > a keepout that isn't supposed to be there. I can't imagine a > situation where I would want to have a via inside a keepout be an > error, but a microvia inside a keepout be a warning or an ignore > (having the separate error codes means you can have seperate severity > settings). If I wanted to know if a particular DRC error referred to > a via or a microvia, I can do that from the linked item information -- > I don't need a category to tell me that. > > What do you think? Does having a lot of very specific error codes > help your workflow? Would you miss these categories if some of them > got consolidated like the example I gave? If so, are there other > changes we could make (or features we could add) that would make it > easier to deal with having less specific error codes? > > Thanks, > Jon > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
