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 |

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 |

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 |

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 |

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 |

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 |

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 |

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 |

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 |

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 |

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 |

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 |

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 |

11/28/2009 1:26:39 AM

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 |

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 |

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 |

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 |

12/6/2012 9:11:51 AM