Integer arithmetic in HDLs

[Jan Decaluwe]

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

 

[Jacko]

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

 

[Andy Peters]

T.M.F. pisze:

Marek S pisze:
Witam
poszukuje preparatu B327 w ilości 2 do 10 kg . Czy ktoś wie gdzie
można takowy kupić ? w TME maja pakowane po 100 g a ja bym chciał
kupić np. w opakowaniu po 1 kg
Marek S

W POCh.
OK dzięki bardzo

 

[Andy]

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