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 System Index value corresponds to a group of blocks that execute independently from other blocks, such as the blocks in a nonvirtual subsystem. Within a model, the System Index values are unique. 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 share a sample rate. 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 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. The blocks inside a virtual subsystem have an execution order in the context of the root-level model. 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 parent model. The blocks inside a nonvirtual subsystem have their own execution orders, which are independent of the parent model.
For example, the following 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 root level. The Integrator block executes first and sends its output to the Scope block in the root-level model, 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 root 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 creates hidden, nonvirtual subsystems, which can affect the sorted execution order.
Algebraic Loops
Blocks within an algebraic loop are moved into a hidden nonvirtual subsystem. The execution order of the hidden subsystem is determined within the context of the other blocks; then, the execution order of the blocks within the hidden subsystem is determined.
Function-Call and Action Subsystems
For function-call and action subsystems, the execution of the subsystem is tied to the execution of the initiator. The subsystem and its initiator therefore share an execution order.
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 Ports 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 port. Examples of blocks that have direct-feedthrough ports include:
Examples of blocks that have non-direct-feedthrough inputs include:
Integrator — Output is a function of its state.
Constant — Does not have an input.
Memory — Output depends on its input from the previous time step.
Rules for Determining Block Execution Order
To sort blocks, Simulink uses the following rules:
If a block drives the direct-feedthrough port of another block, the 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 methods that require current inputs.
Blocks that do not have direct-feedthrough inputs can appear anywhere in the execution order as long as they precede any direct-feedthrough blocks that they drive.
Placing all blocks that do not have direct-feedthrough ports at the beginning of the execution order satisfies this rule. This arrangement allows Simulink to ignore these blocks during the sorting process.
Applying these rules results in the execution order. Blocks without direct-feedthrough ports appear at the beginning of the list in no particular order. These blocks are followed by blocks with direct-feedthrough ports arranged such that they can supply valid inputs to the blocks which they drive.
The following model illustrates this result. The following blocks do not have direct-feedthrough and therefore appear at the beginning of the execution order of the root-level system:
Integrator block in the Car Dynamics virtual subsystem
Speed block in the root-level model
Inside the Discrete Cruise Controller subsystem, all the Gain blocks, which have direct-feedthrough ports, 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 the following 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,
RTB2is reduced toNoOp, 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.
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.
