[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: gEDA-user: wishful UI
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.
If we can transfer this class information into PCB and assign it to the
pins of the nets, then we do not have to care much about routing style
in PCB program. Click on a pin, and traces with correct routing style
will start drawing. Seems to be easy and fast.
Well, I don't think we can make things that simple. You mentioned
ensuring decoupling caps are close enough to their components. But
some components have Vcc and Gnd awkwardly placed, so to connect the
cap would require dropping to another layer to avoid getting in the
way of other pins.
The problem is that there's no way PCB can know this - the autorouter
can know it, because it's routing everything, but your "click on a pin
and it automatically draws" idea doesn't seem feasible.
What /does/ seem feasible, though, is having PCB select the routing
style automatically based on what net you're draw. That would be
awesome. But then we run into the problem of, what happens when you're
connecting components that are far away? How will PCB know what net
you're trying to draw as you work your way around other components, onto
other layers, etc.
And the autorouter can
use all this information. (Of course we may overwrite parameters of
traces in PCB program when it is necessary.) With these net classes the
concept of virtual layers or layer groups in PCB may be obsolete.
I'm not sure about this, either. Layer groups as we currently have them
provide color-coding to make drawing easier. Layer groups as I proposed
separate the board into different workspaces to keep things organized.
Net classes serve a different purpose, IMHO.
Traces
of each net class are drawn in a unique color. If we decide that copper
layer 3 is for power supply, we select that real copper layer and start
drawing traces. Nets for different voltages will get different colors
and parameters, if we have defined special net classes for each voltage
in gschem.
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.
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.
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.
Perhaps the DRC rules of different sets need to be "always available" as
an object tag, so routing being done can use that info to keep
away the right distance. If objects were tagged with
functional-set-design-rules the order of running DRCs
or drawing circuitry would not matter, and fewer
cases of painting oneself or one's autorouter into
a corner would happen.
John Griessen
--
Ecosensory Austin TX
_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user