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

Dave,

Maybe I've been in marketing too long, but I have a very difficult time forming a position. I believe the problem I'm having is knowing (for all cases):

1. What the issue (or requirement) is.
2. What are the alternatives.
3. What are the pros and cons of each alternative.
4. What is the recommendation (which should be consistent with maximizing the pros from the set of alternatives while addressing the issue/requirement).

Without this information, I have no way of making an informed decision. I'm concerned that others will have the same problem.

More for each item below.

> -----Original Message-----
>
> Currently ufixed (5 dt 2) := ufixed (-1 dt -5) / ufixed(-1 dt
> -5); doesn't work, but all other operations (including a
> normal divide with a range like (5 dt -1)) does work.

Why doesn't it work? In other words, what is the issue? This is only a concrete example of the problem. Without knowing the issue, am I expected to take your word that this is the only corner case that won't work correctly?

There's been a lot of discussion on the reflector about negative bounds. Is this issue related to that discussion? If not (or if it is only partially related), then why isn't there any documentation about the issues/requirements for negative bounds, pros and cons, etc.?

> Our agenda will be:
> 1) To vs downto interpretation of bit string literals
> (reference FT09)
> http://www.eda-twiki.org/vhdl-200x/vhdl-200x-ft/proposals/ft09_bit_s <http://www.eda-twiki.org/vhdl-200x/vhdl-200x-ft/proposals/ft09_bit_s>
tring_literal.txt

What? There is no TO vs DOWNTO interpretation of bit string literals. It is simply left to right. The range (as well as full subtype) information comes from the context that the bit string literal is used in.

  Signal Bv : bit_vector(6 downto 0);
  signal slv : std_logic_vector(1 to 7);

  bv <= 7X"8F";
  slv <= 7X"8F"

In the above, both bv and slv have the value "0001111". BV's range is descending and SLV's range is ascending. Neither low nor high (or left or right) bounds of the vector ranges are the same, but the value is (based on position of the bits in the vector).

> Our argument is this:
> variable a8r : ufixed (-1 to 7) := "010011100";
> Is the result interpreted as 57 or 78?
> 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.

Interesting, when I put "010011100" into Windows calculator and then convert it to decimal, I get 156 which is neither of the above interpretations. It seems to me that you are using the negative portion of the range as the fractional part and then assuming that 7 is the MSB. That would explain the value 57. You get 78 if you apply the same interpretation but with bit position 0 in the range being the MSB. This points out that you haven't documented step 1: How you are modeling fixed point types in VHDL. This is basic and unless everyone understands this, you can forget about advancing to other issues. (BTW, consistency with the rest of VHDL and the various packages is that 'left is the MSB.)

If we are to review the fixed point package/types/operations, you must start at square 1 and not jump into the middle somewhere.

(Why not model fixed point types at a higher level? Hide the implementation details from the user -- they don't need to know that negative ranges are used to represent the fractional part. But, provide a complete set of routines so that they can:

1. Specify the range and precision.
2. Get bit-level access and manipulation.
3. Have a full-set of arithmetic operations on data of fixed point type.

Instead of using a negative ranges to access the fractional part, they would simply get bit n or bits n through m of the fractional part. Let synthesis tools figure out how to implement it. If this was done, it would eliminate the problems with negative bounds and ascending vs. descending ranges. Those details are abstracted away from the design process. Which actually brings up an interesting question, how often would a designer need to do bit-level manipulation of the fixed point data if you provide a full set of arithmetic operations? I don't get the purpose of using a high-level language to do assembly-equivalent programming. It also seems to me that all of the problems revolve around the fact that the details of the implementation of the type are completely exposed to users -- a user can define an ascending range when we only want descending, for example. We could define ufixed as a new type in VHDL as VHDL doesn't have the detail hiding capabilities we would ideally want for this case. But we n
ow have the flexibility to do that -- define a new type. We didn't when 1076.3 was outside of VHDL.)

> 2) Bit sizing rules (part 1):
> Currently our bit sizing rules follow those of numeric_std
> unsigned (a downto 0) + unsigned (b downto 0) = unsigned
> (max(a,b) downto 0); 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))
> But we do this, then "a <= a + b;" won't work.
> An option on the last one.
> If we leave the bit sizing rules for +, - alone, then we can
> create the following operators "|+" and "|-"

Again, you need to state the issue/requirement. In this case, it would seem to be the need to specify operators that can overflow (presumption being that the target will have sufficient bits to hold the result) or it won't overflow. This issue is larger than fixed/floating point operations. Therefore, it should be addressed generally.

As a comment on the details, I don't think you want the result defined in terms of min and max of the operands' ranges. Instead, I think you want them defined in terms of the lengths of the operands (number of bits). Integer math requires 1 more bit than the largest operand and multiplication requires lengthA + lengthB bits for the result (the lengths of the operands). If A is (10 downto 5) and B is (-3 downto -8), then with your algorithm, you would get a result with range of (10 downto -8). Wouldn't that be excessive? Perhaps this relates back to the fundamental choices which are assumed throughout but never discussed. If so, then that highlights another shortcoming of the documentation/analysis of this work. The result's range should be defined consistently with VHDL. Any deviation from that must be documented as to why that won't do (again, the issue or requirement central to the return result subtype).

> 3) Bit sizing rules (part 2):
> a) For a multiply in numeric_std:
> 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) 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)
>
> b) for a divide:
> -- divide returns odd combination of widths
> 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.
>
> 4) Overloading
> Already included: ufixed + integer, ufixed + real, sfixed +
> integer, sfixed + real
> a) ufixed := ufixed + unsigned vs ufixed := ufixed +
> to_ufixed (unsigned,x,x)

What are the pros and cons to the two approaches?

> sfixed := sfixed + signed
> If we do this, then "ufixed := ufixed + "010011100" won't work.

I assume this is somehow related to the above discussion, but the connection needs to be made explicit.

> b) sfixed := ufixed - ufixed;
> c) sfixed := sfixed + ufixed; (- * /)
> d) sfixed := ufixed + signed; (- * /) (once a signed number
> is involved the result would be "sfixed")

In general, I have no clue what the overloading section is covering. Are these choices? Are there issues? Does it just work as anyone would expect and included here for completeness?
 
> NAME: David W. Bishop INTERNET: dbishop@vhdl.org
>
>
Received on Sun Jul 11 11:21:19 2004