fpga single versus fixed point

[erfigge]

I have read several papers ect on the new "single floating point" in the FPGA versus fixed point.  My basic understanding is the single floating point is simpler and easier to implement but at a cost of space and/or speed on the FPGA.  Also, where timing is a concern you don't want to use the single floating point. 

I have tried to optimize my fpga code to the best of my ability by taking out divisions, delaying things that don't need to run fast ect.  But the fundimental question for me remains, which would be the best fpga variable type for my project?

I have attached my fpga vi's.  The 9612 fpga.vi is the top level vi.  It has three loops.  The top loop is almost directly off examples for getting a vibration signal.  The second loop down is a loop that is looking at a digital input and setting triggers to calculate a frequency with that output being passed through a gain equation.  The third and fourth loops are slow loops just to pass a couple of indicator through.  And the fifth loop takes a bunch of values and runs them through a gain equation as fast as possible. 

The tach (second) loop and the I/O (fifth) loop are my main questions.  What are the opinions, would I be better served with the single floating versus fixed point? 

I will probably get 10 reply's that my fpga code suck all the way around. 

[nathand]

In a quick glance, I don't see anything immediately wrong with your FPGA VI, but I didn't go through it thoroughly. The most important questions are: does it compile, and if it does compile, does it work? If it compiles and works, then it's a question of what data format is easier for you to use in the host application, and possibly a question of precision and optimization. Are there cases that you're concerned about losing precision? For values that are read from an analog input, or written to an analog output, there's no need to use a value with any more precision than the IO, so a floating point isn't necessary if you're careful about how you scale that value. For values that are handled entirely within the FPGA, and where the magnitude of all values used in the computation is constant, I would use fixed-point because it will be more efficient.

Floating point is useful if you don't know the magnitude of the number ahead of time and can't pick an appropriate fixed-point representation. It is also helpful for passing values to the host, since the host has a processor that can do floating-point calculations efficiently. Of course you can convert from fixed to floating point on the host, but it may be slower than doing the same conversion on the FPGA. That said, if you're not reading data too fast, the difference in speed is irrelevant.

If it all works and the speed and results are satisfactory, then there's no reason change numeric representations. The reasons to switch would be either that you need to save some space on the FPGA by avoiding floating point values, or you have plenty of excess FPGA space and want to make the host code simpler by using floating-point numbers.

[JLewis]

nathand stated the case very well. I notice that your fixed point code is using a lot of 64-bit paths, so it is going to be VERY expensive and slow--have you compiled it yet? There is nothing in your design that would preclude the use of fixed point data types, but it takes some attention to choose reasonable path widths (LabVIEW cannot do this for you, as the choices are very application-dependent). Based on the current state of your VIs, I would definitely recommend starting with SGL, then gradually moving to fixed point if and when it becomes necessary.

[erfigge]

Thank you very much for your responses. I actually just added the top loop and then when I compiled it there were timing errors. It worked before adding the top loop.

So that is when I started looking into the variable types and forcing conversions ect. So the 64 length fixed point was me messing around. I will probably start out changing all the variables to SGL and see what happens.

If I would have to go back to or stay with fixed point, is it best to just choose a reasonable size and force that through all the math operations?

Thanks again,

Eric.

[nathand]

I'll be very interested to know if replacing 64-bit fixed-point values with 32-bit floating points solves timing problems. Replacing 64-bit values with 32-bit ones should reduce resource use dramatically, but I don't know how many more resources are required for floating point rather than fixed.

You don't necessarily want to pick a single fixed-point representation everywhere, unless you have enough FPGA resources to use types that are wider than necessary to store your data with sufficient precision. For maximum efficiency, evaluate the range of values and the required precision for each calculation, and then pick an appropriate representation, which might change after each step of the computation. For example, if at one step you multiply by approximately 10, then you may want to adjust the output representation by 3 bits (a factor of 😎 to maintain approximately the same precision.

[erfigge]

Hmm, that's a good thought on the fixed point precisions. Is there a white paper or layman's explanation on precisions of fixed points?

[Dragis]

There is a decent overview of the fixed point type here: http://zone.ni.com/devzone/cda/pub/p/id/303.

In general, to weigh the cost difference between floating point and fixed point, you have to figure out how dynamic your data is and what operations you are using. It can be somewhat couter-intutive which operators use the most resources or will become the hardest paths to meet timing with. For instance, a fixed point add is generally very cheap because the compiler knows ahead of time how the two values (types) are related and can essentially pre-shift the operands into a normalized format. However, a floating point adder doesn't have this optimization so it must include a large shifting unit to align the two operands before doing the addition and then another to normalize the output value again. 

Like was mentioned above, in the newer hardware targets, there is generally an abundance of DSP blocks for floating point operators to take advantage of, so start with that. You can then gradually migrate parts of the design that don't meet timing or utilize too many resources by analyzing the data that flows through those portion of the design and then pick fixed point types that fit those characteristics as closely as possible.

[erfigge]

Everyone, thanks for the links and help.  With the aid of that last fixed point document we went through and optimized the fixed point size.  It will compile in respect to size on the sbrio 9612 fpga.  However, right at the end I get this error.

What does that mean and how would one go about fixing that?  I have attached the VI's as well.

[nathand]

That error means that the computation will take longer than a single clock cycle to complete, which isn't allowed. You can find a good, if slightly technical explanation, in the LabVIEW help under Understanding Timing Considerations. You'll need to simplify your code, perhaps by reducing the precision of some computations, or restructure it, as explained in the help.

[erfigge]

The code in the picture above is in a sub vi and I don't have any structure of any kind around it.  From what the article you linked to is saying a single cycle loop is actually good/better than nothing at all?  Also, in my main fpga vi I have one loop with a bunch of IO processing.  Would it be better to do a bunch of single cycle loops instead of one big normal loop?

Thanks,

Eric.