Execution order is determined based on data dependencies and should not need to be controlled except in cases where it is underspecified. Underspecified execution order is when multiple valid execution orders exist. This can result in issues if data dependencies exist that are not visible to Simulink (e.g. external code, "Data Store Read"/"Data Store Write"). Since these models do not have a singular, correct execution order, the execution order can change from release to release or between simulation and generated code. Some execution orders will respect unknown data dependencies by chance while others may not.
If the model can be configured in a manner that does not create an underspecified execution order, this should be the primary solution. If this is not possible, Execution Order First or Last, Block Priority, "Function-Call Split", and "Data Store Memory" blocks can be used to explicitly control some or all of the execution order. You may notice that block priority is a more common suggestion, though it is not always the best solution.
1) Execution Order First or Last is a simple option if you need to control only the first and/or last block (or atomic unit of blocks). This feature is best if numerous blocks exist between the desired first and last blocks. One benefit is the user doesn't need to worry about renumbering as one might with block priority. First-last is also not always respected due to optimizations or signal copies.
See Set Execution Order Property for Block to Execute First to set the Execution Order to First (or last).
See Specify Block Execution Order, Execution Priority and Tag for explanation and limitations.
2) Block Priority is a good solution if it is necessary to control every block. It works best with fewer blocks (often inside atomic subsystem) or models that are non-changing. Block priority is not always respected due to optimizations or signal copies. The user must keep track of block priorities, especially if new blocks are added to the model and renumbering may be required.
See Set Priority in Execution Order of Blocks to use block priority.
See Control and Display Execution Order to learn how priority impacts the execution order and the limitations of this feature.
3) Function-call subsystem with "Function-Call Split" allows robust control of one, a few, or all blocks by using a "Function-Call Split" block to call function-call subsystems in a desired order. It is especially useful when blocks can be grouped into subsystems so fewer splits are necessary. The structural changes to the model may or may not be desired, but provide a visual representation of the execution order. This can be flexible to model changes since function-call subsystems and the splits can be added, removed, or swapped quicker than renumbering block priority. This method can also be robust to optimizations compared to block priority and execution order first-last.
See "Function-Call Split" for more information on this feature.
4) Data Store Read and Write Blocks allow explicit control over when data is read or written, especially when combined with one of the execution-order methods described above. By default, "Inport" blocks access input data at the start of a subsystem’s execution. If your application requires accessing data later, after other parts of the model or generated code have run, consider replacing "Inport" blocks with "Data Store Read" and "Data Store Write" blocks. They can also be paired with Simulink.Signal objects to interface with external code.
