[vhdl-200x-ft] RE: Fixed-point package issues

David Bishop wrote:
> > David,
> >
> > A few notes.
> >
> > 1. All the "integer_width" and "fraction_width" arguments are type
NATURAL,
> > but they should be type INTEGER. A UFIXED value in the range [0,1) has
an
> > index range of (-1 DOWNTO x), i.e. an "integer_width" of -1.
>
> The original idea here was to force the user to create a number
> that had a decimal point in it. By making the bounds of type "natural",
> you had to have a positive and a negative index.
>
> Some people like this idea, some don't.

Why require a binary point in the number? This seems like an arbitrary
requirement. Many of the fixed point values I use in simulation and
implementation have the binary point outside the bit range. Consequently,
this limitation could prevent me from using this package.

> > 2. In the "to_ufixed" from REAL routine, why don't you just set
> > result := ufixed(to_unsigned(integer(round(arg *
> > 2**fraction_width))));
>
> Good point. I think that that one needs to be updated.

Many of the other routines could be similarly updated. Someone on the
reflector brought up the question of interpretation of fixed point values.
For me, the current proposal for fixed point types exactly corresponds to an
integer with a power of two scaling. All the operators should be easily
specified by appropriate resizing followed by application of the
corresponding integer operator. I don't see any need for splitting integer
and fractional parts.

> > 3. The attached tests fail. Here is my take on the proper bit sizing
> > rules:
> >
<snip>
> >
> > I would like to understand the rationale behind your bit sizing rules.
How
> > did you come up with yours?
>
> Look through the thread on the VHDL synthesis reflector for this. We
> parsed this out about a year ago. I'll dig through the code once I get
> a chance.
>
> --
> NAME: David W. Bishop INTERNET: dbishop@vhdl.org

I read through the discussion on the reflector. Several questions remained
unanswered (at least to my satisfaction).

A) Interpretation of ascending ranges. I like using negative indices for
VHDL fixed point values because they offer an unambiguous value for each
bit: 2**index. In my opinion, this is the critical advantage to using a
fixed point type instead of a SIGNED or UNSIGNED. Maintaining bit value
would require bit reversal for values with ascending ranges for most
arithmetic operations. Bit reversal could have an impact on simulation
time, but shouldn't produce any extra gates. The problem I see with this
option is that it puts the LSB on the left, which may produce unexpected
results from VHDL's array matching (implicit subtype conversion).

If I understand correctly, the other option is "put the binary point between
the 0 and -1 index" or "negate the indices". This maintains the MSB on the
left, but loses the critical meaning of the bit value.

I prefer the first option. However, I always intend to use descending
ranges, so it matters less to me. Interestingly, your current fixed_pkg
uses the high:low matching (bit value) for "to_slv", but negates the indices
for "to_downto_dir". We should certainly decide on one and be consistent.

B) Bit ranges of results. Again, I see two choices. My approach above is
to conservatively size the result so overflow and data loss are minimized
(prevented for all but division). The programmer can then resize the result
as desired. The second approach is to resize one of the operands to the
desired output size. The next item clinches this decision for me.

C) Rounding and saturation. Several emails raised this issue, but I saw no
proposed resolution. If we added rounding/saturation inputs to the RESIZE
function, the programmer would have complete control with a conservatively
sized the result (my bit width suggestions above). I will check with my
employer to see if I can donate some code on this topic. The current bit
sizing rules result in silent (no warning or error) loss of precision and
overflow information. My suggested bit sizing rules allow for discarding
precision and overflow information, but require this loss to be specified
and accepted by the designer.

Thanks!

---
Ryan Hinton
L-3 Communications, Communication Systems West
ryan.w.hinton@L-3com.com