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 <stambau...@gmail.com> 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 <j...@rokeby.ie >> <mailto:j...@rokeby.ie>> 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 <j...@craftyjon.com >>> <mailto:j...@craftyjon.com>> 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 <j...@rokeby.ie >>> <mailto:j...@rokeby.ie>> 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@lists.launchpad.net >>> <mailto:kicad-developers@lists.launchpad.net> >>> Unsubscribe : https://launchpad.net/~kicad-developers >>> More help : https://help.launchpad.net/ListHelp >>> >> >> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : kicad-developers@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp >> > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
