This is machine translation

Translated by Microsoft
Mouseover text to see original. Click the button below to return to the English version of the page.

Note: This page has been translated by MathWorks. Click here to see
To view all translated materials including this page, select Country from the country navigator on the bottom of this page.

Model Reference Requirements and Limitations

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.

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 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 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:

    • Stateflow graphical functions

    • Machine-parented data

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

Type of S-FunctionSupport for Model References
Level-1 MATLAB S-functionNot supported
Level-2 MATLAB S-function
  • Supports normal and accelerator mode

  • Accelerator mode requires a TLC file

Handwritten C MEX S-function
  • Supports normal and accelerator mode

  • Can be inlined with TLC file

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.

S-Function Sample Time

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 Inherited Sample Time for Referenced Models (Simulink Coder).

S-Functions in Accelerator Mode Referenced Models

For a referenced model that executes in accelerator mode, set Total number of instances allowed per top model to One if the model contains an S-function that is either:

  • Inlined, but has not set the SS_OPTION_WORKS_WITH_CODE_REUSE flag

  • Not inlined

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:

    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 the Simulink Coder™ software.

C S-Functions in 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 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

A protected model cannot use noninlined S-functions directly or indirectly.

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.

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

SignalRequirements and Limitations
0-based or 1-based indexing information propagationSee Index Information Propagation.
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.

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 Model Reference Requirements for Nonvirtual Buses.

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

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. For more information, see State Information for Referenced Models.

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.

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 other than none or Disable all. For details, see Diagnostic Configuration Parameters Ignored in Accelerator Mode.

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.

sim command in accelerator mode

When the sim command executes a referenced model in accelerator mode, the source workspace is always the MATLAB base workspace.

Data logging and visualization in accelerator mode

These logging methods have limitations when specified for referenced models executing in accelerator mode.

  • To Workspace blocks — Data is logged only if you use Timeseries format.

  • Scope, Floating Scope, and Scope Viewer blocks — No data is displayed.

  • Runtime display — Simulation data values, such as port values, do not display.

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.

Caution

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.

Tools Requirements and Limitations

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

Simulink Profiler

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:

  • Model Coverage

  • Simulink Report Generator™

  • Simulink Debugger

  • Simulink Profiler

Printing referenced models

You cannot print a referenced model from a top model.

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 Code Generation Model Referencing Limitations (Simulink Coder).

Related Topics