kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

Jon,

Sorry for the late response but this proposal looks fine to me.  Of
course the devil will be in the details.  One thing I want to try after
v5 is released is to use launchpad blueprints to track road map items.
Blueprints can be linked to a release version so they can be tracked and
marked as complete like bug reports.  One nice feature of blueprints is
that you can just provide a link to an external document rather than use
launchpads limited editing capabilities.  I think in the long run it
will be a better solution than trying to keep the road map documents up
to date.

Cheers,

Wayne

On 4/14/2018 11:53 AM, Jon Evans wrote:
> I started typing up some of my thoughts on this into a proposal:
> https://docs.google.com/document/d/1qvCH9aHwCzp5qtKTna4jJXuloNU0b96gAxAHSKPuXpU/edit?usp=sharing
> 
> (anyone with the link can comment on but not edit the document)
> 
> I haven't gotten very far but I thought I would throw it out here for
> early review/feedback.
> I think if we can agree on some of the basics, we can work towards it
> incrementally.
> I think it wouldn't be too hard to come up with a spec for rule storage
> that could both capture the current possible rules in KiCad 5, and also
> the new things we want to make available in 6.
> 
> -Jon
> 
> On Sat, Apr 14, 2018 at 11:04 AM, Wayne Stambaugh <stambaughw@xxxxxxxxx
> <mailto:stambaughw@xxxxxxxxx>> wrote:
> 
>     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>
>     >> <mailto: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>
>     >> <mailto: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>
>     >>     <mailto: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>>
>     >>     >>> <mailto: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>>
>     >>     >>>>    <mailto: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>>
>     >>     >>>>    <mailto: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>>
>     >>     >>>>        <mailto: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>
>     >>     <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>
>     >>     <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>
>     >>     <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>
>     >>
>     >
> 
>