Main Content

Control and Display Execution Order

The execution order for a model is the order in which Simulink® invokes the block output methods during simulation. Simulink determines this order during a model update, which you can initiate by clicking Update Model on the Modeling tab. Simulink also updates the model during simulation.

You cannot set the execution order, but you can assign priorities to nonvirtual blocks to indicate their execution order relative to other blocks in the corresponding block diagram. Simulink tries to honor block priority settings unless there is a conflict with data dependencies. To confirm the results of the priorities you have set or to debug your model, display and review the execution order of your nonvirtual blocks and subsystems.

Note

For more information about block methods and execution, see:

Execution Order Viewer

On the Debug tab, select Information Overlays > Execution Order. The Execution Order viewer opens in a pane on the right side of the Simulink Editor.

The Execution Order viewer displays a list of tasks for the current system.

Each nonvirtual subsystem has its own System Index value that is unique within the model. Blocks that are directly inside the nonvirtual subsystem have the same System Index value as the subsystem. In model reference hierarchies, the same System Index value may be used multiple times, but it remains unique within each model in that hierarchy. To determine whether subsystems are part of the same system within a model, compare their System Index values.

Each task listed in the Task ID column corresponds to a group of blocks that execute in the same task. For fixed-step sizes, the Treat each discrete rate as a separate task configuration parameter determines whether Simulink executes blocks with discrete rates in one or multiple tasks.

Selecting a task in the Execution Order viewer highlights the blocks that belong to the task and displays their execution order. By default, Simulink selects the first task that corresponds to the active block diagram.

When the active block diagram does not contain any blocks that execute as part of a given task, you cannot select the task in the Execution Order viewer. The active block diagram may contain virtual blocks, such as Inport blocks, that are part of this task.

To hide the highlighting and execution order, click the Clear Highlighting button .

Navigation from Blocks to Tasks

To display the tasks in which a block executes, click on a block.

The selected Subsystem block has an information overlay that says "Task: 0,1." The information overlay contains a link for each task number.

The task numbers in the label are links that you can click to select the corresponding task in the Execution Order viewer. When a model has many tasks, these links provide an alternative to scrolling through the list of tasks in the Execution Order viewer.

To compare tasks among blocks, select multiple blocks.

Execution Order Notation

Simulink displays a number at the top-right corner of each nonvirtual block. These numbers indicate the order in which the blocks execute. The first block to execute has the lowest execution order, which is usually 1. The displayed execution order may skip numbers, but the blocks always execute in order of the visible numbers. Suppose a task displays execution orders 1, 2, and 4. The block labeled 1 executes before the block labeled 2, which executes before the block labeled 4.

For example, in the vdp model, the block execution order ranges from 1 to 9, with each nonvirtual block receiving an execution order.

Virtual and Nonvirtual Subsystems

Virtual Subsystem blocks exist only graphically and do not execute. Consequently, they are not part of the execution order, and each block within a virtual subsystem still executes as an atomic unit. The blocks inside a virtual subsystem have an execution order in the context of the root-level model or, if the virtual subsystem is inside a nonvirtual subsystem, in the context of the parent nonvirtual subsystem. For virtual subsystems, block execution order within the subsystem is listed in curly brackets {}.

Nonvirtual Subsystem blocks exist functionally and execute as a unit. They have a single execution order and a different system index than the root-level model or any parent nonvirtual subsystem. The blocks inside a nonvirtual subsystem have their own execution orders, which are independent of the root-level model or any parent nonvirtual subsystem.

For example, this model contains a virtual subsystem named Car Dynamics and an atomic, nonvirtual subsystem named Discrete Cruise Controller.

The virtual Car Dynamics subsystem shows a list of execution orders within curly brackets for the blocks it contains. The blocks it contains execute at the same level as the Step, Sum, and Scope blocks and the Discrete Cruise Controller nonvirtual subsystem. The Integrator block executes first and sends its output to the Scope block, which executes second.

The nonvirtual Discrete Cruise Controller subsystem has a single execution order (5), which indicates that the subsystem and the blocks within it are the fifth to execute relative to the blocks at the same level.

Note

Depending on your model configuration, Simulink can insert hidden, nonvirtual subsystems in your model. As a result, the visible blocks inside the hidden Subsystem block can have a system index that is different from the current system index. For example, if you select the Conditional input branch execution configuration parameter, Simulink may create hidden, nonvirtual subsystems for optimization, which can affect the sorted execution order.

Algebraic Loops

Blocks within an algebraic loop are moved into a hidden nonvirtual subsystem. Simulink first determines the execution order of the hidden subsystem within the context of the other blocks, then determines the execution order of the blocks within the hidden subsystem. See Algebraic Loop Concepts.

Function-Call and Action Subsystems

For function-call and action subsystems, the execution of the subsystem is controlled by the execution of its initiator. The subsystem and its initiator therefore share an execution order.

Simulink ignores any block priority set on Function-Call Subsystem, If Action Subsystem, or Switch Case Action Subsystem blocks, but you can set the block priority on the blocks that initiate these subsystems.

At the root-level of export-function models, function-call execution orders have an F prefix.

For more information, see Export-Function Models Overview.

Buses and Multiple Initiators

