Find Potential Data Type Issues in Generated Code

Data Type Issues Overview

When you convert MATLAB^® code to fixed point, you can highlight potential data type issues in the generated report. The report highlights MATLAB code that requires single-precision, double-precision, or expensive fixed-point operations.

The double-precision check highlights expressions that result in a double-precision operation. When trying to achieve a strict-single or fixed-point design, manual inspection of code can be time-consuming and error prone.
The single-precision check highlights expressions that result in a single operation.
The expensive fixed-point operations check identifies optimization opportunities for fixed-point code. It highlights expressions in the MATLAB code that require cumbersome multiplication or division, expensive rounding, expensive comparison, or multiword operations. For more information on optimizing generated fixed-point code, see Tips for Making Generated Code More Efficient.

Enable Highlighting of Potential Data Type Issues

Enable the highlight option using the Fixed-Point Converter app

On the Convert to Fixed Point page, click the Settings arrow .
Under Plotting and Reporting, set Highlight potential data type issues to Yes.

When conversion is complete, open the fixed-point conversion report to view the highlighting. Click View report in the Type Validation Output tab.

Enable the highlight option using the command-line interface

Create a fixed-point code configuration object:
```
fixptcfg = coder.config('fixpt');
```
Set the HighlightPotentialDataTypeIssues property of the configuration object to true.
```
fixptcfg.HighlightPotentialDataTypeIssues = true;
```

Find and Address Cumbersome Operations

Cumbersome operations usually occur due to an insufficient range of output. Avoid inputs to a multiply or divide operation that have word lengths larger than the base integer type of your processor. Software can process operations with larger word lengths, but this approach requires more code and runs slower.

This example requires Embedded Coder^® and Fixed-Point Designer™. The target word length for the processor in this example is 64.

Create the function myMul.

function out = myMul(in1, in2)
    out = fi(in1*in2, 1, 64, 0);
end

Generate code for myMul.

cfg = coder.config('lib');
cfg.GenerateReport = true;
cfg.HighlightPotentialDataTypeIssues = true;
fm = fimath('ProductMode', 'SpecifyPrecision', 'ProductWordLength', 64);
codegen -config cfg myMul -args {fi(1, 1, 64, 4, fm), fi(1, 1, 64, 4, fm)}

Click View report.
In the code generation report, click the Code Insights tab.
Expand the Potential data type issues section. Then, expand the Expensive fixed-point operations section.
The report flags the expression in1 * in2. To resolve the issue, modify the data types of in1 and in2 so that the word length of the product does not exceed the target word length of 64.

Find and Address Expensive Rounding

Traditional handwritten code, especially for control applications, almost always uses "no effort" rounding. For example, for unsigned integers and two's complement signed integers, shifting right and dropping the bits is equivalent to rounding to floor. To get results comparable to, or better than, what you expect from traditional handwritten code, use the floor rounding method.

This example requires Embedded Coder and Fixed-Point Designer.

Create the function myRounding.

function [quot] = myRounding(in1, in2)
   quot = in1 / in2;
end

Generate code for myRounding.

cfg = coder.config('lib');
cfg.GenerateReport = true;
cfg.HighlightPotentialDataTypeIssues = true;
codegen -config cfg myRounding -args {fi(1, 1, 16, 2), fi(1, 1, 16, 4)}

Click View report.
In the code generation report, click the Code Insights tab.
Expand the Potential data type issues section. Then, expand the Expensive fixed-point operations section.
The division operation in1/in2 uses the default rounding method, nearest. Changing the rounding method to Floor provides a more efficient implementation.

Find and Address Expensive Comparison Operations

Comparison operations generate extra code when a casting operation is required to do the comparison. For example, before comparing an unsigned integer to a signed integer, one of the inputs must be cast to the signedness of the other. Consider optimizing the data types of the input arguments so that a cast is not required in the generated code.

This example requires Embedded Coder and Fixed-Point Designer.

Create the function myRelop.

function out = myRelop(in1, in2)
    out = in1 > in2;
end

Generate code for myRelop.

cfg = coder.config('lib');
cfg.GenerateReport = true;
cfg.HighlightPotentialDataTypeIssues = true;
codegen -config cfg myRelop -args {fi(1, 1, 14, 3, 1), fi(1, 0, 14, 3, 1)}

Click View report.
In the code generation report, click the Code Insights tab.
Expand the Potential data type issues section. Then, expand the Expensive fixed-point operations section.
The first input argument, in1, is signed, while in2 is unsigned. Extra code is generated because a cast must occur before the two inputs can be compared.
Change the signedness and scaling of one of the inputs to generate more efficient code.

Find and Address Multiword Operations

Multiword operations can be inefficient on hardware. When an operation has an input or output data type larger than the largest word size of your processor, the generated code contains multiword operations. You can avoid multiword operations in the generated code by specifying local fimath properties for variables. You can also manually specify input and output word lengths of operations that generate multiword code.

This example requires Embedded Coder and Fixed-Point Designer. In this example, the target word length is 64.

Create the function myMul.

function out = myMul(in1, in2)
    out = in1 * in2;
end

Generate code for myMul.

cfg = coder.config('lib');
cfg.GenerateReport = true;
cfg.HighlightPotentialDataTypeIssues = true;
codegen -config cfg myMul -args {fi(1, 1, 33, 4), fi(1, 1, 32, 4)}

Click View report.
In the code generation report, click the Code Insights tab.
Expand the Potential data type issues section. Then, expand the Expensive fixed-point operations section.
The report flags the in1 * in2 operation in line 2 of myMul.
In the code pane, pause over in1, in2, and the expression in1 * in2. You see that:
- The word length of in1 is 33 bits and the word length of in2 is 32 bits.
- The word length of the expression in1 * in2 is 65 bits.
The software detects a multiword operation because the word length 65 is larger than the target word length of 64.
To resolve this issue, modify the data types of in1 and in2 so that the word length of the product does not exceed the target word length. Alternatively, specify the ProductMode property of the local fimath object.