Model Reference Requirements and Limitations

Before referencing models, consider model reference requirements and limitations. By understanding the requirements and limitations upfront, you are better prepared to reference models successfully.

Model Reuse

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 Auto or Model default and the default storage class for internal data must be a multi-instance storage class.
The model uses 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 SS_OPTION_WORKS_WITH_CODE_REUSE.
The model contains a function-call subsystem that:
- Simulink^® software 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 One.

Model Masks

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.

S-Functions in Referenced Models

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 and Protected Models
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
S-Function Builder	Supported	Supported
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 `ssSetModelReferenceSampleTimeInheritanceRule` differently based on whether an S-function permits or precludes inheritance. For details, see S-Functions That Specify Sample Time Inheritance Rules (Simulink Coder).
Models Referenced in Accelerator Mode	For accelerator mode referenced models that contain an S-function that requires inlining using a Target Language Compiler (TLC) 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 is referenced more than once in the model 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 Simulink Coder™ software.
Models Referenced in Normal Mode	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 `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.
Protected Models	For protected models that contain an S-function that requires inlining using a Target Language Compiler (TLC) file, the S-function must use the `ssSetOptions` macro to set the `SS_OPTION_USE_TLC_WITH_ACCELERATOR` option in its `mdlInitializeSizes` method.

Model Architecture Requirements and Limitations

Element	Requirements and Limitations
Goto and From blocks	Goto and From blocks cannot cross model reference boundaries.
Iterator subsystems	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.
`InitFcn` callback	An `InitFcn` callback in a top model cannot change parameters used by referenced models.
Printing referenced models	You cannot print a referenced model from a top model.

Signal Requirements and Limitations

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: Accept indexes (such as the Assignment block) Produce indexes (such as the For Iterator block) 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: If a root-level input port of the referenced model connects to index inputs in the model that have different 0-based or 1-based indexing settings, Simulink does not set the 0-based or 1-based indexing property of the root-level Inport block. If a root-level output port of the referenced model connects to index outputs in the model that have different 0-based or 1-based indexing settings, Simulink does not set the 0-based or 1-based indexing property of the root-level Outport block.
Asynchronous rates	Referenced models can only use asynchronous rates if the model meets both of these conditions: An external source drives the asynchronous rate through a root-level Inport block. The root-level Inport block outputs a function-call signal. See Asynchronous Task Specification (Simulink Coder).
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 `Simulink.DataType` or `Simulink.Bus` objects define.
Buses	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 Use Buses at Model Interfaces.
Signal objects	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 `Simulink.Signal` for more information.

Simulation Requirements and Limitations

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.
State initialization	To initialize the states of a model that references other models with states, specify the initial states in structure or structure with time format.
Parameter tunability	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.

Code Generation Requirements and Limitations

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).