To successfully implement Model blocks, before organizing your model into components, consider their requirements and limitations. By understanding requirements and limitations upfront, you are better prepared to use Model blocks.
You can reference a model more than once in a model hierarchy unless the referenced model has any of these properties:
The model contains To File blocks.
The model references another model that is set to single instance.
The model contains an internal signal or state with a storage class that is not
supported for multi-instance models. Internal signals and states must have the
storage class set to
and the default storage class for internal data must be a multi-instance storage
The model uses any of these Stateflow® constructs:
Stateflow graphical functions
The referenced model executes in accelerator mode and contains:
A subsystem that is marked as a function
An S-function that is either not inlined or is inlined but does not set
The model contains a function-call subsystem that:
Simulink® forces to be a function
Is called by a wide signal
If the referenced model has any of these properties, only one instance of the model
can appear in the model hierarchy. The model must have Total number of instances allowed per top
model set to
You can use masked blocks in a referenced model. Also, you can mask a referenced model (see Create and Reference a Masked Model).
To successfully use masks, consider these requirements and limitations:
If a mask specifies the name of a referenced model, the mask must provide the name of the referenced model directly. You cannot use a workspace variable to provide the name.
The mask workspace of a Model block is not available to the referenced model. Any variable that the referenced model uses must resolve to either of these workspaces:
A workspace that the referenced model defines
The MATLAB® base workspace
Mask callbacks cannot add Model blocks, change the Model block name, or change the Model block simulation mode.
Different types of S-functions provide different levels of support for model references.
|Type of S-Function||Support for Model References|
|Level-1 MATLAB S-function||Not supported|
|Level-2 MATLAB S-function||
|Handwritten C MEX S-function||
The S-Function Builder and Legacy Code Tool both support normal and accelerator modes for model references.
For information on how to use S-functions in models, see Use S-Functions in Models.
If an S-function depends on an inherited sample time, the S-function must
explicitly declare a dependence on the inherited sample time. To control sample-time
differently based on whether an S-function permits or precludes inheritance. For
details, see Inherited Sample Time for Referenced Models (Simulink Coder).
For a referenced model that executes in accelerator mode, set
Total number of instances allowed per top
One if the model
contains an S-function that is either:
Inlined, but has not set the
For accelerator mode referenced models that contain an S-function that requires
inlining using a Target Language Compiler file, the S-function must use the
ssSetOptions macro to set the
SS_OPTION_USE_TLC_WITH_ACCELERATOR option in its
mdlInitializeSizes method. The simulation target does not
inline the S-function unless the S-function sets this option.
A referenced model cannot use noninlined S-functions in these cases:
The model uses a variable-step solver.
The S-function supports use of fixed-point numbers as inputs, outputs, or parameters.
The model is referenced more than once in the model reference hierarchy. To work around this limitation, use normal mode or:
Make copies of the referenced model.
Assign different names to the copies.
Reference a different copy at each location that needs the model.
The S-function uses character vector parameters.
A referenced model in accelerator mode cannot use S-functions generated by the Simulink Coder™ software.
Under certain conditions, when a C S-function appears in a referenced model that executes in normal mode, successful execution is impossible. For details, see S-Functions in Normal Mode Referenced Models.
To specify whether an S-function can be used in a normal mode referenced model,
ssSetModelReferenceNormalModeSupport SimStruct function.
For an S-function to work with multiple instances of referenced models in normal
mode, the S-function must indicate explicitly that it supports multiple
exec instances. For details, see Supporting the Use of Multiple Instances of Referenced Models That Are in Normal Mode.
A protected model cannot use noninlined S-functions directly or indirectly.
|Element||Requirements and Limitations|
|Goto and From blocks|
Goto and From blocks cannot cross model reference boundaries.
If the referenced model contains Assignment blocks, you can place the Model block in an iterator subsystem only if the Assignment blocks are also in an iterator subsystem.
In a configurable subsystem with a Model block, during model update, do not change the subsystem that the configurable subsystem selects.
|MATLAB Function block|
A MATLAB Function block in a referenced model that executes in accelerator mode cannot call MATLAB functions that are declared extrinsic for code generation.
|Signal||Requirements and Limitations|
|0-based or 1-based indexing information propagation||See Index Information Propagation.|
Referenced models can only use asynchronous rates if the model meets both of these conditions:
|User-defined data type input or output|
A referenced model can input or output only the user-defined data
types that are fixed point or that
If you use a virtual bus as an input or an output for a referenced model, the bus cannot contain a variable-size signal element. See Model Reference Requirements for Nonvirtual Buses.
A signal that connects to a Model block is
functionally the same signal outside and inside the block. Therefore,
that signal is subject to the restriction that a given signal can have at
most one associated signal object. See
|Simulation Property||Requirements and Limitations|
|Continuous sample time propagation|
A continuous sample time cannot be propagated to a Model block that is sample-time independent.
|Sample times and solvers|
The solver of the topmost model controls all continuous sample times in a model hierarchy. For example, for a fixed-step solver, all continuous rates in referenced models run at the fixed-step size of the topmost model. For information about how sample times impact solvers, see Types of Sample Time.
To initialize the states of a model that references other models with states, specify the initial states in structure or structure with time format. For more information, see State Information for Referenced Models.
When you simulate a model that references other models, under some circumstances, you lose some tunability of block parameters (for example, the Gain parameter of a Gain block). For more information, see Tunability Considerations and Limitations for Other Modeling Goals.
|Normal mode visibility for multiple instances of referenced model|
You can simulate a model that has multiple instances of a referenced model that are in normal mode. All the instances of the referenced model are part of the simulation. However, Simulink displays only one of the instances in a model window. The normal mode visibility setting determines which instance Simulink displays. Normal mode visibility includes the display of Scope blocks and data port values.
To control which instance of a referenced model in normal mode has visibility and to ensure proper simulation of the model, see Configure Models with Multiple Referenced Model Instances.
|Save before using accelerator mode|
When you create a model, you cannot use that model as an accelerator mode referenced model until you have saved the model to disk. You can work around this limitation by setting the model to normal mode. See Simulate Model Hierarchies.
|Diagnostic configuration parameters in accelerator mode|
For models referenced in accelerator mode, Simulink ignores certain runtime diagnostics that you set to a value
|Blocks with runtime checks in accelerator mode|
Some blocks include runtime checks that are disabled when you include the block in a referenced model in accelerator mode. Examples of these blocks include Assignment, Selector, and MATLAB Function blocks.
|Data logging and visualization in accelerator mode|
These logging methods have limitations when specified for referenced models executing in accelerator mode.
|Linearization of discrete states in accelerator mode|
In accelerator mode, discrete states of model references are not exposed to linearization. These discrete states are not perturbed during linearization and, therefore, are not truly free in the trimming process.
|Trimming in accelerator mode|
The outputs of random blocks are not kept constant during trimming. Outputs that are not kept constant can affect the optimization process.
|External mode in accelerator mode|
Accelerator mode does not support the External mode option. If you enable the External mode option, accelerator mode ignores it.
|Sim viewing device in rapid accelerator mode|
In rapid accelerator mode, Simulink does not update a Model block with a sim viewing device.
|SIL and PIL mode|
See Simulation Mode Override Behavior in Model Reference Hierarchy (Embedded Coder).
|Custom C code for referenced model simulation (SIM) target build for accelerator mode|
To use custom C code in accelerator mode, enable the Include custom code for referenced models configuration parameter.
Using custom C code for referenced models in accelerator mode can produce different results than when you simulate the model without using the custom code. If the custom code includes declarations of structures for buses or enumerations, the SIM target generation fails if the build results in duplicate declarations of those structures. Also, if custom code uses a structure representing a bus or enumeration, you can get unexpected simulation results.
|Tool||Requirements and Limitations|
|Simulink Debugger breakpoints|
Working with the Simulink Debugger in a parent model, you can set breakpoints at Model block boundaries. Setting the breakpoints allows you to look at the input and output values of the Model block. You can set a breakpoint inside the referenced model in normal mode. However, you cannot set a breakpoint inside the referenced model in accelerator mode. See Simulink Debugger for more information.
In normal mode, enabling the Simulink Profiler on a parent model does not enable profiling for referenced models. Enable profiling separately for each referenced model. See How Profiler Captures Performance Data.
|Simulink tools that access internal data or model configurations|
Simulink tools that require access to the internal data or the configuration of a model have no effect on referenced models executing in accelerator mode. Specifications made and actions taken by such tools are ignored. Examples of tools that require access to model internal data or configuration include:
|Printing referenced models|
You cannot print a referenced model from a top model.
By understanding code generation requirements and limitations upfront, you are better prepared to properly set up the model hierarchy for code generation. See Code Generation Model Referencing Limitations (Simulink Coder).