From: glen herrmannsfeldt on
rickman <gnuarm(a)gmail.com> wrote:
(snip, then I wrote)

>> Which seems simpler and more natural: ?

>> ? ? ? ? ? [8*n,8*n+7] ? ?or ? ?[31-8*n,24-8*n]

>> I do know that it took me longer to write the second one and
>> to verify that it did what I wanted it to do. ?

>> Or are you asking about the preference of big-endian for
>> processor design?
>
> I don't know what the above equations are for. I have never used
> either forms for anything that I can recall.

That is the verilog from. Most of the time I can read VHDL and
get the right idea, but I have never written it. (I did some
VHDL to verilog conversions that worked, never the other way.)

> I address bits in words all the time in VHDL. I often use notation
> like (foo'high-bar'high downto 0) which gives the lsbs of foo where
> bar is a shorter length than foo. Or conversely (foo'high downto
> bar'high) for the msbs in foo that are wider than bar. I have never
> used any notation like you have shown.

OK,

(8*n upto 8*n+7) or (31-8*n downto 24-8*n)

I believe in some cases verilog can do that with a variable n,
otherwise it can defintely do it with a constant n. Also, note
that the one on the right depends on knowing the width of the
word, while the one on the left does not.

-- glen
From: rickman on
On Oct 17, 3:11 pm, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote:
> rickman <gnu...(a)gmail.com> wrote:
>
> (snip, then I wrote)
>
> >> Which seems simpler and more natural: ?
> >> ? ? ? ? ? [8*n,8*n+7] ? ?or ? ?[31-8*n,24-8*n]
> >> I do know that it took me longer to write the second one and
> >> to verify that it did what I wanted it to do. ?
> >> Or are you asking about the preference of big-endian for
> >> processor design?
>
> > I don't know what the above equations are for.  I have never used
> > either forms for anything that I can recall.
>
> That is the verilog from.  Most of the time I can read VHDL and
> get the right idea, but I have never written it.  (I did some
> VHDL to verilog conversions that worked, never the other way.)

The verilog form for what? I have never used a calculation like
that. What is n? Why are you performing this calculation? What is
the context.


> > I address bits in words all the time in VHDL.  I often use notation
> > like (foo'high-bar'high downto 0) which gives the lsbs of foo where
> > bar is a shorter length than foo.  Or conversely (foo'high downto
> > bar'high) for the msbs in foo that are wider than bar.  I have never
> > used any notation like you have shown.
>
> OK,
>
>         (8*n upto 8*n+7)   or  (31-8*n downto 24-8*n)
>
> I believe in some cases verilog can do that with a variable n,
> otherwise it can defintely do it with a constant n.  Also, note
> that the one on the right depends on knowing the width of the
> word, while the one on the left does not.

Like I said above, I have no idea why you are using a complicated
calculation to specify the bit of a word. It is extremely seldom that
I need to select a bit range based on a byte address the way you have
shown. In fact, I can't remember ever doing that.

Ignoring that, I don't see this one calculation as being a driving
reason to choose a numbering scheme for a bus. It seems to me to be
infinitely more useful to have the index correspond to the weight of
each bit to facilitate the calculation of the values in this signal.

Rick
From: glen herrmannsfeldt on
rickman <gnuarm(a)gmail.com> wrote:
(snip, then I wrote)

>> That is the verilog from. ?Most of the time I can read VHDL and
>> get the right idea, but I have never written it. ?(I did some
>> VHDL to verilog conversions that worked, never the other way.)

> The verilog form for what? I have never used a calculation like
> that. What is n? Why are you performing this calculation? What is
> the context.

(snip)

>> ? ? ? ? (8*n upto 8*n+7) ? or ?(31-8*n downto 24-8*n)

>> I believe in some cases verilog can do that with a variable n,
>> otherwise it can defintely do it with a constant n. ?Also, note
>> that the one on the right depends on knowing the width of the
>> word, while the one on the left does not.

> Like I said above, I have no idea why you are using a complicated
> calculation to specify the bit of a word. It is extremely seldom that
> I need to select a bit range based on a byte address the way you have
> shown. In fact, I can't remember ever doing that.

Select a byte from a word. I haven't looked at the internals
of microblaze at all, but it isn't unusual to address bytes in
a 32 bit word.

assign n=x[0:1];
assign byte=word[8*n,8*n+7];

> Ignoring that, I don't see this one calculation as being a driving
> reason to choose a numbering scheme for a bus. It seems to me to be
> infinitely more useful to have the index correspond to the weight of
> each bit to facilitate the calculation of the values in this signal.

I would expect selecting bytes from words to happen much more
often in processor hardware than calculating the value of bits.

Sometimes software has to compute the value of bits, but even
that is pretty rare.

As I said before, you might make the arguement for little-endian
over big-endian, but when designing a big-endian processor, a
decision that someone else might have made for you, you do it
in the most appropriate way.

-- glen
From: rickman on
On Oct 17, 7:01 pm, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote:
> rickman <gnu...(a)gmail.com> wrote:
>
>  (snip, then I wrote)
>
> >> That is the verilog from. ?Most of the time I can read VHDL and
> >> get the right idea, but I have never written it. ?(I did some
> >> VHDL to verilog conversions that worked, never the other way.)
> > The verilog form for what?  I have never used a calculation like
> > that.  What is n?  Why are you performing this calculation?  What is
> > the context.
>
> (snip)
>
> >> ? ? ? ? (8*n upto 8*n+7) ? or ?(31-8*n downto 24-8*n)
> >> I believe in some cases verilog can do that with a variable n,
> >> otherwise it can defintely do it with a constant n. ?Also, note
> >> that the one on the right depends on knowing the width of the
> >> word, while the one on the left does not.
> > Like I said above, I have no idea why you are using a complicated
> > calculation to specify the bit of a word.  It is extremely seldom that
> > I need to select a bit range based on a byte address the way you have
> > shown.  In fact, I can't remember ever doing that.
>
> Select a byte from a word.  I haven't looked at the internals
> of microblaze at all, but it isn't unusual to address bytes in
> a 32 bit word.
>
>    assign n=x[0:1];
>    assign byte=word[8*n,8*n+7];
>
> > Ignoring that, I don't see this one calculation as being a driving
> > reason to choose a numbering scheme for a bus.  It seems to me to be
> > infinitely more useful to have the index correspond to the weight of
> > each bit to facilitate the calculation of the values in this signal.
>
> I would expect selecting bytes from words to happen much more
> often in processor hardware than calculating the value of bits.
>
> Sometimes software has to compute the value of bits, but even
> that is pretty rare.  
>
> As I said before, you might make the arguement for little-endian
> over big-endian, but when designing a big-endian processor, a
> decision that someone else might have made for you, you do it
> in the most appropriate way.

I don't care about the endianness. I just have never needed to use
that one calculation before. I would code a mux the way I code a mux
for arbitrary inputs.

with x select
byte <= word(31 downto 24) when “00”,
word(23 downto 16) when “01”,
word(15 downto 8) when “10”,
word( 7 downto 0) when “11”;

It may be more verbose, but I think it is more clear than any
calculation, especially since it is the same form as used elsewhere.
I recognize instantly that this is a 4 input mux. But then I code a
hardware description so that I have some idea of what hardware will be
produced. I know a lot of people like to treat HDLs like software
where they depend on the tools to optimize the design.

The calculations I showed had to do with assigning values between
buses of different sizes which is about the only place I can think to
use calculations for array indexes. But then I'm sure there are
others I just am not thinking of.

Like I said, short of some special reason, I would always use N downto
0 notation because it indicates the bit weights. What is the value of
bit 4 and 7 set? In this notation I know it is 144 without even
knowing the width of the word.

Rick
From: Gabor on
On Oct 16, 6:59 pm, rickman <gnu...(a)gmail.com> wrote:
> On Oct 15, 1:10 pm, Andy Peters <goo...(a)latke.net> wrote:
>
>
>
> > On Oct 15, 8:14 am, rickman <gnu...(a)gmail.com> wrote:
>
> > > On Oct 15, 12:51 am, GrIsH <grishkun...(a)gmail.com> wrote:
>
> > > > On Oct 14, 11:35 am, rickman <gnu...(a)gmail.com> wrote:
>
> > > > > I have never worked with SLV in the 0 to N direction.  To be honest, I
> > > > > don't remember the details of how assignments are made between buses
> > > > > using different directions of indexes.  I wouldn't expect any
> > > > > surprises, but then I have no experience with them.  Is there a reason
> > > > > that you are using 0 to N numbering instead of N downto 0 on your SLV
> > > > > arrays?  This may not be a problem, but if you are stuck, why use this
> > > > > uncommon convention?
>
> > > >     for IP2Bus_Data we are not allowed to make this convention of N
> > > > downto 0 that's why i didn't use this convention.
>
> > > Ok, it shouldn't matter really, as long as you use it correctly.  Can
> > > you explain what this bus is and why it is 0 to 31?  Is this a port on
> > > the uBlaze?  Where exactly does this restriction come from.  Why do
> > > you assign your counter result to bits 16 to 31?
>
> > MicroBlaze is big endian. Bits 16 to 31 are the two least significant
> > bytes in a 32-bit word (bit 31 is the right-most bit).
>
> > -a
>
> I wonder why they do that.  I have only seen bit zero as the most
> significant bit in a handful of designs and I expect the first was
> done for fairly obscure reasons and the rest were done to be
> compatible.  Did the uBlaze need to be compatible with something in
> this regard?
>
> Rick

The historical reason is that IBM's Power PC is big endian, so
all of the V2 pro tools were big endian, and microBlaze came
later. Sticking with big endian at that stage in the game
was better than re-writing a bunch of supporting software.

Regards,
Gabor