0x80000000 Integer not supported??

Hi everybody, 
I'm designing a VHDL testbench for a VHDL module.

I have to generate values to be written into a 32 bit register of my
module.
I decided tu use integer variables to compose my data and than convert them
to std_logic_vector to perform the write operation on the module.

The issue is that I discovered that VHDL 
integer range is from -2147483647 to 2147483647,
that is to say 0x80000000 integer is not supported.

Is there any way to work out this limitation without using directly
std_logic_vector type?

Thank you in advance for any help

Claudia



	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

On 25 Okt., 12:24, "cdb" <claudia.de-
bartolomeis@n_o_s_p_a_m.transport.alstom.com> wrote:
> The issue is that I discovered that VHDL
> integer range is from -2147483647 to 2147483647,
> that is to say 0x80000000 integer is not supported.

To be precise, 0x80000000 is not necessary supported, which makes it
way more complicated. Each tool might define integer in a way it like
to do it, as long as integer covers _at least_ the range mentioned
above.  According to LRM it is valid if a simulator uses 64 bit
integer (or 42 bit).

> Is there any way to work out this limitation without using directly
> std_logic_vector type?

No easy way. You could implement whatever you want to use something
else (eg. build your own type int64, costs of course a lot of effort),
but I suggest using std_(u)logic_vector as soon as you need at least
32 bit.

bye Thomas

On Mon, 25 Oct 2010 05:24:50 -0500, "cdb"
<claudia.de-bartolomeis@n_o_s_p_a_m.transport.alstom.com> wrote:

>Hi everybody, 
>I'm designing a VHDL testbench for a VHDL module.
>
>I have to generate values to be written into a 32 bit register of my
>module.
>I decided tu use integer variables to compose my data and than convert them
>to std_logic_vector to perform the write operation on the module.
>
>The issue is that I discovered that VHDL 
>integer range is from -2147483647 to 2147483647,
>that is to say 0x80000000 integer is not supported.

It's worse than that. The integer range is guaranteed to cover that range, but
is not necessarily limited to it.

So some implementations allow 0x80000000 while others do not. That means you can
simulate in Modelsim, and find out later that your code will not synthesise, or
simulate in Xilinx ISE simulator.

>Is there any way to work out this limitation without using directly
>std_logic_vector type?

Use the numeric_std library, either signed or unsigned, if your register values
represent numeric types.

If they represent non-numeric quantites (bitmasks, CPU instructions, characters)
then declare them as such, e.g. std_logic_vector constants.
Using integers for non-numeric quantites only sows confusion about the intent of
your design.

- Brian

>On Mon, 25 Oct 2010 05:24:50 -0500, "cdb"
><claudia.de-bartolomeis@n_o_s_p_a_m.transport.alstom.com> wrote:
>
>>Hi everybody, 
>>I'm designing a VHDL testbench for a VHDL module.
>>
>>I have to generate values to be written into a 32 bit register of my
>>module.
>>I decided tu use integer variables to compose my data and than convert
them
>>to std_logic_vector to perform the write operation on the module.
>>
>>The issue is that I discovered that VHDL 
>>integer range is from -2147483647 to 2147483647,
>>that is to say 0x80000000 integer is not supported.
>
>It's worse than that. The integer range is guaranteed to cover that range,
but
>is not necessarily limited to it.
>
>So some implementations allow 0x80000000 while others do not. That means
you can
>simulate in Modelsim, and find out later that your code will not
synthesise, or
>simulate in Xilinx ISE simulator.
>
>>Is there any way to work out this limitation without using directly
>>std_logic_vector type?
>
>Use the numeric_std library, either signed or unsigned, if your register
values
>represent numeric types.
>
>If they represent non-numeric quantites (bitmasks, CPU instructions,
characters)
>then declare them as such, e.g. std_logic_vector constants.
>Using integers for non-numeric quantites only sows confusion about the
intent of
>your design.
>
>- Brian
>

Thanks Brian,
I need to use 0x80000000  integer only in non-synthesizable code (a
testbench), and I decided to adopt integers at high level of my testbench
,
because at the beginning it seemed more flexible to me ( random number
generation etc. ..)

and I'm using Modelsim.
 
I verified that in fact -2**31 is supported and it's than converted in the
proper std_logic_vector ( I got confused because I was using quartus
packages too, in order to use the to_string fuction for example,and quartus
staff seems not to support (-2**31) value)

