converting std_logic_vector to an integer without sign extension

[Mark]

I'm trying to elegantly convert a std_logic_vector(upper downto lower)
to an integer without sign extension using ieee.numeric_std with upper
and lower taking on values from 31 to 0 and with upper >= lower. I
cannot seem to find a syntax that doesn't generate truncation
warnings, or relies on doing some comparison.

If I use:

i:= to_integer( signed( slv(upper downto lower)));

I'll get sign extension if upper==lower (which I don't want).

To avoid sign extension, I've tried:

i:= to_integer( signed( '0' & slv(upper downto lower)));

That works great until upper=31, and lower=0---leading to a to_signed
truncation warning (since in this case we're creating a 33-bit vector
and reducing it to a 32-bit integer).

I could just check if upper==lower, and break the conversion into two
cases, but I'm wondering if there's a cleaner, more elegant way of
handling this conversion without warnings.

 

[Kenn Heinrich]

I'm trying to elegantly convert a std_logic_vector(upper downto lower)
to an integer without sign extension using ieee.numeric_std with upper
and lower taking on values from 31 to 0 and with upper >= lower. I
cannot seem to find a syntax that doesn't generate truncation
warnings, or relies on doing some comparison.

If I use:

i:= to_integer( signed( slv(upper downto lower)));

I'll get sign extension if upper==lower (which I don't want).

To avoid sign extension, I've tried:

i:= to_integer( signed( '0' & slv(upper downto lower)));

That works great until upper=31, and lower=0---leading to a to_signed
truncation warning (since in this case we're creating a 33-bit vector
and reducing it to a 32-bit integer).

I could just check if upper==lower, and break the conversion into two
cases, but I'm wondering if there's a cleaner, more elegant way of
handling this conversion without warnings.

What's wrong with using unsigned instead of signed?

i:= to_integer( unsigned( slv(upper downto lower)));

- Kenn

 

[Martin Thompson]

I'm trying to elegantly convert a std_logic_vector(upper downto lower)
to an integer without sign extension using ieee.numeric_std with upper
and lower taking on values from 31 to 0 and with upper >= lower. I
cannot seem to find a syntax that doesn't generate truncation
warnings, or relies on doing some comparison.

If I use:

i:= to_integer( signed( slv(upper downto lower)));

I'll get sign extension if upper==lower (which I don't want).

To avoid sign extension, I've tried:

i:= to_integer( signed( '0' & slv(upper downto lower)));

I think you might be trying too hard

How about:
i:= to_integer( unsigned( slv(upper downto lower)));

The *unsigned* type is there for doing, erm, unsigned arithmetic and
conversions

That should work for upper==lower as well:

entity testint is
end entity testint;
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
architecture a1 of testint is
signal slv : std_logic_vector(1 downto 0) := "10";
signal one,zero : integer;
begin -- architecture a1
check: process is
begin -- process check
one <= to_integer(unsigned(slv(1 downto 1)));
zero <= to_integer(unsigned(slv(0 downto 0)));
wait for 0 ps;
assert one = 1 report "1==1 failure" severity error;
assert zero = 0 report "0==0 failure" severity error;
wait;
end process check;
end architecture a1;

Or did I misunderstand the problem?

Cheers,
Martin

 

[Kenn Heinrich]

What's wrong with using unsigned instead of signed?

i:= to_integer( unsigned( slv(upper downto lower)));

- Kenn

Actually, after a brief re-think, you're sort of hosed in any case.
VHDL only officially defines integers as

type integer is range -2147483648 to 2147483647;

which means you can't represent positive x"FFFFFFFF" = 2^32-1 in
integers to begin with. Implementations *may* support larger but it's
not guaranteed.

- Kenn

 

[Mark]

It doesn't matter to me if FFFF_FFFF is treated as -1 or MAX_INT, just
that all the bits are in there. I'd like to get something as C-like
as possible. Unfortunately, VHDL treats unsigned ints (naturals) as a
subtype of integer, and thus are only 31-bits---while C lets you have
32-bit unsigned integers (long)). No problem I thought, I'll just
treat everything as an integer. Unfortunately, doing so in a terse,
warning-free way doesn't seem possible in VHDL.

I'm coming to the conclusion that I'm not going to be able to do a 1-
liner in VHDL without living with warnings. I want my conversions to
be warning free (even if it still works out), so I'm thinking of going
with the following:

lower := c_field_offset;
upper := lower + c_field_size - 1;

