short integer equivalent

[mk.supriya]

hello,
can anybody tell me what data type i should use to reduce the size of
integer to 2 bytes instead of 4?
i.e is there something analogues with short int?

 

[Mike Treseler]

hello,
can anybody tell me what data type i should use to reduce the size of
integer to 2 bytes instead of 4?
i.e is there something analogues with short int?

numeric_std.unsigned(15 downto 0)

-- Mike Treseler

 

[ast]

hello,
can anybody tell me what data type i should use to reduce the size of
integer to 2 bytes instead of 4?
i.e is there something analogues with short int?

integer range 0 to 65535

 

[Shannon]

numeric_std.unsigned(15 downto 0)

-- Mike Treseler

I trust your answer Mike. What would INTEGER RANGE 0 TO 65535 do?

Shannon

 

[Andy]

I trust your answer Mike. What would INTEGER RANGE 0 TO 65535 do?

Shannon

Same thing, and simulate faster too, assuming you wanted an unsigned,
16 bit representation.

Otherwise, "integer range -(2**15) to 2**15-1" would give you a
signed, 16 bit representation.

Andy

 

[Jonathan Bromley]

I trust your answer Mike. What would INTEGER RANGE 0 TO 65535 do?

As Andy said, it would give you a 16-bit unsigned integer.

You can represent anything <= 31 bits in VHDL by using a suitable
integer SUBTYPE. 32 bits is somewhat doubtful, because the
VHDL language standard does not require implementations to
handle the most negative twos complement value -(2**31)
(usually represented as 16#8000_0000#). And anything wider
than 32 bits is unlikely to work with integer subtypes.

So, here are the tradeoffs that I perceive between using
integer subtypes vs. UNSIGNED/SIGNED vectors from numeric_std:

Benefits of vector types
~~~~~~~~~~~~~~~~~~~~~~~~
* Any reasonable bit width is OK - not limited to 31/32 bits,
and (in particular) 32-bit unsigned is easy and reliable
* Trivially easy conversion to/from std_logic_vector
* Trivially easy bit-picking, slicing, logic (AND/OR) operations
* Fuss-free wraparound modulo 2**N (e.g. 8-bit counter contains
255, increment it, 255+1=0 just like real hardware)
* Unknown, uninitialized and tri-state values can be handled

Benefits of integer subtypes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* Faster simulation (even in simulators that have accelerated
implementations of numeric_std)
* Trivially easy arithmetic between signed and unsigned values
* Run-time detection of integer overflow in simulation
* Trivially easy to capture the carry output from +/-
* You can assign numeric constants to them directly

Significant drawbacks of vector types
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* Can't directly assign numeric values to them
* Unsigned vs. signed arithmetic is tricky
* Capturing carry/overflow bits from an arithmetic
operation requires some care

Significant drawbacks of integer subtypes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* Anything >=32 bits is unreliable and/or broken
* Messy conversion to/from std_logic_vector (though you
can easily sugar-coat it with custom functions)
* Modelling modulo-2**N wraparound behaviour is tricky
* Bitwise masking and logic is hopelessly messy

My personal preference has been strongly in favour of
the numeric_std vector types for many years now, primarily
because of the problem with representing unsigned 32-bit
integers using the integer types in VHDL. Others
have taken the opposite stance. Make up your own mind -
but please do it on the basis of reasoned evaluation
rather than guesswork. I make heavy use of integer
types in VHDL when it serves my purposes, especially
in testbench code.

I'd be delighted if anyone else could add to this
pro/con checklist.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
(e-mail address removed)
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Andy]

As Andy said, it would give you a 16-bit unsigned integer.

You can represent anything <= 31 bits in VHDL by using a suitable
integer SUBTYPE. 32 bits is somewhat doubtful, because the
VHDL language standard does not require implementations to
handle the most negative twos complement value -(2**31)
(usually represented as 16#8000_0000#). And anything wider
than 32 bits is unlikely to work with integer subtypes.

So, here are the tradeoffs that I perceive between using
integer subtypes vs. UNSIGNED/SIGNED vectors from numeric_std:

Benefits of vector types
~~~~~~~~~~~~~~~~~~~~~~~~
* Any reasonable bit width is OK - not limited to 31/32 bits,
and (in particular) 32-bit unsigned is easy and reliable
* Trivially easy conversion to/from std_logic_vector
* Trivially easy bit-picking, slicing, logic (AND/OR) operations
* Fuss-free wraparound modulo 2**N (e.g. 8-bit counter contains
255, increment it, 255+1=0 just like real hardware)
* Unknown, uninitialized and tri-state values can be handled

Benefits of integer subtypes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* Faster simulation (even in simulators that have accelerated
implementations of numeric_std)
* Trivially easy arithmetic between signed and unsigned values
* Run-time detection of integer overflow in simulation
* Trivially easy to capture the carry output from +/-
* You can assign numeric constants to them directly

Significant drawbacks of vector types
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* Can't directly assign numeric values to them
* Unsigned vs. signed arithmetic is tricky
* Capturing carry/overflow bits from an arithmetic
operation requires some care

Significant drawbacks of integer subtypes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* Anything >=32 bits is unreliable and/or broken
* Messy conversion to/from std_logic_vector (though you
can easily sugar-coat it with custom functions)
* Modelling modulo-2**N wraparound behaviour is tricky
* Bitwise masking and logic is hopelessly messy

My personal preference has been strongly in favour of
the numeric_std vector types for many years now, primarily
because of the problem with representing unsigned 32-bit
integers using the integer types in VHDL. Others
have taken the opposite stance. Make up your own mind -
but please do it on the basis of reasoned evaluation
rather than guesswork. I make heavy use of integer
types in VHDL when it serves my purposes, especially
in testbench code.

I'd be delighted if anyone else could add to this
pro/con checklist.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
(e-mail address removed)://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

Wow, that's a pretty good summary of pro's and con's.

However, if a conversion between integer and std_logic_vector is
"messy", it should at least be noted that a slightly less messy
conversion is also required between signed/unsigned and
std_logic_vector.

Also, the same condition of not using custom functions (or overridden
operators) for bitwise functions on integers should be stated. I have
package of bitwise logical operators for naturals that I use that
converts them to numeric_bit.unsigned(30 downto 0) and back, but you
have to be careful to modulo the results of some operators (i.e. NOT,
NOR, etc.) before assignment to anything less than a 31 bit natural.
Likewise, grabbing slices using mod and / is not hard either (though
harder than vectors).

Other advantages of integers: Changing "sizes" in assignments is
transparent. Integers can be used directly to index an array, and they
allow use of numeric constants as target expressions in case
statements.

Finaly, (my_integer + 1 > my_integer) is always true, else it will die
trying (assertion)! I don't consider mimicking the hardware
inaccuracies of (my_vector + 1) to be an advantage. :^)

