Re: [vhdl-200x-ft] Bit Rules & methodology for handling math issu es

Ryan,
> I do know that casting is not necessary if mixed
> operators are defined.
I like requiring type conversion for mixed operations,
however, I could be convinced that mixed operators
are ok if there is a hardware savings by using them.
I don't believe your example below is correct see
my notes following it.

> Converting ufixed to sfixed may also result in overly
> conservative result sizes. For example,
>
> signal a : UFIXED(0 downto -9);
> signal delta : SFIXED(-3 downto -9);
> signal result1 : SFIXED(1 downto -9);
> signal result2 : SFIXED(2 downto -9);
>
> result1 <= a + delta;
> result2 <= TO_SFIXED(a) + delta;
>
> since TO_SFIXED() adds a '0' on the top of a UFIXED. The conversion
> function is loses information: the mixed operator knows a to be in the range
> [0, 2), while the matched operator must assume TO_SFIXED(a) can be in the
> range [-2, 2).

I think result1 must also be SFIXED(2 downto -9).
If both A and delta are their largest positive value,
an additional bit will be required to represent the
magnitude of their sum. Then an additional bit is
required to represent the sign. Hence 2 downto -9.

How would you handle the case?
    signal A : UFIXED(0 downto -9);
    signal B : UFIXED(0 downto -9);
    signal Result1 : SFIXED(1 downto -9);
    signal Result2 : SFIXED(2 downto -9);

    Result1 <= A - B ;
    Result2 <= to_sfixed(A) - to_sfixed(B) ;

    Would you want to take advantage of this?

How would you handle the case?
    signal A : ufixed( 3 downto -2) ;
    signal Fract : ufixed(-4 downto -9) ;
    signal result : ufixed( 4 downto -9) ;

    result <= A + Fract ;

Should it be 4 downto -9 (general case) or
3 downto -9 (special case when non-overlapping bits)?
Note the special case would be harder to apply with
subtraction and sfixed.

> I really want mixed arithmetic for the multiply operator.
> That is the only place I am using mixed arithmetic in
> current designs.
Any sizing advantage here?

> The fixed point operators have enough information to properly calculate
> and (usually) properly size the result for matched and mixed arithmetic.
Agreed, but because you can doesn't mean you should.

> I can't think of a reason for it to be bad design.
Requiring type conversion:
   1) It documents that the types are not the same
       and that the mixing of them was intentional.
       Otherwise, you must review the declarations.
       It is similar to documenting the size of the result with resize.

   2) When no type conversion is present, it documents
       that the types are the same.

Cheers,
Jim

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training             mailto:Jim@SynthWorks.com
SynthWorks Design Inc.           http://www.SynthWorks.com
1-503-590-4787
Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~