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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: >>>> >>>> (But I do like being able to assign a severity to a rule.) >>>> >>>> On 11 Jun 2020, at 15:22, Jeff Young <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>>>> 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 <[email protected]> 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 <[email protected]> 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 <[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 >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>>> >> _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
