Integer arithmetic in HDLs

If you are doing HDL-based design, you are probably using
integer arithmetic regularly. In doing so, you may often be
struggling with mysterious behaviour, sign bit extensions,
resizings and type conversions, in order to get things
to work as you want.

I believe such efforts are a waste of your valuable
engineering time, caused by bad language design choices
in Verilog and VHDL.

I have written an essay that explores these issues in
detail, and proposes a solution:

http://www.jandecaluwe.com/hdldesign/counting.html

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Python as a hardware description language:
http://www.myhdl.org

Jan Decaluwe

Hi

This is a good argument. It is why I prefered ieee.std_logic_arith an
staying with bit vectors. It means the cast signed or unsigened is
placed around each input std_logic_vector, and the output
automatically casts to the required std_logic_vector.

Ooooooh, don't you just miss the division operators from numeric_std?
No. I don't even miss the multiplication operators. If I get to
needing such things, I will use one from either synopsis free
distribution files, or a homebrew one.

So put simply the signed or unsigned just specifies the sign extension
for the arithmetic. I find no problem in thinking in terms of
std_logic_vector. It does not suffer from integer's lack of width
generics. Although useful for generate statements integers be, ya ,
yoda.

cheers jacko

Jacko

On Mar 10, 7:03*am, Jan Decaluwe <j...@jandecaluwe.com> wrote:
> If you are doing HDL-based design, you are probably using
> integer arithmetic regularly. In doing so, you may often be
> struggling with mysterious behaviour, sign bit extensions,
> resizings and type conversions, in order to get things
> to work as you want.
>
> I believe such efforts are a waste of your valuable
> engineering time, caused by bad language design choices
> in Verilog and VHDL.
>
> I have written an essay that explores these issues in
> detail, and proposes a solution:
>
> http://www.jandecaluwe.com/hdldesign/counting.html

Excellent treatise although I'm not convinced I want to use Python for
hardware development. I use integers and naturals, with appropriate
ranges, all the time.

Perhaps the people on the VHDL committee could promulgate the
following for the next update to the language, whenever that might be:

a) the arbitrary 32-bit limit on the size of integers and naturals
should be relaxed or eliminated, for the obvious reasons. And it's
probably also obvious that everyone who does use integers and naturals
in VHDL code already uses ranges.

b) when dealing with signed and unsigned types, sign-extension should
be implicit (no need for resize() calls) such that all operands on the
RHS get extended to the size of LHS result. An error should be thrown
if any operand on the RHS is larger than the LHS result -- no need for
obscure truncation rules a-la Verilog.

-a

Andy Peters

If we use VHDL integer arithmetic as a model, all operations are
promoted to 32 bit signed (i.e. the largest size available),
regardless of the subranges or signedness of the operands. Then the
results are automatically truncated upon assignment to a subranged
(and either natural or integer) object. Synthesis will prune
intermediate results based on the final truncation.

One VHDL arithmetic type not mentioned in the paper is the new ieee
fixed point types (ufixed & sfixed), which also work well for integers
with a zero rightmost index (i.e. zero digits to the right of the
binary point). What is different between fixed point (ufixed & sfixed)
and numeric_std (signed & unsigned) arithmetic, is that addition/
subtraction is always promoted by one bit to handle potential
overflow, which effectively duplicates the promotion part of the
behavior of integer arithmetic. Unfortunately, what is not included is
the promotion of ufixed operands to an sfixed result for subtraction.
This is really interesting since subtraction of two ufixed operands
still increases the bit size by one, but still does not make it
signed. There is also no definition of any operators for mixed ufixed/
sfixed operands.

I think "fixing" the automatic truncation of vectors on assignment is
probably on the "too hard" list without changing a lot of existing
behavior in the VHDL language, unless overloading the assignment
operator was allowed. Promotion of all results to sfixed (save perhaps
addition of two ufixed operands) is not too hard, and should be
considered, especially since a truncation function is almost always
needed anyway, and could be combined with a sfixed/ufixed conversion.
With these additions/changes, the fixed point type model could go a
long ways toward providing integer-like arithmetic with arbitrary
width data.

Andy

Andy