| Simulink® | |
Set up optimizations for a model's active configuration set. Optimizations are set for both simulation and code generation.
Set the parameters displayed.
Stateflow® software optimizations appear only when Real-Time Workshop® and Stateflow products are both installed on your system and the model includes Stateflow charts or Embedded MATLAB™ Function blocks. The settings you make for the Stateflow software options also apply to all Embedded MATLAB Function blocks in the model. You do not need a Stateflow license to use Embedded MATLAB Function blocks.
Reduce execution time by collapsing or removing groups of blocks.
Default: On
OnSimulink® software searches for and reduces the following block patterns:
Accumulators — A group consisting of a Constant block, a Sum block, and feedback through a Unit Delay block.
Redundant type conversions — Unnecessary type conversion blocks, such as an int type conversion block with an input and output of type int.
Dead code — Blocks or signals in an unused code path.
Fast-to-slow Rate Transition block in a single-tasking system — Rate Transition blocks with an input frequency faster than its output frequency.
OffSimulink software does not search for block patterns that can be optimized. Simulation and generated code are not optimized.
When you select Block reduction, Simulink software collapses certain groups of blocks into a single, more efficient block, or removes them entirely. This results in faster execution during model simulation and in generated code.
Block reduction does not change the appearance of the source model.
Tunable parameters do not prevent a block from being reduced by dead code elimination.
Once block reduction takes place, Simulink software does not display the sorted order for blocks that have been removed.
Block reduction is intended to remove only the generated code that represents execution of a block. Other supporting data, such as definitions for sample time and data types might remain in the generated code.
Accumulators. Simulink software recognizes the block diagram shown in the following figure as an accumulator:
An accumulator construct is recognized anywhere across a block diagram, or within subsystems at lower levels.
With the Block reduction option enabled, Simulink software creates a synthesized block, Sum_synth_accum. The synthesized block replaces the previous block diagram, resulting in a simple increment calculation.
Dead Code Elimination. Any blocks or signals in an unused code path are eliminated from generated code.
The following conditions need to be met for a block to be considered part of an unused code path:
All signal paths for the block end with a block that does not execute. Examples of blocks that do not execute include Terminator blocks, disabled Assertion blocks, S-Function blocks configured for block reduction, and To Workspace blocks for which MAT-file logging is disabled for code generation.
No signal paths for the block include global signal storage downstream from the block.
Tunable parameters do not prevent a block from being reduced by dead code elimination.
Consider the signal paths in the following block diagram.
If you check Block reduction, Real-Time Workshop software responds to each signal path as follows:
| For Signal Path... | Real-Time Workshop Software... |
|---|---|
| In1 to Out1 | Always generates code because dead code elimination conditions are not met. |
| In2 to Terminator | Never generates code because dead code elimination conditions are met. |
| In3 to Scope | Generates code if MAT-file logging is enabled and eliminates code if MAT-file logging is disabled. |
| Parameter: BlockReduction |
| Type: string |
| Value: 'on' | 'off' |
| Default: 'on' |
| Application | Setting |
|---|---|
| Debugging | Off (for simulation and during development) No impact (for production code generation) |
| Traceability | Off |
| Efficiency | On |
| Safety precaution | Off |
Improve model execution when the model contains Switch and Multiport Switch blocks.
Default: On
On Executes only the blocks required to compute the control input and the data input selected by the control input. This optimization speeds execution of code generated from the model. Limits to Switch block optimization:
Only blocks with -1 (inherited) or inf (Constant) sample time can participate.
Blocks with outputs flagged as test points cannot participate.
No multirate block can participate.
Blocks with states cannot participate.
Only S-functions with option SS_OPTION_CAN_BE_CALLED_CONDITIONALLY set can participate.
OffExecutes all blocks driving the Switch block input ports at each time step.
| Parameter: ConditionallyExecuteInputs |
| Type: string |
| Value: 'on' | 'off' |
| Default: 'on' |
| Application | Setting |
|---|---|
| Debugging | No impact |
| Traceability | On |
| Efficiency | On |
| Safety precaution | Off |
Transform tunable parameters into constant values.
Default: Off
OnEnabling Inline parameters has the following effects:
Real-Time Workshop software uses the numerical values of model parameters, instead of their symbolic names, in generated code.
Reduces global RAM usage, because parameters are not declared in the global parameters structure.
The Configure button becomes enabled. Clicking the Configure button opens the Model Parameter Configuration dialog box.
Off Uses symbolic names for model parameters in generated code.
Simulink software allows you to override the Inline parameters option for parameters whose values are defined by variables in the MATLAB® workspace. To specify that such a parameter remain tunable, specify the parameter as global in the Model Configuration Parameters dialog box (see Model Parameter Configuration Dialog Box). To display the dialog box, click the adjacent Configure button.
To tune a global parameter, change the value of the corresponding workspace variable and select Update Diagram (Ctrl+D) from the Simulink Edit menu.
You cannot tune inlined parameters in code generated from a model. However, when simulating a model, you can tune an inlined parameter if its value derives from a workspace variable. For example, suppose that a model has a Gain block whose Gain parameter is inlined and equals a, where a is a variable defined in the model's workspace. When simulating the model, Simulink software disables the Gain parameter field, preventing you from using the block's dialog box to change the gain. However, you can still tune the gain by changing the value of a at the MATLAB command line and updating the diagram.
When a top-level model uses referenced models:
All referenced models must specify Inline parameters to be on.
The top-level model can specify Inline parameters to be on or off.
See Inline Parameter Requirements for more information.
This parameter enables:
Configure button
Inline invariant signals
| Parameter: InlineParams |
| Type: string |
| Value: 'on' | 'off' |
| Default: 'off' |
| Application | Setting |
|---|---|
| Debugging | Off (for simulation and during development) On (for production code generation) |
| Traceability | On |
| Efficiency | On |
| Safety precaution | No impact |
Controls the output data type of blocks that generate logic signals.
Default: On
On Blocks that generate logic signals output a signal of boolean data type. This reduces the memory requirements of generated code.
OffBlocks that generate logic signals output a signal of double data type. This ensures compatibility with models created by earlier versions of Simulink software.
Setting this option on reduces the memory requirements of generated code, because a Boolean signal typically requires one byte of storage compared to eight bytes for a double signal.
Setting this option off allows the current version of Simulink software to run models that were created by earlier versions of Simulink software that supported only signals of type double.
This optimization affects the following blocks:
Logical Operator block – This parameter affects only those Logical Operator blocks whose Output data type mode parameter specifies Logical. If this parameter is selected, such blocks output a signal of boolean data type; otherwise, such blocks output a signal of double data type.
Relational Operator block – This parameter affects only those Relational Operator blocks whose Output data type mode parameter specifies Logical. If this parameter is selected, such blocks output a signal of boolean data type; otherwise, such blocks output a signal of double data type.
Combinatorial Logic block – If this parameter is selected, Combinatorial Logic blocks output a signal of boolean data type; otherwise, they output a signal of double data type. See Combinatorial Logic in the Simulink Reference for an exception to this rule.
Hit Crossing block – If this parameter is selected, Hit Crossing blocks output a signal of boolean data type; otherwise, they output a signal of double data type.
This parameter is disabled for models created with a version of Simulink software that supports only signals of type double.
| Parameter: BooleanDataType |
| Type: string |
| Value: 'on' | 'off' |
| Default: 'on' |
| Application | Setting |
|---|---|
| Debugging | No impact |
| Traceability | No impact |
| Efficiency | On |
| Safety precaution | On |
Reuse signal memory.
Default: On
On Simulink software reuses memory buffers allocated to store block input and output signals, reducing the memory requirement of your real-time program.
OffSimulink software allocates a separate memory buffer for each block's outputs. This makes all block outputs global and unique, which in many cases significantly increases RAM and ROM usage.
This option applies only to signals with storage class Auto.
Turning this option off can substantially increase the amount of memory required to simulate large models.
Disable this option if you need to:
Debug a C-MEX S-function
Use a Floating Scope or a Display block with the Floating display option selected to inspect signals in a model that you are debugging
Simulink software opens an error dialog if Signal storage reuse is enabled and you attempt to use a Floating Scope or floating Display block to display a signal whose buffer has been reused.
This parameter enables:
Enable local block outputs
Reuse block outputs
Eliminate superfluous temporary variables (Expression folding)
| Parameter: OptimizeBlockIOStorage |
| Type: string |
| Value: 'on' | 'off' |
| Default: 'on' |
| Application | Setting |
|---|---|
| Debugging | Off |
| Traceability | Off |
| Efficiency | On |
| Safety precaution | No impact |
Specify how long (in days) an application that contains blocks depending on elapsed or absolute time should be able to execute before timer overflow.
Default: inf
Min: Must be greater
than zero
Max: inf
Enter a positive (nonzero) scalar value (for example, 0.5) or inf.
If you are licensed for the Real-Time Workshop® Embedded Coder™ product and select an ERT target for your model, the default value for Application lifespan (days) is 1.
This parameter is ignored when you are operating your model in external mode, have Mat-file logging enabled, or have a continuous sample time because a 64 bit timer is required in these cases.
Specifying a lifespan, along with the simulation step size, determines the data type used by blocks to store absolute time values.
For simulation, setting this parameter to a value greater than the simulation time will ensure time does not overflow.
Simulink software evaluates this parameter first against the model workspace. If this does not resolve the parameter, Simulink software then evaluates it against the base workspace.
The Application lifespan also determines the word size used by timers in the generated code, which can lower RAM usage. For more information, see Timing Services in the Real-Time Workshop documentation.
Application lifespan, when combined with the step size of each task, determines the data type used for integer absolute time for each task, as follows:
If your model does not require absolute time, this option affects neither simulation nor the generated code.
If your model requires absolute time, this option optimizes the word size used for storing integer absolute time in generated code. This ensures that timers do not overflow within the lifespan you specify. If you set Application lifespan to inf, two uint32 words are used.
If your model contains fixed-point blocks that require absolute time, this option affects both simulation and generated code.
For example, using 64 bits to store timing data enables models with a step size of 0.001 microsecond (10E-09 seconds) to run for more than 500 years, which would rarely be required. To run a model with a step size of one millisecond (0.001 seconds) for one day would require a 32-bit timer (but it could continue running for 49 days).
A timer will allocate 64 bits of memory if you specify a value of inf.
To minimize the amount of RAM used by time counters, specify a lifespan no longer than necessary.
Must be the same for top and referenced models.
Optimize the size of counters used to compute absolute and elapsed time.
| Parameter: LifeSpan |
| Type: string |
| Value: positive (nonzero) scalar value or inf |
| Default: 'inf' |
| Application | Setting |
|---|---|
| Debugging | No impact |
| Traceability | No impact |
| Efficiency | Finite value |
| Safety precaution | inf |
Control how parameter data is generated for reusable subsystems.
Default: NonHierarchical
Generates a separate header file, defining an independent parameter structure, for each subsystem that meets the following conditions:
The subsystem's Real-Time Workshop system code parameter is set to Reusable function.
The subsystem does not violate any code reuse limitations.
The subsystem does not access parameters other than its own (such as parameters of the root-level model).
Each subsystem parameter structure is referenced as a substructure of the root-level parameter data structure, creating a structure hierarchy.
Generates a single, flat parameter data structure. Subsystem parameters are defined as fields within the structure. A nonhierarchical data structure can reduce compiler padding between word boundaries, producing more efficient compiled code.
This parameter requires a Real-Time Workshop license.
Inline parameters must be enabled.
| Parameter: InlinedParameterPlacement |
| Type: string |
| Value: 'Hierarchical' | 'NonHierarchical' |
| Default: 'NonHierarchical' |
| Application | Setting |
|---|---|
| Debugging | No impact |
| Traceability | Hierarchical |
| Efficiency | NonHierarchical |
| Safety precaution | No impact |
Specify whether block signals are declared locally or globally.
Default: On
If it is not possible to declare an output as a local variable, the generated code declares the output as a global variable.
If you are constrained by limited stack space, you can turn Enable local block outputs off and still benefit from memory reuse.
This parameter requires a Real-Time Workshop license.
This parameter is enabled by Signal storage reuse.
| Parameter: LocalBlockOutputs |
| Type: string |
| Value: 'on' | 'off' |
| Default: 'on' |
| Application | Setting |
|---|---|
| Debugging | Off |
| Traceability | No impact |
| Efficiency | On |
| Safety precaution | No impact |
Specify how Real-Time Workshop software handles casting of intermediate variables in mixed-bit systems.
Default: Off (GUI), 'on' (command-line)
OnReal-Time Workshop software collapses block computations into a single expression, avoiding casts of intermediate variables, improving efficiency. Check this parameter if:
You are concerned with generating the least amount of code possible.
Code generation and simulation results do not need to match.
Off (default)The results of 8- and 16-bit integer expressions are explicitly downcast.
To ensure consistency between simulation and code generation, the results of 8 and 16-bit integer expressions must be explicitly downcast. Selecting this option improves code efficiency by avoiding casts of intermediate variables.
Expressions involving 8- and 16-bit arithmetic are less likely to overflow in code than they are in simulation. Therefore, it is good practice to turn off Ignore integer downcasts in folded expressions for safety, to ensure that answers obtained from generated code are consistent with simulation results.
This parameter requires a Real-Time Workshop license.
| Parameter: EnforceIntegerDowncast |
| Type: string |
| Value: 'on' | 'off' |
| Default: 'on' |
Note The command-line values are reverse of the settings values. Therefore, 'on' in the command line corresponds to the description of "Off" in the settings section, and 'off' in the command line corresponds to the description of "On" in the settings section. |
| Application | Setting |
|---|---|
| Debugging | Off |
| Traceability | No impact |
| Efficiency | On |
| Safety precaution | Off |
Collapse block computations into single expressions.
Default: On
On Enables expression folding.
Eliminates temporary variables, incorporating the information into the main code statement.
Improves code readability and efficiency.
OffDisables expression folding.
This parameter requires a Real-Time Workshop license.
This parameter is enabled by Signal storage reuse.
| Parameter: ExpressionFolding |
| Type: string |
| Value: 'on' | 'off' |
| Default: 'on' |
| Application | Setting |
|---|---|
| Debugging | Off |
| Traceability | No impact (for simulation and during development) Off (for production code generation) |
| Efficiency | On |
| Safety precaution | No impact |
Specify whether Real-Time Workshop software reuses signal memory.
Default: On
On (default)Real-Time Workshop software reuses signal memory whenever possible, reducing stack size where signals are being buffered in local variables.
Selecting this parameter trades code traceability for code efficiency.
OffSignals are stored in unique locations.
This parameter requires a Real-Time Workshop license.
This parameter is enabled by Signal storage reuse.
| Parameter: BufferReuse |
| Type: string |
| Value: 'on' | 'off' |
| Default: 'on' |
| Application | Setting |
|---|---|
| Debugging | Off |
| Traceability | Off |
| Efficiency | On |
| Safety precaution | No impact |
Transform symbolic names of invariant signals into constant values.
Default: Off
OnReal-Time Workshop software uses the numerical values of model parameters, instead of their symbolic names, in generated code. An invariant signal is not inlined if it is nonscalar, complex, or the block inport the signal is attached to takes the address of the signal.
Off Uses symbolic names of model parameters in generated code.
This parameter requires a Real-Time Workshop license.
This parameter is enabled by Inline parameters.
| Parameter: InlineInvariantSignals |
| Type: string |
| Value: 'on' | 'off' |
| Default: 'off' |
| Application | Setting |
|---|---|
| Debugging | Off |
| Traceability | Off |
| Efficiency | On |
| Safety precaution | No impact |
Specify the minimum signal or parameter width for which a for loop is generated.
Default: 5
Specify the array size at which the code generator begins to use a for loop instead of separate assignment statements to assign values to the elements of a signal or parameter array.
When there are perfectly nested loops, the code generator uses a for loop if the product of the loop counts for all loops in the perfect loop nest is greater than or equal to the threshold.
This parameter requires a Real-Time Workshop license.
| Parameter: RollThreshold |
| Type: string |
| Value: any valid value |
| Default: '5' |
| Application | Setting |
|---|---|
| Debugging | No impact |
| Traceability | No impact |
| Efficiency | >0 |
| Safety precaution | >1 |
Specify whether to generate initialization code for root-level inports and outports set to zero.
Default: Off (GUI), 'on' (command-line)
On Does not generate initialization code for root-level inports and outports set to zero.
OffGenerates initialization code for all root-level inports and outports. You should use the default:
To ensure that memory allocated for C MEX S-function wrappers is initialized to zero
For safety-critical applications that require that all internal and external data be initialized to zero
This parameter requires a Real-Time Workshop license.
This parameter only appears for ERT-based targets.
| Parameter: ZeroExternalMemoryAtStartup |
| Type: string |
| Value: 'off' | 'on' |
| Default: 'on' |
Note The command-line values are reverse of the settings values. Therefore, 'on' in the command line corresponds to the description of "Off" in the settings section, and 'off' in the command line corresponds to the description of "On" in the settings section. |
| Application | Setting |
|---|---|
| Debugging | No impact |
| Traceability | No impact |
| Efficiency | On |
| Safety precaution | Off |
Specify whether to generate code that explicitly initializes floating-point data to 0.0.
Default: Off
On Uses memset to clear internal storage for floating-point data to integer bit pattern 0 (all bits 0), regardless of type. An example of a case for selecting this option is to gain compiler efficiency when the compiler and target CPU both represent floating-point zero with the integer bit pattern 0.
OffGenerates extra code to explicitly initialize storage for data of types float and double to 0.0. The resulting code is slightly less efficient than code generated when you select the option.
You should not select this option if you need to ensure that memory allocated for C MEX S-function wrappers is initialized to zero.
This parameter requires a Real-Time Workshop Embedded Coder license.
This parameter only appears for ERT-based targets.
| Parameter: InitFltsAndDblsToZero |
| Type: string |
| Value: 'on' | 'off' |
| Default: 'off' |
| Application | Setting |
|---|---|
| Debugging | No impact |
| Traceability | No impact |
| Efficiency | On |
| Safety precaution | No impact |
Specify whether to generate initialization code for internal work structures, such as block states and block outputs, to zero.
Default: Off (GUI), 'on' (command-line)
On Does not generate code that initializes internal work structures to zero. An example of when you might select this option is to test the behavior of a design during warm boot—a restart without full system reinitialization.
Selecting this option does not guarantee that memory is in a known state each time the generated code begins execution. When you run a model or generated S-function multiple times, each run can produce a different answer.
If want to get the same answer on every run from a generated S-function, enter the command clear SFcnNam or clear mex in the MATLAB Command Window before each run.
OffGenerates code that initializes internal work structures to zero. You should use the default:
To ensure that memory allocated for C MEX S-function wrappers is initialized to zero
For safety critical applications that require that all internal and external data be initialized to zero
This parameter requires a Real-Time Workshop Embedded Coder license.
This parameter only appears for ERT-based targets.
| Parameter: ZeroInternalMemoryAtStartup |
| Type: string |
| Value: 'off' | 'on' |
| Default: 'on' |
Note The command-line values are reverse of the settings values. Therefore, 'on' in the command line corresponds to the description of "Off" in the settings section, and 'off' in the command line corresponds to the description of "On" in the settings section. |
| Application | Setting |
|---|---|
| Debugging | No impact |
| Traceability | No impact |
| Efficiency | On |
| Safety precaution | Off |
Specify whether to generate initialization code for blocks that have states.
Default: on
On Suppresses generation of initialization code for blocks that have states unless the blocks are in a system that can reset its states, such as an enabled subsystem. This results in more efficient code, but requires that you not refer to the model from a Model block that resides in a system that resets states. If you violate this constraint, Simulink software reports an error, in which case you can disable this optimization.
OffGenerates initialization code for all blocks that have states. Disable this option if the current model includes a subsystem that resets states, such as an enabled subsystem, and the model is referred to from another model with a Model block.
This parameter requires a Real-Time Workshop Embedded Coder license.
This parameter only appears for ERT-based targets.
You must disable this option if your model includes enabled subsystem and model is referred to from another model with Model block.
| Parameter: OptimizeModelRefInitCode |
| Type: string |
| Value: 'on' | 'off' |
| Default: 'on' |
| Application | Setting |
|---|---|
| Debugging | No impact |
| Traceability | No impact |
| Efficiency | On |
| Safety precaution | No impact |
Remove wrapping code that handles out-of-range floating-point to integer conversion results.
Default: Off
OnRemoves code that ensures the execution of the generated code produces the same results as simulation when out-of-range conversions occur. Select this parameter if code efficiency is critical to your application and the following conditions are true for at least one block in the model:
Computing the block's outputs or parameters involves converting floating-point data to integer or fixed-point data.
The block's Saturate on integer overflow parameter is disabled.
Off Out-of-range values simulation and generated code results match. The generated code is larger than when this parameter is checked.
Enabling this parameter reduces the size and increases the speed of the generated code at the cost of potentially producing results that do not match simulation in the case of out-of-range values.
Enabling this parameter affects code generation results only for out-of-range values and cannot cause code generation results to differ from simulation results for in-range values.
The code generator uses the fmod function to handle out-of-range conversion results.
The following code fragment shows the code generated for a conversion with this option disabled.
_fixptlowering0 = (rtb_Switch[i1] + 9.0) / 0.09375;
_fixptlowering1 = fmod(_fixptlowering0 >= 0.0 ?
floor(_fixptlowering0) :
ceil(_fixptlowering0), 4.2949672960000000E+009);
if(_fixptlowering1 < -2.1474836480000000E+009) {
_fixptlowering1 += 4.2949672960000000E+009;
} else if(_fixptlowering1 >= 2.1474836480000000E+009) {
_fixptlowering1 -= 4.2949672960000000E+009;
}
cg_in_0_20_0[i1] = (int32_T)_fixptlowering1;
The code generated for the conversion when you select this optimization follows:
cg_in_0_20_0[i1] = (int32_T)((rtb_Switch[i1] + 9.0) / 0.09375);
This parameter requires a Real-Time Workshop license.
| Parameter: EfficientFloat2IntCast |
| Type: string |
| Value: 'on' | 'off' |
| Default: 'off' |
| Application | Setting |
|---|---|
| Debugging | Off |
| Traceability | Off |
| Efficiency | On |
| Safety precaution | Off (for simulation and during development) On (for production code generation) |
Specify whether to generate code that guards against division by zero for fixed-point data.
Default: on
On Does not generate code that guards against division by zero for fixed-point data. When you select this option, simulation results and results from generated code might not be in bit-for-bit agreement.
OffGenerates code that guards against division by zero for fixed-point data.
This parameter requires a Real-Time Workshop Embedded Coder license.
This parameter only appears for ERT-based targets.
| Parameter: NoFixptDivByZeroProtection |
| Type: string |
| Value: 'on' | 'off' |
| Default: 'on' |
| Application | Setting |
|---|---|
| Debugging | No impact |
| Traceability | No impact |
| Efficiency | On |
| Safety precaution | Off |
Use bitsets to reduce the amount of memory required to store state configuration variables.
Default: Off
OnStores state configuration variables in bitsets. Potentially reduces the amount of memory required to store the variables. Potentially requires more instructions to access state configuration, which can result in less optimal code.
OffStores state configuration variables in unsigned bytes. Potentially increases the amount of memory required to store the variables. Potentially requires fewer instructions to access state configuration, which can result in more optimal code.
Enabling this parameter can significantly reduce the amount of memory required to store the variables. However, it can increase the amount of memory required to store target code if the target processor does not include instructions for manipulating bitsets.
Enable this setting for Stateflow charts that have a large number of sibling states at a given level of hierarchy.
Disable this setting for Stateflow charts with a small number of sibling states at a given level of hierarchy.
| Parameter: statebitsets |
| Type: Boolean |
| Value: 1 | 0 |
| Default: 0 |
| Application | Setting |
|---|---|
| Debugging | Off |
| Traceability | Off |
| Efficiency | Off |
| Safety precaution | No impact |
Use bitsets to reduce the amount of memory required to store Boolean data.
Default: Off
On Stores Boolean data in bitsets. Potentially reduces the amount of memory required to store the data. Potentially requires more instructions to access the data, which can result in less optimal code.
OffStores Boolean data in unsigned bytes. Potentially increases the amount of memory required to store the data. Potentially requires fewer instructions to access the data, which can result in more optimal code.
Enable this setting for Stateflow charts that reference Boolean data infrequently.
Disable this setting for Stateflow charts that reference Boolean data frequently.
| Parameter: databitsets |
| Type: Boolean |
| Value: 1 | 0 |
| Default: 0 |
| Application | Setting |
|---|---|
| Debugging | Off |
| Traceability | Off |
| Efficiency | Off |
| Safety precaution | No impact |
Minimize global array read operations by using temporary variables. In certain microprocessors, global array read operations are more expensive than accessing a temporary variable on the stack.
Default: Off
Enable this setting if your target tolerates large stack frames.
In certain microprocessors, global array read operations are more expensive than accessing a temporary variable on stack. Using this option minimizes array reads by using temporary variables when possible.
For example, the generated code
a[i] = foo();
if(a[i]<10 && a[i]>1) {
y = a[i]+5;
}else{
z = a[i];
}
now becomes
a[i] = foo();
temp = a[i];
if(temp<10 && temp>1) {
y = temp+5;
}else{
z = temp;
}| Parameter: redundantloadelimination |
| Type: Boolean |
| Value: 1 | 0 |
| Default: 0 |
| Application | Setting |
|---|---|
| Debugging | No impact |
| Traceability | No impact |
| Efficiency | On |
| Safety precaution | No impact |
The Model Parameter Configuration dialog box allows you to override the Inline parameters option (see Inline parameters) for selected parameters.
Note Simulink software ignores the settings of this dialog box if a model contains references to other models. However, you can still tune parameters of such models, using Simulink.Parameter objects (see Inline Parameter Requirements for more information). |
The dialog box has the following controls.
Displays a list of workspace variables. The options are:
MATLAB workspace
Lists all variables in the MATLAB workspace that have numeric values.
Referenced workspace variables
Lists only those variables referenced by the model.
Updates the source list. Click this button if you have added a variable to the workspace since the last time the list was displayed.
Adds the variables selected in the source list to the adjacent table of tunable parameters.
Defines a new parameter and adds it to the list of tunable parameters. Use this button to create tunable parameters that are not yet defined in the MATLAB workspace.
Note This option does not create the corresponding variable in the MATLAB workspace. You must create the variable yourself. |
Used for code generation. See the Real-Time Workshop® User's Guide for more information.
Used for code generation. See the Real-Time Workshop® User's Guide for more information.
Sets the degree of optimization used by the compiler when generating code for acceleration.
Default: Optimizations off (faster builds)
Specifies the compiler not to optimize code. This results in faster build times.
Specifies the compiler to generate optimized code. The generated code will run faster, but the model build will take longer than if optimizations are off.
The default Optimizations off is a good choice for most models. This quickly produces code that can be used with acceleration.
Set Optimizations on to optimize your code. The fast running code produced by optimization can be advantageous if you will repeatedly run your model with the accelerator.
| Parameter: SimCompilerOptimization |
| Type: string |
| Value: 'on' | 'off' |
| Default: 'off' |
| Application | Setting |
|---|---|
| Debugging | No impact |
| Traceability | No impact |
| Efficiency | No impact |
| Safety precaution | No impact |
Select the amount of information displayed during code generation.
Default: Off
OffDisplay limited amount of information during the code generation process.
On Display progress information during code generation, and show the compiler options in use.
| Parameter: AccelVerboseBuild |
| Type: string |
| Value: 'on' | 'off' |
| Default: 'off' |
| Application | Setting |
|---|---|
| Debugging | No impact |
| Traceability | No impact |
| Efficiency | No impact |
| Safety precaution | No impact |
For more information about AccelVerboseBuild , see Controlling Information During Code Generation.
| Data Import/Export Pane | Diagnostics Pane: Solver | |
| © 1984-2008- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |