converting std_logic_vector to an integer without sign extension

Discussion in 'VHDL' started by Mark, Nov 25, 2009.

  1. Mark

    Mark Guest

    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.
     
    Mark, Nov 25, 2009
    #1
    1. Advertising

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

    --
    ---------------------------------
     
    Kenn Heinrich, Nov 25, 2009
    #2
    1. Advertising

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

    --

    TRW Conekt - Consultancy in Engineering, Knowledge and Technology
    http://www.conekt.net/electronics.html
     
    Martin Thompson, Nov 25, 2009
    #3
  4. Kenn Heinrich <> writes:

    > Mark <> 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.
     
    Kenn Heinrich, Nov 25, 2009
    #4
  5. Mark

    Mark Guest

    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, Nov 25, 2009
    #5
  6. Mark

    Mark Guest

    On Nov 25, 9:30 am, Jonathan Bromley <>
    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.
     
    Mark, Nov 25, 2009
    #6
  7. Mark

    Mark Guest

    On Nov 25, 10:36 am, Mark <> 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.  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 ...
     
    Mark, Nov 25, 2009
    #7
  8. Mark

    Tricky Guest

    On 25 Nov, 16:47, Mark <> wrote:
    > On Nov 25, 9:30 am, Jonathan Bromley <>
    > 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.
     
    Tricky, Nov 26, 2009
    #8
  9. Mark

    Jan Decaluwe Guest

    Tricky wrote:
    > On 25 Nov, 16:47, Mark <> wrote:
    >> On Nov 25, 9:30 am, Jonathan Bromley <>
    >> 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
     
    Jan Decaluwe, Nov 26, 2009
    #9
  10. On Wed, 25 Nov 2009 23:25:41 +0100, Jonathan Bromley <> 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
     
    Gerhard Hoffmann, Nov 26, 2009
    #10
  11. On Fri, 27 Nov 2009 23:32:40 +0100, Jonathan Bromley <> 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
     
    Gerhard Hoffmann, Nov 28, 2009
    #11
  12. Mark

    Andy Guest

    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
     
    Andy, Oct 1, 2012
    #12
  13. Mark

    Rob Gaddi Guest

    Re: converting std_logic_vector to an integer without signextension

    On Sun, 30 Sep 2012 18:23:56 -0500
    kcn9 <> 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.
     
    Rob Gaddi, Oct 1, 2012
    #13
  14. Mark

    Jim Lewis Guest

    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
     
    Jim Lewis, Dec 5, 2012
    #14
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    5
    Views:
    27,229
  2. Replies:
    3
    Views:
    11,558
    David Binnie
    Apr 30, 2006
  3. Jimmy
    Replies:
    1
    Views:
    962
    Cowboy \(Gregory A. Beamer\)
    Nov 21, 2006
  4. Thomas Rouam
    Replies:
    6
    Views:
    1,155
  5. Rockerboy
    Replies:
    5
    Views:
    11,449
Loading...

Share This Page