David,
> Our Monday Telecon will be dedicated to going over the action
> items from the fixed point package.
>
> The source code is at:
> http://vhdl.org/vhdlsynth/proposals/dave_p3.html
Can you also put the below information into the
proposal so that it all gets captured.
> The fixed point packages introduce two new types:
> type ufixed is array (integer range <>) of std_logic;
> type sfixed is array (integer range <>) of std_logic;
> Where "ufixed" is an unsigned fixed point number and "sfixed"
> is a signed fixed point number.
> These numbers can have a negative index. A decimal point
> is assumed between the "0" and "-1" element in the string.
Agreed for "downto". Proposal 1 below gives different
possible interpretations for "to".
> Usage model:
> use work.fixed_pkg.all;
> ....
> signal a, b : sfixed (7 downto -5);
> signal mulout : sfixed (14 downto -10);
> begin
> ....
> a <= to_sfixed (-5.4, a'high, a'low);
> mulout <= a * b;
>
> Proposals to be discusses (part 1):
>
> 1) Issue: How do we interpretation of bit string literals
> Our argument is this:
> variable a8r : ufixed (-1 to 7) := "010011100";
> How is the string interpreted? Are the lower bits "10" or "00"?
> Alternatives:
> Is the result interpreted as 57.0 or 78.0?
> Bit wise, if we reverse the range to be 7 downto -1 the result
> would be 58. However, if we follow the rules from "numeric_std"
> the answer would be 78.
--------------------
Option 1:
> variable a8r : ufixed (-1 to 7) := "010011100";
Understand the value in a8r as 57:
57 = 00111001.0
Under this option, the decimal point is between
the "0" and "-1" and the string is reversed to
arrive at its value.
Con: This is opposite of any current numeric
representation
--------------------
Option 2:
> variable a8r : ufixed (-1 to 7) := "010011100";
Understand the value in a8r as 78:
78 = 01001110.0
To arrive at this, first translate the indices
to the equivalent downto indicies:
> variable a8 : ufixed (7 downto -1) := "010011100";
Now the decimal point is between the "0" and the
"-1" index.
Pro: Preserves the sense of numeric_std
Con: The decimal point is in an odd place
--------------------
Option 3:
> variable a8r : ufixed(-1 to 7) := "010011100";
Understand the value in a8r as 1.34375:
1.34375 = 01.0011100
Under this,
1) MSB is on the left
2) Whole number is on the left
3) Fraction is on the right
4) Decimal point is to the right of the 0 index.
Pro: Preserves the sense of numeric_std
Pro: Consistency in that decimal point is
to the right of the "0" index.
--------------------
> Pros and Cons:
> Con:
> In numeric_std (1076.3) we always interperate the left most bit
> to be the LSB. If we follow that convention in the fixed point
> packages then the answer is 78.0. Any other interpretation would
> be a break from this convention.
> Pro:
> Looking at the number and the interpretation of it (expressed
> as "to" rather than "downto") an interpretation of 57.0 would seem
> natural.
> Con:
> This would also complicate the interpretation of FT09.
>
> Recommendation:
> Stick with the numeric_std interpretation (answer is 78.0).
>
> 2) Issue:
> Bit sizing rules for addition and subtraction.
> Currently we have
> ufixed(a downto b) + ufixed(c downto d) = ufixed(max(a,c) downto min(b,d))
> Which actually tosses the overflow bit.
> Proposed is the following:
> ufixed(a downto b) + ufixed(c downto d) = ufixed(max(a,c)+1 downto
> min(b,d))
>
> Alternatives:
> a) Do nothing (you can use a RESIZE funciton to maintain bit width as is
> done in "numeric_std".
> b) Change the current output bit width of the add the extra bit on the MSB
> c) We could create a new operator, proposed is "|+" and "|-"
>
> Pros and Cons:
> Con: (alternative b)
> This would be another departure from the "numeric_std" convention
> Con: (alternative b)
> a <= a + b would no longer work
> Pro: (alternative b)
> We currently throw away the overflow bit. This would maintain it.
> Pro: (alternative c)
> This would make both camps happy. The new operators can also be used
> for the current fixed point Mathcad based schematics.
> Con: (alternative c)
> This would require more coding, and more functions which would have
> to be carefully documented.
>
> Recommendation:
> Add the "|+" and "|-" operaters to extend the bit width, leave
> the current "+" and "-" alone (c).
>
>
>
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jim Lewis Director of Training mailto:Jim@SynthWorks.com SynthWorks Design Inc. http://www.SynthWorks.com 1-503-590-4787 Expert VHDL Training for Hardware Design and Verification ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Received on Mon Jul 12 10:54:17 2004
This archive was generated by hypermail 2.1.8 : Mon Jul 12 2004 - 10:54:23 PDT