kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

We definitely should define this before we get too far down the road.  I
would rather not store layout constraints in the board file if at all
possible.  I think this was somewhat shortsighted when I originally
wrote the current board file format.  I would rather the constraints be
written either to a separate file or into the configuration file so they
can easily be reused between projects.  I find that I reuse the same
constraints from project to project so being able to easily reuse them
without having to reenter them every new project or modify the board
file with a text editor would be rather handy.  This would also have a
nice side effect of the board file format not changing every time we
want to add a new constraint.

Wayne

On 04/14/2018 09:37 AM, Jon Evans wrote:
> I see what you are saying, but I also think that if there's any chance
> we will be able to define a spec/format for design rules this cycle, we
> can avoid the need for multiple (potentially incompatible) changes to
> the way rules are stored during the development cycle. 
> 
> On Sat, Apr 14, 2018, 09:25 Jeff Young <jeff@xxxxxxxxx
> <mailto:jeff@xxxxxxxxx>> wrote:
> 
>     Hi Jon,
> 
>     I agree we should have that conversation, but I also don’t want to
>     fall into the trap of doing nothing until you can do everything.
> 
>     We don’t store even the single set of differential pair dimensions
>     in the board right now.
> 
>     Cheers,
>     Jeff.
> 
> 
>>     On 14 Apr 2018, at 14:12, Jon Evans <jon@xxxxxxxxxxxxx
>>     <mailto:jon@xxxxxxxxxxxxx>> wrote:
>>
>>     I'm not exactly sure what you're planning, but I think before you
>>     go too far down this road we should have a conversation / plan for
>>     how we actually want DRC to work architecturally.
>>
>>     There are definitely lots of reasons to have multiple diff pair
>>     rules per board, and also have those rules only apply to certain
>>     areas of the board.
>>
>>     There might not be a specific feature request for this because it
>>     is part of a request for a net class system and rule by area system. 
>>
>>     The ideal DRC system, in my mind at least, has a split between the
>>     "what objects does this rule apply to" part and the "what is this
>>     rule and what are its limits" part. That makes it very flexible
>>     and easy to expand.
>>
>>     It would be nice to be able to build a rule kind of like a
>>     database query like:
>>
>>     "If something is part of a diff pair AND "is part of net class
>>     'USB'" AND is within the polygon 'FlexArea'"
>>
>>     Then once you have a selector that applies to the objects you
>>     want, you can apply whatever rule is relevant (trace widths,
>>     spacing, what vias are allowed, how close copper pours can come,
>>     and 100 other things if you like) 
>>
>>     (the above selector happens to rely on two features that KiCad
>>     doesn't have yet, but could have for V6: net classes and named areas) 
>>
>>     These selectors would be cascading, like CSS, so you could define
>>     a base set of rules that apply to everything, and more specific
>>     rules that override things defined in the general rules. 
>>
>>     Not a super trivial bit of code to write, but an important one in
>>     my mind since it's the only way to offer the flexibility of rules
>>     that people who are used to tools like Altium/Cadence/Mentor are
>>     used to. 
>>
>>     -Jon 
>>
>>
>>     On Sat, Apr 14, 2018, 08:57 Jeff Young <jeff@xxxxxxxxx
>>     <mailto:jeff@xxxxxxxxx>> wrote:
>>
>>         I was looking into moving the solder mask and paste
>>         dimensions, courtyard rules, and differential pairs dimensions
>>         to the board for 6.0.  It seemed like having multiple sets of
>>         differential pair dimensions (like we do for tracks and vias)
>>         would be good, yet there are no feature requests for this. 
>>         Are differential pairs specific enough that there is usually
>>         only one spec per board?
>>
>>         Thanks,
>>         Jeff.
>>         _______________________________________________
>>         Mailing list: https://launchpad.net/~kicad-developers
>>         Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>         <mailto: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
>