Re: [vhdl-200x-ft] Questions/Remarks concerning fixed_pkg

yannick.grugni@philips.com wrote:

> 
> Hi David,
> 
> I have some questions/remarks concerning your fixed_pkg.
> 
> 1)  In the following function :
> /  function to_sfixed (
>    arg                     : REAL;     -- real
>    constant left_index     : INTEGER;  -- size of integer portion
>    constant right_index    : INTEGER;  -- size of fraction
>    constant guard_bits     : NATURAL := fixed_guard_bits;  -- # of guard 
> bits
>    constant round_style    : BOOLEAN := fixed_round;  -- turn on 
> rounding by default
>    constant overflow_style : BOOLEAN := fixed_saturate)  -- saturate by 
> default/
> could you confirm that  the following line is correct ?
> /    if fixed_guard_bits > 0 and round_style then/
> Is it not 'guard_bits' instead of 'fixed_guard_bits' :
> /          //if guard_bits > 0 and round_style then/

Yup, bug.  Fixed.

> 2)  Same question than above but for the function to_ufixed.

Same.

> 3) Would it  be  possible to add to this package the following functions :
> /SHIFT_RIGHT (ARG : sfixed; COUNT : NATURAL)/
> /SHIFT_RIGHT (ARG : ufixed; COUNT : NATURAL)/
> /SHIFT_LEFT  (ARG : ufixed; COUNT : NATURAL)/
> /SHIFT_LEFT  (ARG : sfixed; COUNT : NATURAL)/
> /FIND_LSB, FIND_MSB/
> For signed and unsigned, I use them more often than the operator 
> sll,srl,sla,sra. And a code using SHIFT_LEFT,SHIFT_RIGHT is also more 
> clear to read back.

Good question for the group.  The vhdl-93 LRM introduced "sll and srl", etc.
However, mathmatically the definitions for "sla" and "sra" were wrong, as
it would replicate the LSB.

When I wrote these for signed and unsigned I fixed this behavior.  They
now only replicate the MSB.  (both of them can shift left or right).  Thus:
SHIFT_RIGHT(sfixed, 5); = sfixed sra 5   or   sfixed sla -5

Should we continue to support the old "SHIFT_RIGHT" syntax, or the new
operator?

> 4)Do you have any plan to create fixed_math_pkg with the same functions 
> than in the math_real_pkg like SQRT,LOG,SIN,COS

You are thinking ahead!  Next release (after fast track) these could
come along.  The problem is that these wind up being taylor series, which
means lots of loops.

> 5)3 years ago, I had myself created more or less the same pkg in the 
> goal to use it in my project. I had or still have some problems with 
> synthesize tools.
> May be you or somebody else will have similar problems.

In my test with one tool, the only thing that I have hit is that it can't
deal with a "mod".  The rest of it works great.

> 5.a) The first problem concerns negative index. A negative index in vhdl 
> will stay a negative index in verilog after synthesis. The problem is 
> that some backend tools doesn't like netlist containing negative index.

Think you got an answer for this one.

> 5.b) The second problem concerns the support of constants of type reals 
> by the synthesize tools.
>    being able to write directly :
> /        B <= A+1.375;/
>    is much more nice and simple than writing :
> /        CONSTANT onepoint375 : sfixed(1 downto -3) := "01011"; /
> /        B <= A+onepoint375;/
> /  /For the moment only Synplify_pro & Synplify_asic from symplicity are 
> able to understand (/B <= A+1.375;/)

In my test case I have:
           if (in1reg3 = 3.1415) then
and
           if (in1reg3 = in2reg3 + 3.1415) then
Which synthesize it just fine.

>   In a near futur (march/april), RTL compiler (also known as Get2Chip) 
> from cadence will be able to understand it.

Keep me updated with them.

>   Synopsys, for the moment doesn't support it, I have introduced a 
> request to them but it would be nice that other people do the same to 
> have more weigths.

Yes they do.  Hit the following switch:
hdlin_enable_presto_for_vhdl = true

>   Concerning the others synthesis tools like Leonardo Spectrum or Magma 
> Blast, I don't have access to them. SO It would be nice that the ones 
> who have access to it, test it and introduce a request if it's not yet 
> supported.

I've tried Leo.  Magma I have not tried yet.

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