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