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.

Simulate Model Hierarchies

Simulating a model that uses model reference differs in some ways from simulating a standalone model that does not use model reference.

There are some limitations for simulating model hierarchies. For details, see Simulation Requirements and Limitations and Signal Requirements and Limitations.

Simulate a Top Model

The top model in a model hierarchy executes the same way that models without model references execute. The top model supports all Simulink® simulation modes. To speed up execution of a top model in a model hierarchy, you can use Simulink accelerator or rapid accelerator mode. For information about accelerator mode, see Acceleration. For information about rapid accelerator mode, see Accelerate, Refine, and Test Hybrid Dynamic System on Host Computer by Using RSim System Target File (Simulink Coder).

When you execute a top model in accelerator or rapid accelerator mode, all referenced models execute in accelerator mode.

Referenced Model Simulation

You can simulate a referenced model in one of these modes:

  • Normal

  • Accelerator

  • Software-in-the-loop (SIL)

  • Processor-in-the-loop (PIL)

For more information about using these simulation modes for referenced models, see Comparison of Simulation Modes for Referenced Models.

The simulation modes used for referenced models depend on the simulation mode of the parent model. For details, see Parent and Referenced Model Simulation Modes.

Specify the Simulation Mode for Referenced Models

The Model block for each instance of a referenced model controls the simulation mode of the instance. To set or change the simulation mode for a referenced model:

  1. Access the block parameter dialog box for the Model block.

  2. Set the Simulation mode parameter.

  3. Click OK or Apply.

Comparison of Simulation Modes for Referenced Models

You can use rapid accelerator mode for the top model in a model hierarchy, but not for Model blocks. You can set referenced models to rapid accelerator mode, but the simulation mode of the top model, parent Model block, or referenced model Model block overrides the referenced model simulation mode.

The different simulation modes for referenced models share many capabilities and techniques, but they have different implementations, requirements, and limitations.

Tip

Accelerator mode execution of a referenced model is different from:

For more information about Accelerator mode execution of a referenced model, see Model Reference Simulation Targets.

Simulation ModeDescriptionWhen to Use
NormalExecutes referenced model interpretively.

Compared to other simulation modes, normal mode:

  • Executes slower.

  • Requires no delay for code generation or compilation.

  • Works with more Simulink and Stateflow® tools, supporting tools such as:

    • Scopes, port value display, and other output viewing tools.

    • Model coverage analysis.

    • Stateflow debugging and animation.

  • Provides more accurate linearization analysis.

  • Supports more S-functions than accelerator mode does.

When you simulate multiple instances of a referenced model in normal mode, Simulink software displays results for only one of the normal-mode instances. For details, see Simulate Multiple Referenced Model Instances in Normal Mode.

Accelerator

Executes the referenced model by creating a MEX-file (a simulation target) for the referenced model, then running the MEX-file.

For more information, see Model Reference Simulation Targets.

  • Executes faster than normal mode.

  • Takes time for code generation and code compilation.

  • Does not fully support some Simulink tools, such as Model Coverage and the Simulink Debugger.

  • Supports Scope blocks, but requires using the Signal & Scope Manager and adding test points to signals. Adding or removing a test point requires rebuilding the SIM target for a model.

SIL

Executes referenced model by generating production code. This code is compiled for, and executed on, the host platform.

Requires Embedded Coder® software. For more information, see SIL and PIL Limitations (Embedded Coder) and Numerical Equivalence Testing (Embedded Coder).

  • Verifies generated source code without modifying the original model.

  • Supports the reuse of test harnesses for the original model with the generated source code.

SIL mode provides a convenient alternative to PIL simulation when the target hardware is not available.

PIL

Executes referenced model by generating production code. This code is cross-compiled for, and executed on, a target processor or an equivalent instruction set simulator.

Requires Embedded Coder software. For more information, see SIL and PIL Limitations (Embedded Coder) and Numerical Equivalence Testing (Embedded Coder).

  • Verifies deployment object code on target processors without modifying the original model.

  • Supports the reuse of test harnesses for the original model with the generated source code.

Note

Simulation results for a given model are nearly identical in normal and accelerator modes. Trivial differences can occur, depending on differences in the optimizations and libraries that you use.

Configuration parameter setting requirements and behavior can vary depending on the simulation mode. For details, see Accelerated Simulation and Code Generation Changes Settings and Diagnostics That Are Ignored in Accelerator Mode.

Diagnostic Configuration Parameters Ignored in Accelerator Mode.  For models referenced in accelerator mode, Simulink ignores the values of these configuration parameter settings if you set them to a value other than None:

  • Array bounds exceeded (ArrayBoundsChecking)

  • Inf or NaN block output (SignalInfNanChecking)

  • Simulation range checking (SignalRangeChecking)

  • Division by singular matrix (CheckMatrixSingularityMsg)

  • Wrap on overflow (IntegerOverflowMsg)

