f



converting std_logic_vector to an integer without sign extension

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.



0
11/25/2009 2:28:01 PM
comp.lang.vhdl 6430 articles. 2 followers. Post Follow

18 Replies
5166 Views

Similar Articles

[PageSpeed] 21

Mark <marmarjohnson@gmail.com> writes:

> 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

-- 
---------------------------------

-1
Kenn
11/25/2009 3:28:13 PM
Mark <marmarjohnson@gmail.com> writes:

> 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

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html
-1
Martin
11/25/2009 3:30:08 PM
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.
-- 
Jonathan Bromley, Verification Engineer

Verilab   www.THAT_COMPANY.com
  end;
0
Jonathan
11/25/2009 3:30:08 PM
Kenn Heinrich <kwheinri@uwaterloo.ca> writes:

> Mark <marmarjohnson@gmail.com> writes:
>
>> 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

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



-- 
---------------------------------
Remove NOSPAM from email address.
0
Kenn
11/25/2009 3:33:30 PM
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
0
Mark
11/25/2009 4:36:49 PM
On Nov 25, 9:30=A0am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> 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 >=3D lower. =A0I
> >cannot seem to find a syntax that doesn't generate truncation
> >warnings, or relies on doing some comparison.
>
> What's wrong with...
> =A0 i :=3D 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. =A0That'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. =A0How about packing to 32 bits
> first, and then doing the conversion?
>
> =A0 i :=3D to_integer(
> =A0 =A0 =A0 =A0 =A0signed(
> =A0 =A0 =A0 =A0 =A0 =A0 std_logic_vector'(31 downto upper+1 =3D> '0') & s=
lv
> =A0 =A0 =A0 =A0 =A0)
> =A0 =A0 =A0 =A0);
>
> This *may* give warnings for the null range when upper=3D31,
> although it's legal VHDL (I'm pretty sure).
>
> Finally, why not write a custom function instead of trying to
> inline the ghastly mess?
> =A0 function to_uint(v: std_logic_vector) return integer is
> =A0 begin
> =A0 =A0 if v'length =3D 0 then
> =A0 =A0 =A0 return 0;
> =A0 =A0 elsif v'length =3D 1 then
> =A0 =A0 =A0 return to_integer(unsigned(v));
> =A0 =A0 else
> =A0 =A0 =A0 return to_integer(signed(v));
> =A0 =A0 end if;
> =A0 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 =A0www.THAT_COMPANY.com
> =A0 end;

Gave

   i :=3D to_integer( signed( std_logic_vector'(31 downto upper+1 =3D>
'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.
0
Mark
11/25/2009 4:47:02 PM
On Nov 25, 10:36=A0am, Mark <marmarjohn...@gmail.com> wrote:
> It doesn't matter to me if FFFF_FFFF is treated as -1 or MAX_INT, just
> that all the bits are in there. =A0I'd like to get something as C-like
> as possible. =A0Unfortunately, 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)). =A0No problem I thought, I'll just
> treat everything as an integer. =A0Unfortunately, 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. =A0I want my conversions to
> be warning free (even if it still works out), so I'm thinking of going
> with the following:
>
> =A0 lower :=3D =A0 =A0 =A0 =A0 c_field_offset;
> =A0 upper :=3D lower + c_field_size - 1;
>
> =A0 if (2**c_field_size-1) > integer'high then
> =A0 =A0 i :=3D to_integer( =A0 signed( slv(upper downto lower)));
> =A0 else
> =A0 =A0 i :=3D to_integer( unsigned( slv(upper downto lower)));
> =A0 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 ...
0
Mark
11/25/2009 5:42:57 PM
On Wed, 25 Nov 2009 08:47:02 -0800 (PST), Mark wrote:

>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.

It wasn't as good a suggestion as "write a function to do it".
If you're really allergic to homemade functions, though, you
could kill the warning from the command line:

  vcom -nowarn 1246 .....

(or something very like that; check the help files).

Please note, to echo and expand on what someone else said, that
VHDL is NOT guaranteed to support the full 32-bit range.  In
particular, the extreme negative value -(2**31) is NOT
guaranteed to be representable as INTEGER.  This means that
precisely one 32-bit value (0x8000_0000) is not safe.  

Yes, I know it's a damned nuisance, but that's what the 
language standard says.
-- 
Jonathan Bromley, Verification Engineer

