Re: [vhdl-200x-ft] Review of Fixed_Pkg

Jim Lewis wrote:

> Review of Package Declaration of fixed_pkg:
>
> Missing logic operators
> Without logic operators, basic operations like and-or
> readback type logic cannot be done without converting
> to std_logic_vector.
> With logic operators it makes fixed_pkg more consistent
> with Numeric_std.

I considered this when I wrote the package. There are some issues
with the negative index, but nothing I can't overcome.

My working idea for this was that you would convert to "std_logic_vector"
to do logical operations, then convert back.

I'll add them just for completeness.

> To_X01 is missing
> Need this function to be consistent with numeric_std/std_logic_1164

Will add, this needs to be there.

> Need constants:
> constant fixed_truncate: boolean := false; -- Round or truncate
> constant fixed_modulo: boolean := false-- saturate or wrap
>
> Complements the positive ones already defined:
> constant fixed_round : boolean := true; -- Round or truncate
> constant fixed_saturate : boolean := true -- saturate or wrap

Already added. The constants I put in are:
   constant fixed_round : BOOLEAN := true; -- Turn on rounding routine
   constant fixed_truncate : BOOLEAN := false; -- Turn off rounding routine
   constant fixed_saturate : BOOLEAN := true; -- Saturate large numbers
   constant fixed_wrap : BOOLEAN := false; -- Wrap large numbers

Note that the wrap is not a modulo (which is the way numeric_std does it).
You can wrap away a sign bit in fixed_pkg, and you can't do that in numeric_std.

> Should we use generics and create fixed_pkg_base?
> Round_Style
> EndPoint_Style
> GuardBits

In the standard operators, you don't need to worry about these. The sizing
rules take care of everything.
The only problem you have is the divide function. If you do now want
rounding or guard bits on the "/" operator, you can use the "divide" function
which has those inputs.

> Use of resize vs. to_ufixed?
> It seems like there would be less to remember if
> resize were named to_ufixed instead. That way all
> conversions that convert to a particular size of ufixed
> use the same function name independent of the argument.
>
> to_ufixed(ufixed, ... vs.
> resize(ufixed, ...

This was done to be to make the packages look more like numeric_std.
There is a "to_" function to convert between different formats, and a
"resize" function to convert the same type to a different size.

I could add a "to_ufixed(ufixed)" that would work the same way as the
"resize" then we would have both.

> For to_unsigned and to_signed, do we need to specify a rounding mode and
> saturate mode?
> Consider the ufixed value: "1111.111"
> -- unsigned fixed point to unsigned (truncates)
> function to_unsigned (
> arg : ufixed; -- fixed point input
> constant size : NATURAL) -- length of output
> return UNSIGNED;

Yes, these need to have rounding and saturate. Will add.

> For to_integer for ufixed and sfixed, do we need to specify a saturate
> mode?
> Consider the ufixed value: "1111.111"
> function to_integer (
> arg : ufixed; -- fixed point input
> constant round_style : BOOLEAN := fixed_round) -- rounding by default
> return NATURAL;

I thought about this one. I took the approach that C does when you convert
a "float" to a "double". If you convert "float" infinity to a "double"
infinity, you get a "double" which is 2**127, which is NOT infinity.

Thus in this case, you would get 16 (or 15 if rounding is turned off).
Remember, there are no rules about how to deal with infinity, or a saturated
number in fixed point. So, we give the nearest representable number.

> From unsigned to sfixed:
> to_sfixed(signed('0' & A_uv), ...) ;

I had these in there. You told me to get rid of them, remember Jim?

We will do the following:
to_sfixed (add_sign(unsigned))

> What is to_fix and to_ufix?
> It seems there should be one input format for
> the fraction width, it should either be a positive
> value (like to_fix and to_ufix) or it should be a
> negative index value (like to_sfixed and to_ufixed).

These were made for a 3rd party tool which already does fixed point.
They are there for compatibility reasons.

> Interesting boundry conditions that don't work well with either model:
> No fraction and lacking some of the right bits of the integer.
> for example: signal A : ufixed (7 downto 3) ;
> No integer portion and lacking some of the left bits of the fraction.
> for example: signal A : ufixed (-3 downto -7) ;

That is how the 3rd party tool works. I know it's wrong, they probably
know it's wrong at this point, but it's grandfathered in.

> To_fix is badly named:
> It would be more consistent if to_fix were to_sfix.

Those are the names of the functions in the 3rd party tool. I didn't
pick them.

> I will send the review of the package body separately.

Ok. I will make these changes.

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