Also, for models referenced in accelerator mode, Simulink ignores these configuration parameters when you set them to a value other than Disable all. For details, see Data Store Diagnostics.

  • Detect read before write (ReadBeforeWriteMsg)

  • Detect write after read (WriteAfterReadMsg)

  • Detect write after write (WriteAfterWriteMsg)

You can use the Model Advisor to identify models referenced in accelerator mode for which Simulink ignores these configuration parameters.

  1. In the Simulink Editor, select Analysis > Model Advisor.

  2. Select By Task.

  3. Run the Check diagnostic settings ignored during accelerated model reference simulation check.

To see the results of running the identified diagnostics with settings to produce warnings or errors, simulate the model in normal mode. Inspect the diagnostic warnings and then simulate in accelerator mode.

Parent and Referenced Model Simulation Modes

The simulation modes you can use for a referenced model depend on the simulation mode of its parent model.

Parent Model Simulation ModeReferenced Model Simulation Modes
Normal
  • Referenced models can use normal, accelerator, SIL, or PIL mode.

  • If every model that is superior to a referenced model in the model hierarchy also executes in normal mode, that referenced model can execute in normal mode.

Accelerator
  • All subordinate models must also execute in accelerator mode.

  • When a normal mode model is subordinate to an accelerator mode model, Simulink returns a warning and temporarily overrides the normal mode specification.

  • When a SIL-mode or PIL-mode model is subordinate to an accelerator mode model that is not the top model, an error occurs.

SIL
  • If their simulation modes are normal, accelerator, or SIL, all subordinate models also execute in SIL mode. Otherwise, an error occurs. See Simulation Mode Override Behavior in Model Reference Hierarchy (Embedded Coder).

  • Multiple Model blocks, starting at the top of a model hierarchy, can execute in SIL mode. However, if code coverage or code execution profiling is enabled, only one Model block can execute at a time in SIL mode.

PIL
  • If their simulation modes are normal, accelerator, or PIL, all subordinate models also execute in PIL mode. Otherwise, an error occurs. See Simulation Mode Override Behavior in Model Reference Hierarchy (Embedded Coder).

  • Multiple Model blocks, starting at the top of a model hierarchy, can execute in PIL mode. However, if code coverage or code execution profiling is enabled, only one Model block can execute at a time in PIL mode.

Simulate Conditional Referenced Models

You can run a standalone simulation of a conditional referenced model. A standalone simulation is useful for unit testing because it provides consistent data across simulations in terms of data type, dimension, and sample time. Use normal, accelerator, or rapid accelerator mode to simulate a conditional model.

Triggered, Enabled, and Triggered and Enabled Models

Triggered, enabled, and triggered and enabled models require an external input to drive the Trigger or Enable blocks. In the Signal Attributes pane of the Trigger or Enable block dialog box, specify values for the signal data type, dimension, and sample time.

To run a standalone simulation, specify the inputs using the Input parameter. For details about how to specify the input, see Comparison of Signal Loading Techniques. The following conditions apply when you use the Input parameter for trigger and enable block inputs:

  • Use the last data input for the trigger or enable input. For a triggered and enabled model, use the last data input for the trigger input.

  • If you do not provide any input values, the simulation uses zero as the default values.

You can log data to determine which signal caused the model to run. For the Trigger or Enable block, in the Main pane of the Block Parameters dialog box, select Show output port.

Function-Call Models

When you simulate a function-call model, it simulates as if a function call at the fastest rate for the system drives the function-call block. You can also configure the model to calculate output at specific times using a variable-step solver (see Samples to Export for Variable-Step Solvers).

Log Signals in Referenced Models

In a referenced model, you can log any signal configured for signal logging. Use the Signal Logging Selector to select a subset or all the signals configured for signal logging in a model hierarchy. For details, see Models with Model Referencing: Overriding Signal Logging Settings.

You can use the Simulation Data Inspector to view and analyze signals logged in referenced models. You can view signals on multiple plots, zoom, and use data cursors to understand and evaluate the data. Also, you can compare signal data from multiple simulations. For an example of viewing signals with referenced models, see Viewing Signals in Model Reference Instances.

Set Diagnostics and Debug Model Hierarchies

You can enable or suppress warning messages about mismatches between a Model block and its referenced model by setting diagnostics on the Diagnostics Pane: Model Referencing.

Working with the Simulink Debugger in a parent model, you can set breakpoints at Model block boundaries. Setting breakpoints allows you to look at the input and output values of the Model block. However, you cannot set a breakpoint inside the model that the Model block references. See Simulink Debugger for more information.

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

Related Topics