numeric_std omissions

B

Ben Jones

Guest
Hi all,

Anyone know why ieee.numeric_std doesn't contain definitions for the
operators "sra" and "sla" for types signed and unsigned? In particular the
former omission is a PITA because it is actually very useful.

I notice that it's possible to call the underlying function directly, i.e.:

variable a, b : signed;
variable c : natural;

a := shift_right(b, c);

....but it still annoys me. Or is it just my implementation (Modelsim in this
case)? And will it be fixed in the next revision?

Cheers,

-Ben-
 
Ben Jones wrote:

Anyone know why ieee.numeric_std doesn't contain definitions for the
operators "sra" and "sla" for types signed and unsigned?
It would be redundant.
numeric_std has SLL and shift_left functions
that do the "right thing" for signed or unsigned vectors.
A shift on a signed type is the equivalent to an SLA on a std_logic_vector.

Use numeric_std.RESIZE for extension.

-- Mike Treseler
 
Ben,
It is fixed in Accellera VHDL-2006 standard 3.0 which
was approved at DAC-2006 and is available for vendor
adoption. So ask your vendor to implement it.

To understand why they weren't there, you have to look at
the definitions of "sra" and "sla". "sla" is defined in
terms of a basic shift operation which is as follows:
"a basic shift operation replaces L with a value that
is the result of a concatenation whose left argument
is the rightmost (L'LENGTH - 1) elements of L
and whose right argument is L(L'RIGHT)."

"sra" for negative shift values returns L sla -R.
This is ok only when the MSB is on the right. For
numeric_std, the MSB/sign bit is on the left.

In the new standard, "sra" and "sla" are implemented
mathematically correct for the MSB/sign bit being on
the left.

Cheers,
Jim
SynthWorks VHDL Training http://www.synthworks.com

P.S.
Why do I repetitively say, "So ask your vendor to implement
it." For a vendor, supporting a standard is a business
decision. By being vocal about your requests, you can
potentially elevate the priority of features.



Hi all,

Anyone know why ieee.numeric_std doesn't contain definitions for the
operators "sra" and "sla" for types signed and unsigned? In particular the
former omission is a PITA because it is actually very useful.

I notice that it's possible to call the underlying function directly, i.e.:

variable a, b : signed;
variable c : natural;

a := shift_right(b, c);

...but it still annoys me. Or is it just my implementation (Modelsim in this
case)? And will it be fixed in the next revision?

Cheers,

-Ben-
 
Hi Jim,

"Jim Lewis" <jim@synthworks.com> wrote in message
news:12ndsqgpfoiuf6e@corp.supernews.com...
Ben,
It is fixed in Accellera VHDL-2006 standard 3.0 which
was approved at DAC-2006 and is available for vendor
adoption. So ask your vendor to implement it.
Touché. :)

To understand why they weren't there, you have to look at
the definitions of "sra" and "sla". "sla" is defined in
terms of a basic shift operation which is as follows:
"a basic shift operation replaces L with a value that
is the result of a concatenation whose left argument
is the rightmost (L'LENGTH - 1) elements of L
and whose right argument is L(L'RIGHT)."
"sra" for negative shift values returns L sla -R.
This is ok only when the MSB is on the right. For
numeric_std, the MSB/sign bit is on the left.
Duh, I see. Has anyone ever, ever put the MSB on the right? Regardless of
whether the vector is ascending or descending, or what index it starts and
ends at, I have never seen anything but MSB-on-the-left.

Still not sure why this can't be fixed by overloading both sla and sra for
signed and unsigned. I might try it myself as an exercise and then when I
get stuck you can say "I told you so" :)

In the new standard, "sra" and "sla" are implemented
mathematically correct for the MSB/sign bit being on
the left.
Excellent, super, fantastic, great news. In that at the very least it means
I'm not going crazy.

Thanks a lot for your help!

-Ben-
 

Welcome to EDABoard.com

Sponsor

Back
Top