kicad-developers team mailing list archive

[Jeff Young <jeff@xxxxxxxxx>]

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 <stambaughw@xxxxxxxxx> 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 <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
>> 
> 
> _______________________________________________
> 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