X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Mon, 21 Sep 2015 14:33:46 +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: <201509091737.t89Hb1nQ021026@envy.delorie.com>
Message-ID: <alpine.DEB.2.11.1509211409470.1633@newt>
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>
 <201509091737 DOT t89Hb1nQ021026 AT envy DOT delorie DOT com>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
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 Wed, 9 Sep 2015, DJ Delorie wrote:
>> 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.

It appears we have a different notion of a bus.  What you're suggesting is 
what I implemented, only that I'm expecting the "bus" bit of what you call 
a "non-singular" net or pin to be set to 1.

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

The point of the example schematic is to demonstrate the new features, so 
it obviously won't work with anything but the experimental netlister. 
That said, naming the nets wouldn't work in this case because they are in 
the subschematic's namespace.  Setting the portname= of the bus I/O symbol 
has the same effect as setting the refdes= of an I/O symbol in the stable 
netlister, i.e., connecting the net/bus to the corresponding pin on the 
subschematic symbol.

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

This would have to be implemented over and over for each backend which 
should support bus pins.  What I did was build that support into the 
netlister itself so any backend automatically supports it.

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

We have bus pins for PCB *now*.  Just use the experimental netlister.

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

So what you are criticize it the fact that I use buses and bus pins for 
"multiple nets" whereas you prefer to use non-bus nets and ordinary pins?