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