This floatingpoint format occupies 4 bytes (32 bits) and represents a wide dynamic range of values. In LabVIEW FPGA 2012, this data type is compliant with IEEE Std 7542008 with the exception of subnormal numbers. The 32 bit base 2 format is officially referred to as binary 32 but, must generally known as single (SGL).
Figure 1. LabVIEW FPGA 2012 single precision floatingpoint data type is compliant with IEEE Std 7542008
Single precision data type is included in the LabVIEW FPGA Numeric Palette as a SGL numeric constant along with Math & Scientific Constants.
Figure 2. LabVIEW FPGA 2012 exposes a set of single precision floating point data type constants in the numeric palette
Along with the inclusion of SGL constants, a set of primitives have been optimized for its use with the SGL data type on FPGA. These functions are only suitable for being used outside SingleCycle Timed Loops (SCTLs). If the code requires the use of a SCTL with floating point operators, the use of the IP Integration Node or the Xilinx Core Generator IP FloatingPoint palette is recommended instead.
Figure 3. Single precision floatingpoint data type supported LabVIEW primitives
Before LabVIEW FPGA 2012 the use of the floatingpoint data type was constrained to complicated conversions. This represented extra programming work to perform common instructions such as targettohost DMA communications and highthroughput mathematics. Conversions from fixedpoint to single precision floatingpoint required to be done by the Host or RealTime part of the application mostly due to the complexity of implementing this on FPGA. This conversion resulted time consuming if performed on the host side but, still easier to implement than in FPGA. Moreover, performing the fixedpoint to floatingpoint conversion on the host reduced the host’s speed performance up to 40%. The workaround for this issue was to encode the fixedpoint data into an integer U32 representation before sending it to the host to lessen the effects of this conversion over the speed execution in the host code. This resulted in extra work to implement the complicated encoding in FPGA, and the host still required a type cast conversion to single precision floatingpoint. For more detailed information about this process visit the FixedPoint to Single (SGL) Conversion on LabVIEW FPGA document.
Figure 4. Fixedpoint to single precision floatingpoint conversion performed on FPGA code
On the other hand, LabVIEW FPGA includes other software development productivity tools such as the Xilinx CORE Generator IP Palette, which makes floatingpoint implementation feasible through code reuse. This palette includes code that generates IP for conversion to, and basic operations for, floatingpoint numbers.
Figure 5. The Xilinx Core Generator FloatingPoint Operator IP core offers a floatingpoint function library that can be integrated into LabVIEW FPGA with the Xilinx CoreGEN
LabVIEW FPGA 2012 makes this process even more accessible by introducing the To Single Precision Float function. This function is part of the Conversion palette and allows users to perform single precision floatingpoint data type operations without involving extra code. This function becomes especially important when it comes to coercions, i.e. automatic conversions that occur in FPGA VIs can consume significant logic resources, especially when the terminal is coerced to the SGL data type. Thus, as a general rule is always advisable to use conversion functions to explicitly convert data types.
Figure 6. To Single Precision Float function can be used to easy perform communications from Target to Host and advanced math operations directly on the FPGA
In addition to constants, primitives, and conversion functions, the single precision floatingpoint is supported in targetscoped, host to targetDMA, target to hostDMA, and peer to peer writer/reader FIFOs. Furthermore, memory elements can be used along with SGL data type in their targetscoped and VI defined implementations. This support is leveraged to elements that were able to perform floating point operations in the past such as the Xilinx Core Generator IP and the IP Integration Node for increased performance and functionality.
Figure 7. The single precision floatingpoint data type support is extended to other preexisting features throughout the FPGA module
When developing applications with single precision floatingpoint data type on FPGA it is paramount to consider that this data type uses more resources than the fixedpoint data type, and requires more clock cycles to complete an operation. While the fixedpoint data type is very efficient for hardwarebased designs when it comes to speed and resource utilization, it does not provide the flexibility that the floatingpoint data type offers. This turns especially important when designing large applications with specific timing requirements and limited resources. The use of floatingpoint data type on FPGA is only recommended for applications in which the use of resources and timing is not a concern.
For applications with strict timing requirements, designers can still program advanced algorithms on FPGA using the IP Integration Node and the Xilinx Core Generator IP Palette within a Single Cycle TimedLoop (SCTL). This allows keeping timing requirements at the same time developers take advantage of floatingpoint operations. It is important to note that while the floatingpoint data type offers many benefits, it has limited support when used in SingleCycle Timed Loops, and uses significantly more FPGA resources than the fixedpoint data type for certain operations. The following features are supported in the Single Cycle TimedLoop with single precision floatingpoint data type:
Additionally, currently LabVIEW FPGA 2012 does not support subnormal numbers (denormalized numbers). A subnormal number is any nonzero number which is smaller than the smallest normal number. For instance, if a floatingpoint divide function is used to divide 2 numbers and its result is an extremely small number with mantissa smaller than 1, the result can be expressed as a subnormal number. The Xilinx FloatingPoint Divide function treats this result as a zero with a sign taken from the subnormal number.
Considering the resource consumption of floatingpoint operations, in some applications might be useful to mix fixedpoint with floatingpoint operators. That is, if the inputs of our processes are already fixedpoint numbers, it becomes natural to perform basic operations in this format. However, when more advanced operations appear in the algorithm it is advisable to switch to a floatingpoint implementation. This is the case of the implementation of a multiplieraccumulator unit (MAC) on an FPGA which is a basic building block of DSP applications.
Figure 8. Iterative accumulation algorithms are susceptible to overflow and precision errors due to data types
The multiplyaccumulate operation is a common step that computes the product of two numbers and adds the product to an accumulator. When implemented in fixedpoint, the FPGA design benefits from the superior speed this data type offers as well as from the minimum amount of hardware resources it demands. However, when increasing the size of the algorithm and the number of iterations that the MAC unit must process, we can run into the problem of overflowing the fixedpoint number. On the other hand, floating point based MAC units lack of this problem due to the intrinsic wide dynamic range of this data type; nevertheless, its implementation can be resource expensive and slower. Thus, there is a tradeoff between data type representation capacity, speed, and space. Mixing both data types in the same algorithm will result in a reduction of FPGA’s resources consumption eliminating this way the chance of having overflowing errors.
Figure 9. The multiplyaccumulate operation can benefit from a mixed fixedpoint / floatingpoint implementation in terms of dynamic range and resource utilization
The block diagram above demonstrates three different ways of implementing a simple multiplieraccumulator algorithm in an FPGA. The algorithm multiplies 2 numbers and iteratively adds them in an accumulator until it reaches a saturation status due to data type limitations. The loop with best performance is the fixedpoint implementation, despite the fact it saturates fast over time. The floatingpoint implementation lacks of this problem dramatically outrunning fixedpoint due to its high dynamic range precision; still, this implementation represents a high cost in resource consumption. Mixing both data types can lead to more balanced FPGA designs meeting specific performance requirements. While floatingpoint algorithms can be executed directly on FPGA, mixed implementations offer increased flexibility and superior performance in key calculations within an algorithm.
Figure 10. Mixing fixedpoint and floatingpoint data types reduces hardware resource consumption improving performance for advanced algorithms
Performance, resource consumption, code reuse, algorithm complexity, and compatibility of functions are the main factors to consider when deciding where to use a specific data type within an FPGA code. This section presents a benchmarking based on the PID algorithm included in the Control palette of the LabVIEW FPGA 2012 Module. Device utilization and timing capabilities are analyzed for two PID implementations based on fixedpoint and single precision floatingpoint. This study uses default compilation settings for the Xilinx 13.4 compilation tool. Fixedpoint and floatingpoint PID algorithms were implemented on a NI PXI7854R target with a Virtex5 LX110 FPGA to serve this benchmarking. For more detailed information about the VIs used please refer to the download section.
Figure 11. LabVIEW FPGA PID control fixedpoint implementation
Figure 12. LabVIEW FPGA PID control floatingpoint implementation
Device utilization map and final timing performance were used as comparison parameters for both implementations. As expected, single precision floatingpoint implementation significantly increases the amount of resources needed for the PID design; however, it leverages more accuracy and flexibility due to the 24bit significand and increased dynamic range. Moreover, the floatingpoint implementation presents a higher latency, but still PID loops rates close to 800kS/s can be achieved. This way, custom sophisticated algorithms completely programmed in floatingpoint can be used directly in an FPGA overcoming the limitations of fixedpoint implementations. For instance, in this PID example, the floatingpoint implementation is not limited by the 16 bit width PID output or the PID gains restriction to <±,16,8> bit of the fixedpoint representation.
Device Utilization (Map) 
Total 
Used 
Percent 