if (2**c_field_size-1) > integer'high then
i := to_integer( signed( slv(upper downto lower)));
else
i := to_integer( unsigned( slv(upper downto lower)));
end if;

5-lines instead of 1---but then that's VHDL

 

[Mark]

What's wrong with...
  i := to_integer(unsigned(slv));

It will of course give you warnings if the MSB of a 32-bit SLV
is set, because VHDL integer cannot represent anything more
positive than (2**31)-1.  That's tedious, but a fact of life.
But it should work fine with any slv with between 1 and 31
bits, and it will also work with 32-bit SLVs provided their
MSB is zero.

If you want to use signed() so that 32-bit slv's with the MSB
set will come out as negative integers (yuck) then yes, you have
a small problem with 1-bit values.  How about packing to 32 bits
first, and then doing the conversion?

  i := to_integer(
         signed(
            std_logic_vector'(31 downto upper+1 => '0') & slv
         )
       );

This *may* give warnings for the null range when upper=31,
although it's legal VHDL (I'm pretty sure).

Finally, why not write a custom function instead of trying to
inline the ghastly mess?
  function to_uint(v: std_logic_vector) return integer is
  begin
    if v'length = 0 then
      return 0;
    elsif v'length = 1 then
      return to_integer(unsigned(v));
    else
      return to_integer(signed(v));
    end if;
  end;

The function also provides you with a convenient place
to report application-specific errors and so forth.
But most of all it allows you to hide the kruft.
--
Jonathan Bromley, Verification Engineer

Verilab  www.THAT_COMPANY.com
  end;

Gave

i := to_integer( signed( std_logic_vector'(31 downto upper+1 =>
'0') & slv(upper downto lower) ));

a try. Got:

** Warning: [3] test.vhd(25): (vcom-1246) Range 31 downto 32 is
null.

Thanks for the suggestion, though.

 

[Mark]

It doesn't matter to me if FFFF_FFFF is treated as -1 or MAX_INT, just
that all the bits are in there.  I'd like to get something as C-like
as possible.  Unfortunately, VHDL treats unsigned ints (naturals) as a
subtype of integer, and thus are only 31-bits---while C lets you have
32-bit unsigned integers (long)).  No problem I thought, I'll just
treat everything as an integer.  Unfortunately, doing so in a terse,
warning-free way doesn't seem possible in VHDL.

I'm coming to the conclusion that I'm not going to be able to do a 1-
liner in VHDL without living with warnings.  I want my conversions to
be warning free (even if it still works out), so I'm thinking of going
with the following:

  lower :=         c_field_offset;
  upper := lower + c_field_size - 1;

  if (2**c_field_size-1) > integer'high then
    i := to_integer(   signed( slv(upper downto lower)));
  else
    i := to_integer( unsigned( slv(upper downto lower)));
  end if;

5-lines instead of 1---but then that's VHDL

FYI, the (2**c_field_size - 1) doesn't work as 2**c_field_size itself
needs to be within the range of integers! I finally punted and just
made it : if c_field_size > 31 then ...

 

[Tricky]

What's wrong with...
  i := to_integer(unsigned(slv));

It will of course give you warnings if the MSB of a 32-bit SLV
is set, because VHDL integer cannot represent anything more
positive than (2**31)-1.  That's tedious, but a fact of life.
But it should work fine with any slv with between 1 and 31
bits, and it will also work with 32-bit SLVs provided their
MSB is zero.

If you want to use signed() so that 32-bit slv's with the MSB
set will come out as negative integers (yuck) then yes, you have
a small problem with 1-bit values.  How about packing to 32 bits
first, and then doing the conversion?

  i := to_integer(
         signed(
            std_logic_vector'(31 downto upper+1 => '0') & slv
         )
       );

This *may* give warnings for the null range when upper=31,
although it's legal VHDL (I'm pretty sure).

Finally, why not write a custom function instead of trying to
inline the ghastly mess?
  function to_uint(v: std_logic_vector) return integer is
  begin
    if v'length = 0 then
      return 0;
    elsif v'length = 1 then
      return to_integer(unsigned(v));
    else
      return to_integer(signed(v));
    end if;
  end;

The function also provides you with a convenient place
to report application-specific errors and so forth.
But most of all it allows you to hide the kruft.

Verilab  www.THAT_COMPANY.com
  end;

Gave

   i := to_integer( signed( std_logic_vector'(31 downto upper+1 =>
'0') & slv(upper downto lower) ));

