kicad-developers team mailing list archive

[Ian McInerney <Ian.S.McInerney@xxxxxxxx>]

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
>