Integer arithmetic in HDLs

Discussion in 'VHDL' started by Jan Decaluwe, Mar 10, 2009.

  1. Jan Decaluwe

    Jan Decaluwe Guest

    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, Mar 10, 2009
    #1
    1. Advertising

  2. Jan Decaluwe

    Jacko Guest

    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, Mar 10, 2009
    #2
    1. Advertising

  3. Jan Decaluwe

    Andy Peters Guest

    On Mar 10, 7:03 am, Jan Decaluwe <> 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, Mar 10, 2009
    #3
  4. Jan Decaluwe

    Andy Guest

    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, Mar 12, 2009
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. nfirtaps

    Integer arithmetic

    nfirtaps, Dec 1, 2006, in forum: VHDL
    Replies:
    1
    Views:
    628
  2. joshc
    Replies:
    5
    Views:
    583
    Keith Thompson
    Mar 31, 2005
  3. sarathy

    integer promotion and arithmetic conversion

    sarathy, Aug 16, 2006, in forum: C Programming
    Replies:
    6
    Views:
    533
  4. Frederick Gotham
    Replies:
    2
    Views:
    411
    Frederick Gotham
    Jul 7, 2006
  5. rickman

    Are HDLs Misguided?

    rickman, Dec 11, 2010, in forum: VHDL
    Replies:
    37
    Views:
    1,533
    Paul Colin Gloster
    Dec 24, 2010
Loading...

Share This Page