|
|
|
| R2011b Documentation → Simulink | |
Learn more about Simulink |
|
| Contents | Index |
Specify the options for including other models in this model, this model in other models, and for building simulation and code generation targets.
Set the parameters displayed.
The Model Referencing pane allows you to specify options for:
Including other models in this model.
Including the current model in other models.
The option descriptions use the term this model to refer to the model that you are configuring and the term referenced model to designate models referenced by this model.
Select the method used to determine when to rebuild simulation and Simulink Coder targets for referenced models before updating, simulating, or generating code from this model.
There are four rebuild options. Two options, Always and Never, either always rebuild the model reference target or never rebuild the target, respectively. The other two options (If any changes detected and If any changes in known dependencies detected) cause Simulink to check the model and its dependencies to determine whether or not to rebuild the model reference target. As part of this checking, Simulink:
Automatically identifies a set of "known" target dependencies that it examines for changes.
May compute the model's structural checksum, which reflects changes to the model that can affect simulation results.
For additional background information to help you determine which rebuild option setting to use, see the "Definitions" and "Tips" sections.
Default: If any changes detected
Always rebuild targets referenced by this model before simulating, updating, or generating code from this model.
Rebuild a target for a referenced model if Simulink detects a change that could affect simulation results. To do this, Simulink first looks for changes to the known target dependencies and to the model, and, if none are found, it then computes the structural checksum of the model to check that the model reference target is up to date.
Rebuild a target if Simulink detects a change in known target dependencies or in both the model and its structural checksum. If Simulink does not detect a change in known target dependencies or the model, it does not compute the structural checksum of the model and does not rebuild the model reference target. You must list all user-created dependencies in the Model dependencies parameter.
Never rebuild targets referenced by this model before simulating, updating, or generating code from this model.
Known target dependencies are files and data outside of .mdl files that Simulink examines for changes when checking to see if a model reference target is up to date. Simulink automatically computes a set of known target dependencies. Simulink examines the known target dependencies to determine whether they have changed, which it can do quickly. Examples of known target dependencies are:
Global variables
Changes to the model workspace, if its data source is a MAT-file or MATLAB file
Enumerated type definitions
User-written S-functions and their TLC files
Files specified in the Model dependencies parameter
Although Simulink automatically examines every known target dependency, you can have files that can impact the simulation results of your model that Simulink does not automatically identify. Some examples of user-created dependencies are:
MATLAB files that contain code executed by callbacks
MAT-files that contain definitions for variables used by the model that are loaded as part of a customized initialization script
You can add user-created dependencies to the set of known target dependencies by using the Model dependencies parameter.
As part of determining whether a model reference target is up to date, Simulink may compute the structural checksum of a model, which reflects changes to the model that can affect simulation results.
When Simulink computes the structural checksum, it loads and compiles the model. To compile the model, Simulink must execute callbacks and access all variables that the model uses. As a result, the structural checksum reflects changes to the model that can affect simulation results, including changes in user-created dependencies, regardless of whether you have specified those user-created dependencies in the Model dependencies parameter.
For more information about the kinds of changes that affect the structural checksum, see the Simulink.BlockDiagram.getChecksum documentation.
You do not need to have the same rebuild option setting for every model in a model reference hierarchy. When you simulate, update, or generate code for a model, the rebuild option setting for that model applies to all models that it references.
To improve rebuild detection speed and accuracy, use the Model dependencies parameter to specify user-created dependencies. If you use the If any changes in known dependencies detected rebuild option, then specify all user-created dependencies for your model in the Model dependencies parameter.
Each rebuild option setting has benefits and limitations, depending on your rebuild goal. The following table lists the options in the order of the thoroughness of rebuild detection. For detailed information about how Simulink determines whether a model reference target is out of date, see the Change Detection Processing table, which is part of the next tip.
Benefits and Limitations of Each Option
| Rebuild Goal | Rebuild Option Setting | Notes |
|---|---|---|
Make all the model reference targets up to date. | Always | Requires the most processing time. Can trigger unnecessary builds before simulating, updating, or generating code from a referenced model. Before you deploy a model, use the Always setting. |
Perform extensive detection of changes to dependencies of the referenced models. | If any changes detected | Default. Reduces the number of rebuilds, compared to the Always setting. Detects changes in the dependencies of the target, as well as changes in the structural checksum of the referenced model. The structural checksum can detect changes that occur in user-created dependencies that are not specified with the Model dependencies parameter. |
Reduce time required for rebuild detection. | If any changes in known dependencies detected | Reduces the number of rebuilds, compared to the If any changes detected option. Ignores cosmetic changes, such as annotation changes, in the referenced model and its libraries. Subset of the checks performed by the If any changes detected option. Invalid simulation results may occur if you do not specify with the Model dependencies parameter every user-created dependency. |
Avoid rebuilds during model development. | Never | Least amount of processing time, but requires that you ensure that the model reference targets are up to date. If you are certain that the model reference targets are up to date, you can use this option to avoid target dependency checking when simulating, updating, or generating code from a model. May lead to invalid results if referenced model targets are not in fact up to date. To have Simulink check for changes in known target dependencies and report if the model reference targets may be out of date, use the Never rebuild diagnostic parameter. To manually rebuild model reference targets, use the slbuild function. |
To detect whether to perform a rebuild, Simulink uses different processing for each Rebuild setting. The following table summarizes the main types of change detection checks that Simulink performs.
Change Detection Processing
| Rebuild Option Setting | Simulink Change Detection Processing |
|---|---|
Always | Does no change detection processing. Always rebuilds targets referenced by this model before simulating, updating, or generating code from this model. |
If any changes detected and If any changes in known dependencies detected | For both If any changes detected and If any changes in known dependencies detected, starts by checking for changes in known target dependencies. If finds changes, then triggers a rebuild. If does not find changes, looks for changes in .mdl files of the model and its libraries.
If you are unsure whether the list of files specified in the Model dependencies parameter is complete, use the If any changes detected rebuild option. |
Never | Change detection processing determined by the Never rebuild diagnostic parameter. |
The following examples illustrate differences between the If any changes detected and If any changes in known dependencies detected options.
If you change a MATLAB file that is executed as part of a callback script (or other user-created dependency) that you have not listed in the Model dependencies parameter:
If any changes detected – Causes a rebuild, because the change to the file changes the structural checksum of the model.
If any changes in known dependencies detected – Does not cause a rebuild, because no known target dependency has changed.
If you move a block in a model:
If any changes detected – Causes a rebuild, because the model has changed.
If any changes in known dependencies detected – Does not cause a rebuild, because this change does not change the model's structural checksum.
Selecting Never enables the Never rebuild diagnostic parameter.
| Parameter: UpdateModelReferenceTargets |
| Type: string |
| Value: 'Force' | 'IfOutOfDateOrStructuralChange' | 'IfOutOfDate' | 'AssumeUpToDate' |
| Default: 'IfOutOfDateOrStructuralChange' |
| UpdateModelReferenceTargets Value | Equivalent Rebuild Value |
|---|---|
| 'Force' | Always |
| 'IfOutOfDateOrStructuralChange' | If any changes detected |
| 'IfOutOfDate' | If any changes in known dependencies detected |
| 'AssumeUpToDate' | Never |
| Application | Setting |
|---|---|
| Debugging | No impact |
| Traceability | No impact |
| Efficiency | No impact |
| Safety precaution | If any changes detected or Never If you use the Never setting, then set the Never rebuild diagnostic parameter to Error if rebuild required. |
Select the diagnostic action that Simulink software should take if it detects a model reference target that needs to be rebuilt.
Default: Error if rebuild required
Simulink takes no action.
Simulink displays a warning.
Simulink terminates the simulation and displays an error message.
If you set the Rebuild parameter to Never and set the Never rebuild diagnostic parameter to Error if rebuild required or Warn if rebuild required, then Simulink:
Performs the same change detection processing as for the If any changes in known dependencies detected rebuild option setting, except it does not compare structural checksums
Issues an error or warning (depending on the Never rebuild diagnostic setting), if it detects a change
Never rebuilds the model reference target
Selecting None bypasses dependency checking, and thus enables faster updating, simulation, and code generation. However, the None setting can cause models that are not up to date to malfunction or generate incorrect results. For more information on the dependency checking, see Rebuild.
This parameter is enabled only if you select Never in the Rebuild field.
| Parameter: CheckModelReferenceTargetMessage |
| Type: string |
| Value: 'none' | 'warning' | 'error' |
| Default: 'error' |
| Application | Setting |
|---|---|
| Debugging | No impact |
| Traceability | No impact |
| Efficiency | No impact |
| Safety precaution | Error if rebuild required |
Specify whether to use automatic parallel building of the model reference hierarchy whenever possible.
Default: Off
On Simulink software builds the model reference hierarchy in parallel whenever possible (based on computing resources and the structure of the model reference hierarchy).
OffSimulink never builds the model reference hierarchy in parallel.
Selecting this option enables the MATLAB worker initialization for builds parameter.
| Parameter: EnableParallelModelReferenceBuilds |
| Type: string |
| Value: 'on' | 'off' |
| Default: 'off' |
| Application | Setting |
|---|---|
| Debugging | No impact |
| Traceability | No impact |
| Efficiency | No impact |
| Safety precaution | No impact |
Reducing Build Time for Referenced Models in the Simulink Coder documentation
Specify how to initialize MATLAB workers for parallel builds.
Default: None
Simulink software takes no action. Specify this value if the child models in the model reference hierarchy do not rely on anything in the base workspace beyond what they explicitly set up (for example, with a model load function).
Simulink attempts to copy the base workspace to each MATLAB worker. Specify this value if you use a setup script to prepare the base workspace for all models to use.
Simulink loads the top model on each MATLAB worker. Specify this value if the top model in the model reference hierarchy handles all of the base workspace setup (for example, with a model load function).
For values other than None, limitations apply to global variables in the base workspace. Global variables are not propagated across parallel workers and do not reflect changes made by top and child model scripts.
Selecting the option Enable parallel model reference builds enables this parameter.
| Parameter: ParallelModelReferenceMATLABWorkerInit |
| Type: string |
| Value: 'None' | 'Copy Base Workspace' | 'Load Top Model' |
| Default: 'None' |
| Application | Setting |
|---|---|
| Debugging | No impact |
| Traceability | No impact |
| Efficiency | No impact |
| Safety precaution | No impact |
Reducing Build Time for Referenced Models in the Simulink Coder documentation
Specify how many references to this model can occur in another model.
Default: Multiple
The model cannot be referenced. An error occurs if a reference to the model occurs in another model.
The model can be referenced at most once in a model reference hierarchy. An error occurs if more than one reference exists.
The model can be referenced more than once in a hierarchy, provided that it contains no constructs that preclude multiple reference. An error occurs if the model cannot be multiply referenced, even if only one reference exists.
To use multiple instances of a referenced model in Normal mode, use the Multiple setting. For details, see Using Normal Mode for Multiple Instances of Referenced Models.
| Parameter: ModelReferenceNumInstancesAllowed |
| Type: string |
| Value: 'Zero' | 'Single' | 'Multi' |
| Default: 'Multi' |
| Application | Setting |
|---|---|
| Debugging | No impact |
| Traceability | No impact |
| Efficiency | No impact |
| Safety precaution | No impact |
Specify whether a model that calls (references) this model passes its scalar inputs to this model by value.
Default: Off (GUI), 'on' (command-line)
On A model that calls (references) this model passes scalar inputs to this model by value.
OffThe calling model passes the inputs by reference (it passes the addresses of the inputs rather than the input values).
This option is ignored in either of these two cases:
The C function prototype control is not the default.
The C++ encapsulation interface is not the default.
Passing roots by value allows this model to read its scalar inputs from register or local memory which is faster than reading the inputs from their original locations.
However, passing roots by value can lead to incorrect results if the model's root scalar inputs can change within a time step. This can happen, for instance, if this model's inputs and outputs share memory locations (as a result of a feedback loop) and the model is invoked multiple times in a time step; for example, by an Inport or Trigger block (see Function-Call Subsystems). In such cases, this model sees scalar input changes that occur in the same time step only if the inputs are passed by reference. That is why this option is off by default.
If you are certain that this model is not referenced in contexts where its inputs can change within a time step, select this option to generate more efficient code for this model.
Selecting this option can affect reuse of code generated for subsystems. See Reusable Code and Referenced Models for more information.
For SIM targets, a model that references this model passes inputs by reference, regardless of how you set the Pass fixed-size scalar root inputs by value for code generation parameter.
| Parameter:ModelReferencePassRootInputsByReference |
| 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 | No impact |
| Traceability | No impact |
| Efficiency | No impact |
| Safety precaution | Off |
Try to eliminate artificial algebraic loops from a model that involve the current referenced model
Default: Off
On Simulink software tries to eliminate artificial algebraic loops from a model that involve the current referenced model.
OffSimulink software does not try to eliminate artificial algebraic loops from a model that involve the current referenced model.
Enabling this option disables:
Conditional input branch optimization for simulation
The Simulink Coder Single output/update function parameter (disabling this parameter generates separate model_output and model_update functions)
| Parameter:ModelReferenceMinAlgLoopOccurrences |
| Type: string |
| Value: 'on' | 'off' |
| Default: 'off' |
| Application | Setting |
|---|---|
| Debugging | No impact |
| Traceability | No impact |
| Efficiency | No impact |
| Safety precaution | Off |
Select how variable-size signals propagate through referenced models.
Default: Infer from blocks in model
Searches a referenced model and groups blocks into the following categories.
| Category | Description | Example Blocks in This Category |
|---|---|---|
| 1 | Output signal size depends on input signal values. | Switch or Enable Subsystem block whose parameter Propagate sizes of variable-size signals is set to During execution |
| 2 | States require resetting when the input signal size changes. | Unit Delay block in an Enabled Subsystem whose parameter Propagate sizes of variable-size signals is set to Only when enabling |
| 3 | Output signal size depends only on the input signal size. | Gain block. |
The search stops at the boundary of Enable, Function-Call, and Action subsystems because these subsystems can specify when to propagate the size of a variable-size signal.
Simulink sets the propagation of variable-size signals for a referenced model as follows:
One or more blocks in category 1, and all other blocks are in category 3, select During execution.
One or more blocks in category 2, and all another blocks are in category 3, select Only when enabling.
Blocks in category 1 and 2, report an error.
All blocks in category 3 with a conditionally executed subsystem that is not an Enable, Function-Call, or Action subsystem, report an error. Simulink, in this case, cannot determine when to propagate sizes of variable-size signals.
All blocks in category 3 with only conditionally executed subsystems that are an Enable, Function-Call, or Action subsystem, support both Only with enabling and During execution.
Propagates sizes of variable-size signals for the referenced model only when enabling (at Enable method).
Propagates sizes of variable-size signals for the referenced model during execution (at Outputs method).
| Parameter: PropagateVarSize |
| Type: string |
| Value: 'Infer from blocks in model' | 'Only when enabling'| 'During execution' |
| Default: 'Infer from blocks in model' |
| Application | Setting |
|---|---|
| Debugging | No impact |
| Traceability | No impact |
| Efficiency | No impact |
| Safety precaution | Off |
Although Simulink automatically examines every known target dependency, you can have files that can impact the simulation results of your model that Simulink does not automatically identify. Some examples of user-created dependencies are:
MATLAB files that contain code executed by callbacks
MAT-files that contain definitions for variables used by the model that are loaded as part of a customized initialization script
You can add user-created dependencies to the set of known target dependencies by using the Model dependencies parameter.
Simulink examines the files specified with the Model dependencies parameter when determining whether the model reference target is up to date. If the Rebuild parameter is set to:
Always, then the listed files are not examined.
Either If any changes detected or If any changes in known dependencies detected, then changes to listed files cause the model reference target to rebuild.
Never, and the Never rebuild diagnostic parameter is set to either Warn if rebuild required or Error if rebuild required, then changes to listed files cause Simulink to report a warning or error.
Default: ''
Specify the dependencies as a cell array of strings, where each cell array entry is one of the following:
File name — Simulink looks on the MATLAB path for a file with the given name. If the file is not on the MATLAB path, then specify the path to the dependent file, as described below.
Path to the dependent file — The path can be relative or absolute, and must include the file name.
Folder — Simulink treats every file in that folder as a dependent file. Simulink does not include files of subfolders of the folder you specify.
File names must include a file extensions (for example, .m or .mat)
File names and paths can include spaces.
You can use the following characters in the strings:
The token $MDL, as a prefix to a dependency to indicate that the path to the dependency is relative to the location of this model file
An asterisk (*), as a wild card
A percent sign (%), to comment out a line
An ellipsis (...), to continue a line
To improve rebuild detection speed and accuracy, use the Model dependencies parameter to specify model dependencies other than those that Simulink checks automatically as part of the its rebuild detection. For details, see the Rebuild parameter documentation.
If the Rebuild setting is If any changes in known dependencies detected, to prevent invalid simulation results, add every user-created dependency (for example, MATLAB code files or MAT-files).
Using the Simulink Manifest Tools can help you to identify model dependencies. For more information, see Model Dependencies.
If Simulink cannot find a specified dependent file when you update or simulate a model that references this model, Simulink displays a warning.
The dependencies automatically include the model.mdl and linked library .mdl files, so you do not need to specify those files with the Model dependencies parameter.
| Parameter: ModelDependencies |
| Type: string |
| Value: any valid value |
| Default: '' |
| Application | Setting |
|---|---|
| Debugging | No impact |
| Traceability | No impact |
| Efficiency | No impact |
| Safety precaution | No impact |
 | Hardware Implementation Pane | Simulation Target Pane: General |  |
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 |