Verilab   www.THAT_COMPANY.com
0
Jonathan
11/25/2009 10:25:41 PM
On 25 Nov, 16:47, Mark <marmarjohn...@gmail.com> wrote:
> On Nov 25, 9:30=A0am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
> wrote:
>
>
>
> > 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 >=3D lower. =A0=
I
> > >cannot seem to find a syntax that doesn't generate truncation
> > >warnings, or relies on doing some comparison.
>
> > What's wrong with...
> > =A0 i :=3D 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. =A0That'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. =A0How about packing to 32 bits
> > first, and then doing the conversion?
>
> > =A0 i :=3D to_integer(
> > =A0 =A0 =A0 =A0 =A0signed(
> > =A0 =A0 =A0 =A0 =A0 =A0 std_logic_vector'(31 downto upper+1 =3D> '0') &=
 slv
> > =A0 =A0 =A0 =A0 =A0)
> > =A0 =A0 =A0 =A0);
>
> > This *may* give warnings for the null range when upper=3D31,
> > although it's legal VHDL (I'm pretty sure).
>
> > Finally, why not write a custom function instead of trying to
> > inline the ghastly mess?
> > =A0 function to_uint(v: std_logic_vector) return integer is
> > =A0 begin
> > =A0 =A0 if v'length =3D 0 then
> > =A0 =A0 =A0 return 0;
> > =A0 =A0 elsif v'length =3D 1 then
> > =A0 =A0 =A0 return to_integer(unsigned(v));
> > =A0 =A0 else
> > =A0 =A0 =A0 return to_integer(signed(v));
> > =A0 =A0 end if;
> > =A0 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 =A0www.THAT_COMPANY.com
> > =A0 end;
>
> Gave
>
> =A0 =A0i :=3D to_integer( signed( std_logic_vector'(31 downto upper+1 =3D=
>
> '0') & slv(upper downto lower) ));
>
> a try. =A0Got:
>
> =A0 =A0** 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.
0
Tricky
11/26/2009 8:52:20 AM
Tricky wrote:
> On 25 Nov, 16:47, Mark <marmarjohn...@gmail.com> wrote:
>> On Nov 25, 9:30 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
>> wrote:
>>
>>
>>
>>> 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.
>>> --
>>> 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.
> 
> 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
0
Jan
11/26/2009 9:21:54 AM
On Wed, 25 Nov 2009 23:25:41 +0100, Jonathan Bromley <jonathan.bromley@MYCOMPANY.com> wrote:


>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

0
Gerhard
11/26/2009 1:23:22 PM
On Thu, 26 Nov 2009 14:23:22 +0100, Gerhard Hoffmann wrote:

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

Nothing that I know of.  It would be a nice exercise.
Presumably you could represent the big-integer as an
array of (say) 16-bit integers.  Then you would need
all the operator overloads, and conversion functions
to/from regular integers (with warnings on overflow),
to/from numeric_std types, and to/from string because
otherwise there would be no easy way to represent 
wide literal values.

It is not blindingly obvious that a hand-crafted
package like that would be faster than the simulators'
highly optimized internal implementations of numeric_std.
Certainly it would be no good for synthesis.  But I
can see it being useful for testbench, as you suggest.

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).

I don't have time to play with this idea in detail
just now, but it sounds like a pleasant project for
an idle weekend some time.
-- 
Jonathan Bromley, Verification Engineer

Verilab   www.THAT_COMPANY.com
0
Jonathan
11/27/2009 10:32:40 PM
On Fri, 27 Nov 2009 23:32:40 +0100, Jonathan Bromley <jonathan.bromley@MYCOMPANY.com> wrote:


>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
0
Gerhard
11/28/2009 1:26:39 AM
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.

0
kcn9 (1)
9/30/2012 11:23:56 PM
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 ti=
me ago they were. Use numeric_std instead, which defines types signed and u=
nsigned, along with operators and conversions for them. In general, do not =
use "to" ranges for arrays of bits that have a numeric interpretation, unle=
ss it is an externally defined interface that already uses "to". It just le=
ads to problems not unlike this one.

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

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

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

You could overload to_integer() to do the conversion of test_bits_array typ=
e 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, yo=
u should use subtype, not type: Subtype test_bits_array is unsigned(17 down=
to 0); or: subtype slv_bits is unsigned(1 downto 0);

Andy
0
Andy
10/1/2012 5:25:57 PM
On Sun, 30 Sep 2012 18:23:56 -0500
kcn9 <compgroups@cec-services.com> wrote:

> 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?

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.
0
Rob
10/1/2012 5:27:35 PM
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
0
Jim
12/5/2012 11:02:45 PM
On Wed, 05 Dec 2012 15:02:45 -0800, Jim Lewis wrote:

> 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.

Some simulators do (Modelsim among them), some don't. Xilinx ISIM around 
10.1 didn't, but complained about code Modelsim was happy about. (I 
haven't rechecked this issue recently).

Some synth tools used to complain  - early Leonardo or maybe even 
Autologic(!) but I haven't seen that recently...

- Brian
0
Brian
12/6/2012 9:11:51 AM
Reply: