I guess we just think about this differently. I would not use "errors" for anything that is a cost difference. I would only use errors to mean "this can't be built at any cost from my preferred manufacturer" or "this design won't work if I try to build it"
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. > > > > On 11 Jun 2020, at 16:47, Jon Evans <j...@craftyjon.com> wrote: > > > > Unconnected copper can also have electrical impacts. I agree it makes > > sense to have some separation between copper and non-copper (not > > connected vs. non-connected). > > > > I'm okay in general with the idea of trying to have different > > severities for production vs. design performance constraints and so > > on. Keeping annulus separate from via diameter is fine. > > > > Can you explain a situation where it makes sense to have e.g. > > through-via drill be a warning but uVia drill be an error or > > vice-versa? This is what I don't understand. > > > > On Thu, Jun 11, 2020 at 11:24 AM Jeff Young <j...@rokeby.ie> wrote: > >> > >> I’d definitely want to set edge clearance apart from other clearance. > >> > >> And I’d definitely want to set connected-item clearance (an electrical > >> constraint) apart from non-connected-copper-item clearance (a production > >> constraint). > >> > >> And I’d definitely want different violations for via annulus (a production > >> constraint) and via size (possibly just a current/heat constraint). > >> > >> I’m still on the fence with throughVia drill vs. uVia drill. The rest I > >> can agree with. > >> > >> Cheers, > >> Jeff. > >> > >> > >>> On 11 Jun 2020, at 15:56, Jon Evans <j...@craftyjon.com> wrote: > >>> > >>> I think having fewer codes is something to strive for, especially > >>> since we are auto-generating severity options from the list of codes. > >>> > >>> Having a bunch of severity settings where people wouldn't reasonably > >>> need to change them clutters the UI. > >>> > >>> Having excessive categorization in the DRC window makes it harder to > >>> sort through that information (for me at least). > >>> > >>> I don't think we need to be able to set severities independently for > >>> each rule in the "classic" system, we just need enough different > >>> severity settings to make sense. > >>> > >>> For example, going down the classic DRC rules dialog: > >>> > >>> Allowed features: both checkboxes generate DRCE_ALLOWED_FEATURES > >>> Arc/circle and zone fill: these aren't actually DRC checks > >>> Copper min clearance: generates DRCE_CLEARANCE > >>> Min track width: generates DRCE_WIDTH > >>> Min via annulus: generates DRCE_VIA_SIZE > >>> Min via diameter: generates DRCE_VIA_SIZE > >>> Copper edge clearance: generates DRCE_CLEARANCE > >>> Min through hole: generates DRCE_HOLE_SIZE > >>> Hole to hole: generates DRCE_HOLE_CLEARANCE > >>> uVia diameter: generates DRCE_VIA_SIZE > >>> uVia drill: generates DRCE_HOLE_SIZE > >>> > >>> > >>> > >>> On Thu, Jun 11, 2020 at 10:42 AM Jeff Young <j...@rokeby.ie> wrote: > >>>> > >>>> What does that buy us? The only things the error code gives us is a > >>>> string and a severity. The data storage (items, locations, etc.) is > >>>> already completely orthogonal. > >>>> > >>>>> On 11 Jun 2020, at 15:36, Jon Evans <j...@craftyjon.com> wrote: > >>>>> > >>>>> But couldn't this taxonomy be separate from the DRC_ITEM (i.e. error > >>>>> code) taxonomy? > >>>>> > >>>>> For example you could have a "classic minimum clearance" severity > >>>>> setting. > >>>>> This would set the severity of any DRCE_CLEARANCE items generated > >>>>> where the rule source is the classic system. > >>>>> This would replace all of the "X too close to Y" error codes > >>>>> > >>>>> I think if we did this, the minimum set of error codes would look > >>>>> something like one error code per setting in the Constraints setup > >>>>> dialog. > >>>>> Maybe even smaller than that number of settings, because you can set > >>>>> separate numbers for vias and microvias and I still don't think you > >>>>> need separate severities for those. > >>>>> > >>>>> On Thu, Jun 11, 2020 at 10:24 AM Jeff Young <j...@rokeby.ie> wrote: > >>>>>> > >>>>>> (But I do like being able to assign a severity to a rule.) > >>>>>> > >>>>>> On 11 Jun 2020, at 15:22, Jeff Young <j...@rokeby.ie> wrote: > >>>>>> > >>>>>> I think we’d still need some sort of taxonomy to put the severities on > >>>>>> for the “classic” system. > >>>>>> > >>>>>> On 11 Jun 2020, at 15:01, Ian McInerney <ian.s.mciner...@ieee.org> > >>>>>> wrote: > >>>>>> > >>>>>> Why not make the severity attached to the rule being used instead of > >>>>>> the error code type. I think being able to say "this rule is very > >>>>>> important and should be treated as an error" and "this rule is just a > >>>>>> guideline and can be treated as a warning" while they are both the > >>>>>> same error code would make more sense. > >>>>>> > >>>>>> -Ian > >>>>>> > >>>>>> On Thu, Jun 11, 2020 at 2:53 PM Jon Evans <j...@craftyjon.com> wrote: > >>>>>>> > >>>>>>> The only reasons to have multiple violation error codes is to be able > >>>>>>> to set a different severity for them, or to be able to filter/sort > >>>>>>> them. > >>>>>>> > >>>>>>> I can't think of a situation in which I would want to do either of > >>>>>>> those things for different via types. > >>>>>>> > >>>>>>> On Thu, Jun 11, 2020 at 9:48 AM Wayne Stambaugh > >>>>>>> <stambau...@gmail.com> wrote: > >>>>>>>> > >>>>>>>> I was thinking along the same lines. Wouldn't it make more sense to > >>>>>>>> define the objects that violate a DRC rule and generate the error > >>>>>>>> message on the fly rather than adding violation error codes for every > >>>>>>>> possible error? > >>>>>>>> > >>>>>>>> On 6/11/20 9:26 AM, Jon Evans wrote: > >>>>>>>>> I think microvias and vias using different technologies means they > >>>>>>>>> need different *rules*, not different error codes. > >>>>>>>>> > >>>>>>>>> Whether a hole is laser or mechanically drilled, it will have some > >>>>>>>>> rules, and those rules could generate an error "hole size is outside > >>>>>>>>> allowed range". > >>>>>>>>> > >>>>>>>>> You can tell from the affected items whether the hole in question > >>>>>>>>> is a > >>>>>>>>> via, microvia, blind via, buried via. > >>>>>>>>> You can tell from the rule source whether this came from a microvia > >>>>>>>>> rule, normal via rule, custom rule, etc. > >>>>>>>>> > >>>>>>>>> Why should we have separate violations per via type? (not separate > >>>>>>>>> *rules* but separate violations) I still don't get the use case. > >>>>>>>>> > >>>>>>>>> As mentioned in the last taxonomy discussion, I still think we could > >>>>>>>>> get rid of the tons of different "X close to Y" errors and just call > >>>>>>>>> it a "clearance error", but I understand that might be more > >>>>>>>>> contentious so I'd like to focus for now on just the keepouts and > >>>>>>>>> vias. > >>>>>>>>> > >>>>>>>>> -Jon > >>>>>>>>> > >>>>>>>>> On Thu, Jun 11, 2020 at 6:51 AM Jeff Young <j...@rokeby.ie> wrote: > >>>>>>>>>> > >>>>>>>>>> The “Inside Keepout” issue might be a bad example. I’d definitely > >>>>>>>>>> be in favour of folding all of those into a single violation > >>>>>>>>>> because a keepout already specifies which types of things are > >>>>>>>>>> excluded. > >>>>>>>>>> > >>>>>>>>>> But other things I’d be less in favour of. I want a warning about > >>>>>>>>>> NPTHs in courtyards; I don’t want one for PTHs (the former likely > >>>>>>>>>> has a mechanical fixing, the later likely doesn't). > >>>>>>>>>> > >>>>>>>>>> While I don’t personally use uVias, I’d certainly think we’d want > >>>>>>>>>> separate violations for their holes (as they’re made with > >>>>>>>>>> different technologies). On the flip side, I’m not sure there’s > >>>>>>>>>> any value in distinguishing between throughVia holes and pad holes. > >>>>>>>>>> > >>>>>>>>>> But that gives us a different taxonomy for size vs. hole, as the > >>>>>>>>>> difference between uVia and throughVia size may not be important. > >>>>>>>>>> (We already have this to some extent as I didn’t bother with > >>>>>>>>>> separate annulus violations for via types, although there’s a TODO > >>>>>>>>>> in the code). > >>>>>>>>>> > >>>>>>>>>> This all begs the question “how bad is an uneven taxonomy”? Is it > >>>>>>>>>> just an ivory-tower kind of thing, or will it actually cause > >>>>>>>>>> confusion? > >>>>>>>>>> > >>>>>>>>>> Back to specific instances, I like being able to treat > >>>>>>>>>> track-too-close-to-connected-item separately from > >>>>>>>>>> track-to-close-to-unconnected-item, but I’m less fussed about the > >>>>>>>>>> differences between the type of connected item > >>>>>>>>>> (track-to-close-to-via vs track-to-close-to-track). (For what > >>>>>>>>>> it’s worth, unconnected items are already grouped as we don’t have > >>>>>>>>>> separate errors for track-to-close-to-graphics vs > >>>>>>>>>> track-to-close-to-text. Yet another bit of unevenness in the > >>>>>>>>>> existing taxonomy.) > >>>>>>>>>> > >>>>>>>>>> Oddly I find the parallel-tracks vs crossing-tracks useful, but I > >>>>>>>>>> have no idea why. I guess it just gives me a better idea of what > >>>>>>>>>> I’m looking for on the board? > >>>>>>>>>> > >>>>>>>>>> One last note: Greg’s request for specific exclusions is already > >>>>>>>>>> in the nightlies. > >>>>>>>>>> > >>>>>>>>>> Cheers, > >>>>>>>>>> Jeff > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> On 11 Jun 2020, at 06:19, Greg Smith <ecomput...@yahoo.com> wrote: > >>>>>>>>>>> > >>>>>>>>>>> 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 <j...@craftyjon.com> > >>>>>>>>>>>> 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 : kicad-developers@lists.launchpad.net > >>>>>>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers > >>>>>>>>>>>> More help : https://help.launchpad.net/ListHelp > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> 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 > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> 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 > >>>>>>>>> > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> 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 > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> 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 > >>>>>> > >>>>>> _______________________________________________ > >>>>>> 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 > >>>>>> > >>>>>> > >>>>>> > >>>> > >> > _______________________________________________ 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
