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

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

> > Telecon information:
> >
> > 888-742-8686
> > 303-928-2600 (int'l)
> > Conference ID: 4737027
> > Time 2 PM PST Monday 7/12

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.

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.

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

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