gEDA-dev: net and buses netnames

[Peter Clifton]

On Sun, 2007-04-08 at 16:28 +0200, Carlos Nieves Ónega wrote:
> Hi,
> I think I've found a bug, unless anyone can give me a good reason for
> this:
>   - draw a bus or a net with an U shape.
>   - double click on the first segment and set the netname to
> "named_net1" in the multiple attribs window.
>   - double click on any other segment:
>     the previous assigned netname is not shown.
> 
> It seems that attributes are attached to net segments, instead of to the
> net itself...
> 
> I can even set another different netname and both attributes are shown
> (I know there is no current mechanism to check attributes), but I think
> that at least the already assigned netname should be shown when you edit
> the attributes of any other segment.
>    
> Regards,
> 
> Carlos
> 
> P.D.: Peter, have you considered this case in your datastructures
> diagram?

Currently, no netlist exists, so it isn't simple to determine what
net-segments to search for pre-existing attributes. My plan for
on-the-fly netlisting (at least of one page, or "circuit" at the
particular hierarchy level would help checking like this).

The netname could / should be attached to the net, however I was
thinking of a slightly different approach.

I've had some ideas about making netnames like an imaginary "star"
point, which are connected to by notional (fictional) net-segments.
These (fictional) net segments are actually invoked by attaching an
appropriate netname. There will be as many "star" points as there are
unique net-names.

This way of considering netnames, means that if I want to do a
graph-traversal to update connectivity, I can consider the "net-name" a
node on the graph. It will be seen as "connected to" a net, in the same
way its neighbours are now.

Oh - and I've also of the view that it should be possible to have
multiple net-names per "net".

For example, If I have an AGND and a DGND throughout my circuit, I could
potentially join these with a shorting link with two pins and a net
between them. In a hierarchical netlist, they remain separate. Only when
flattened do the netlists get merged, and the merged net should (in
principle at least) retain both names.

(If required, the final netlist output back-end could construct a unique
name for this net - perhaps by string concatenation.)

Peter C