kicad-developers team mailing list archive

[Jon Evans <jon@xxxxxxxxxxxxx>]

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 <jeff@xxxxxxxxx> 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 <jon@xxxxxxxxxxxxx> 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 <jeff@xxxxxxxxx> 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 <jon@xxxxxxxxxxxxx> 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 <jeff@xxxxxxxxx> 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 <jon@xxxxxxxxxxxxx> 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 <jeff@xxxxxxxxx> wrote:
> >>>>>>
> >>>>>> (But I do like being able to assign a severity to a rule.)
> >>>>>>
> >>>>>> On 11 Jun 2020, at 15:22, Jeff Young <jeff@xxxxxxxxx> 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.McInerney@xxxxxxxx> 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 <jon@xxxxxxxxxxxxx> 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 <stambaughw@xxxxxxxxx> 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 <jeff@xxxxxxxxx> 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 <ecomputerd@xxxxxxxxx> 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 <jon@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
> >>>>>>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
> >>>>>>>>>>>> More help   : https://help.launchpad.net/ListHelp
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> _______________________________________________
> >>>>>>>>>>> Mailing list: https://launchpad.net/~kicad-developers
> >>>>>>>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> >>>>>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
> >>>>>>>>>>> More help   : https://help.launchpad.net/ListHelp
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> _______________________________________________
> >>>>>>>>> Mailing list: https://launchpad.net/~kicad-developers
> >>>>>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> >>>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
> >>>>>>>>> More help   : https://help.launchpad.net/ListHelp
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> Mailing list: https://launchpad.net/~kicad-developers
> >>>>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> >>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
> >>>>>>>> More help   : https://help.launchpad.net/ListHelp
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> Mailing list: https://launchpad.net/~kicad-developers
> >>>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> >>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
> >>>>>>> More help   : https://help.launchpad.net/ListHelp
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Mailing list: https://launchpad.net/~kicad-developers
> >>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> >>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
> >>>>>> More help   : https://help.launchpad.net/ListHelp
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>
>