Re: gEDA-user: Support for busses

["Bill Cox" <bill@viasic.com>]

Hi, Svenn.

----- Original Message ----- 
From: "Svenn Are Bjerkem" <svenn@bjerkem.de>
To: <geda-user@seul.org>
Sent: Sunday, November 09, 2003 3:21 PM
Subject: Re: gEDA-user: Support for busses


> On Saturday 08 November 2003 16:35, Bill Cox wrote:
> > I want to implement the bus tap rules you suggest. I went to go write
> > the code and realized I don't have quite enough information. In
> > particular, busses can be multiple signals concatentated. For example,
> > a legal bus name is "A1,A2,A3,A4", or "a[7:0],b[7:0]". If I simply put
> > an attribute name on a bus tap like [4], then I assume that means the
> > 5th signal in the bus. However, if the bus name is "a[63:32]", I would
> > like to be able to tap signals with names like "[35]", rather than
> > making them 0-based indexes.
>
> with [4], do you mean then that it is A4 above (in A1,A2,A3,A4) if it is
one
> based? I don't see how you want to make the user aware that a signal is 1
> based or 0 based.
>
> Remember there are logical and physical busses in many designs. Cadence do
> make a difference between logical and physical busses. I havent quite
grasped
> the difference in Cadence as I consequently use the <> bus declaration.
>
> What I do recognize is a need to make simplified representation of complex
> signal collections. An example may be on the very top level of a chip or a
> module used in a chip, you want to have a human-readable bus name, say,
> control[15:0] which go between the two blocks uRom and Accu and consist of
> regtl<7:0>,regls<3:2,0>,regrt<9,7,5,3,1> which are the actual lines. (the
> names are made up for example only)
>
> This way you don't need to change the top level bus if the local signal
names
> change due to reusability. (I could use a different uRom module for the
same
> Accumulator if the uRom happen to have other signal names) Care must be
taken
> on the left to right assignment on each of the end of the busses, but that
is
> also the reason why I use <> all the time in Cadence. (Also there are some
> netlisting errors if I use [])
>
>
> -- 
> Svenn

Logical vs. physical busses is an interesting notion that I'm not familiar
with.  For example, a PCI bus could be very complicated, but at the top
level, we could just call it PCI[145:0] (or whatever... I don't know the
correct length).  Individual signals would be assigned through the bus taps
at lower levels.  Is this right?

It sounds like the bus tap itself might need to hold some range data.  For
example a bus tap named [31:16] could be a sub-bus tap from a larger bus.
This would be useful for tapping out sub-busses from complex busses, such as
PCI bus.  If a bus tap had no range data on it, I could assume that the net
or sub-bus name had to match the logical name on the bus, and figure out the
connection that way.  If the bus tap had a range, but the sub-bus had no
name, I could inherit the logical name of the larger bus onto the smaller
one.

Does this sound right?

I think the rapid adoption of Verilog and VHDL curtailed the advancement of
schematic capture to this level for most systems.  Basically, by the time
busses were so complex that we didn't run feel like writing out the whole
bus contents everywhere, it was time to switch to an HDL anyway.  Once
concerne I have with this scheme is that I don't know how to keep the
physical names when I convert the schematics to a netlist, and then flatten
it.  I'd hate to see names like PCI[54] showing up instead of
PCI_WRITEENABLE, or some such thing.  I could add the concept of a logical
net name to the netlist database.  In that case, what should I do when
flattening?  For example, should I verify that all the physical net names in
sub-netlists attached to a logical signal are the same, and then use that
instead of the logical name?

I can easily do all of this, but I want to make sure I'm doing the right
thing first.

Bill