kicad-developers team mailing list archive

[Jeff Young <jeff@xxxxxxxxx>]

I still don’t think I’d put netclass dimensions in the schematic.  However, I do completely agree with putting the netclass *set* (and net membership) in the schematic.

For that kind of stuff we could start leaning more heavily on the project file, or we could use inter-app communication as we do for the netlist.

From first blush I’d prefer the later (as it makes stand-alone files more viable).  But, like I said, first blush….


> On 14 Apr 2018, at 15:37, Jon Evans <jon@xxxxxxxxxxxxx> wrote:
> 
> It's also a somewhat common workflow for design rules to be driven from the schematic (rather than created as part of board layout). Having a separate file for design rules isn't the only way to do that, but I just wanted to mention that use case so that it is also considered. In that workflow, you need a way to define design rules before there is even a PCB design started. 
> 
> On Sat, Apr 14, 2018, 10:29 Wayne Stambaugh <stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>> wrote:
> 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 <stambaughw@xxxxxxxxx <mailto: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>
> >>> <mailto: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>
> >>>>    <mailto: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>
> >>>>    <mailto: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 <https://launchpad.net/~kicad-developers>
> >>>>        Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
> >>>>        <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>
> >>>>        Unsubscribe : https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers>
> >>>>        More help   : https://help.launchpad.net/ListHelp <https://help.launchpad.net/ListHelp>
> >>>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Mailing list: https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers>
> >>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
> >>> Unsubscribe : https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers>
> >>> More help   : https://help.launchpad.net/ListHelp <https://help.launchpad.net/ListHelp>
> >>>
> >>
> >> _______________________________________________
> >> Mailing list: https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers>
> >> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
> >> Unsubscribe : https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers>
> >> More help   : https://help.launchpad.net/ListHelp <https://help.launchpad.net/ListHelp>
> > 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers>
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
> Unsubscribe : https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers>
> More help   : https://help.launchpad.net/ListHelp <https://help.launchpad.net/ListHelp>