|
|
|
| R2012a Documentation → Simulink Coder | |
Learn more about Simulink Coder |
|
| Contents | Index |
Use Simulink Coder Model Advisor checks to configure your model for code generation.
Check model solver and sample time configuration settings.
Incorrect configuration settings can stop the Simulink Coder software from generating code. Underspecifying sample times can lead to undesired results. Avoid generating code that might corrupt data or produce unpredictable behavior.
| Condition | Recommended Action |
|---|---|
| The solver type is set incorrectly for model level code generation. | Set Configuration Parameters > Solver > |
| Multitasking diagnostic options are not set to error. | Set Configuration Parameters > Diagnostics >
|
You do not have to modify the solver settings to generate code from a subsystem. The Embedded Coder build process automatically changes Solver type to fixed-step when you select Code Generation > Build Subsystem or Code Generation > Generate S-Function from the subsystem context menu.
Identify blocks not supported by code generation or not recommended for deployment.
The code generator creates code only for the blocks that it supports. Some blocks are not recommended for production code deployment.
| Condition | Recommended Action |
|---|---|
| A block is not supported by the Simulink Coder software. | Remove the specified block from the model or replace the block with the recommended block. |
| A block is not recommended for production code deployment. | Remove the specified block from the model or replace the block with the recommended block. |
| Check for Gain blocks whose value equals 1. | Replace Gain blocks with Signal Conversion blocks. |
Supported Products and Block Usage
Identify lookup table blocks that generate code to protect against out-of-range inputs for breakpoint or index values.
This check verifies that the following blocks do not generate code to protect against inputs that fall outside the range of valid breakpoint values:
This check also verifies that Interpolation Using Prelookup blocks do not generate code to protect against inputs that fall outside the range of valid index values.
Following the recommended actions increases both execution and ROM efficiency of the generated code.
| Condition | Recommended Action |
|---|---|
The lookup table block generates out-of-range checking code. | Change the setting on the block dialog box so that out-of-range checking code is not generated.
|
Clicking Modify prevents lookup table blocks from generating out-of-range checking code, which makes the generated code more efficient.
n-D Lookup Table block in the Simulink documentation
Prelookup block in the Simulink documentation
Interpolation Using Prelookup block in the Simulink documentation
Tips to Optimize Generated Code for Lookup Table Blocks in the Simulink documentation
Identify logic blocks that do not use boolean for the output data type.
This check verifies that the output data type of the following blocks is boolean:
Compare To Constant
Compare To Zero
Detect Change
Detect Decrease
Detect Fall Negative
Detect Fall Nonpositive
Detect Increase
Detect Rise Nonnegative
Detect Rise Positive
Interval Test
Interval Test Dynamic
Logical Operator
Relational Operator
Using output data type boolean increases execution efficiency of the generated code.
| Condition | Recommended Action |
|---|---|
| The output data type of a logic block is not boolean. | In the block dialog box, set Output data type to boolean. |
Clicking Modify forces logic blocks to use boolean as the output data type. If a logic block uses uint8 for the output type, clicking Modify changes the output type to boolean.
Identify blocks using one-based indexing.
Zero-based indexing is more efficient in the generated code than one-based indexing. This check identifies blocks using one-based indexing.
Using zero-based indexing increases execution efficiency of the generated code.
See cgsl_0101: Zero-based indexing.
| Condition | Recommended Action |
|---|---|
| The model or subsystem contains blocks configured for one-based indexing. | Configure the blocks for zero-based indexing. Update the supporting blocks. |
| The model or subsystem contains blocks requiring one-based indexing. | Evaluate the blocks to determine if one-based indexing is used. Consider replacing the blocks with Simulink basic blocks. |
Identify inconsistent or underspecified hardware implementation settings
The Simulink and Simulink Coder software require two sets of target specifications. The first set describes the final intended production target. The second set describes the currently selected target. If the configurations do not match, the code generator creates extra code to emulate the behavior of the production target. Inconsistencies or underspecification of hardware attributes can lead to inefficient or incorrect code generation for the target hardware.
| Condition | Recommended Action |
|---|---|
| Device type is set to Unspecified (assume 32-bit Generic). | Set Configuration Parameters > Hardware Implementation > Device type to the target hardware. |
| Hardware implementation parameters are not set to recommended values. | Specify the following Configuration Parameters > Hardware
Implementation parameters:
|
| Hardware implementation Embedded hardware settings do not match Emulation hardware settings. | Consider selecting the Configuration Parameters > Hardware Implementation > None check box, or modify the settings to match. |
Making GRT-Based Targets ERT-Compatible
Identify questionable software environment settings.
Support for some software environment settings can lead to inefficient code generation and nonoptimal results.
Industry standards for C, such as ISO and MISRA®, require identifiers to be unique within the first 31 characters.
Stateflow charts with weak Simulink I/O data types lead to inefficient code.
| Condition | Recommended Action |
|---|---|
| The maximum identifier length does not conform with industry standards for C. | Set the Configuration Parameters > Code Generation > Symbols > Maximum identifier length parameter to 31 characters. |
| Configuration Parameters > Code Generation > Interface parameters are not set to recommended values. | Clear the following parameters on the Configuration
Parameters > Code Generation > Interface pane:
|
| Configuration Parameters > Code Generation > Symbols parameters are not set to recommended values. | Set the Configuration Parameters > Code Generation > Symbols > Generate scalar inlined parameters as parameter to Literals. |
| Support: variable-size signals is selected. This might lead to inefficient code. | If you do not intend to support variable-sized signals, clear the Code Generation > Interface > Support: variable-size signals check box in the Configuration Parameters dialog box. |
| The model contains Stateflow charts with weak Simulink I/O data type specifications. | Select the Stateflow chart property Use Strong Data Typing with Simulink I/O. You might need to adjust the data types in your model after selecting the property. |
A Stateflow license is required when using Stateflow charts.
Strong Data Typing with Simulink I/O
Identify questionable code instrumentation.
Instrumentation of the generated code can cause nonoptimal results.
Test points require global memory and are not optimal for production code generation.
| Condition | Recommended Action |
|---|---|
| Interface parameters are not set to recommended values. | Set the Configuration Parameters > Code Generation > Interface parameters to the recommended values. |
| Blocks generate assertion code. | Set the Configuration Parameters > Diagnostics > Data Validity > Model Verification block enabling parameter to Disable All on a block-by-block basis or globally. |
| Block output signals have one or more test points and the Ignore test point signals check box is cleared in the Code Generation pane of the Configuration Parameters dialog box . | Remove test points from the specified block output signals. For each signal, in the Signal Properties dialog box, clear the Test point check box. Alternatively, if the model is using an ERT-based system target file, select the Ignore test point signals check box in the Code Generation pane of the Configuration Parameters dialog box to ignore test points during code generation. |
Identify blocks with constraints on tunable parameters.
Lookup Table and Lookup Table (2-D) blocks have strict constraints when they are tunable. If you violate lookup table block restrictions, the generated code produces wrong answers.
| Condition | Recommended Action |
|---|---|
| Lookup Table blocks have tunable parameters. | When tuning parameters during simulation or when running the
generated code, you must:
|
| Lookup Table (2-D) blocks have tunable parameters. | When tuning parameters during simulation or when running the
generated code, you must:
|
Identify blocks that are not supported or recommended for MISRA-C:2004 compliant code generation.
Following the recommendations of this check increases the likelihood of generating MISRA-C:2004 compliant code for embedded applications.
See hisl_0020: Blocks not recommended for MISRA-C:2004 compliance.
| Condition | Recommended Action |
|---|---|
| Blocks that are not supported or recommended for MISRA-C:2004 compliant code generation were found in the model or subsystem. For a list of blocks, see hisl_0020: Blocks not recommended for MISRA-C:2004 compliance. | Consider replacing the specified blocks. |
This check does not review libraries.
Develop Models and Code That Comply with MISRA C Guidelines in the Embedded Coder documentation.
MISRA-C:2004 Compliance Considerations in the Simulink documentation.
Identify configuration parameters that might impact MISRA-C:2004 compliant code generation.
Following the recommendations of this check increases the likelihood of generating MISRA-C:2004 compliant code for embedded applications.
See hisl_0060: Configuration parameters that improve MISRA-C:2004 compliance.
| Condition | Recommended Action |
|---|---|
| Model Verification block enabling is set to Use local settings or Enable All. | In the Configuration Parameters dialog box, on the Diagnostics > Data Validity pane, set Model Verification block enabling to Disable All. |
| System target file is set to a GRT-based target. | In the Configuration Parameters dialog box, on the Code Generation > General pane, set System target file to an ERT-based target. |
| Code Generation > Interface parameters are not set to the recommended values. | In the Configuration Parameters dialog box, on the Code Generation > Interface pane:
|
| Parenthesis level is not set to Maximum (Specify precedence with parentheses). | In the Configuration Parameters dialog box, on the Code Generation > Code Style pane, set Parenthesis level to Maximum (Specify precedence with parentheses). |
| Maximum identifier length is not set to 31. | In the Configuration Parameters dialog box, on the Code Generation > Symbols pane, set Maximum identifier length to 31. |
Clicking Modify All changes the parameter values to the recommended values.
This check does not review referenced models.
Develop Models and Code That Comply with MISRA C Guidelines in the Embedded Coder documentation.
MISRA-C:2004 Compliance Considerations in the Simulink documentation.
Identify referenced model configuration parameter settings that do not match the top model configuration parameter settings.
The code generator cannot create code for top models that contain referenced models with different, incompatible configuration parameter settings.
| Condition | Recommended Action |
|---|---|
| The top model and the referenced model have inconsistent configuration parameter settings. | Modify the specified Configuration Parameters settings. |
Model Referencing Configuration Parameter Requirements
Check for blocks that generate expensive saturation or rounding code.
Setting the Saturate on integer overflow parameter can produce condition-checking code that your application might not require.
Generated rounding code is inefficient because of Integer rounding mode parameter setting.
| Condition | Recommended Action |
|---|---|
| Blocks generate expensive saturation code. | Check whether your application requires setting Function Block Parameters > Signal Attributes > Saturate on integer overflow. Otherwise, clear the Saturate on integer overflow parameter for the most efficient implementation of the block in the generated code. |
| Generated code is inefficient. | Set the Function Block Parameters > Integer rounding mode parameter to the recommended value. |
Set up the sample time and tasking mode for your system.
Incorrect tasking mode can result in inefficient code execution or incorrect generated code.
| Condition | Recommended Action |
|---|---|
| The model represents a multirate system but is not configured for multitasking. | Set the Configuration Parameters > Solver > Tasking mode for periodic sample times parameter as recommended. |
| The model is configured for multitasking, but multitasking is not desirable on the target hardware. | Set the Configuration Parameters > Solver > Tasking mode for periodic sample times parameter to SingleTasking, or change the Configuration Parameters > Hardware Implementation settings. |
Single-Tasking and Multitasking Execution Modes
Identify questionable subsystem block settings.
Subsystem blocks implemented as void/void functions in the generated code use global memory to store the subsystem I/O.
| Condition | Recommended Action |
|---|---|
| Subsystem blocks have the Subsystem Parameters > Function packaging option set to Function. | Set the Subsystem Parameters > Function packaging parameter to Auto. |
Subsystem block
Identify fixed-point operations that can lead to nonoptimal results.
The following operations can lead to nonoptimal results:
Division
The rounding behavior of signed integer division is not fully specified by C language standards. Therefore, the generated code for division is large to provide bit-true agreement between simulation and code generation.
Integer division generated code contains protection against arithmetic exceptions such as division by zero, INT_MIN/-1, and LONG_MIN/-1. If you construct models making it impossible for exception triggering input combinations to reach a division operation, the protection code generated as part of the division operation is redundant.
The index search method Evenly-spaced points requires a division operation, which can be computationally expensive.
Multiplication
Product blocks are configured to do more than one division operation. Multiplying all the denominator terms together first, and then computing only one division operation improves accuracy and speed in floating-point and fixed-point calculations.
Product blocks are configured to do more than one multiplication or division operation. Using several blocks, with each block performing one multiplication or one division operation, allows you to control the data type and scaling used for intermediate calculations. The choice of data types for intermediate calculations affects precision, range errors, and efficiency.
Blocks that have the Saturate on integer overflow parameter selected, and have an ideal multiplication product with a larger integer size than the target integer size, must determine the ideal product in generated C code. The C code required to do this multiplication is large and slow.
Blocks with relative scaling of inputs and outputs must determine the ideal product in the generated C code. The C code required to do this multiplication is large and slow.
Blocks that multiply signals with nonzero bias require extra steps to implement the multiplication. Inserting Data Type Conversion blocks remove the biases, and allow you to control data type and scaling for intermediate calculations. The conversion is done once and other blocks in the subsystem benefit from simpler, bias-free math.
Blocks are multiplying signals with mismatched slope adjustment factors. This mismatch causes the overall operation to involve two multiply instructions.
Blocks are multiplying signals with mismatched slope adjustment factors. This mismatch causes the overall operation to involve integer multiplication followed by shifts. Under certain simplicity and accuracy conditions when the net slope is a reciprocal of an integer, it is sometimes more efficient to replace the multiplication and shifts with an integer division.
The Simulink Coder software generates a reciprocal operation followed by a multiply operation for Product blocks that have a divide operation for the first input, and a multiply operation for the second input. If you reverse the inputs so that the multiplication occurs first and the division occurs second, the Simulink Coder software generates a single division operation for both inputs.
An input with an invariant constant value is used as the denominator in an online division operation. If the operation is changed to multiplication, and the invariant input is replaced by its reciprocal, then the division is done offline and the online operation is multiplication. This leads to faster and smaller generated code.
Addition
Sum blocks can have a range error when the input range exceeds the output range.
A Sum block has an input with a slope adjustment factor that does not equal the slope adjustment factor of the output. This mismatch requires the Sum block to do one or more multiplication operations.
The net sum of the Sum block input biases does not equal the bias of the output. The generated code includes one extra addition or subtraction instruction to account for the net bias adjustment. For better accuracy and efficiency, nonzero bias terms are collected into a single net bias correction term. The ranges given for the input and output exclude their biases.
Using Relational Operator blocks
The data types of the Relational Operator block inputs are not the same. A conversion operation is required every time the block is executed. If one of the inputs is invariant, then changing the data type and scaling of the invariant input to match the other input improves the efficiency of the model.
The Relational Operator block inputs have different ranges, resulting in a range error when casting, and a precision loss each time a conversion is performed. You can insert Data Type Conversion blocks before the Relational Operator block to convert both inputs to a common data type that has enough range and precision to represent each input.
The inputs of the Relational Operator block have different slope adjustment factors. The mismatch causes the Relational Operator block to require a multiply operation each time the input with lesser positive range is converted to the data type and scaling of the input with greater positive range.
When you select isNan, isFinite, or isInf as the operation for the Relational Operator block, the block switches to one-input mode. In this mode, if the input data type is fixed point, boolean, or a built-in integer, the output is FALSE for isInf and isNan, TRUE for isFinite. This might result in dead code which will be eliminated by Simulink Coder.
Using MinMax blocks
The input and output of the MinMax block have different data types. A conversion operation is required every time the block is executed. The model is more efficient with the same data types.
The input of the MinMax block is converted to the data type and scaling of the output before performing a relational operation, resulting in a range error when casting, or a precision loss each time a conversion is performed.
The input of the MinMax block has a different slope adjustment factor than the output. This mismatch causes the MinMax block to require a multiply operation each time the input is converted to the data type and scaling of the output.
Discrete-Time Integrator blocks have a complicated initial condition setting. The initial condition for the Discrete-Time Integrator blocks are used to initialize the state and output. As a result, the output equation generates excessive code and an extra global variable is required.
The Compare to Zero block uses the input data type to represent zero. If the input data type of the Compare to Zero block cannot represent zero exactly, the input signal is compared to the closest representable value of zero, resulting in parameter overflow.
The Compare to Constant block uses the input data type to represent its Constant value parameter. If the Constant value is outside the range that the input data type can represent, the input signal is compared to the closest representable value of the constant, resulting in parameter overflow.
| Conditions | Recommended Action | |
|---|---|---|
| Integer division generated code is large. | Set the Configuration Parameters > Hardware Implementation > Signed integer division rounds to parameter to the recommended value. | |
| Protection code generated as part of the division operation is redundant. | Verify that your model cannot cause exceptions in division operations and then remove redundant protection code by setting the Configuration Parameters > Optimization > Remove code that protects against division arithmetic exceptions parameter. | |
| Generated code is inefficient. | Set the Function Block Parameters > Integer rounding mode parameter to the recommended value. | |
| Lookup Table vector of input values is not evenly spaced. | If breakpoint data is nontunable, adjust the data to have even, power of 2 spacing. See fixpt_look1_func_approx. | |
| Lookup Table vector of input values is not evenly spaced when quantized, but it is very close to being evenly spaced. | If breakpoint data is nontunable, adjust the data to have even, power of 2 spacing. See fixpt_evenspace_cleanup. | |
| Lookup Table vector of input values is evenly spaced, but the spacing is not a power of 2. | If breakpoint data is nontunable, adjust the data to have even, power of 2 spacing. See fixpt_look1_func_approx. | |
| For a Prelookup or n-D Lookup Table block, Index search method is Evenly spaced points. Breakpoint data does not have power of 2 spacing. | If breakpoint data is nontunable, adjust the data to have even, power of 2 spacing. Otherwise, in the block parameter dialog box, specify a different Index search method to avoid the computation-intensive division operation. | |
| n-D Lookup Table breakpoint data is not evenly spaced and Index search method is not Evenly spaced points. | If breakpoint data is nontunable, adjust the data to have even, power of 2 spacing and then set Index search method to Evenly spaced points. | |
| n-D Lookup Table breakpoint data is evenly spaced and Index search method is Evenly spaced points. But the spacing is not a power of 2. | If breakpoint data is nontunable, adjust the data to have even, power of 2 spacing. See fixpt_look1_func_approx. | |
| n-D Lookup Table breakpoint data is evenly spaced, but the spacing is not a power of 2. Also, Index search method is not Evenly spaced points. | Set Index search method to Evenly spaced points. Also, if the data is nontunable, consider an even, power of 2 spacing. | |
| n-D Lookup Table breakpoint data is evenly spaced, and the spacing is a power of 2. But the Index search method is not Evenly spaced points. | Set Index search method to Evenly spaced points. | |
| Blocks require cumbersome multiplication. | Restrict multiplication operations:
| |
| Blocks multiply signals with nonzero bias. | Insert a Data Type Conversion block before and after the block containing the multiplication operation. | |
| Product blocks are multiplying signals with mismatched slope adjustment factors. | Change the scaling of the output so that its slope adjustment factor is the product of the input slope adjustment factors. | |
| Product blocks are multiplying signals with mismatched slope adjustment factors. The net slope correction uses multiplication followed by shifts, which is inefficient for some target hardware. | Select Use integer division to handle
net slopes that are reciprocals of integers if the net
slope is the reciprocal of an integer and division is more efficient
than multiplication and shifts on the target hardware.
| |
| Product blocks are configured to do multiple division operations. | Multiply all the denominator terms together, and then do a single division using cascading Product blocks. | |
| Product blocks are configured to do many multiplication or division operations. | Split the operations across several blocks, with each block performing one multiplication or one division operation. | |
| Product blocks are configured with a divide operation for the first input and a multiply operation for the second input. | Reverse the inputs so the multiply operation occurs first and the division operation occurs second. | |
| An input with an invariant constant value is used as the denominator in an online division operation. | Change the operation to multiplication, and replace the invariant input by its reciprocal. | |
| The data type range of the inputs of Sum blocks exceeds the data type range of the output, which can cause overflow or saturation. | Change the output and accumulator data types so the range equals or exceeds all input ranges. For example, if the model has two inputs
The data type range of the output and accumulator must equal or exceed –128 to 255. A int16 (–32768 to 32767) data type meets this condition. | |
| A Sum block has an input with a slope adjustment factor that does not equal the slope adjustment factor of the output. | Change the data types so the inputs, outputs, and accumulator have the same slope adjustment factor. | |
| The net sum of the Sum block input biases does not equal the bias of the output. | Change the bias of the output scaling, making the net bias adjustment zero. | |
| The inputs of the Relational Operator block have different data types. |
| |
| The inputs of the Relational Operator block have different slope adjustment factors. | Change the scaling of either input. | |
| The output of the Relational Operator block is constant. This might result in dead code which will be eliminated by Simulink Coder. | Review your model design and either remove the Relational Operator block or replace it with the constant. | |
| The input and output of the MinMax block have different data types. | Change the data type of the input or output. | |
| The input of the MinMax block has a different slope adjustment factor than the output. | Change the scaling of the input or the output. | |
| The initial condition of the Discrete-Time Integrator block is used to initialize both the state and the output. | Set the Function Block Parameters > Use initial condition as initial and reset value for parameter to State only (most efficient). | |
| Parameter overflow occurred for the Compare to Zero block. This block uses the input data type to represent zero. The input data type cannot represent zero exactly, so the input value was compared to the closest representable value of zero. | Select an input data type that can represent zero. | |
| Parameter overflow occurred for the following Compare to Constant block. This block uses the input data type to represent its Constant value parameter. The Constant value parameter is outside the range that the input data type can represent. The input signal was compared to the closest representable value of the Constant value parameter. | Choose an input data type that can represent the Constant value parameter or change the Constant value parameter to match the input data type. |
A Simulink Fixed Point license is required to generate fixed-point code.
Check the configuration parameter settings for the model against the code generation objectives.
Each parameter in the Configuration Parameters dialog box might have different recommended settings for code generation based on your objectives. This check helps you identify the recommended setting for each parameter so that you can achieve optimized code based on your objective.
| Condition | Recommended Action |
|---|---|
| Parameters are set to values other than the value recommended for the specified objectives. | Set the parameters to the recommended values. |
Clicking Modify Parameters changes the parameter values to the recommended values.
The Simulink Coder Recommended Settings Summary
The Embedded Coder Recommended Settings Summary
Application Objectives in the Simulink Coder User's Guide.
Application Objectives in the Embedded Coder documentation.
Identify optimization parameters that depend on the Execution efficiency or ROM efficiency objectives.
Setting the optimization parameter Use memcpy for vector assignment to the recommended value increases the execution efficiency and reduces ROM usage.
| Condition | Recommended Action |
|---|---|
| The model specifies an execution or ROM efficiency objective and the Use memcpy for vector assignment parameter is cleared. | In the Configuration Parameters dialog box, on the Optimization > Signals and Parameters pane, select Use memcpy for vector assignment. |
Clicking Modify changes the parameter value to the recommended value.
This check is in the Code Generation Advisor only.
Use memcpy for vector assignment in the Simulink documentation
 | Model Advisor Checks |
Learn more about Simulink through this collection of videos, articles, technical literature and the Getting Started with Simulink Guide.
| © 1984-2012- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |
