Re: [vhdl-200x-ft] Bit size rules

This is another inconsistency with numeric_std.

For addition, we have the hardest pill to swallow:
In numeric_std:
unsigned (a downto 0) + unsigned (b downto 0) = unsigned (max(a,b) downto 0);
unsigned (a downto 0) - unsigned (b downto 0) = unsigned (max(a,b) downto 0);
signed (a downto 0) + signed (b downto 0) = signed (max(a,b) downto 0);
signed (a downto 0) - signed (b downto 0) = signed (max(a,b) downto 0);
Since this proposal says "max(a,b)+1" then you can no longer say:
signal a, b : ufixed (7 downto -3);
a <= a + b;
Because the result needs to be one bit wider.
You would have to say:
a <= resize (a+b, 7, -3);

For multiplication and division, these rules make sense as they
maintain the precision on the bit width.
In numeric_std:
signed (a downto 0) * signed (c downto 0) = signed (a+c+1 downto 0)
unsigned (a downto 0) * unsigned (c downto 0) = unsigned (a+c+1 downto 0)
So this will be different in the "signed" case.
Division in fixed point is a whole other animal. So it must be different.

Hinton, Ryan W @ CSW-SLC wrote:

> PROPOSAL 5
>
> Change the bit widths of arithmetic results. Here are my proposed bit
> sizing rules.
>
> -- addition (note mixed addition returns signed)
> ufixed(a downto b) + ufixed(c downto d) = ufixed(max(a,c)+1 downto
> min(b,d))
> ufixed(a downto b) + sfixed(c downto d) = sfixed(max(a,c)+1 downto
> min(b,d))
> sfixed(a downto b) + sfixed(c downto d) = sfixed(max(a,c)+1 downto
> min(b,d))
>
> -- subtraction the same except "ufixed - ufixed = sfixed"
> ufixed(a downto b) - ufixed(c downto d) = sfixed(max(a,c)+1 downto
> min(b,d))
>
> -- multiply returns almost sum of widths
> ufixed(a downto b) * ufixed(c downto d) = ufixed(a+c+1 downto b+d)
> ufixed(a downto b) * sfixed(c downto d) = sfixed(a+c+1 downto b+d)
> sfixed(a downto b) * sfixed(c downto d) = sfixed(a+c downto b+d)
>
> -- divide returns odd combination of widths
> ufixed(a downto b) / ufixed(c downto d) = ufixed(a-d+1 downto b-c-1)
> ufixed(a downto b) / sfixed(c downto d) = sfixed(a-d+1 downto b-c)
> sfixed(a downto b) / ufixed(c downto d) = sfixed(a-d downto b-c-1)
> sfixed(a downto b) / sfixed(c downto d) = sfixed(a-d downto b-c)
>
> Note that these do not match the bit sizing conventions for numeric_std.
> The result sizes above are conservative in that (except for division) they
> do not lose any information in the worst case.
>
> Take addition for example. These rules mandate bit growth in sums. In some
> cases wrapping may be the desired behavior, so this behavior should be easy
> to specify using the RESIZE functions proposed above. In other cases bit
> growth may be overly conservative, for example the last sum in "((a+b)+c)+d"
> where a, b, c, and d are all the same range. The language can't determine
> this automatically. It could if we had unconstrained elements in records,
> and could do it efficiently if we had multi-mode (mixed constant/signal)
> records. However, these cases are the exception rather than the rule.
>
> These types are intended for signal processing hardware. The numeric_std
> result sizes require input resizing for every operation in order to not lose
> range or precision. (I looked at some old code and confirmed this: I had at
> least one input or output RESIZE on _every line_ of code.) I think these
> proposed rules promote good signal processing hardware design instead of
> hindering it. Again, I think this reason justifies being inconsistent with
> numeric_std.
>
> CONCLUSION
>
> Proposals 1 and 2 are specific to the new fixed point types. Proposals 3
> and 4 are enhancements that I have talked with David and others about adding
> to numeric_std (though there may be some issues). I would love to see
> Proposal 5 implemented in numeric_std also, but it would be impossible to
> maintain backward compatibility. Still, I don't think we should mandate
> that the new system has to be broken in the same ways the old system was
> broken.
>
> Discussion is welcome as always.
>
> ---
> Ryan Hinton
> L-3 Communications / Communication Systems - West
> ryan.w.hinton@L-3com.com
>

-- 
NAME:     David W. Bishop           INTERNET: dbishop@vhdl.org