IP Corner: The LabVIEW Fixed-Point Data Type Part 2 – Working with Fixed-Point

Publish Date: Nov 16, 2009 | 6 Ratings | 4.50 out of 5 | Print | Submit your review

<<< Part 1 - Fixed-point 101

This first important concept that you must know when working with fixed-point conversions in NI LabVIEW software is the effect quantization has on data. Quantization happens when you convert a number from one representation to a less descriptive representation. For the purposes of this section, examine quantization errors that stem from floating-point (FLT) to fixed-point (FXP) conversion. These errors are introduced because you are coercing each data point to the closest fixed-point representation using a finite number of user-specified bits. Because floating point uses a representation similar to scientific notation, as opposed to fixed point, which uses a direct binary representation, you can show a much higher range and many times resolution with FLT. Therefore, converting from FLT to FXP often introduces rounding errors. Figure 1 shows the quantization of a sine wave from conducting a floating-point to a 4-bit fixed-point conversion.

Figure 1. One period of a sine wave in floating point (red) is overlaid with a 4-bit representation of the same wave (white). Notice that the quantization errors look like stair steps.

Take a look at the graph in Figure 2, which shows the mean squared error introduced from converting the same floating-point sine wave to various fixed-point representations, varying the bits of resolution along the x-axis. The error gets exponentially less as the number of bits increases.

Figure 2. Mean squared error from converting a floating-point sign wave (DBL) to fixed point with varying bit widths plotted on a log scale (y-axis).


With LabVIEW, you can exert more control over quantization by choosing the rounding and overflow modes for the conversion from any other data type to FXP, including floating-point and other bit-width combinations of fixed point. Refer to Part 1 to learn more about the theory behind the types of rounding and overflow.

Figure 3. The property window for the FXP conversion bullet (or other mathematical functions) shows where you select rounding modes and overflow modes in LabVIEW. To see this window, right-click the FXP conversion function and select “Properties…”


As a rule of thumb, rounding half-even and saturation overflow modes typically renders the most desirable results. Rounding usually gives an overall more accurate fixed-point representation of the input number. Saturation prevents outputs from jumping between the top and bottom of the FXP range when input numbers are outside FXP bounds. The only drawback is that rounding half-even and saturation modes requires slightly more field-programmable gate array (FPGA) logic compared to the truncate and wrap modes.

Figure 4. A graph of mean squared error using rounding and truncation shows that, in the case of a floating-point sine wave, rounding produces less error at all bit levels and improves with larger bit width (plotted on a log scale).


Fixed-Point Bitwise Representation
To convert a fixed-point number to its bitwise representation in LabVIEW, use the “Number to Boolean Array” function. This operation returns a bitwise (Boolean) representation of the FXP number. The least significant bit is located at index 0.

Figure 5. Use “Number to Boolean Array” to convert FXP to its bitwise representation. The example shows 2.6875 converted to 00101011 (LSB at index 0).

The most important advantage of converting FXP to a bitwise representation is the ability to convert FXP to an equivalent integer. This is necessary because, before LabVIEW 8.5, the FXP data type did not exist. Thus, all FPGA algorithms were written using the integer data type. Even in LabVIEW 8.5, there are many functions and algorithms in the palettes, including DMA, filters, and memory, that still use the integer data type, not to mention any previously written LabVIEW FPGA IP you might have created or obtained. The fact is, you can still use the integer-based functions with the FXP data type as long as you convert to the bitwise equivalent integer. Keep in mind, bitwise representation is not the same as converting the number to an integer with the “To Integer” numeric conversion. Doing this returns the closest integer to the value of the input – not the bitwise equivalent. The Figure 6 LabVIEW block diagram shows how to convert FXP to a bitwise equivalent unsigned integer incorrectly and correctly.

Figure 6. You cannot implement a simple integer conversion to use FXP with existing integer-based IP. Instead use “Number to Boolean Array” to get the bitwise representation and “Boolean Array to Number” to convert that to a bitwise equivalent integer. (Note: This is the simplified unsigned case.)

Use the reverse process when the integer returns from the IP to get the number back to the same FXP point data type, being sure that the "Boolean Array to Number" is configured to output the same type as the original FXP number. Note the following about this bit-conversion method: 

  1. This method is actually a “free” operation on the FPGA. The “gates” representing bits on the FPGA do not care whether they are a <32,16> fixed-point number, a U32, or 32 individual bits. This method changes only the representation shown to the user and used in LabVIEW. 
  2. This method does not work if the IP has different input and output bit widths. For example, this simple conversion does not work if the input is U16 and the output is U32, unless you know exactly how the number increased in bit width and where to put the resulting radix point. 
  3. When dealing with signed numbers, you must add extra logic in some cases to implement sign bit extension so that the resulting integer preserves the correct sign (refer to "Sign Bit Extension").

Sign Bit Extension
When passing a signed fixed-point number to IP, it is sometimes necessary to implement sign extension for the resulting integer to have the correct sign. For example, consider that you need to convert a signed 5-bit number to a signed 8-bit integer to pass the number to a piece of IP. If you use the simple method above, you get a positive value, which obviously does not preserve the sign. Instead, you should pass the two's complement of the bitwise representation of the absolute value. This is called sign extension. Mathematically it is the two’s complement of the absolute value. Algorithmically, you take the sign bit and pad out the most significant bit. See Figure 7.

Figure 7. Conversion With and Without Sign Extension

In LabVIEW 8.5, the trick for sign extension is to first use the fixed-point numeric conversion to pad the integer part with zeros. Use the exact amount needed to make the new FXP number the same bit width as the desired integer. Then go through the normal steps to convert this new equivalent number to the bitwise representation and then to the integer form. Doing this makes the sign bits line up correctly such that sign extension is achieved. Refer to the example below.

Figure 8. This shows the correct conversion of a signed - <5,2> FXP number to a sign-extended 8-bit integer that has bitwise equivalency.

Quantization and bitwise representation are two important concepts to understand when working with the fixed-point data type in LabVIEW. Quantization is the basis of floating- to fixed-point conversion. Although, this is an extremely hard problem to solve in some cases, the first step is to understand the basic building blocks of FXP versus FLT. Furthermore, learning about manipulating fixed-point numbers at the bit level using arrays of Boolean in LabVIEW is important to use integer-based IP and infrastructure with the fixed-point data type.


IP Corner addresses issues and presents technical information on LabVIEW FPGA application reusable functionality, also known as FPGA IP. This article series is designed for those interested in learning, testing, or discussing topics to make FPGA designs better and faster through the reuse of IP.


Back to Top

Bookmark & Share


Rate this document

Answered Your Question?
Yes No