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

Bailey, Stephen wrote:
> 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.

Sorry, I was assuming that people were up to date on all of the arguments.

I will reformat on a seperate e-mail.

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

I'm not sure why this one doesn't work. I plan to carefully review my
math on Monday and figure it out. It is most likely due to the way I am
converting the number into an UNSIGNED and converting it back.
This is not one of the topics for discussion, I am simply showing that
the negative indecies are mostly working at this point.

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

Notice the proposals for "unsigned" and "signed" literals in this
proposal. Here a bit ordering is implied here.

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

Our discussion has been on the various nits of the fixed point packages.
Remember that these packages have been under development for the past
2 years.

> (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
> idea lly want for this case. But we now have the flexibility to do that --
> define a new type. We didn't when 1076.3 was outside of VHDL.)

True. Within the original scope of 1076.3 we were not able to add
anything to the language. At this point it would be a bit late to change
things.

These packages were also written so that they would synthesize as is,
without any modification to the language or the synthesis tools.

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

If you do the following:
ufixed (10 downto 5) + ufixed (-3 downto -8) then this is what you
have requested.

These were discusses, under 1076.3 almost 2 years ago.

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

I will put this in a sepeate e-mail.

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