Re: gEDA-user: wishful UI

[Andrew Poelstra <asp11@xxxxxx>]

On Sat, Aug 07, 2010 at 12:51:34AM +0200, Stefan Salewski wrote:
> 
> The current status of my mind:
> 
> Having net classes in gschem would make all much easier.
> We can start drawing schematics as now. Then we define a set (or load
> existing) of net classes, each class can define parameters like trace
> width, clearance, maximum length, maybe impedance...
>

Sounds good so far.
 
> First we select all nets and assign a default class.
> Then we select a other class and click on all nets which should be a
> member of this class (power3.3V, power5.0V, gnd, fast signals, slow
> signals, sensitive analog signals, traces with maximum total
> length, ...). 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.

> 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.

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.

> One more idea: Maybe we can have subnets in gschem, which connects two
> pins and ensures that the pins have a maximum distance to each other. So
> we can ensure that a bypass capacitor is close to its OpAmp on the PCB
> board. Auto-Placer may use that information.
>

This is good, and almost certainly necessary. Different subnets of the
Gnd net are going to have different properties on pretty much any board,
for example.

The hard part for PCB will be ensuring that the entire path between
any two components fulfill the required DRC rules. ie, no "shortcuts"
are taken through less demanding subnets.


Andrew
 


_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user