Documentation Center

  • Trial Software
  • Product Updates

Control and Display the Sorted Order

What Is Sorted 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 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.

Display the Sorted Order

To display the sorted order of the vdp model:

  1. Open the van der Pol equation model:

    vdpvdp
  2. 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 0.

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 0:1, executes second. Similarly, the remaining blocks execute in numeric order from 0:2 to 0:8.

You can save the sorted order setting with your model. To display the sorted order when you reopen the model, select Simulation > Update diagram.

Sorted Order Notation

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 TypeSorted Order NotationDescription
Nonvirtual Blockss:b
  • s is the system index of the model or subsystem the block resides in. For root-level models, s is always 0.

  • b specifies the block position within the sorted order for the designated execution context.

Nonvirtual Subsystems (not including function-call and action subsystems)s:b
  • s is the system index of the model or subsystem.

  • b specifies the block position within the sorted order for the designated execution context.

Virtual Blocks and SubsystemsNot applicableVirtual blocks do not execute.
Action Subsystemss:b'
  • s is the system index of the model or subsystem the block resides in. For root-level models, s is always 0.

  • b' is the block index of the action block (but not of the action subsystem).

Function-Call Subsystems and Function-Call modelsOne non-grounded initiator:

s:bi

  • s is the system index of the model or subsystem the block resides in. For root-level models, s is always 0.

  • bi is the block index of the root initiator in the subsystem's hierarchy.

Two or more initiators:

  • s:bi1, s:bi2, ..., s:bin where n is the number of non-grounded initiators.

  • s is the system index of the model or subsystem the block resides in. For root-level models, s is always 0.

  • bin is the block index of the n-th root initiator in the subsystem's hierarchy.

Initiators are either Ground blocks or are unconnected:
  • s:G

  • s is the system index of the model or subsystem the block resides in. For root-level models, s is always 0.

  • G indicates that all function-call initiators are grounded.

Branched Function-Call Signalss:bi[Bk]
  • s is the system index of the model or subsystem the block resides in. For root-level models, s is always 0.

  • bi is the block index of the root initiator in the subsystem's hierarchy.

  • Bk indicates that it is a branched function-call subsystem with branch index k.

Function-Call Feedback Latch Blockss:bi[Bm]
  • s is the system index of the model or subsystem the block resides in. For root-level models, s is always 0.

  • bi is the block index of the root initiator in the subsystem's hierarchy.

  • Bm indicates that it is a branched subsystem with branch index m.

Blocks in a model with asynchronous function-call inputsFunction-call root-level Inport and Outport blocks: Fi
  • F indicates that it is executed in a function-call context.

  • i is the function-call index.

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: Fi

Root-level branched function-call blocks: Fi[Bk]
  • F indicates that it is executed in a function-call context.

  • i is the function-call index.

Blocks inside Export Function Models (See Execution Order for Function-Call Root-level Inport Blocks)Function-call root-level Inport and Outport blocks: Fi
  • F indicates that it is a function-call block.

  • i is the execution order for the function-call root-level Inport or Outport block in normal simulation mode.

Root-level function-call subsystems: Fi

Root-level branched function-call subsystems: Fi[Bk]
  • F indicates that it is a function-call block.

  • i is the execution order for the function-call root-level Inport block in normal simulation mode.

  • Bk indicates a branched function-call subsystem with index k.

Merge and Data Store Memory blocks: Fi, Fj, ...
  • F indicates that it is a function-call block.

  • i is the block execution index.

Root-level data Inport and Outport blocks: Same execution order as the function-call subsystems they are connected to. 
Bus-Capable Blockss:B
  • s is the system index of the model or subsystem the block resides in. For root-level models, s is always 0.

  • B indicates a bus-capable block.

Nonvirtual Blocks

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 model is 0, and the block execution order ranges from 0 to 8.

Nonvirtual Subsystems

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 of 0:5:

  • 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:b, where:

  • 1 is the system index for that subsystem.

  • b is the block position in the execution order. In the Discrete Cruise Controller subsystem, the sorted order ranges from 0 to 8.

Virtual Blocks and Subsystems

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 of 0:0, indicating that the Integrator block is the first block executed in the context of the top-level model.

Function-Call Subsystems

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 the notation s:bi, where s is the index of the system that contains the initiator and bi is the block index of the root initiator in the subsystems hierarchy.

For example, the sorted order for the subsystems f and g is 0:0, since the sorted order of their root initiator, Chart, is 0:0.

Multiple Initiators.  For a function-call subsystem that connects to more than one initiator, the sorted order notation is s:bi1, s:bi2, ..., s:bin where n is the number of non-grounded initiators, s is the system index of the model or subsystem the block resides in, and bin is the block index of the n-th root initiator in the subsystem's hierarchy.

For example, open the sl_subsys_fcncall6 model. 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 0:2 and Chart has a sorted order of 0:4,the function-call subsystem f has a sorted order notation of 0:2,0:4.

Branched Function-Call Signals

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 s:bi[Bk] to indicate this order. s is the system index of the model or subsystem the block resides in, bi is 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 sl_subsys_fcncall11 model and display the sorted order. The sorted order indicates that the subsystem f (B0) executes before the subsystem g (B1).

Bus-Capable Blocks

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 order as s:B where B stands for bus.

For example, open the sldemo_bus_arrays model and display the sorted order. Open the For Each Subsystem to see that the sorted order for the Bus Assignment block appears as 1:B.

For more information, see Bus-Capable Blocks.

How Simulink Determines the Sorted Order

Direct-Feedthrough Ports Impact on Sorted Order

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.

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 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

Inside the Discrete Cruise Controller subsystem, all the Gain blocks, which have direct-feedthrough ports, run before the Sum block that they drive.

Assign Block Priorities

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.

Assigning Block Priorities Programmatically

To set priorities programmatically, use the command:

set_param(b,'Priority','n')

where

  • b is the block path.

  • n is any valid integer. (Negative integers and 0 are valid priority values.)

Assigning Block Priorities Interactively

To set the priority of a block or subsystem interactively:

  1. Right-click the block and select Properties.

  2. On the General tab, in the Priority field, enter the priority.

Rules for Block Priorities

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

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.

BlockPriority
Gain3
Gain12
Gain21

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.

Priorities Are Hierarchical

In the Car Dynamics virtual subsystem, suppose you set the priorities of the Gain blocks as follows.

BlockPriority
Gain2
Gain11

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 other subsystem.

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 1:0 to 1:7.

Lack of Priority May Not Result in Low Priority

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 priorities of 1 and 2 respectively 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.

Block Priority Violations

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 Block Priority Violation diagnostic message.

As an example:

  1. Open the sldemo_bounce model.

    Notice that the output of the Memory block provides the input to the Coefficient of Restitution Gain block.

  2. Set the priority of the Coefficient of Restitution block to 1, and set the priority of the Memory block to 2.

    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.

  3. In the model window, enable sorted order by selecting Format > Block displays > Sorted Order.

  4. Select Simulation > Update Diagram.

    The block priority violation warning appears in the MATLAB® Command Window. The warning includes the priority for the respective blocks:

    Warning: Unable to honor user-specified priorities. 
    'sldemo_bounce/Memory' (pri=[2]) has to execute
    before 'sldemo_bounce/Coefficient of  Restitution'
     (pri=[1]) to satisfy data dependencies 
  5. Remove the priorities from the Coefficient of Restitution and Memory blocks and update the diagram again to see the correct sorted order.

Was this topic helpful?