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 sorted 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 sorted order of your nonvirtual blocks and subsystems.
To display the sorted order of the
Open the van der Pol equation model:
In the model window, select Display > Blocks > Sorted Execution Order.
Simulink displays a notation 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 sorted order of
For example, in the van der Pol equation model, the Integrator
block with the sorted order
0:0 executes first.
The Out1 block, with the sorted order
second. Similarly, the remaining blocks execute in numeric order from
You can save the sorted order setting with your model. To display the sorted order when you reopen the model, select Simulation > Update diagram.
The sorted order notation varies depending on the type of block. The following table summarizes the different formats of sorted order notation. Each format is described in detail in the sections that follows the table.
|Block Type||Sorted Order Notation||Description|
|Nonvirtual Subsystems (not including function-call and action subsystems)|
|Virtual Blocks and Subsystems||Not applicable||Virtual blocks do not execute.|
|Function-Call Subsystems and Function-Call models||One non-grounded initiator: |
Two or more initiators:
|Initiators are either Ground blocks or are unconnected:|
|Branched Function-Call Signals|
|Function-Call Feedback Latch Blocks|
|Blocks in a model with asynchronous function-call inputs||Function-call root-level Inport and Outport blocks: |
|Root-level data Inport blocks: If they drive a function-call
subsystem, it is the function-call index of the subsystem.|
If they are part of the model that is not driven by asynchronous function-call inputs, then no function-call index is displayed.
Root-level function-call blocks:
|Blocks inside Export Function Models (See Execution Order for Function-Call Root-level Inport Blocks)||Function-call root-level Inport and Outport blocks: |
Root-level function-call subsystems:
|Merge and Data Store Memory blocks: |
|Root-level data Inport and Outport blocks: Same execution order as the function-call subsystems they are connected to.|
In the van der Pol equation model, all the nonvirtual blocks
in the model have a sorted order. The system index for the top-level
0, and the block execution order ranges
The following model contains an atomic, nonvirtual subsystem named Discrete Cruise Controller.
When you enable the sorted order display for the root-level system, Simulink displays the sorted order of the blocks.
The Scope block in this model has the lowest sorted order, but its input depends on the output of the Car Dynamics subsystem. The Car Dynamics subsystem is virtual, so it does not have a sorted order and does not execute as an atomic unit. However, the blocks within the subsystem execute at the root level, so the Integrator block in the Car Dynamics subsystem executes first. The Integrator block sends its output to the Scope block in the root-level model, which executes second.
The Discrete Cruise Controller subsystem has a sorted order
0 indicates that this atomic subsystem
is part of the root level of the hierarchal system comprised of the
primary system and the two subsystems.
5 indicates that the atomic subsystem
is the sixth block that Simulink executes relative to the blocks
within the root level.
The sorted order of each block inside the Discrete Cruise Controller
subsystem has the form
1 is the system index for that
b is the block position
in the execution order. In the Discrete Cruise Controller subsystem,
the sorted order ranges from
Virtual blocks, such as the Mux block, exist only graphically and do not execute. Consequently, they are not part of the sorted order and do not display any sorted order notation.
Virtual subsystems do not execute as a unit, and like a virtual block, are not part of the sorted order. The blocks inside the virtual subsystem are part of the root-level system sorted order, and therefore share the system index.
In the model in Nonvirtual Subsystems, the virtual subsystem Car Dynamics
does not have a sorted order. However, the blocks inside the subsystem
have a sorted order in the execution context of the root-level model.
The blocks have the same system index as the root-level model. The
Integrator block inside the Car Dynamics subsystem has a sorted order
0:0, indicating that the Integrator block is
the first block executed in the context of the top-level model.
Single Initiator. A function-call subsystem (or model) executes when the initiator
invokes the function-call subsystem (or model) and, therefore, does
not have a sorted order independent of its initiator. Specifically,
for a subsystem that connects to one initiator, Simulink uses
s is the index of the system that
contains the initiator and
the block index of the root initiator in the subsystems hierarchy.
For example, the sorted order for the subsystems f and g is
since the sorted order of their root initiator, Chart, is
Multiple Initiators. For a function-call subsystem that connects to more than one
initiator, the sorted order notation is
n is the number of non-grounded initiators,
the system index of the model or subsystem the block resides in, and
the block index of the n-th root initiator in the subsystem's
For example, open the
The f subsystem has three initiators from the same level in the subsystem's
hierarchy. Two are from the Stateflow® chart, Chart1, and one
from the Stateflow chart, Chart.
Because Chart1 has a sorted order
Chart has a sorted order of
subsystem f has a sorted order notation of
When a function-call signal is branched using a Function-Call
Split block, Simulink displays the order in which subsystems
(or models) that connect to the branches execute when the initiator
invokes the function call. Simulink uses the notation
to indicate this order.
s is the system
index of the model or subsystem the block resides in,
the block index of the root initiator in the subsystem's hierarchy,
and Bk indicates that it is a branched function-call
subsystem with branch index k.
For example, open the
and display the sorted order. The sorted order indicates that the
subsystem f (
B0) executes before the subsystem
A bus-capable block does not execute as a unit and therefore
does not have a unique sorted order. Such a block displays its sorted
For example, open the
and display the sorted order. Open the For Each Subsystem to see that
the sorted order for the Bus Assignment block appears as
For more information, see Bus-Capable Blocks.
To ensure that the sorted 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.
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 sorted 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 sorted 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 sorted order satisfies this rule. This arrangement allows Simulink to ignore these blocks during the sorting process.
Applying these rules results in the sorted 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 Subsystems, illustrates this result. The following blocks do not have direct-feedthrough and therefore appear at the beginning of the sorted order of the root-level system:
Integrator block in the Car Dynamics virtual subsystem
Speed block in the root-level model
You can assign a priority to a nonvirtual block or to an entire subsystem. Higher priority blocks appear before lower priority blocks in the sorted order. The lower the number, the higher the priority.
To set priorities programmatically, use the command:
b is the block path.
n is any valid integer. (Negative
integers and 0 are valid priority values.)
To set the priority of a block or subsystem interactively:
Right-click the block and select Properties.
On the General tab, in the Priority field, enter the priority.
Simulink honors the block priorities that you specify unless they violate data dependencies. (Block Priority Violations describes situations that cause block property violations.)
In assessing priority assignments, Simulink attempts to create a sorted order such that the priorities for the individual blocks within the root-level system or within a nonvirtual subsystem are honored relative to one another.
Three rules pertain to priorities:
Priorities are relative; the priority of a block is relative to the priority of the blocks within the same system or subsystem.
For example, suppose you set the following priorities in the Discrete Cruise Controller subsystem in the model in Nonvirtual Subsystems.
After updating the diagram, the sorted order for the Gain blocks is as follows.
The sorted order values of the Gain, Gain1, and Gain2 blocks reflect the respective priorities assigned: Gain2 has highest priority and executes before Gain1 and Gain; Gain1 has second priority and executes after Gain2; and Gain executes after Gain1. Simulink takes into account the assigned priorities relative to the other blocks in that subsystem.
The Gain blocks are not the first, second, and third blocks to execute. Nor do they have consecutive sorted orders. The sorted order values do not necessarily correspond to the priority values. Simulink arranges the blocks so that their priorities are honored relative to each other.
In the Car Dynamics virtual subsystem, suppose you set the priorities of the Gain blocks as follows.
After updating the diagram, the sorted order for the Gain blocks is as illustrated. With these priorities, Gain1 always executes before Gain.
You can set a priority of
1 to one block
in each of the two subsystems because of the hierarchal nature of
the subsystems within a model. Simulink never compares the priorities
of the blocks in one subsystem to the priorities of blocks in any
For example, consider this model again.
The blocks within the Car Dynamics virtual subsystem are part
of the root-level system hierarchy and are part of the root-level
sorted order. The Discrete Cruise Controller subsystem has an independent
sorted order with the blocks arranged consecutively from
A lack of priority does not necessarily result in a low priority (higher sorting order) for a given block. Blocks that do not have direct-feedthrough ports execute before blocks that have direct-feedthrough ports, regardless of their priority.
If a model has two atomic subsystems, A and B, you can assign
to A and B. This priority causes all the blocks in A to execute before
any of the blocks in B. The blocks within an atomic subsystem execute
as a single unit, so the subsystem has its own system index and its
own sorted order.
Simulink software honors the block priorities that you
specify unless they violate data dependencies. If Simulink is
unable to honor a block priority, it displays a
Violation diagnostic message.
As an example:
Notice that the output of the Memory block provides the input to the Coefficient of Restitution Gain block.
Set the priority of the Coefficient of Restitution
1, and set the priority of the Memory
Setting these priorities specifies that the Coefficient of Restitution block execute before the Memory block. However, the Coefficient of Restitution block depends on the output of the Memory block, so the priorities you just set violate the data dependencies.
In the model window, enable sorted order by selecting Format > Block displays > Sorted Order.
Select Simulation > Update Diagram.
The block priority violation warning appears in the Diagnostic Viewer. To open the Diagnostic Viewer window, click View > Diagnostic Viewer. The warning includes the priority for the respective blocks:
Warning: Unable to honor user-specified priorities. 'sldemo_bounce/Memory' (pri=) has to execute before 'sldemo_bounce/Coefficient of Restitution' (pri=) to satisfy data dependencies
Remove the priorities from the Coefficient of Restitution and Memory blocks and update the diagram again to see the correct sorted order.