Control and Display the Execution Order

What Is Execution Order?

During the updating phase of simulation, Simulink® determines the order in which to invoke the block methods during simulation. This block invocation ordering is the execution order.

You cannot set this order, but you can assign priorities to nonvirtual blocks to indicate to Simulink their execution order relative to other blocks. Simulink tries to honor block priority settings, unless there is a conflict with data dependencies. To confirm the results of priorities that 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:

Display the Execution Order

To display the execution order of the vdp model:

  1. Open the vdp model.

  2. On the Debug tab and in the Diagnostics section. select the Information Overlays drop-down arrow. In the Blocks section of the dialog, select Execution Oder. The Execution Oder viewer opens in a pane on the right-side of the Simulink Editor.

Simulink displays a number in the top-right corner of each nonvirtual block and each nonvirtual subsystem. These numbers indicate the order in which the blocks execute. The first block to execute has a execution order of 1.

For example, in the van der Pol equation model, the Integrator block with the execution order 1 executes first. The Out1 block, with the execution order 2, executes second. Similarly, the remaining blocks execute in numeric order from 3 to 9.

Execution Order Notation

Nonvirtual Blocks

In the van der Pol equation model, all the nonvirtual blocks in the model have a execution order. The system index for the top-level model is 0, and the block execution order ranges from 0 to 8.

Nonvirtual and Virtual Subsystems

The following model contains an atomic, nonvirtual subsystem named Discrete Cruise Controller and a virtual subsystem named Car Dynamics.

When you enable the execution order display for the root-level system, Simulink displays the execution order of the blocks.

Virtual subsystem blocks exist only graphically and do not execute. Consequently, they are not part of the execution order. The execution order for the blocks within a virtual subsystem are determined within the context of the root-level model. Their order is displayed on the virtual subsystem block as a list within curly brackets.

However, the blocks inside the subsystem have a execution order in the execution context of the root-level model.

The Car Dynamics subsystem is a virtual subsystem. It does not have a single execution order. The blocks execute at the root level with the Integrator block executing first. The Integrator block sends its output to the Scope block in the root-level model, which executes second.

The Discrete Cruise Controller subsystem is an atomic subsystem.

  • The execution order 5 indicates the subsystem and the blocks within it are the fifth to execute relative to the blocks at the root level.

  • The blocks within the atomic subsystem have their own execution order and execute in that order.


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 Conditional input branch execution, Simulink creates hidden, nonvirtual subsystems, which can affect the sorted execution order.

How Simulink Determines the Execution Order

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:

  • 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 Sorting Blocks

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, from Nonvirtual and Virtual Subsystems, 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.

Related Topics