kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 04/14/2018 10:46 AM, Jeff Young wrote:
> 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.

I see netclasses as just another constraint.  I use the same netclasses
over and over again in my projects so having a way to make them easily
shareable between projects would be useful to me.  I'm not sure a
separate method to handle netclasses versus all other constraints makes
sense.  I do agree that it should be possible to defined them in the
schematic editor.  I would think a properly designed constraint editor
would work equally well in both the schematic and board editors as well
as stand alone.  Given what I have learned about the board file design,
saving the netclasses and other constraints in the schematic file
doesn't make sense.  This will need to be defined before I can begin
writing the new schematic file format.

> 
> 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.

I would consider inter-app communication a given regardless of where we
store this information.  What form the inter-app communication takes is
certainly open for discussion.  It could be using our kiway messaging or
it could be a file watcher that updates the constraints when the
constraint file is edited.

> 
> 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
>> <mailto: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
>>     >>>>        Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>     >>>>        <mailto: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
>>     <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
>>     <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
>>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>     Unsubscribe : https://launchpad.net/~kicad-developers
>>     More help   : https://help.launchpad.net/ListHelp
>>
>