Before referencing models, consider model reference requirements and limitations. By understanding the requirements and limitations upfront, you are better prepared to reference models successfully.
You can reference a model more than once in a model hierarchy unless the referenced model has any of these properties:
The model references another model that is set to single instance.
The model contains To File blocks.
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:
Exported Stateflow graphical functions
The referenced model executes in accelerator mode and contains an S-function
that is either not inlined or is inlined but does not set the option
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.
|S-Function Type||Models Referenced in Normal Mode||Models Referenced in Accelerator Mode|
|Level-1 MATLAB S-function||Not supported||Not supported|
|Level-2 MATLAB S-function||Supported||Supported — requires a TLC file|
|Handwritten C MEX S-function|
Supported — can be inlined with a TLC file
|Supported — can be inlined with a TLC file|
|Legacy Code Tool||Supported||Supported|
When you use S-functions in referenced models, consider these requirements and limitations.
|S-Function Consideration||Requirements and Limitations|
|Sample Time Inheritance|
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 inheritance, use
|Accelerator Mode Referenced Models|
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
A referenced model cannot use noninlined S-functions in these cases:
A referenced model in accelerator mode cannot use S-functions generated by Simulink Coder™ software.
|Normal Mode Referenced Models|
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, use the
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
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.
|Printing referenced models|
You cannot print a referenced model from a top model.
|Signal||Requirements and Limitations|
|0-based or 1-based indexing information propagation|
In two cases, Simulink does not propagate 0-based or 1-based indexing information to referenced model root-level ports connected to blocks that:
An example of a block that accepts indexes is the Assignment block. An example of a block that produces indexes is the For Iterator block.
The two cases result in a lack of propagation that can cause Simulink to fail to detect incompatible index connections. These two cases are:
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-sized signal element. See Use Buses at Model Interfaces.
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 top 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 top 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.
By understanding code generation requirements and limitations upfront, you are better prepared to properly set up the model hierarchy for code generation. See Set Configuration Parameters for Code Generation of Model Hierarchies (Simulink Coder) and Code Generation Limitations for Model Reference (Simulink Coder).