a try.  Got:

   ** Warning: [3] test.vhd(25): (vcom-1246) Range 31 downto 32 is
null.

Thanks for the suggestion, though.

Why do you have to use the integer type? why cant you just stick with
signed/unsigned? Afaik, you can still do all the same arithmatic on
signed/unsigned, but you have no bit width problems.

 

[Jan Decaluwe]

On Wed, 25 Nov 2009 06:28:01 -0800 (PST), Mark wrote:
I'm trying to elegantly convert a std_logic_vector(upper downto lower)
to an integer without sign extension using ieee.numeric_std with upper
and lower taking on values from 31 to 0 and with upper >= lower. I
cannot seem to find a syntax that doesn't generate truncation
warnings, or relies on doing some comparison.
What's wrong with...
i := to_integer(unsigned(slv));
It will of course give you warnings if the MSB of a 32-bit SLV
is set, because VHDL integer cannot represent anything more
positive than (2**31)-1. That's tedious, but a fact of life.
But it should work fine with any slv with between 1 and 31
bits, and it will also work with 32-bit SLVs provided their
MSB is zero.
If you want to use signed() so that 32-bit slv's with the MSB
set will come out as negative integers (yuck) then yes, you have
a small problem with 1-bit values. How about packing to 32 bits
first, and then doing the conversion?
i := to_integer(
signed(
std_logic_vector'(31 downto upper+1 => '0') & slv
)
);
This *may* give warnings for the null range when upper=31,
although it's legal VHDL (I'm pretty sure).
Finally, why not write a custom function instead of trying to
inline the ghastly mess?
function to_uint(v: std_logic_vector) return integer is
begin
if v'length = 0 then
return 0;
elsif v'length = 1 then
return to_integer(unsigned(v));
else
return to_integer(signed(v));
end if;
end;
The function also provides you with a convenient place
to report application-specific errors and so forth.
But most of all it allows you to hide the kruft.

Gave

i := to_integer( signed( std_logic_vector'(31 downto upper+1 =>
'0') & slv(upper downto lower) ));

a try. Got:

** Warning: [3] test.vhd(25): (vcom-1246) Range 31 downto 32 is
null.

Thanks for the suggestion, though.

Why do you have to use the integer type? why cant you just stick with
signed/unsigned? Afaik, you can still do all the same arithmatic on
signed/unsigned, but you have no bit width problems.

That is not true: with signed/unsigned you are forced to
deal with bit widths and resizes explicitly, unlike integer.

Given all the pain that comes out of discussions such as this one,
I'd like to point out that with MyHDL, I think I have solved these issues.
In MyHDL, you can use a (constrained) integer with arbitrary sizes,
and the convertor to VHDL will deal with the low-level issues for you.

See:
http://www.myhdl.org/doku.php/why#you_think_vhdl_requires_too_many_conversion_functions

Background:
http://www.jandecaluwe.com/hdldesign/counting.html

Jan

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Python as a HDL: http://www.myhdl.org
VHDL development, the modern way: http://www.sigasi.com
Analog design automation: http://www.mephisto-da.com
World-class digital design: http://www.easics.com

 

[Gerhard Hoffmann]

Yes, I know it's a damned nuisance, but that's what the
language standard says.

Is there somewhere a standard or near-standard package
for things like u_int64 or s_int128?

Writing a testbed for a 64 bit CPU is a royal pain, and
even if these long ints were composed from the usual 31.9 bit ints,
this should simulate much faster than SLVs, where each and
every single bit has to be kissed individually.


regards, Gerhard

 

[Gerhard Hoffmann]

Do you think it would be sufficient to have signed
and unsigned versions of 16xN bits (1<=N<=lots)?
Obviously one would need to represent a bigint in
units of words, enforcing a granularity on the
available widths; representing it in bits would be
hopelessly inefficient, and using a record with
a bit-width as one of its members would also bring
significant memory and runtime penalty (I suspect).

16 bit chunks might still be dangerous for mul & div
because of that 0x8000_0000 value that even resists abs()
and that doesn't really exist in VHDL.

Also, I see no cheap way to extract and insert bit fields
from/to integers. ObHeresy: sometimes unions or
variant records are handy ;-)

Maybe some BCD-style arithmetic on 4 or 8 bit chunks
would be a good compromise. The basic operations could be
table driven but would not hurt the cache tooooo badly.

String I/O was easy and would avoid a lot of extra-long
mul/div/mod, most welcome in test bed codes.