Andy

 

[mk.supriya]

Wow, that's a pretty good summary of pro's and con's.

However, if a conversion between integer and std_logic_vector is
"messy", it should at least be noted that a slightly less messy
conversion is also required between signed/unsigned and
std_logic_vector.

Also, the same condition of not using custom functions (or overridden
operators) for bitwise functions on integers should be stated. I have
package of bitwise logical operators for naturals that I use that
converts them to numeric_bit.unsigned(30 downto 0) and back, but you
have to be careful to modulo the results of some operators (i.e. NOT,
NOR, etc.) before assignment to anything less than a 31 bit natural.
Likewise, grabbing slices using mod and / is not hard either (though
harder than vectors).

Other advantages of integers: Changing "sizes" in assignments is
transparent. Integers can be used directly to index an array, and they
allow use of numeric constants as target expressions in case
statements.

Finaly, (my_integer + 1 > my_integer) is always true, else it will die
trying (assertion)! I don't consider mimicking the hardware
inaccuracies of (my_vector + 1) to be an advantage. :^)

Andy- Hide quoted text -

- Show quoted text -

thank you all for the reply. simulation is fine, but during synthesis
if i say just integer it takes a lot of unwanted space, so i will try
this and see

 

[Andy]

thank you all for the reply. simulation is fine, but during synthesis
if i say just integer it takes a lot of unwanted space, so i will try
this and see

You need to define your integer signals/variables with a range to
limit their bit width.

signal my_int : integer range 0 to 2**bits-1;

BTW, I thought of another disadvantage to integers: you cannot query
the range of an integer (or integer subtype) port/signal/variable. For
example, you can declare my_slv : std_logic_vector(my_port'range) to
make it the same length as the port; you cannot do that with an
integer port, you have to pass a generic for this. Or you can use a
declared subtype, for which you can query the 'high, and 'low
attributes. I have seen a few instances where optimization resulted in
pruning integer logic paths down to the size of what they were
assigned to/from, but it has not been consistent.

Andy

 

[Mike Treseler]

Trust, but verify.
Write a simple example and try it with your own tools.

Yes. I would prefer NATURAL range 0 to 65535

Yes. My top annoyance as well.
A work-around for this is to add the zero
init constant to the right side expression:

constant vec_zero_c : my_uns_vec_t := (others => '0');
forty_seven_c := vec_zero_c + 47;

Yes -- address math. This is the main reason why numeric_std is
my default for numeric vectors of configurable width.

my_port <= std_logic_vector(my_uns_v); -- is this messy?

BTW, I thought of another disadvantage to integers: you cannot query
the range of an integer (or integer subtype) port/signal/variable. For
example, you can declare my_slv : std_logic_vector(my_port'range) to
make it the same length as the port; you cannot do that with an
integer port.

Aligning variables to ports or subprogram args is one
of my favorites. Easy to write and read.

-- Mike Treseler

 

[Andy]

Trust, but verify.
Write a simple example and try it with your own tools.


Yes. I would prefer NATURAL range 0 to 65535


Yes. My top annoyance as well.
A work-around for this is to add the zero
init constant to the right side expression:

constant vec_zero_c : my_uns_vec_t := (others => '0');
forty_seven_c := vec_zero_c + 47;


Yes -- address math. This is the main reason why numeric_std is
my default for numeric vectors of configurable width.


my_port <= std_logic_vector(my_uns_v); -- is this messy?


Aligning variables to ports or subprogram args is one
of my favorites. Easy to write and read.

-- Mike Treseler

My point was that

my_slv_port <= std_logic_vector(my_unsigned);

is only slightly less messy than

my_slv_port <= std_logic_vector(to_unsigned(my_natural,
my_slv_port'length));

Both are too verbose.

Definitions of "messy" and "slightly less" are open to interpretation
of course!

My answer to the above is to make the port unsigned or natural in the
first place. Only for top level ports on the device would I use SLV,
unless it made sense to do so.

And when I do, I use my favorite shortcut:

subtype slv is std_logic_vector;

That way I can write:

my_slv_port <= slv(my_slv);

or

my_slv_port <= slv(to_unsigned(my_natural, my_slv_port));

Andy