It makes sense to me to have importing and exporting constraints as part
of the design.  I would also add copying a default constraints file as
part of the new project and new project by template commands.  I think
that pretty much covers all of the bases.

On 04/14/2018 10:23 AM, Jeff Young wrote:
> Good point.  A lot of the constraints are defined by the fab house rather 
> than the particular board design.
> FrameMaker had a “Use Formats From” feature which imported page layouts, 
> paragraph formats, variable definitions, etc. from another document.  Our 
> customers liked that a lot better than having to manage yet another file.
>> On 14 Apr 2018, at 15:14, Wayne Stambaugh <> wrote:
>> 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 <
>>> <>> 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 <
>>>>    <>> 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 <
>>>>    <>> 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:
>>>>        Post to     :
>>>>        <>
>>>>        Unsubscribe :
>>>>        More help   :
>>> _______________________________________________
>>> Mailing list:
>>> Post to     :
>>> Unsubscribe :
>>> More help   :
>> _______________________________________________
>> Mailing list:
>> Post to     :
>> Unsubscribe :
>> More help   :

Mailing list:
Post to     :
Unsubscribe :
More help   :

Reply via email to