On Sat, Aug 07, 2010 at 09:55:32AM -0500, John Griessen wrote: > Andrew Poelstra wrote: > >On Sat, Aug 07, 2010 at 12:51:34AM +0200, Stefan Salewski wrote: > The classes of nets can be marked by colors, we go on > >>until all nets have the correct class. > >> > > > >Do we want each net to have one class? Or would it be useful for nets > >to be "tagged" with multiple classes? Probably not, but it's something > >to think about. > > I can think of reasons to have a trace routed one way in a zone, and change > design rules to satisfy some constraint like pin distance apart at a chip. > The way to handle that concept is allow part of a trace to be in one set, > and another part to be in another and use the less restrictive DRC on the > place where the two kinds touch. See below for implementation ideas. >
I think that we should store actual information in terms of attributes, as John Goty suggested. Classes would just be a way of organizing groups of attributes. So there's no good reason not to allow multiple classes. > > > >Right now the trace color shows the physical layer of the trace, which > >helps you determine where everything is, and to prevent shorts. I'm sure > >you'll agree preventing shorts is the most important DRC rule of all :). > >I don't think we want to override trace color for anything. > > [jg] You're thinking of the many use cases PCB handles very well for > someone new at the program Andrew. You're not new to pcb design. > Thanks :) but I'm actually fairly new to both. But I work in embedded devices and have a lot of PCB designers to talk to. > >What I would suggest is adding a panel to the sidebar that displays > >information about each trace when you select it - what its net is, what > >layer it's on, what rules it has, what rules it's breaking. > > I like your planning and use of tags. If any PCB object is taggable, > it opens up future searches (and replacements) of wires or copper planes > or pads or pins. How are you thinking DRCs for different functional sets > of objects will work relative to other sets? I imagine treating everything > not in the set you are running DRC on as the same is feasible, if you draw > objects and check design rules in order. The order to run DRCs will need > to be widest clearance DRCs first to avoid getting > functional sets of circuitry too close to each other. Also the only DRC > that will work on the set of all objects is the least restrictive -- the > one requiring the smallest clearances. > Well, the DRC would check all the board's rules - it would just only show you the ones relevant to the current functional set. Optimally, I'd like the DRC to be running in real time, perhaps drawing a small "!" icon or something to indicate mistakes. So the "design rule checker" would be more like "view design rule errors". > A way to handle schematic driven work styles like Stefan seems to want is > to make a PCB plugin to color traces differently, or just temporarily, > as an aid to using the correct DRC rules as you draw, or autoroute. > Rather than using a plugin system, I think we should allow the user to configure the coloring, assigning drawing parameters like "color", "brightness" and "opacity" to any net attributes he wishes. Presets would be stored in $HOME/.pcb . Andrew _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
