| Products & Services | Solutions | Academia | Support | User Community | Company |
| Download Product Updates | | | Get Pricing | | | Trial Software |
| Documentation → Real-Time Workshop |
| Contents | Index |
| Learn more about Real-Time Workshop |
Use Real-Time Workshop Model Advisor checks to configure your model for code generation.
Check model solver and sample time configuration settings.
Incorrect configuration settings can stop the Real-Time Workshop 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 Real-Time Workshop Embedded Coder build process automatically changes Solver type to fixed-step when you select Real-Time Workshop > Build Subsystem or Real-Time Workshop > 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 Real-Time Workshop 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. |
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
Identify inconsistent or underspecified hardware implementation settings
The Simulink and Real-Time Workshop 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 nonoptimal results.
| Condition | Recommended Action |
|---|---|
| Your system target file is grt.tlc. | Use an ERT-based target to generate final production code. |
| Hardware implementation parameters are not set to recommended values. | Specify the following Configuration Parameters > Hardware
Implementation parameters to the recommended values:
|
| Hardware implementation Embedded Hardware settings do not match Emulation Hardware settings. | Select the Configuration Parameters > Hardware Implementation > None check box and configure the Emulation hardware settings. |
| The target hardware has not been configured. | Specify the parameters in the Emulation hardware box in the Configuration Parameters > Hardware Implementationpane. |
A Real-Time Workshop Embedded Coder license is required to use an ERT-based target.
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 > Real-Time Workshop > Symbols > Maximum identifier length parameter to 31 characters. |
| Real-Time Workshop Interface parameters are not set to recommended values. | Set the following Configuration Parameters > Real-Time
Workshop > Interface parameters
to the recommended values:
|
| Real-Time Workshop Symbols parameters are not set to recommended values. | Set the Configuration Parameters > Real-Time Workshop > 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 Real-Time Workshop > 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 > Real-Time Workshop > 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 Real-Time Workshop 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 Real-Time Workshop 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 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 > Real-Time Workshop system code option set to Function. | Set the Subsystem Parameters > Real-Time Workshop system code parameter to Auto. |
Subsystem block
Disables unnecessary signal logging.
Disabling unnecessary signal logging avoids declaring extra signal memory in generated code.
| Conditions | Recommended Action |
|---|---|
| Signals are logged. | Disable signal logging on all signals. |
Clicking Modify All disables signal logging on all logged signals.
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 each block to ensure that your application requires setting Function Block Parameters > Signal Attributes > Saturate on integer overflow. Otherwise, clear the Saturate on integer overflow parameter to ensure 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 appropriate for 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 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, Real-Time Workshop code contains statements as needed to ensure bit-true agreement for the results of integer and fixed-point division in simulation, production code, and test code. Such statements add overhead when the code executes.
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 all 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 Real-Time Workshop 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 Real-Time Workshop 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 correctly 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 sufficient range and precision to represent each input, making the relational operation error-free.
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.
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.
| Condition | 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 Lookup Table (n-D) 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. | |
| Lookup Table (n-D) 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. | |
| Lookup Table (n-D) 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. | |
| Lookup Table (n-D) 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. | |
| Lookup Table (n-D) 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 factor. | |
| 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 factor. | Change the scaling of either input. | |
| 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). |
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 Real-Time Workshop Recommended Settings Summary
The Real-Time Workshop Embedded Coder Recommended Settings Summary
Configuring Code Generation Objectives in the Real-Time Workshop User's Guide.
Mapping Application Objectives to Model Configuration Parameters in the Real-Time Workshop Embedded Coder documentation.
![]() | Model Advisor Checks |

Learn more about Simulink through this collection of videos, articles, technical literature and the Getting Started with Simulink Guide.
| © 1984-2009- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |