Re: [myhdl-list] FW: Floating-point support

[Jan C. <jan...@mu...>]

On 09/03/11 14:14, Christopher Felton wrote:

> You lost me a little, I think you might have mispoken.  You stated
> "request that interest me ... provision of synthesizable modules to perform
> basic FP ..."
> but then later said
> "... automatically string these modules together based on a higher level
> description is probably beyond my interest..."
>
> These are conflicting statements?  I am not sure what you are looking for
> but lets take an example, a simple floating-point expression in MyHDL

Sorry that my cautiousness to reply and provide explanation has 
cost you so much writing. Your 3 cents is much appreciated, but I 
only have a 1 cent answer.

Your design sketch would be appropriate where maximum processing 
rate is required, otherwise it would not be ideal.  Implementation 
efficiency can be increased by using a serial data format, and 
abandoning the IEEE float representation formats.

There is a clear processing speed penalty here.  There are also 
less obvious benefits: The chip area used is reduced by a greater 
proportion than the loss in performance.  When using streamed data 
with many values close to zero the number of bits pulled from 
memory is reduced by a large factor.

Because the proposed data representation is not IEEE compliant, any 
modelling requiring equivalent methods must use a suitable 
equivalent data type in python.  Two unconstrained integers may  be 
used to represent an unconstrained float.

For modelling purposes unconstrained integers can be represented in 
python as a list of packets of bits. This can be synthesized as a 
stream of packets of bits.  I now have tested models of an adder, 
multiplier, and barrel shifter, so with this, and a little extra 
sequencing glue I am ready to start testing python models of FP 
adder and multiplier.

The data representation and methods used are suitable for 
synthesis, and I do not expect further problems ,apart from having 
to learn to use MyHDL effectively.


> fp_in  = Signal(0.0)
> fp_out = Signal(0.0)
>
> def fp_expr1(clk, fp_in, fp_out):
>      a = Signal(0.125)
>      b = Signal(0.00344)
>      c = Signal(0.01)
>
>     @always (clk.posedge)
>     def rtl_fp():
>         fp_out.next = a*fp_in**2 + b*fp_in + c
>
>     return rtl_fp

Ok, so I need two adders for the final sum, one multiplier for the 
square, one constant multiplier for the *0.344, and a barrel 
shifters for the *0.125

My diagram would be much the same as yours, but I would want a 
separate component for multiplication by a constant to allow 
suitable optimisation.

Surplus logic in the barrel shifter would be optimised away because 
the shift value is a constant. Because power of two removal would 
be part of a constant multiplier this would be a better component 
choice than the barrel shifter.

The proposed system might require twice the number of clock cycles 
to process the signal, but would likely consume 50-90% less chip 
area.  The number of clock cycles is also dependant on required 
signal resolution, and the chosen signal buss width.  Therefore, if 
more clock cycles are available, these can be traded for further 
chip area reductions.

<snipped sim, synth, diagram, MyHDL code & dire warnings>

> Good luck, hope you guys are enthusiastic about this project and make some
> great progress!  Any questions please post to the group.
>
> my 3 cents
Thanks Chris, very much appreciated.  I could never have imagined 
just how much excitement I am planning to miss out on.

BTW, another interesting feature of unbounded floats is that they 
can declare their own resolution.

Jan Coombs
--