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

Dave, et al,

There are typos and/or errors, plus additional comments.

-Steve

> -----Original Message-----
>
> 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.

I assume Dave meant 57 at the end of the 2nd sentence of Alternatives.

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

The left most bit is the *MSB* not the LSB according to 1076.3-1997. Since a change in what is MSB/LSB would not be backward compatible, I assume this was a typo on Dave's part.

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

I continue to believe the root of all evil is that the encoding of the value representation is visible to all. But, I do understand that VHDL is currently limited in its ability to hide this information and Dave wants the package to be synthesizable without requiring synthesis tools to be modified.

However, if we must endure a visible bit-vector representation, then:

The bit string literal is assigned as it is in any case in VHDL: From left to right with no interpretation of the value represented by the bit-string literal. This is the core of my original point to Dave: Numeric_Std DOES NOT force an interpretation on the bit-string literal! Numeric_Std does state the assumption that 'left is the MSB. But, this interpretation is on the SIGNED and UNSIGNED data types and not on bit-string literals. The fact that we typically write and read bit string literals with an implicit interpretation of the MSB as the left most bit is simply a validation that the choice Numeric_Std took was the right one for most cases.

If users meant some other interpretation of the bit string literal in the assignment, then the burden is on them to arrange the bit pattern to match the left to right position with the corresponding position of the fixed point object. After all, if you are accustomed to seeing fixed point data represented as: (-1 to 7) with the first bit being the fraction and the right most 8 bits being the integer, then an interpretation of the string literal "010011100" as anything but the value 57.0 would seem to be really odd as that does not fit your chosen encoding.

We could extend VHDL to allow a binary, octal or hex point within a bit string literal with a corresponding interpretation that the bits to the right of the point are the fraction and assigned to corresponding negative index bit positions in the target, etc. I don't think we want to go there with VHDL as it codifies in the language the value encoding within a bit-vector of fixed (and perhaps real) values. At least, I'm not ready to go there.

Besides, any change in the semantics of how bit-string literals are assigned to vectors or addition of a point in the bit-string would require a change to the implementation of synthesis tools to support the new package. This violates a stated goal.

BTW, you can always define a SET procedure that does an assignment in a way other than left-to-right bit copy to match whatever interpretation you think people might believe they are specifying with a bit-string literal assignment to an ascending range u/sfixed type object.

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

(Before spending much time on this question, see the next point starting with "NOTE:" below.)
Please define the range (bounds and direction) of the result for the following operations:

  ufixed(a downto -b) + ufixed(-c to d)
  ufixed(-e to f) + ufixed(g downto -h)

> 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

NOTE: There is a fundamental, underlying assumption at work here: The left hand argument has both the max('high) and min('low) or broadest range of the two arguments. Otherwise, the assignment will NEVER succeed!

This is a facet of a much broader issue: The operators have no information on how the result will be used. Therefore, I don't think the operators can be used in this situation. I think procedure calls will need to be defined where the procedure can check the range of the result (actual associated with the result parameter) and encode and resize the result value accordingly. No separate set of overflow vs. non-overflow operators would be needed as the result would be automatically resized.

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

I like this recommendation. However, I want the operators added to the language in general and defined for Numeric_Bit and Numeric_Std as well as range constrained integer types. As noted above, I'm not sure they can be properly implemented for s/ufixed usage.

> --
> 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:26:40 2004