A block has multiple execution orders when the block executes multiple times based on different execution paths to that block. For example:

  • A block connected to a bus has an execution order corresponding to each signal that the bus contains.

  • A function-call or action subsystem with multiple initiators has an execution order corresponding to each initiator.

How Simulink Determines Execution Order

Simulink uses task-based sorting to set the execution order of blocks and ports based on their derived sample time information. Task-based sorting provides an efficient and simpler process for determining the execution order of blocks.

With task-based sorting:

  • Tasks are sorted individually based on sample time.

  • Multiple sorted lists are generated instead of one flattened, sorted list of blocks across all tasks.

  • Rate transition handling is simplified.

  • False data dependency violations involving blocks in different tasks are avoided.

  • Code generation results are in efficient rate groupings.

  • One subsystem can belong to different sorted lists in multiple tasks.

Direct-Feedthrough Input Impact on Execution Order

To ensure that the execution order reflects data dependencies among blocks, Simulink categorizes block input ports according to the dependency of the block outputs on the block input ports. An input port whose current value determines the current value of one of the block outputs is a direct-feedthrough input. See Algebraic Loop Concepts. Examples of blocks that have direct-feedthrough inputs include:

Examples of blocks without direct-feedthrough inputs include:

Rules for Determining Block Execution Order

To sort blocks, Simulink uses these rules:

  • If a block drives the direct-feedthrough input of another block, the driving block must appear in the execution order ahead of the block that it drives.

    This rule ensures that the direct-feedthrough inputs to blocks are valid when Simulink invokes block output methods that require current inputs.

  • If a block drives the input of another block that is not a direct-feedthrough input, there is no data dependency between the two blocks, so their relative execution order does not matter.

This model illustrates this result.

  • The Integrator block 1/s in the Car Dynamics virtual subsystem has no direct-feedthrough input. Therefore, even though its input is connected to the Gain block 1/m, the Integrator block is sorted before the Gain block 1/m. The output of the Integrator block drives the input of the Gain block b, so the Integrator block is sorted before that Gain block.

  • In the root-level model, the Step block step response drives a Sum block, so the Step block is sorted before the Sum block. The Sum block drives the direct-feedthrough input of the Discrete Cruise Controller nonvirtual subsystem, so the subsystem is sorted after the Sum block.

The Discrete Cruise Controller nonvirtual subsystem is treated as a block with a direct-feedthrough input because its output depends on the current value of the input via the branch with the Kp Gain block. Inside the subsystem, all the Gain blocks, which have direct-feedthrough inputs, run before the Sum block that they drive.

Rules for Determining Block Execution Order in Models Containing Asynchronous Tasks

In simulation, asynchronous function call initiators have the highest priority when determining block sorting order within a task. For more information, see Asynchronous Sample Time and Rate Transitions and Asynchronous Blocks (Simulink Coder).

To determine the block execution order in models containing asynchronous sample times, Simulink uses these rules:

  • If an asynchronous function call initiator is triggered by a discrete rate shared by the corresponding rate transition block, then in the task of the common discrete rate, the asynchronous function call initiator will be sorted first.

    For example, in the below model, there is one asynchronous function call initiator that is triggered by the discrete rate D1. Within the discrete task, the asynchronous function call initiator is sorted first. The Rate Transition blocks convert between the asynchronous rate, A1, and the discrete rate, D1.

  • If a Rate Transition block is reduced to NoOp, the Rate Transition block does not execute, and its position in the sorted order within the discrete task is transferred to the upstream or downstream discrete block to which it is connected.

    For example, in the above model, RTB2 is reduced to NoOp, so its position in the sorted order is transferred to the downstream Gain block.

  • If two asynchronous function call initiators share a common discrete rate task, then asynchronous function call initiator with higher priority executes first within the discrete rate task.

    For example, in the below model, two asynchronous function call initiators are triggered by the same discrete rate, D1. The one with higher task priority is sorted first.

  • The union of asynchronous sample times is not supported by task-based sorting. Models containing the union of multiple asynchronous sample times default to a global execution order, in which all blocks are sorted within a single task.

Checks for Execution Order Changes Involving Data Store Memory Blocks

Model Upgrades

Using task-based sorting instead of legacy (block) sorting can change the relative execution order involving Data Store Memory blocks. An Upgrade Advisor check detects the changes and provides an option to keep the original execution order when upgrading your model from earlier versions of Simulink.

  1. Open the Upgrade Advisor. On the Modeling tab, select Model Advisor > Upgrade Advisor.

  2. Select the check box for Check relative execution orders for Data Store Read and Data Store Write blocks.

  3. Click Run This Check.

  4. Review any changes in the Result table. If you want to keep the original execution order, click Modify.

Code Generation

When a model is compiled for code generation, the relative execution order of Data Store Read and Data Store Write blocks can differ in the generated code from the order in normal simulation mode. A Model Advisor check detects these differences and provides an option to change the execution order in normal simulation mode to match the order in the generated code.

  1. Open the Model Advisor. On the Modeling tab, select Model Advisor > By Product > Simulink Coder.

  2. Select the check box for Check for relative execution order change for Data Store Read and Data Store Write blocks.

  3. Click Run This Check.

  4. Review any changes in the Result table. If there are discrepancies listed and you want to change the execution order in normal simulation to conform with the execution order in generated code, click Modify block priorities.

Related Topics