Main Content

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 any of these Stateflow® constructs:

    • Exported Stateflow graphical functions

    • Machine-parented data

  • 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® 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 TypeModels Referenced in Normal ModeModels Referenced in Accelerator Mode and Protected Models
Level-1 MATLAB S-functionNot supportedNot supported
Level-2 MATLAB S-functionSupportedSupported — 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 BuilderSupportedSupported
Legacy Code ToolSupportedSupported

When you use S-functions in referenced models, consider these requirements and limitations.

S-Function ConsiderationRequirements 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:

    1. Make copies of the referenced model.

    2. Assign different names to the copies.

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

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

Configurable subsystems

In a configurable subsystem with a Model block, during model update, do not change the subsystem that the configurable subsystem selects.

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

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


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.

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

Related Topics