X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
Date: Wed, 9 Sep 2015 13:37:01 -0400
Message-Id: <201509091737.t89Hb1nQ021026@envy.delorie.com>
From: DJ Delorie <dj AT delorie DOT com>
To: geda-user AT delorie DOT com
In-reply-to: <alpine.DEB.2.00.1509091224440.3949@lichen> (message from Roland
	Lutz on Wed, 9 Sep 2015 12:51:28 +0200 (CEST))
Subject: Re: [geda-user] New experimental netlist features
References: <alpine DOT DEB DOT 2 DOT 11 DOT 1509031356150 DOT 13201 AT nimbus> <msi77b$6rr$1 AT ger DOT gmane DOT org> <alpine DOT DEB DOT 2 DOT 00 DOT 1509082036590 DOT 3066 AT lichen> <201509082040 DOT t88KerD6005455 AT envy DOT delorie DOT com> <alpine DOT DEB DOT 2 DOT 00 DOT 1509091224440 DOT 3949 AT lichen>
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


> In my implementation, busses are exactly that: net-like objects with more 
> than one signal.  "netname=D[0..15]" is a valid attribute for a bus and is 
> equivalent to setting "netname=D0" to "netname=D15" on the individual 
> nets.

If we allow a net to be more than one signal (which verilog allows, so
precedent ;) then buses *are* nets, and we don't need anything new,
other than to teach the netlisters how to deal with a non-singular
net connecting to a non-singular pin.

> This is still how nets are connected to busses (remember, I didn't change 
> the way bus rippers work).  For example, in the subsheet "resistors.sch" 
> of my example schematic, I assigned the netname "left[7..0]" to a bus and 
> then assigned the netnames "left7" to "left0" to a bunch of nets.  For 
> clarity, I didn't use bus rippers, but I obviously could have done.

In this example, with current software, there's no need to assign
names to bus symbols - the fact that the nets are named is sufficient
to cause connectivity.  What benefit, then, of naming the bus symbols?

> > pinnumber=5,6,8,9
> >
> > the netlister could match that up with netname=D[0..3]
> 
> I'm not sure if I understand you correctly.  The usual list/range notation 
> is obviously supported for bus I/O ports, too.  The "pinnumber" attribute 
> of a pin on a subschematic symbol is, as usual, ignored.  The "pinlabel" 
> attribute has to match the "portname" of the port symbol--that's how the 
> netlister knows which nets should be connected.

With the *current* software, we match the netname of a net to the
pinnumber of a pin.  I.e. netname=D7 to pinnumber=5.  The netlister
does this pretty much as a "last step", so the pcbfwd exporter gets
data like 'net "D[7:0]" connects to device "U7" on pinnumber
"4-8,10-12"'.  It can expand that in an exporter-specific way.

If the pcbfwd exporter had a patch to do this matching, we'd have bus
pins for pcb *now*.

This concept can be applied to nets consistently, without changing how
the bus symbols work, or adding new symbols to gschem.