Re: [myhdl-list] Floating Point Libraries

[Tom D. <td...@di...>]

On 04/15/2011 02:56 AM, Jan Decaluwe wrote:
> 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.

I have done similar for complex fixed point numbers and it works fine. 
Just have to unwrap the objects for top level I/O.

Even though the signals and logic are in a class, does not keep the 
generator from resolving it. As long as you used class methods to 
instantiate your logic.

Some thing like:

x = a * b

Will not work for the generator if x,a, or b or an object from your 
floating point class.

Instead

U0 = fp.mult(x,a,b)
return U0

will work fine as by the top fp.mult is flattened all references to the 
fp class are gone, since at the lowest level all the operations are 
using types that MyHDL can convert.

> 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.
>
I would recommend starting simple, then adding features. Good unittests 
and behavioral (not convertible, more like a model) code first. There 
are a lot of nuances to the operators to make all cases work.

Then as users have applications for different types of operators, they 
could be built, tested, then added to the common IP.
> 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.

I am not sure how hot they would be. They would be useful for anyone 
developing with MyHDL and needing them and might attract some folks to 
MyHDL if they were available.

It will take some work to make them as efficient as the proprietary 
vendor (Xilinx, Altera) libraries.

Floating point operators are fairly expensive logic wise, which keeps 
most DSP logic using fixed point numbers. In FPGA systems, you get some 
transplants with DSP processor experience who absolutely think they need 
floating point. It is much simpler for them if you can deliver a system 
that will just match the accuracy they had using a floating point 
processor.

Python has very strong math/science modeling capability with 
Numeric/Numpy package. The combination of Numpy for the system guys and 
MyHDL with floating point logic development would be attractive.


> 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.

That is one of the strong points for MyHDL and python, it is very simple 
to include other packages (IP libraries). Just get the package in your 
PYTHONPATH and import.

In time you would want some common structure to the IP delivery, like 
documentation, delivery/install and interfaces just to make it simpler 
to bring in IP and use it.