Re: [vhdl-200x-ft] fixed point package action items and telecon

As I mentioned previously, I don't think we can define the arithmetic operators in the general case as there's no way to know how the returned value aligns with how it is to be used. (The result could be assigned to an object that has a different number of fractional and integral bits as the returned value, but the total number of bits returned matches. As with bit-string literals the value will be assigned in left to right order and the resulting value will not have the same fixed point interpretation as the returned value!

The only possible way that operators might be acceptable is if both the left and right operands' ranges are identical. Even then, the assumption is that the result will be assigned or used within a context that has the exact same range!

However, I think that procedures MUST be used as the range of the result is most definitely relevant and it is the only way to be sure that the operation is meaningful. This includes operations with one operand that is a real, integer, signed or unsigned type.

-Steve Bailey

> -----Original Message-----
> From: owner-vhdl-200x-ft@eda.org
> [mailto:owner-vhdl-200x-ft@eda.org <mailto:owner-vhdl-200x-ft@eda.org> ] On Behalf Of David Bishop
> Sent: Monday, July 12, 2004 12:25 PM
> To: 'vhdl-200x-ft@eda.org'
> Subject: Re: [vhdl-200x-ft] fixed point package action items
> and telecon
>
> Proposals to be discusses (part 2):
>
>
> 3) Issue:
> Bit sizing rules for multiplication and division For a
> multiply 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) Currently in the fixed point packages
> ufixed(a downto b) * ufixed(c downto d) = ufixed(a+c downto b+d)
> sfixed(a downto b) * sfixed(c downto d) = sfixed(a+c downto b+d)
> Proposed is:
> 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)
>
> For division in numeric_std:
> signed (a downto 0) / signed (c downto 0) := signed (a downto 0);
> unsigned (a downto 0) / unsigned (c downto 0) := unsigned
> (a downto 0); Currently in the fixed point package
> ufixed (a downto b) / ufixed (c downto d) := ufixed
> (max(a,c) downto min(b,d))
> sfixed (a downto b) / sfixed (c downto d) := sfixed
> (max(a,c) downto min(b,d))
> Proposed:
> 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 from several post (and the problem I am currently
> having with the packages) they appear to be problematic.
>
> Alternatives:
> 1) do nothing (once again you can use a "resize")
> 2) Follow these precision
>
> Pro:
> These maintain precision, and actually follow the
> "numeric_std" idea for multiply more closely.
> Pro:
> Division in fixed point is very different than Division in
> "numeric_std".
> Con:
> Makes it more difficult to understand division.
>
> Recommendation:
> Accept the proposal
>
>
> 4) Issue:
> Overloading.
> Initially, we have
> ufixed <= ufixed + ufixed, sfixed <= sfixed + sfixed; We
> automatically add the following:
> ufixed <= ufixed + integer, ufixed <= ufixed + real; (same
> for sfixed).
> Next, if we add (and these already exist in the package:)
> ufixed <= ufixed + unsigned, sfixed <= sfixed + signed.
> At this point we can no longer add bit literals. The reasons are two:
> 1) The bit literal is not bounded (our type is ufixed is
> array (integer range
> <>) of std_logic;)
> 2) Since we already have "ufixed" and "unsigned" there is a
> type conflict.
> Thus ALL bit liters must be either casted or assigned to a
> type before being used.
>
> The proposal is to add the following functions:
> b) sfixed := ufixed - ufixed;
> c) sfixed := sfixed + ufixed; (- * /)
> d) sfixed := ufixed + signed; (- * /) (once a signed number
> is involved the result would be "sfixed")
>
> Pros:
> People need to do this anyway
> Pro:
> You already MUST cast any bit literals
> Con:
> more functions to maintain and test
> Con:
> Doesn't have the same restrictions as "numeric_std".
>
> Work around:
> sfixed := sfixed + to_sfixed (ufixed);
>
> Recommendation:
> Accept the proposal.
>
>
> --
> David W. Bishop dbishop@vhdl.org All standard disclaimers apply.

------------
Stephen Bailey
ModelSim Verification TME
Mentor Graphics
sbailey@model.com
303-775-1655 (mobile, preferred)
720-494-1202 (office)
www.model.com <www.model.com>
Received on Mon Jul 12 21:47:58 2004