← Back to team overview

kicad-developers team mailing list archive

Re: DRC rules

 

Jeff,

A definite +1 for that from over here! Thanks for the clarification.

Yours,
James.

On Thu, May 21, 2020 at 1:33 PM Jeff Young <jeff@xxxxxxxxx> wrote:

> While the prototype is selector-based the “real” implementation is likely
> to be expression-based, so you’ll be able to say something like:
>
> (rule “my special rule” … (condition “A.net == B.net”))
>
> Cheers,
> Jeff.
>
>
> On 21 May 2020, at 12:19, James Jackson <james.a.f.jackson.2@xxxxxxxxx>
> wrote:
>
> Hi Jeff,
>
> The background is that I'm looking at a ruleset which has different rules
> depending on whether two neighbouring vias are in the same, or different,
> nets. Running the risk of 'feature creep', of course, I think the
> constraints can indeed be met by what is there, but I suppose my question
> (and apologies for think out loud - the nature of the beast!) can be
> considered as 'Can a rule be matched based on whether the two objects are
> in the same, or different, nets?' Of course, this could be done by matching
> all permutations and combinations of nets, but that would become a
> combinatorial nightmare!
>
> Yours,
> James.
>
>
> On Thu, May 21, 2020 at 11:29 AM Jeff Young <jeff@xxxxxxxxx> wrote:
>
>> Hi James,
>>
>> It sounds like you’re looking for hole-to-hole min.  That’s in the
>> existing constraints system in 5.99; you don’t need rules for that.
>>
>> Or does your hole-to-hole min depend on the specific via, specific
>> netclass, or something else?  (The current hole-to-hole min is board-wide.)
>>
>> Cheers,
>> Jeff
>>
>>
>> On 21 May 2020, at 10:54, James Jackson <james.a.f.jackson.2@xxxxxxxxx>
>> wrote:
>>
>> Hi Jeff,
>>
>> Many thanks for this - looks very powerful, and when it gets hooked in to
>> the PNS router will be killer. An issue I'm currently grappling with a
>> variety of rules considering placements around vias. Some rules require a
>> distance measured from the outside of the annular ring to a track (or
>> another annular ring outer edge), and some from the outside of a hole (i.e.
>> the inside of the annular ring) to the nearest other outside edge of a
>> hole. I suspect the former is achieved with what is currently there, but is
>> the latter possible? It's essentially a question of where via-to-via
>> measurements are made.
>>
>> Thanks,
>> James.
>>
>>
>>
>> On Sat, May 16, 2020 at 4:44 PM Jeff Young <jeff@xxxxxxxxx> wrote:
>>
>>> I’ve just merged a possible implementation of the DRC rules.  I’d like
>>> to get some feedback on it, and also some testing.  (Because the rules
>>> support such a wide range of possibilities it’s going to need a good deal
>>> of testing.)
>>>
>>> For now, it picks up DRC rules from a file named “drc-rules” in the
>>> project directory.
>>>
>>> There’s no GUI editor at present: use a text editor.
>>>
>>> Grammar is s-expr.  It generally follows the ideas set down here:
>>>
>>>
>>> https://docs.google.com/document/d/1qvCH9aHwCzp5qtKTna4jJXuloNU0b96gAxAHSKPuXpU
>>>
>>> with one major exception: I found the select-a-single-rule didn’t pan
>>> out.  You have to duplicate too much stuff in each rule for that.
>>>
>>> Also, because the DRC engine (and zone filler) don’t currently support
>>> min/opt/max the prototype implements min with Seth’s “relaxed” option.
>>>
>>> Top level is a list; first expression must be (version x) followed by
>>> any number of (selector…) and (rule…) expressions.
>>>
>>> /*
>>>  * Match tokens:
>>>  *     match_netclass
>>>  *     match_type
>>>  *     match_layer
>>>  *     match_all
>>>  *     match_area  (not yet implemented with the exception of “$board”, which matches everything)
>>>  *
>>>  *     (selector (match_area "$board") (rule "OSHParkClass3") (priority 100))
>>>  *
>>>  *     (selector (match_netclass "HV") (rule "HV_internal"))
>>>  *     (selector (match_netclass "HV") (match_layer "F_Cu") (rule "HV_external"))
>>>  *     (selector (match_netclass "HV") (match_layer "B_Cu") (rule "HV_external"))
>>>  *
>>>  *     (selector (match_netclass "HV") (match_netclass "HV") (rule "HV2HV"))
>>>  *     (selector (match_netclass "HV") (match_netclass "HV") (match_layer "F_Cu") (rule "HV2HV_external"))
>>>  *     (selector (match_netclass "HV") (match_netclass "HV") (match_layer "B_Cu") (rule "HV2HV_external"))
>>>  *
>>>  *   TODO: pads for connector pins or wire pads have even larger required creepage clearances.  How to encode?
>>>  *   User attributes on parent footprint?
>>>  *
>>>  *     (selector (match_netclass "HV") (match_type "pad") (match_netclass "HV") (match_type "pad") (rule "pad2PadHV"))
>>>  *
>>>  *     (selector (match_netclass "signal") (match_area "BGA") (rule "neckdown"))
>>>  *
>>>  * Type tokens:
>>>  *     track
>>>  *     via
>>>  *     micro_via
>>>  *     blind_via
>>>  *     pad
>>>  *     zone
>>>  *     text
>>>  *     graphic
>>>  *     board_edge
>>>  *     hole
>>>  *     npth
>>>  *     pth
>>>  *
>>>  * Rule tokens:
>>>  *     allow  (not yet implemented)
>>>  *     clearance
>>>  *     annulus_width
>>>  *     track_width
>>>  *     hole
>>>  *
>>>  * Rule modifiers:
>>>  *     relaxed
>>>  *
>>>  *     (rule "HV" (clearance 200) (priority 200))
>>>  *     (rule "HV_external" (clearance 400) (priority 200))
>>>  *     (rule "HV2HV" (clearance 200) (priority 200))
>>>  *     (rule "HV2HV_external" (clearance 500) (priority 200))
>>>  *     (rule "pad2padHV" (clearance 500) (priority 200))
>>>  *
>>>  *     (rule "signal" (clearance 20))                       // implied priority of 1
>>>  *     (rule "neckdown" (clearance relaxed 15) (priority 2))
>>>  *
>>>  *     (rule "allowMicrovias" (allow microvia))
>>>  */
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>
>>
>

References