Modelsim integer extension seems to solve my problems,
but as you rightly noticed, it's not a clear solution:
to express non-numeric quantities ( es values to be written on a 32 bit
control register) as integer I'm forced to use signed value
and consequently a std_logic_vector(TO_SIGNED(...) way of convert them.

Modelsim positive/natural range seems to be up to (2*31 - 1) ... 


Thank you
Bye
Claudia

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

"cdb" <claudia.de-bartolomeis@n_o_s_p_a_m.transport.alstom.com> wrote in 
message news:Cs2dnSXM2OBvx1jRnZ2dnUVZ_rudnZ2d@giganews.com...
> Hi everybody,
> I'm designing a VHDL testbench for a VHDL module.
>
> I have to generate values to be written into a 32 bit register of my
> module.
> I decided tu use integer variables to compose my data and than convert 
> them
> to std_logic_vector to perform the write operation on the module.
>
> The issue is that I discovered that VHDL
> integer range is from -2147483647 to 2147483647,
> that is to say 0x80000000 integer is not supported.
>
> Is there any way to work out this limitation without using directly
> std_logic_vector type?
>
> Thank you in advance for any help
>
> Claudia
>

Perhaps I'm missing the point, but I would have used x"8000_0000"

With the underscore being optional.

On Oct 25, 6:27=A0am, Brian Drummond <brian_drumm...@btconnect.com>
wrote:
> If they represent non-numeric quantites (bitmasks, CPU instructions, char=
acters)
> then declare them as such, e.g. std_logic_vector constants.
> Using integers for non-numeric quantites only sows confusion about the in=
tent of
> your design.
>

I generally agree, unless simulation performance is paramount, due to
the operations required, and/or the amount of memory required by the
simulation. Sometimes a little less obvious intent is worth it for
huge simulation performance gains. And for anyone who's been around
low level embedded SW, the techniques will feel right at home.

Bit-wise logical operations (AND/OR/NOT/XOR, etc.) are not supported
on integers, so there is no way to use built-in processor instructions
for simulating these even if you wrote your own package to implement
them. Otherwise, extracting or shifting bit-fields is simple (*, /,
mod by powers of two), much faster executing (simulating) than with
vector based quantities, and simulation memory requirements are
drastically reduced too.

Andy

On 10/25/2010 06:53 AM, cdb wrote:
>> On Mon, 25 Oct 2010 05:24:50 -0500, "cdb"
>> <claudia.de-bartolomeis@n_o_s_p_a_m.transport.alstom.com>  wrote:
>>
>>> Hi everybody,
>>> I'm designing a VHDL testbench for a VHDL module.
>>>
>>> I have to generate values to be written into a 32 bit register of my
>>> module.
>>> I decided tu use integer variables to compose my data and than convert
> them
>>> to std_logic_vector to perform the write operation on the module.
>>>
>>> The issue is that I discovered that VHDL
>>> integer range is from -2147483647 to 2147483647,
>>> that is to say 0x80000000 integer is not supported.
>>
>> It's worse than that. The integer range is guaranteed to cover that range,
> but
>> is not necessarily limited to it.
>>
>> So some implementations allow 0x80000000 while others do not. That means
> you can
>> simulate in Modelsim, and find out later that your code will not
> synthesise, or
>> simulate in Xilinx ISE simulator.
>>
>>> Is there any way to work out this limitation without using directly
>>> std_logic_vector type?
>>
>> Use the numeric_std library, either signed or unsigned, if your register
> values
>> represent numeric types.
>>
>> If they represent non-numeric quantites (bitmasks, CPU instructions,
> characters)
>> then declare them as such, e.g. std_logic_vector constants.
>> Using integers for non-numeric quantites only sows confusion about the
> intent of
>> your design.
>>
>> - Brian
>>
>
> Thanks Brian,
> I need to use 0x80000000  integer only in non-synthesizable code (a
> testbench), and I decided to adopt integers at high level of my testbench
> ,
> because at the beginning it seemed more flexible to me ( random number
> generation etc. ..)
>
> and I'm using Modelsim.
>
> I verified that in fact -2**31 is supported and it's than converted in the
> proper std_logic_vector ( I got confused because I was using quartus
> packages too, in order to use the to_string fuction for example,and quartus
> staff seems not to support (-2**31) value)
>
> Modelsim integer extension seems to solve my problems,
> but as you rightly noticed, it's not a clear solution:
> to express non-numeric quantities ( es values to be written on a 32 bit
> control register) as integer I'm forced to use signed value
> and consequently a std_logic_vector(TO_SIGNED(...) way of convert them.
>
> Modelsim positive/natural range seems to be up to (2*31 - 1) ...

If you do end up doing something a little 'weird' then comment the heck 
out of it, to alleviate the confusion you necessarily sow.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html

Thomas Stanka <usenet_nospam_valid@stanka-web.de> wrote:
> On 25 Okt., 12:24, "cdb" <claudia.de-
> bartolomeis@n_o_s_p_a_m.transport.alstom.com> wrote:
>> The issue is that I discovered that VHDL
>> integer range is from -2147483647 to 2147483647,
>> that is to say 0x80000000 integer is not supported.
 
> To be precise, 0x80000000 is not necessary supported, which makes it
> way more complicated. Each tool might define integer in a way it like
> to do it, as long as integer covers _at least_ the range mentioned
> above.  According to LRM it is valid if a simulator uses 64 bit
> integer (or 42 bit).

In many high-level languages, constants are not signed.
The unary negation operator, -, is applied to a positive constant.
In that case, in 32 bits you can't hava a constant -2147483648,
but in most cases it can be the result of an expression.

It might be that it is unsupported, or implementation dependent,
only when written as a literal constant.

-- glen

On Oct 25, 12:27=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu>
wrote:
> Thomas Stanka <usenet_nospam_va...@stanka-web.de> wrote:
> > On 25 Okt., 12:24, "cdb" <claudia.de-
> > bartolomeis@n_o_s_p_a_m.transport.alstom.com> wrote:
> >> The issue is that I discovered that VHDL
> >> integer range is from -2147483647 to 2147483647,
> >> that is to say 0x80000000 integer is not supported.
> > To be precise, 0x80000000 is not necessary supported, which makes it
> > way more complicated. Each tool might define integer in a way it like
> > to do it, as long as integer covers _at least_ the range mentioned
> > above. =A0According to LRM it is valid if a simulator uses 64 bit
> > integer (or 42 bit).
>
> In many high-level languages, constants are not signed.
> The unary negation operator, -, is applied to a positive constant.
> In that case, in 32 bits you can't hava a constant -2147483648,
> but in most cases it can be the result of an expression.
>
> It might be that it is unsupported, or implementation dependent,
> only when written as a literal constant.
>
> -- glen

This is the first time I've seen any justification for not including
the entire 32 bit two's complement representable range in integer.
Interesting... I have a feeling many implementations do not extend the
range (as allowed by the LRM) to 32 bit two's complement not because
of this, but because they simply did not realize or care that it was
not quite 32 bits.

However, the way the LRM is written, the bounds of a data type range
specification apply equally to constants, signals and variables of
that type. Thus an implementation would not be allowed to accept a
signal or variable value that is beyond what it would accept for a
constant of the same type. The implementation either has to allow it
in all three cases, or disallow it in all three cases.

Andy

Andy <jonesandy@comcast.net> wrote:
(snip)

>> In many high-level languages, constants are not signed.
>> The unary negation operator, -, is applied to a positive constant.
>> In that case, in 32 bits you can't hava a constant -2147483648,
>> but in most cases it can be the result of an expression.

>> It might be that it is unsupported, or implementation dependent,
>> only when written as a literal constant.
 
> This is the first time I've seen any justification for not including
> the entire 32 bit two's complement representable range in integer.
> Interesting... I have a feeling many implementations do not extend the
> range (as allowed by the LRM) to 32 bit two's complement not because
> of this, but because they simply did not realize or care that it was
> not quite 32 bits.

It is at least true for C and Fortran in places where expressions
are allowed.  (The Fortran DATA statement allows for a signed constant,
as expressions are not allowed.)
 
> However, the way the LRM is written, the bounds of a data type range
> specification apply equally to constants, signals and variables of
> that type. Thus an implementation would not be allowed to accept a
> signal or variable value that is beyond what it would accept for a
> constant of the same type. The implementation either has to allow it
> in all three cases, or disallow it in all three cases.

It isn't so obvious for verilog, but both C and Fortran allow for
sign magnitude and ones complement.  ANSI C requires binary, but
Fortran allows for any base greater than one.  Does verilog
allow for a sign magnitude or ones complement integer?

-- glen