Here it's time to test my own bed now.
Have a nice weekend,

Gerhard

 

[Andy]

Kcn9,

Do NOT use std_logic_arith, std_logic_unsigned or std_logic_signed packages.. They are NOT standard IEEE libraries, even though Synopsys said a long time ago they were. Use numeric_std instead, which defines types signed and unsigned, along with operators and conversions for them. In general, do not use "to" ranges for arrays of bits that have a numeric interpretation, unless it is an externally defined interface that already uses "to". It just leads to problems not unlike this one.

ISE is not the best at giving good error messages, or even checking for many errors. Your test_bits_array type is defined with a "to" range, but you indexed test_bits with a "downto" range, which is an error. Did you intend to reverse the order of arrat elements prior to the conversion?

Also, to_integer() takes either a numeric_std.signed or a numeric_std.unsigned argument. Both are arrays of sl, not arrays of slv_bits (e.g. array of array of sl).

While some synthesis tools let you get away with supplying an slv (or otherarray of sl) instead of a signed/unsigned, standard-compliant tools (othersynthesis tools and almost all simulators) correctly will not.

You could overload to_integer() to do the conversion of test_bits_array type arguments. Note that you have not indicated whether your type represents two's complement or straight binary formats (are negative values possible?).. Among other things, that is what signed/unsigned types implicitly do for you.

Or just define the data as an 18 bit signed/unsigned to begin with...

Note that to preserve signed/unsigned/slv compatibility of custom types, you should use subtype, not type: Subtype test_bits_array is unsigned(17 downto 0); or: subtype slv_bits is unsigned(1 downto 0);

Andy

 

[Rob Gaddi]

My similar problem is this.

LIBRARY ieee ;
USE ieee.math_real.ALL ;
USE ieee.std_logic_1164.ALL ;
USE ieee.std_logic_unsigned.ALL;
USE ieee.numeric_std.ALL ; -- use this above scope of **
USE ieee.std_logic_arith.ALL ; -- **
USE ieee.numeric_bit.ALL ;

VARIABLE nlut_idx : INTEGER ;

SUBTYPE slv_bit IS std_logic ; -- notice slv_bit is in the singular
TYPE slv_bits IS ARRAY ( 0 TO 1) OF slv_bit ; -- notice slv_bits is in the plural

TYPE test_bits_array IS ARRAY ( 0 TO 8) OF slv_bits ; -- 18 bits = 9 x 2-bits
VARIABLE test_bits : test_bits_array ;

nlut_idx := to_integer( ( test_bits( 8 DOWNTO 0))) ;

-- The above barfs in ISE 14.2 as:
--
-- ERROR:HDLCompiler:432 - ...
-- Line 16548: Formal <arg> has no actual or default value.
-- ERROR:HDLCompiler:541 - ...
-- Line 16548: Type integer is not an array type and cannot be indexed.

I'm not sure what you're trying to do, but I'd barf too. Are you
trying to test the ability of the compiler to handle things that you
believe to be syntactically correct but obscure, or are you just lost?

First of all, you've got massively conflicting packages in there.
You've brought in every conceivable math library, and over-overloaded
several types. Just use:

LIBRARY ieee ;
USE ieee.math_real.ALL ;
USE ieee.std_logic_1164.ALL ;
USE ieee.numeric_std.ALL ;

Past that, there's no reason to provide your own redefinition of number
types; that's why you're bringing those packages in in the first place.

-- Always use downto for signed/unsigned.
subtype short_num is unsigned(1 downto 0);

You misunderstand what you're doing in creating your test_bits_array.
You haven't created an 18 bit array there; you've created a 9-length
array of 2-bit structures. They don't concatenate; the two axes are
orthogonal.

That help a bit?

 

[Jim Lewis]

Gerhard,
No 64 or 128 bit integers currently in the language,
but it is something that has been talked about. One
person is looking into a package based approach.

All are welcome to participate. See:
http://www.eda.org/twiki/bin/view.cgi/P1076/WebHome

One thing for sure is that the work that gets done is
the work people are passionate about. If no one is
real passionate about this issue, it reduces its
likelihood of getting done.

WRT representing -2**31, my suspicion is that if your
computer supports it, then so does your simulator.
The language was ambiguous like that so that it could
run on a ones complement machine without performance
issues when doing integer based math. Are there any
one's complement computers out there? Maybe the language
can be safely updated.

Best Regards,
Jim Lewis