kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #43889
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