Re: [myhdl-list] Floating Point Libraries

[Jan D. <ja...@ja...>]

On 04/14/2011 07:00 PM, Tom Dillon wrote:
> some comments below:
>
> On 04/14/2011 08:32 AM, Christopher Felton wrote:
>>
>> At the risk of embarrassing myself but to keep this thread going I
>> will start a FP interface based on Jan D and Tom D. suggestions.
>> Something like the following could be a start to an interface
>> definition.
>>
>> class FloatingPoint(object):
>>
>> def __init__(self): pass
>>
>> def Add(self, clk, reset, a_sign, a_mant, a_exp, dva, b_sign,
>> b_mant, b_exp, dvb, r_sign, r_mant, r_exp, dvr, EXP_W=8,
>> MAN_W=23): pass
>>
>> def Mul(self, clk, reset, a_sign, a_mant, a_exp, dva, b_sign,
>> b_mant, b_exp, dvb, r_sign, r_mant, r_exp, dvr, EXP_W=8,
>> MAN_W=23): pass
>>
>> def Div(self, clk, reset, a_sign, a_mant, a_exp, dva, b_sign,
>> b_mant, b_exp, dvb, r_sign, r_mant, r_exp, dvr, EXP_W=8,
>> MAN_W=23): pass
>>
> I would recommend the class be the MyHDL representation of the number
> itself.
>
> I don't think there is any real benefit to the operators being in the
> class as they will just be called like function calls returning the
> MyHDL instances.
>
> So I see it as something like this:
>
> class fp(object) : __slots__ = ['sign', 'exp', 'man', '_expW',
> '_manW'] def __init__(self,initNum=0.0,expW=8,manW=23) : self._expW =
> expW self._manW = manW self.setvalue(initNum)
>
> Note the fp object would keep all information about the structure and
> widths.
>
> Then a Add module would look like this:
>
> def FpAdd(x,a,b,clk=None,reset=None,pipes=0) :
>
> x,a, and b being the required ports of type fp (could expand to other
> types (fixed point). Option ports and parameters follow. You will end
> up with more parameters before you are done.
>
> In floating point, something like an Add will have to have the option
> for pipelines to be very useful. You may also want options for
> multi-cycle operation to optimize the logic when they don't need to
> run at the full clock rate.
>
> The operators don't need to know the width of the operands. That will
> be determined by the i/o ports. You may want to allow mixed widths.
>
> You will like passing only the objects and not the sign, man and exp
> separately. You may also decide that you don't store the sign
> internally if that turned out to be more efficient. Keeping the sign
> in the mantissa.
>
> Now when this is done it will be cleaner to use but will present a
> problem with you get to conversion as the you won't be able to have
> an fp object in the ports list at the top level. That is where you
> will need a wrapper that breaks out and attaches the elements inside
> fp.
>
> I think that is much easier than having three times the ports for all
> module connections. You also increase your cross wiring chances.
>
> You can add a lot to the fp class that will make your life easier as
> well.

That is how I was thinking. I just don't know how
easy/feasible it will be to support such a class in conversion.
I recommend to experiment with such a class extensively
in modeling first, to see what we really want.

My workaround proposal was intended for those who want to
get started today, including conversion support.
To be honest, usage can hardly be worse than using
ip libraries such as altera. Thinking futher about it,
I'm not even sure the altera ip is about efficiency -
it may just be about obfuscation and vendor lock-in.

In other words, if floating point ip is hot, there
may be an opportunity here for someone who would like
to develop a technology-independent MyHDL libary.

For clarity: it is not my intention to include design IP
libaries ever in MyHDL itself. Those should be different
(potentially competing) libraries, with an appropriate
license, as decided by the project.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     Analog design automation: http://www.mephisto-da.com
     World-class digital design: http://www.easics.com