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

With all of the e-mail activity over the past day on this one,
I though I would summarize things:

Hinton, Ryan W @ CSW-SLC wrote:

> PROPOSAL 1
>
> The first change is to allow negative index ranges. I quite often model my
> fixed point data as a real number with absolute value less than 1.0. For
> the UFIXED type, this would give me an index range of (-1 downto -x). Many
> other values I use have ranges that would exclude a binary point from the
> index range. This is a critical feature for me as a user.

There appears to be no argument on this one, and I have been asked by
several commercial fixed point developers to include this as well.
Approved unless there are some objections.

> PROPOSAL 2
>
> Change the interpretation of ascending ranges to maintain the bit values.
> The killer feature of a fixed point type is that it gives an unambiguous
> value to each bit. For a descending range, bit 0 has value 2**0, bit -1 has
> value 2**-1, etc. The current interpretation of ascending ranges negates
> the bounds and swaps the directions. Here is an example
>
> -- descending --
> descending range: ufixed(0 downto -3)
> descending value: 1.110b = 1.75d
>
> -- old ascending --
> ascending range: ufixed(-3 to 0)
> descending range: ufixed(3 downto 0)
> ascending value: 011.1b = 1.75d
> descending value: 0.111b = 0.875d
>
> -- proposed ascending --
> ascending range: ufixed(-3 to 0)
> descending range: ufixed(0 downto -3)
> ascending value: 011.1b = 1.75d
> descending value: 1.110b = 1.75d
>
> Note that the proposed ascending range interpretation requires reversing the
> bits for the corresponding descending value, which differs from VHDL's
> default matching rule (for implicit subtype conversions). This is
> different, but I think it is the right solution. Again, the reason for this
> change is to maintain bit values.

This one is stirring up a lot of controversy.
We will most likely need a vote on this one.

> PROPOSAL 3
>
> Add one or more extra arguments to RESIZE to specify rounding/saturation
> method. This control is critical to signal processing hardware design, and
> often varies even within a single block. I think David has something in
> mind based on IEEE 854.

Once again no controversy. This will follow the floating point packages
standard for doing rounding.
Unless there is an objection this is Approved.

> PROPOSAL 4
>
> Define mixed signed/unsigned logic. Add "+", "*", "-", and "/" operators
> for all combinations of UFIXED/SFIXED. This is another fairly common
> operation in signal processing hardware that is well-defined. David noted
> that bit literals need a type cast anyway, so we shouldn't have the same
> problem as mixed arithmetic in numeric_std.

The questions raised around this one have to do with bit litterals. Since
you can't do a bit literal with an open ended type, this is not an issue.
Once again, unless there is an objection this is Approved.

> 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.

For multiply and divide, these rules make sense.
For addition this causes problems because:
a <= a + b;
will no longer work.
The idea set forth by John Williams is to create a new operator
"|+" which will be a bit growth add, and the standard add will
remain the same.
Sounds like an easy fix, but this one will also need a vote.

-- 
David W. Bishop dbishop@vhdl.org       All standard disclaimers apply.