X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
Date: Tue, 8 Sep 2015 16:40:53 -0400
Message-Id: <201509082040.t88KerD6005455@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.1509082036590.3066@lichen> (message from Roland
	Lutz on Tue, 8 Sep 2015 22:21:15 +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>
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


> >> Pin ranges can be denoted by either ".." or ":"; when using the latter 
> >> notation, the last pin isn't included in the list.
> >
> > what is the benefit of the ":"-format?
> 
> I'm not a fan of notations where the first and last included element are 
> mentioned; but I realize some users might want to use such a format, so I 
> allowed typing "0..7" instead of "0:8".

Aren't there standards for this already?  I'm thinking of verilog...

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

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.

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