Hardware floating point?

s

I've done it in a Xilinx, and it's not fast. First you have to go across t he routing fabric and go through a set of LUTs to get onto the carry chain. The carry chain is pretty fast; getting on and off the carry chain is slo w. After you get off the carry chain, you have to go through the general r outing fabric again. This is where most of your clock cycle gets eaten up. Remember, if you had dedicated hardware, this would be a dedicated route. Now you get into a second set of LUTs, where you have to AND the data fro m the carry chain with the original number in order to get a one-hot bus wi th only the leading 1 set. Now you have to encode that into a number which you can use for your shifter. You may be able to do this with the same se t of LUTs; I can't remember.

Reply to
Kevin Neilson
Loading thread data ...

What Xilinx part?

The Altera Stratus 10 (I think that's the one) uses paired DSP blocks that are designed with a bit of extra logic so that you can use the pair of them as a floating-point block, or each one as a fixed-point block. (I'm not using their terminology).

Apparently there's enough stuff going on at the really high end that floating point is better.

--
Tim Wescott 
Control systems, embedded software and circuit design 
 Click to see the full signature
Reply to
Tim Wescott

c.

Yeah, you're right.

Reply to
Benjamin Couillard

The comparison is using a carry chain vs. not using a carry chain. First 1 in LUTs is either log2(N) in depth and linear in size or log2(N) in size and linear in depth (speed). Using general routing and LUTs this is very slow. Using a fast carry uses a LUT to enter the carry chain and a LUT to exit the carry chain. The carry chain is a fraction of a nanosecond per bit.

--

Rick C
Reply to
rickman

I'm not sure what "high end" means. Floating point has some advantages and it has some disadvantages. Fixed point is the same. Neither is perfect for all uses or even *any* uses actually. You always need to analyze the problem you are solving and consider the sources of computational errors. They are different but always potentially present with either approach.

--

Rick C
Reply to
rickman

Yes, you are correct.

I tend to mostly work with stuff that comes out of an ADC, goes through some processing (usually for me it's a processor and not an FPGA, but it's still DSP), and then goes out a DAC. In that case, fixed-point processing for the signal itself is usually the way to go because the ADC and DAC between them pretty much set the ranges, which means that floating point is just a waste of silicon.

HOWEVER: that's just what I mostly run into. I'm currently working on a project where, by its nature, the sensible numerical format is double- precision floating point (not FPGA -- it's _slow_ data reception on a PC- class processor, where double-precision floating point is almost as fast as integer math unless you use the DSP extensions).

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.