X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Wed, 9 Sep 2015 12:51:28 +0200 (CEST)
From: Roland Lutz <rlutz AT hedmen DOT org>
To: geda-user AT delorie DOT com
Subject: Re: [geda-user] New experimental netlist features
In-Reply-To: <201509082040.t88KerD6005455@envy.delorie.com>
Message-ID: <alpine.DEB.2.00.1509091224440.3949@lichen>
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>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
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

On Tue, 8 Sep 2015, DJ Delorie wrote:
>> The main reason I didn't implement bus rippers is that I couldn't come up
>> with a convincing way they should work that offers a significant advantage
>> to the current state.  How exactly do you think bus rippers should work?
>
> I thought on this for a while in the past, and I think busses should
> remain "fluff" on the page, with nets being the workhorse - assuming
> nets can be more than a single signal (like netname=D[0..15]).  In
> that case, "bus ripping" is something only the netlister needs to
> worry about.

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.

> Why?  Because pulling a subset of signals out of a bus is much more
> complicated than just making a connection.  Using a bus graphic allows
> you to add a net segment that *seems* connected to the bus but has a
> completely independent signal group in it.

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.

>>>> - Subschematics can now have I/O busses.  I/O bus pins work
>>>> analogously to normal bus pins but have a "pinlabel=" attribute
>>>> instead of a "pinnumber=" attribute.  Inside the subschematic, you
>>>> can either use a matching I/O port symbol with a bus pin or
>>>> individual net port symbols.  Bus I/O ports currently only support
>>>> the new "portname=" syntax.
>
> No reason to not support a list/range in pinnumber= (or pinlabel=)
> though.
>
> 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.

What's connected to the subschematic symbol's pin is up to you.  If a bus 
with "netname=D[0..3]" is connected to a bus pin with "pinlabel=5,6,8,9", 
and a bus port symbol with "portname=5,6" in the subschematic is connected 
to a bus with "netname=a,b", then the net "subsheet/a" is connected to 
"D0", and "subsheet/b" is connected to "D1".

Roland