Control and Display Execution Order

The execution order for a model is the order in which the software invokes the block output methods during simulation. The software determines this order during a model update, which you can initiate by clicking Update Model on the Modeling tab. The software 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.

Some nonvirtual blocks do not support block priorities. For example, the software ignores priorities set on these blocks:

Merge blocks.
Blocks with function-call input ports, such as Function-Call Subsystem blocks and Model blocks that reference export-function models.
Blocks with action ports, such as If Action Subsystem and Switch Case Action Subsystem blocks.
For Iterator blocks inside For Iterator Subsystem blocks and While Iterator blocks inside While Iterator Subsystem blocks. For Iterator and While Iterator blocks must be the first blocks to execute inside For Iterator Subsystem and While Iterator Subsystem blocks, respectively.

If a priority is set on these blocks, the Block priority violation configuration parameter setting determines whether you receive a warning or error.

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

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.

Execution Order viewer

The Execution Order viewer displays information based on the latest compiled execution order.

System Index — Unique value within a model that represents the current system or nonvirtual subsystem. For the top-level model, the system index is 0. For each nonvirtual subsystem, the system index is a positive integer.
Blocks that are directly inside the nonvirtual subsystem have the same system index as the subsystem. To determine whether subsystems are part of the same system within a model, compare their system indexes.
In model reference hierarchies, the same system index may be used multiple times. It remains unique only within each model of the hierarchy.
Execution Order Block List — List of blocks in order of their task-based execution order. The block list provides complete execution order information for the selected task, providing more information than the block diagram displays. For example, the list includes hidden blocks and blocks in subsystem block diagrams.
Task ID — Unique identifier for each task in the current system. Each task corresponds to a group of blocks that execute in a set order relative to each other based on their derived sample time information. A single Task ID can contain blocks with multiple different types of sample times. Execution order displays blocks with different types of constant sample times in separate tasks. For example, Simulink blocks with constant sample times of [Inf 0] and [Inf Inf] are displayed in Task 1 and Task 2, respectively. For more information about sample times, see Constant Sample Time.
To obtain the sample time information programmatically, use get_param function.
```
get_param('model_name/block_name','CompiledSampleTime')
```
For more information, see Block Compiled Sample Time.
For fixed-step sizes, the Treat each discrete rate as a separate task configuration parameter determines whether blocks with discrete rates execute in one or multiple tasks.

To update execution order information for a model that has changed since its last compile, recompile the model. In the Execution Order viewer, click the Recompile model to update execution order information button .

To highlight the blocks that belong to a task and display their execution order, select the task in the Execution Order viewer. By default, the software selects the first task that corresponds to the active block diagram.

Note

Starting in R2023b, the execution order display no longer highlights signal lines and virtual blocks for a selected task. For more information about virtual blocks see, Nonvirtual and Virtual Blocks.

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

The block diagram 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 this model, the block execution order ranges from 1 to 12, with each nonvirtual block receiving an execution order.

Each block in the model is labelled with their execution order. Execution Order viewer also shows those blocks arranged in their 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. Creating virtual subsystems can affect the execution order of blocks when the blocks are sorted by block path. Each block within a virtual subsystem executes as an atomic unit and has 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.

Execution of the virtual and nonvirtual subsystems

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.

Execution order of blocks inside the virtual subsystem

The nonvirtual discrete cruise controller subsystem has a single execution order (4), which indicates that the subsystem and the blocks within it are the fourth to execute relative to the blocks at the same level.

Execution order of blocks in the nonvirtual subsystem

Note

Depending on your model configuration, the software 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, the software 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. The software 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.

Execution order of blocks in a model with algebraic loop

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.

Execution order model containing function fall subsystem

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

Execution order for root-level export-function model

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.

Determining Execution Order

Task-based sorting sets 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, the software 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, the software 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 the software 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 Gain block named Kp. Inside the subsystem, all the Gain blocks, which have direct-feedthrough inputs, run before the Sum block that they drive.

Execution order of blocks in the nonvirtual subsystem

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, the software 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 (an Async Interrupt (Simulink Coder) block) 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 (two Async Interrupt (Simulink Coder) blocks) 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. All blocks associated with the union of multiple asynchronous sample times are sorted within a single task.
For example, in the below model, two asynchronous function-call initiators (two Async Interrupt (Simulink Coder) blocks) with same Simulink task priority are triggered by the same discrete rate, D1. In this model, a Rate Transition block RTB1_Union computes U1 = union(A4 , A5). The blocks associated with the union is grouped in Task 0. For more information about union sample time, see Union Rate and asynchronous sample time, see Asynchronous Sample Time.

Check 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 Simulink versions.

Open the Upgrade Advisor. On the Modeling tab, select Model Advisor > Upgrade Advisor.
Select the check box for Check relative execution orders for Data Store Read and Data Store Write blocks.
Click Run This Check.
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.

Open the Model Advisor. On the Modeling tab, select Model Advisor > By Product > Simulink Coder.
Select the check box for Check for relative execution order change for Data Store Read and Data Store Write blocks.
Click Run This Check.
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.