Low Cost Hardware Flaoting Point processor? whats available

Take a look at

They have a couple FP chips IIRC, all with SPI interfaces. I think they're pretty expensive though so you might have better luck with something like a cheap DSP like a DSPic from Microchip.

Chris

I don't think anyone makes FPUs any more. If you can't do the FP fast enough on the Rabbit, using an ARM is probably the way to go. The Philips LPC2000 chips are very cheap - you could either use one as an FPU or redesign the whole system. Of course, that depends on whether the software FP on the ARM is fast enough for you, otherwise you'll have to use a device with hardware FP.

Leon

The Real Andy wrote in news: snipped-for-privacy@4ax.com:

A PIC coprocessor?

I need to find a low cost FPU to interface to a Rabbit 2000 processor. Having done no embedded hardware design in the last 3-4 years I have found myself already drifing away from current trends.

As for the exact precision, no sure at this stage. Still investigating and open on this one. I prefer to avoid DSP's if at all possible and need something that will interface to an 8 bit wide General IO port on the rabbit, so bitbashing serial would also be fine.

All i can find on google is ARM's and DSP's, which are a bit of an overkill. If it comes to this a complete redisgn will be done, which I would dearly love to avoid.

Suggestions?

Andy

Looks like it might have to be double precision too.

Have a look at

Wim

How fast does it have to be?

The Rabbit could be programmed with a FP library to do it slowly.

You can use a FPGA to do it.

You can connect a few more processors to the main one.

Someone I work with put a 1/(1+X) table into a PROM to get the speed he needed on a calculation where X was a small value.

If you can stand the speed of serial transfers, the math can go on serially in the FPU. This could make it fit into a smallish CPLD.

OK, I don't even know what the above means. But if the number of math operations (multiplies, divides) is only a few dozen and the system is "interactive" (user pressing buttons, gets a display within a fraction of a second) then there's no problem doing software floating-point on the Rabbit.

Tim.

IIRC, the Rabbit is not particularly fast. If the speed is marginal, then a cheap 32-bit processor such as the ARM would surely be fast enough. You can likely just use a C compiler that supports the precision you need.

Do you have a numerical estimate of the number of floating point operations required per second (and the mix, as multiply generally is faster than divide, sometimes a lot faster). For control applications I try to massage the algorithm into a form that minimizes the number of divides in favor of multiplies. But maybe, as Tim says, it doesn't matter much in your case.

Best regards, Spehro Pefhany

If this is just a slot machine, isn't the payout a lookup function?

Somewhere the actuaries figured out what the payout was on each, right?

Obviously I don't spend enough time in Vegas :-)

Tim.

In doing so they probably used factorials... is that why you say you need double precision, you want to reproduce these combinatorics?

If so it's vastly more efficient to write "m choose n" (which is usually a smallish manageable number) than to do the ratio of factorials (each of which may well overflow a IEEE double!)

Tim.

Well, I feel like I need to insert a comment here. "Double Precision" doesn't necessarily require "Floating Point." Depending on the range in question, it might be possible to scale everything and do integer arithmetic. I've seen some pretty sophisticated digital filters done in integers.

Of course, I'd feel a lot more comfortable giving "advice" if I had some clue just what "jackpot win points" are. And I've been terrified of "statistics" for a very long time. :-)

Good Luck! Rich

In article , Spehro Pefhany wrote: [...]

It is very common in DSP like situations to find 1/X and multiply because it can be coded to be much faster than a divide.

For numbers very near 1, (2-X) = 1/X

If A, B, C, and D are numbers in the form of 1.??, 1.0??, 1.00?? the multiplies needed to bring the denomination near enough to 1.0 can be done as byte or word operations instead of having to work with the full number of bits in the mantissa.

On an 8051, a 64 bit 1/X calculation can be done in a 1mS or so, so I doubt that an external FPU is really needed for a slot machine.

We are doing some fairly computational heavy statistical calculations for creating jackpot win points. The math (apparently) requires double precision, or so the author of the algorithm tells me. I am taking this on face value, as I am yet to have a real good look at it.

In the mean time, we are waiting for regulatory approval to do the win point calculation on a PC and pass it down to the rabbit. The plan is to calculate many win points and have the rabbit do a random selection on one of them. If we can get away with this, then the we can avoid the whole math-coprocessor thing.

Maybe the library you're using to get a random number distributed according to a geometric distribution needs double precision floating point, but there are several trivial ways of doing it with only integers, all very efficiently.

Tim.

Only if a court decides so. How much money you got?

Not C, but VHDL...

PIC assembler...

Can you extract what you want from an C library for Atmel AVR?

Matt Roberds

Isn't the rabbits instruction set basically the same as the Z80's?

If so, I know there must be a package out there. The Synclair ZX81 computer's basic used a floating point library. Somewhere around here, I have a disassembled listing of the 8K basic. I remember that there was a hunk of it that was obviously in a different style and was linked in as one solid block. It was obvious that it was a FP library.

Doesn't the patent fall to 'prior art'?