Yeah, I want to know if the cost is going to increase (so it’s a warning), but I only want an error if it’s going to drop me out of pooling.
> On 11 Jun 2020, at 18:18, Jon Evans <[email protected]> wrote: > > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[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
