Modeling for Multitasking Execution

Multitasking and Pseudomultitasking Modes

When periodic tasks execute in a multitasking mode, by default the blocks with the fastest sample rates are executed by the task with the highest priority, the next fastest blocks are executed by a task with the next higher priority, and so on. Time available in between the processing of high-priority tasks is used for processing lower priority tasks. This results in efficient program execution.

Where tasks are asynchronous rather than periodic, there may not necessarily be a relationship between sample rates and task priorities; the task with the highest priority need not have the fastest sample rate. You specify asynchronous task priorities using Async Interrupt and Task Sync blocks. You can switch the sense of what priority numbers mean by selecting or clearing model configuration parameter Higher priority value indicates higher task priority.

In multitasking environments (that is, under a real-time operating system), you can define separate tasks and assign them priorities. For bare-metal target hardware (that is, no real-time operating system present), you cannot create separate tasks. However, generated application modules implement what is effectively a multitasking execution scheme using overlapped interrupts, accompanied by programmatic context switching.

This means an interrupt can occur while another interrupt is currently in progress. When this happens, the current interrupt is preempted, the floating-point unit (FPU) context is saved, and the higher priority interrupt executes its higher priority (that is, faster sample rate) code. Once complete, control is returned to the preempted ISR.

The next figures illustrate how timing of tasks in multirate systems are handled by the code generator in multitasking, pseudomultitasking, and single-tasking environments.

Timing diagram that shows how the code generator handles timing of tasks in multirate systems

The next figure shows how overlapped interrupts are used to implement pseudomultitasking. In this case, Interrupt 0 does not return until after Interrupts 1, 2, and 3.

Timing diagram that shows how overlapped interrupts are used to implement pseudomultitasking

Build a Program for Multitasking Execution

To use multitasking execution, select model configuration parameter Treat each discrete rate as a separate task. This parameter is active only if you set Solver type to Fixed-step. Auto mode results in a multitasking environment if your model has two or more different sample times. A model with a continuous and a discrete sample time runs in single-tasking mode if the fixed-step size is equal to the discrete sample time.

Execute Multitasking Models

In cases where the continuous part of a model executes at a rate that is different from the discrete part, or a model has blocks with different sample rates, the Simulink^® engine assigns each block a task identifier (tid) to associate the block with the task that executes at the block's sample rate.

You set sample rates and their constraints on the Solver pane of the Model Configuration Parameters dialog box. To generate code, select Fixed-step for the solver type. Certain restrictions apply to the sample rates that you can use:

The sample rate of a block must be an integer multiple of the base (that is, the fastest) sample period.
When you set model configuration parameter Periodic sample time constraint to unconstrained, the base sample period is determined by the setting of parameter Fixed step size.
When you set parameter Periodic sample time constraint to Specified, the base rate fixed-step size is the first element of the sample time matrix that you specify for parameter Sample time properties. The Solver pane from the example model MultirateMultitaskingBareBoard shows an example.
Continuous blocks execute by using an integration algorithm that runs at the base sample rate. The base sample period is the greatest common denominator of rates in the model only when you set model configuration parameter Periodic sample time constraint to Unconstrained and parameter Fixed step size to Auto.
The continuous and discrete parts of the model can execute at different rates only if the discrete part is executed at the same or a slower rate than the continuous part and is an integer multiple of the base sample rate.

Multitasking Execution

You can simulate and execute code generated from this simple multirate model, which is configured to use a fixed-step solver, in single-tasking or multitasking mode.

Execution order of blocks in model, labeled A through F.

The tasking mode that gets applied depends on the setting of model configuration parameter Treat each discrete rate as a separate task. When cleared, the parameter specifies single-tasking mode. When selected, the parameter specifies multitasking mode.

The example description refers to the six blocks in the model as A through F.

The execution order of the blocks (indicated in the upper right of each block) is forced into the order shown by assigning higher priorities to blocks F, E, and D. The ordering shown is one possible valid execution ordering for this model. For more information, see Simulation Phases in Dynamic Systems.

The execution order is determined by data dependencies between blocks. In a real-time system, the execution order determines the order in which blocks execute within a given time interval or task. This discussion treats the model execution order as a given, because it is concerned with the allocation of block computations to tasks, and the scheduling of task execution.

Note

The discussion and timing diagrams in this section are based on the assumption that the Rate Transition blocks are used in the default (protected) mode, with block parameters Ensure data integrity during data transfer and Ensure deterministic data transfer (maximum delay) selected.

When this model is configured for multitasking, block computations are executed under two tasks, prioritized by rate:

The slower task, which gets the lower priority, is scheduled to run every second. This is called the 1 second task.
The faster task, which gets higher priority, is scheduled to run 10 times per second. This is called the 0.1 second task. The 0.1 second task can preempt the 1 second task.

For each block in the model, this table shows the execution order, the task under which the block runs, and whether the block has an output or update computation. Blocks A and B do not have discrete states, and accordingly do not have an update computation.

Blocks (in Execution Order)	Task	Output	Update
E	0.1 second task	Y	Y
F	0.1 second task	Y	Y
D	The Rate Transition block uses port-based sample times. Output runs at the output port sample time under 0.1 second task. Update runs at input port sample time under 1 second task. For more information on port-based sample times, see Referenced Model Sample Times.	Y	Y
A	0.1 second task	Y	N
B	The Rate Transition block uses port-based sample times. Output runs at the output port sample time under 0.1 second task. For more information on port-based sample times, see Referenced Model Sample Times.	Y	N
C	1 second task	Y	Y

Real-Time Multitasking Execution

This figure shows the scheduling of computations when the generated code is deployed in a real-time system in multitasking mode. The generated program is shown running in real time as two tasks under control of interrupts from a 10 Hz timer.

Timing diagram that shows scheduling of computations in multitasking solver mode when generated code is deployed in a real-time system

Simulated Multitasking Execution

This figure shows the execution of the model during a Simulink simulation loop.

This figure shows a simulation of the model in multitasking mode. The Simulink engine runs the blocks in one thread of execution, simulating multitasking. Preemption does not occur.

Timing diagram that shows the Simulink execution of the model in multitasking solver mode