Mail Archives: geda-user/2015/09/21/08:33:39
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?
- Raw text -