Numeric Package Proposals for VHDL-200X Fast Track

ID:	  N-008

Proposed by:  David Bishop  03/05/2003
Analyzed by:  
Resolved:     

Summary:  
    Add packages for fixed point arithmetic

Detail:

fixed_pkg.vhd package for the fixed point standard
fixed_pkg_body.vhd synthesizable body
test_fixed.vhd tests for the above code

Analysis: [To be performed by the Working Group]
E-mail discussion on "vhdlsynth@vhdl.org" reflector
E-mail discussion on "vhdl-200x-ft@eda.org" reflector

There are two ways to implement this:
1. Modify the "signed" and "unsigned" types in 1076.3 to be "array (integer range <>)" instead of the current "array (natural range <>)" and use anything that is a negative index to be the part of the number less than zero. For positive indices the functionality will not change. (Problem, what to do with "signed (-3 to 3)"?).
2. Created a new type called "fixed" which will be a "array (integer range <>) of std_logic" that will be used for fixed point arithmetic. (signed or unsigned?)
Please tell me (David) what you think. Note that this discussion will parallel one on the Verilog 200x side.
Resolution: A new type needs to be created. Changing the type of "signed" and "unsigned" would cause funcitonal changes in how these types work and cause existing code problems.
Create two fixed point representations, one for "signed" and one for "unsigned".
Resolution: These will be called "sfixed" (signed fixed point) and "ufixed" (unsigned fixed point). Their behavior will be similar to that of the signed and unsigned arithmetic in numeric_std.
Allow for "little endian" representations of fixed point numbers.
Normally the fixed point representation will be "ufixed (7 downto -8)" however may people expressed the need for "ufixed (-8 to 7)" to be supported and to be treated as having the same direction as the downto example.
Resolution: Will be supported
Use a record type to store the fixed point number.
Resolution: Can't be done because arrays in records must have fixed lenghts.

Bit widths: The following bit widths will be the result of the following operations:

fixed + fixed := fixed (max(l'high,r'high) downto -(max(-l'low,-r'low)))
   8:-3 + 9:-2 := 9:-3
   numeric_std rule:  + and - = size of largest input strung
fixed - fixed := fixed (max(l'high,r'high) downto -(max(-l'low,-r'low)))
   8:-3 + 9:-2 := 9:-3
fixed * fixed := fixed (l'high+r'high downto l'low+r'low)
   8:-3 * 9:-2 := 17:-5
   numeric_std rule:  * = add the sizes together to create result
fixed / fixed := fixed (l'high downto l'low+r'low)
   8:-3 / 9:-2 := 8:-5
   numeric_std rule:  / = size of left operand.

Resolution: [To be determined by the Working Group]

Discussion moved to vhdl-200x-ft group when 1076.3 was included in the vhdl-200x-ft par
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;
```
Summary: How do we interpretation of bit string literals
Detail: Our argument is this:
```
variable a8r : ufixed (-1 to 7)     := "010011100";
```
How is the string interpreted? Are the lower bits "10" or "00"? Analysis: 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 57. 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 MSB. 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).
Resolution
- Assending ranges are not to be allowed.
- Research and see of the following resolution is possible within the vhdl-200x-ft time frame:
```
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.
Summary: 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). Resolution:
Expand the number
ufixed(a downto b) + ufixed(c downto d) = ufixed(max(a,c)+1 downto min(b,d))
use the resize funciton to make the a <= a+b case work

SummaryBit 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

Resolution: Accept the proposal

Summary 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.
Resolution: Only overload for "real" force all others to convert.

Back to the numeric package proposals
Please send feedback to David Bishop dbishop@vhdl.org