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 <j...@craftyjon.com >> <mailto:j...@craftyjon.com>> 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 <stambau...@gmail.com >> <mailto:stambau...@gmail.com>> 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 <stambau...@gmail.com >> <mailto: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> >> >>> <mailto: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> >> >>>> <mailto: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> >> >>>> <mailto: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> >> >>>> <mailto: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 >> <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 >> <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 >> <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