ULP Considerations of Native Floating-Point Operators

The representation of infinitely real numbers with a finite number of bits requires an approximation. This approximation can result in rounding errors in floating-point computation. To measure the rounding errors, the floating-point standard uses relative error and ULP (Units in the Last Place) error. To learn about relative error, see Relative Accuracy and ULP Considerations.

If the exponent range is not upper-bounded, Units in Last Place (ULP) of a floating-point number x is the distance between two closest straddling floating-point numbers a and b nearest to x. The IEEE-754 standard requires that the result of an elementary arithmetic operation such as addition, multiplication, and division is correctly round. A correctly rounded result means that the rounded result is within 0.5 ULP of the exact result.

Adherence of Native Floating Point Operators to IEEE-754 Standard

Native floating point technology in HDL Coder™ follows IEEE standard of floating-point arithmetic. Basic arithmetic operations such as addition, subtraction, multiplication, division, and reciprocal are mandated by IEEE to have zero ULP error. When you perform these operations in native floating-point mode, the numerical results obtained from the generated HDL code match the original Simulink^® model.

Certain advanced math operations such as exponential, logarithm, and trigonometric operators have machine-specific implementation behaviors because these operators use recurring taylor series and remez expression based implementations. When you use these operators in native floating-point mode, there can be relatively small differences in numerical results between the Simulink model and the generated HDL code.

You can measure the difference in numerical results as a relative error or ULP. A nonzero ULP for these operators does not mean noncompliance with the IEEE standard. A ULP of one is equivalent to a relative error of 10^-7. You can ignore such relatively small errors by specifying a custom tolerance value for the ULP when generating a HDL test bench. For example, you can specify a custom floating-point tolerance of one ULP to ignore the error when verifying the generated code. For more information, see configuration parameters Floating point tolerance check based on and Tolerance Value.

ULP Values of Floating Point Operators

The table enumerates the ULP of floating-point operators that have a nonzero ULP. In addition to these operators, the HDL Reciprocal block has a ULP of five.

Math Functions

Simulink Blocks	Data Type	Units in the Last Place (ULP) error
exp	Single	1
exp	Half	1
log	Double	1
	Single	1
	Half	1
log10	Single	1
log10	Half	1
10^u	Single	1
pow	Single	1
hypot	Single	1

Math Operations

Simulink Blocks	Data Type	Units in the Last Place (ULP) error
HDL Reciprocal	Single	5
Sqrt	Double	1

Trigonometric Functions

Simulink Blocks	Data Type	Units in the Last Place (ULP) error
sin	Double	1
	Single	2
	Half	1
cos	Double	1
	Single	2
	Half	1
tan	Single	3
asin	Single	2
acos	Single	2
atan	Single	2
atan2	Single	5
sinh	Single	1
cosh	Single	1
tanh	Single	1
asinh	Single	2
acosh	Single	2
atanh	Single	3
sincos	Single	2

Considerations

For certain floating-point input values, some blocks can produce simulation results that vary from the MATLAB^® simulation results. To see the difference in results, before you generate code, enable generation of the validation model. In the Configuration Parameters dialog box, on the HDL Code Generation pane, select the Generate validation model check box.

If you perform computations that involve complex numbers and an exception such as Inf or NaN, the HDL simulation result with native floating point can potentially vary from the Simulink simulation result. For example, if you multiply a complex input with Inf, the Simulink simulation result is Infi whereas the HDL simulation result is NaN+Infi.
HDL Coder does not generate a mismatch error between reference and native floating-point values if both values are NaN irrespective of the sign.
If you compute the square root or logarithm of a negative number, the HDL simulation result with native floating point is 0. This result matches the simulation result when you verify the design with a SystemVerilog DPI test bench. In Simulink, the result obtained is NaN. According to the IEEE-754 standard, if you compute the square root or logarithm of a negative number, the result is that number itself.
If the input to the Direct Lookup Table (n-D) is of floating-point data type, but the elements of the table use a smaller data type, the generated HDL code can be potentially incorrect. For example, the input is of single type and the elements use uint8 type. To obtain accurate HDL simulation results, use the same data type for the input signal and the elements of the lookup table.
If you use the Cosine block with the inputs -7.729179E28 or 7.729179E28, the generated HDL code has a ULP of 4. For all other inputs, the ULP is 2.
When you use a Math Function block to compute mod(a,b) or rem(a,b), where a is the dividend and b is the divisor, the simulation result in native floating-point point mode varies from the MATLAB simulation result in these cases:
- If $b is integer and \frac{a}{b} > 2^{32}$ , the simulation result in native floating-point mode is zero. For such significant difference in magnitude between the numbers a and b, this implementation saves area on the target FPGA device.
- If $\frac{a}{b} is close to 2^{23}$ , the simulation result in native floating-point mode can potentially vary from the MATLAB simulation results.

Related Examples

Floating Point Support: Field-Oriented Control Algorithm