kicad-developers team mailing list archive

[Jon Evans <jon@xxxxxxxxxxxxx>]

Jeff - what do you think about this?

I think it's an interesting thought.

Previously, we've had very close to a 1:1 mapping between rule and error code.
So, it made sense to assign severities to error codes.

Now with the expanded rules system in the works, I think it will be a
N:1 mapping between rule and error code.  I think what Wayne and Ian
mention makes a lot of sense to me.

-Jon



On Thu, Jun 11, 2020 at 10:01 AM 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