NI PXI7854R 
FXP 
FP 
FXP 
FP 

Total Slices  17280 
760 
2585 
4.4 
15 
Slice Registers  69120 
1418 
4162 
2.1 
6 
Slice LUTs  69120 
1510 
6275 
2.2 
9.1 
DSP48s  64 
3 
3 
4.7 
4.7 
Table 1. Device utilization for NI PXI7854R benchmarking
Timing (Place and Routing) 
Requested (MHz) 
Maximum (MHz) 

NI PXI7854R 
FXP 
FP 

40 MHz Onboard Clock  40 
78.20 
110.62 
Table 2. Timing performance for NI PXI7854R benchmarking
LabVIEW FPGA 2012 offers an easy to use programming environment to inexperienced FPGA developers through familiar floatingpoint functions. Moreover, it empowers signal processing experts with high level tools to reduce the design time and rapidly test algorithms on FPGA. The floatingpoint data type support on LabVIEW FPGA 2012 opens a wide range of application possibilities while catching up with the latest technologies in the embedded systems market. LabVIEW FPGA floatingpoint support empowers embedded developers to:
It is important to note that while the floatingpoint data type offers many benefits, it has limited support when used in SingleCycle Timed Loops, and uses significantly more FPGA resources than the fixedpoint data type for certain operations. For more information on the functions and structures that support the floatingpoint data type, see the LabVIEW FPGA 2012 Help document.