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
