[Icc-mot] 64 bits FP chip....

[Richard]

At 01:14 AM 5/16/2007, Edvardas wrote:


>>I am considering producing something like this:
>>
>>64 bits FP support will be provided by the new iFPLightning chip. 
>>The product is integrated fully into our compilers (initially AVR 
>>but later on supporting other ICC compilers as well). The 
>>approximate performance goals are
>
>
>What, already integrated?; do you support 64bit FP on 8bit AVRs and 
>only 32bit FP on 16bit HC12? :-(

I meant that the use of this chip will be transparent to ICC users. 
They click on a checkbox, and the compiler will generate the right 
library code, which will be supplied by us. All you have to do is to 
hook up the chip to your system using the SPI bus.

Currently, only 32-bit FP is supported on all our compilers.


>>1 uSec for 32 bit FP MUL
>>1.5 uSec for DIV
>>and ~2X for 64 bits.
>
>Could you shed some more light on this?
>1) First of all are these */+- fully standard compliant (sorry, but 
>I little doubt it)? Does it pass compliancy tests?

Yes, the are IEEE compliant. We will be sure to run the torture tests etc.

>2) Having hardware mul and div, FP add can be the slowest OP. How 
>long does it take to SUB something like 1.00001 - 1.00002 (close to 
>the worst single precision case)?

FP add should not be slower than FPadd.

>3) 64 bits only 2X slower? What are internal data paths then, 64bits?

It's based on a 70Mhz ARM7TDMI


>>This is at least 15x-20X faster than the equivalent AVR code and of 
>>course free up code space on the AVR chip.
>>
>>The data transfer overheard is ~10 uSec to transfer two operands and
>
>Is it SPI/IIC/something else?

SPI. I2C is too slow?

>>a result. Complex expressions will use the intermediate results 
>>directly without data transfer. The API uses a stack architecture 
>>so interrupt can remain enabled except during the data transfer.
>>
>>The iFPLightning chip comes in a 16 or 18 pin DIP module, ~0.7" x 
>>0.6" in size.
>>
>>The following pricing is very tentative, but is our best guess:
>>
>>1-50            $30
>>100             $27
>>500             $25
>>1000            $22
>>
>>It is highly likely that the chip will provide full high level math 
>>support such as sin/cos/etc. We are also open to other API such as DSP etc.
>
>Since data transfer takes quite a lot, I think you shouldn't release 
>it without most popular sin/cos/etc.
>
>>
>>What do you think?
>
>64bits doubles are of course welcome.
>
>Edward

// richard (This email is for mailing lists. To reach me directly, 
please use richard at imagecraft.com)