FAQ 783: How to Enforce the Order of Commands in TargetLink 

Question

Sometimes, for example, in scenarios with data store read/write or in case of a hidden data flow, the order of generated code might not match your intentions or might cause different results between MIL and SIL/PIL simulations in TargetLink. How can you enforce the intended order in TargetLink?

To the left, the data store reads. To the right, the data store writes. The code you can expect for this model is:

A=1;
A=A*2;
A=A+B;

Simulink block priorities are not considered in the TargetLink production code. If the block execution order is not completely determined by the control flow and data flow, the TargetLink block scheduling can be different from that of Simulink. The resulting code might be:

A=A*2;
A=A+B;
A=1;

The grey lines might be removed during optimization. For the generated code, they do not influence the result A=1. It might be useful to temporarily deactivate optimization to understand the generated code. You can find this option in the TargetLink Main dialog on the Advanced page.

Solution A: Modeling an Unambiguous Block Order

In this simple situation, the recommendation is to model the order using signal lines:
 

In some situations, this kind of modeling approach might not be possible. Thus, this FAQ will also present alternative modeling techniques to control the execution order.

Solution B: Atomic Subsystems (Data Flow)
 

In the above example, the operations are executed in the expected order because they are placed in atomic subsystems and data flow determines the execution order of the atomic subsystems. Note that atomic subsystems are required in this situation. If the three outer subsystems were virtual subsystems, the order in which A=1, A=A*2, and A=A+B are executed would be undefined.

Solution C: Scheduling (Control Flow)

The two previously proposed solutions were based on a data flow modeled by signal lines. An alternative is to introduce control flow using function calls.
 

Here, a function call generator makes sure the function-call subsystems are called in the right order. 
If you get an error message or warning related to ‘SystemTime‘,refer to FAQ 729 – “Supplying a System Time Variable”. For more advanced scheduling, replace the function call generator with a Stateflow chart that has multiple event outports.

Note that for TargetLink versions ≥ 2025-B (25.1), TargetLink also supports the Function-Call Split block as an alternative to splitting function-call signals with a Demux block (as shown in the screenshot above).

Limiting the Optimization (Applies to All Solutions)

The approaches demonstrated so far ensure that the correct order is reflected in the initial code. Later, the optimization might interleave and combine code from multiple atomic subsystems but does not change the result of the code.

In situations where a changed order of (external) function calls causes different behavior, make sure to uncheck the SIDE_EFFECT_FREE optimization of the corresponding function class.

If you are in a situation where the code from several atomic subsystems must be kept separate, you can clear the AllowInterleavingCodeForAllSubsystems code generator option.

Further reading

Control and Display the Sorted Order (Simulink Documentation)
 

To the left, the data store reads. To the right, the data store writes. The code you can expect for this model is:

A=1;

A=A*2;

A=A+B;

Simulink block priorities are not considered in the TargetLink production code. If the block execution order is not completely determined by the control flow and data flow, the TargetLink block scheduling can be different from that of Simulink. The resulting code might be:

A=A*2;

A=A+B;

A=1;

The grey lines might be removed during optimization. For the generated code, they do not influence the result A=1. It might be useful to temporarily deactivate optimization to understand the generated code. You can find this option in the TargetLink Main dialog on the Advanced page.