Validate Task-to-CPU Mapping

Open Live Script

Using the Code Profile Analyzer and task execution times from a software-in-the-loop (SIL), processor-in-the-loop (PIL), or XCP-based external mode simulation, perform a CPU feasibility analysis with these steps:

Map generated tasks to CPUs by applying well-known algorithms.
Observe the effect of the mapping on CPU utilization.
Validate the mapping by using well-known checks that assume the tasks are independent and statically partitioned.

Check whether your target hardware can execute generated tasks without encountering scheduling issues, for example, task overrun events where new task instances arrive before the termination of previous instances.

Run Simulation and Open Code Profile Analyzer

Open the model.

open_system('TaskToCPUMapping');

Configure an XCP-based external mode simulation.

set_param(gcs, 'SimulationMode', 'external');
set_param(gcs, 'SolverType', 'Fixed-step');
set_param(gcs, 'ExtMode', 'on');

cs = getActiveConfigSet(gcs);
index = Simulink.ExtMode.Transports.getExtModeTransportIndex(cs, 'XCP on TCP/IP');
set_param(gcs, 'ExtModeTransport', index);

set_param(gcs, 'GenerateSampleERTMain', 'on');
set_param(gcs, 'TargetOS', 'BareBoardExample'); 

set_param(gcs, 'ReturnWorkspaceOutputs', 'off');

Treat each discrete rate as a separate task.

set_param(gcs, 'EnableMultiTasking', 'on');

Enable code execution profiling.

set_param(gcs, 'CodeExecutionProfiling', 'on');
set_param(gcs, 'CodeProfilingInstrumentation', 'off');

Start the simulation.

set_param(gcs, 'SimulationCommand', 'start');

At the end of the simulation, open the Code Profile Analyzer.

isExternalSimulationActive = true;
while isExternalSimulationActive
    pause(0.1);
    simStatus = get_param(gcs, 'SimulationStatus');
    isExternalSimulationActive = ~strcmp(simStatus, 'stopped');
end
coder.profile.show(executionProfile);

Click the Task Validation panel, which provides four views.

Task Validation Views

List of tasks to map

This view displays information about tasks generated from the profiled component:

Task – Task name.
Period – Sample period. You can edit this column.
Fixed Priority – Relative importance of the task. The higher the value, the higher the priority. The initial generation of values assumes that the scheduling is rate-monotonic. You can edit this column.
Average Execution Time – Average time between the start and the end of the task.
Maximum Execution Time – The longest time between the start and the end of the task.

List of CPUs

Initially, this view shows:

For XCP-based external mode simulations, the clock frequency for each CPU on the target hardware.
For SIL or PIL simulations, the clock frequency for the first CPU.

You can edit the CPU Clock column.

Task-to-CPU mapping

In this view, you can map a generated task to an available CPU, that is, you can set statically the CPU affinity for each task.

When you open the Code Profile Analyzer, it assigns initially all tasks to the first CPU. To create the task-to-CPU mapping, you can:

Manually map tasks to CPUs.
Use an algorithm from the Map tasks automatically drop-down list. For the algorithm, you must also specify the use of average (default) or maximum task execution times. For a list of algorithms, see Options for Task-to-CPU Mapping.

Analyze CPU workload

This view shows, through the Average Utilization (%) and Maximum Utilization (%) columns, the percentage of time that each CPU is busy running the mapped tasks. To validate CPU utilization for the mapped tasks, click Validate Mapping. Depending on the task scheduling algorithm, execution issues can arise even when a CPU is not fully loaded. For a list of algorithms, see Options for Task Mapping Validation.

Perform Mapping and Validation

To make the viewing of results for this example easier, on the toolstrip, in the Time unit field, specify Seconds (s). In the List of tasks to map view, note the periods and average execution times of these tasks:

TaskToCPUMapping_step1 – Executed every 0.4 s and takes 0.12 s.
TaskToCPUMapping_step2 – Executed every 0.5 s and takes 0.20 s.
TaskToCPUMapping_step3 – Executed every 2.0 s and takes 0.50 s.

Using the initial mapping and default scheduler and check algorithm (Rate Monotonic - Least Upper Bound), click Validate Mapping. The validation process produces a warning, indicating that tasks can overrun.

From the Validate task mapping drop-down list, select Rate Monotonic – Response Time Analysis. Then click Validate Mapping.

Compared to the default algorithm, which checks an upper bound, Rate Monotonic – Response Time Analysis is exact and expensive - see Options for Task Mapping Validation. Although the validation process does not detect overrun issues, the CPU utilization value is high. To address the problem, use one of these approaches:

Map Tasks Manually

In the Task-to-CPU mapping view, on the TaskToCPUMapping_step3 row, from the CPU cell drop-down list, select CPU 2. Then, click Validate Mapping.

By using another CPU, the utilization value for CPU 1 decreases.

Use Automatic Task Mapping

From the Map tasks automatically drop-down list, select Worst-Fit. Then, click Map Tasks, which maps the tasks to available CPUs.

Click Validate Mapping.

The validation process shows moderate utilization values for the CPUs.

Increase Sample Periods

In the List of tasks to map view, increase the sample periods for the tasks. For example, for TaskToCPUMapping_step1, change 0.4 s to 0.6 s and for TaskToCPUMapping_step2, change 0.5 s to 0.8 s. Tasks are executed less frequently, which provides more CPU headroom.
Use the initial mapping. From the Map tasks automatically drop-down list, select First-Fit. Then, click Map Tasks.
Use the default scheduler and check algorithm. From the Validate task mapping drop-down list, select Rate Monotonic - Least Upper Bound. Then, click Validate Mapping.

The validation process does not detect overrun issues and displays a moderate CPU utilization value. Although the schedulability issue is resolved, changing sample periods might affect your algorithm. Use this approach carefully.

Use Faster CPU

Consider the task set with the initial period values and mapping.

If you use the default scheduler and check algorithm (Rate Monotonic - Least Upper Bound), the validation process produces a warning, indicating that tasks can overrun.

To specify a faster CPU, in the List of CPUs view, for CPU 1, change the CPU Clock (MHz) value to a higher value. Then, click Validate Mapping.

The validation process does not detect overrun issues and displays a moderate CPU utilization value.

Check Fixed-Priority Scheduling

If your target hardware does not use rate-monotonic scheduling, you can check schedulability for a fixed-priority task set. Use this task set and the corresponding fixed-priority values.

To check task schedulability:

From the Validate task mapping drop-down list, select Fixed Priority – Response Time Analysis.
Click Validate Mapping. The validation process does not detect execution-time issues for the specified task-to-CPU mapping.

In the Lists of tasks to map view, for TaskToCPUMapping_step3, increase the Fixed Priority value to 25. Since the priority of TaskToCPUMapping_step3 is now higher than the priority of TaskToCPUMapping_step2, TaskToCPUMapping_step3 can preemt TaskToCPUMapping_step2. You can expect overrun events for TaskToCPUMapping_step2.

Click Validate Mapping.

The validation process indicates that tasks can overrun.

Options for Task-to-CPU Mapping

You can control task-to-CPU mapping by specifying an algorithm. From the Map tasks automatically drop-down list, select one of these options:

First-Fit – Assigns a task to the first available CPU.
Best-Fit - Assigns a task to the CPU with the smallest resources that can accommodate the task utilization.
Worst-Fit – Assigns a task to the CPU with the biggest resources that can accommodate the task utilization.
First-Fit Decreasing – Like First-Fit but sorts tasks from highest to lowest utilization.
Best-Fit Decreasing – Like Best-Fit but sorts tasks from highest to lowest utilization.
Worst-Fit Decreasing – Like Worst-Fit but sorts tasks from highest to lowest utilization.
Round Robin – Does not consider task utilization but assigns tasks to CPUs in a round-robin fashion, aiming for an even distribution.

The First-Fit, Best-Fit, and Worst-Fit algorithms do not use a defined order when mapping tasks to CPUs.

Options for Task Mapping Validation

You can select a scheduler and algorithm for validating the task-to-CPU mapping. From the Validate task mapping drop-down list, select one of these options:

Rate Monotonic - Least Upper Bound
Rate Monotonic – Response Time Analysis
Fixed Priority – Response Time Analysis

Rate-monotonic scheduling assigns fixed priorities to tasks by using their periods: the shorter the period, the higher the task priority.

Fixed-priority scheduling assigns priorities to tasks statically. The List of tasks to map view displays the priority values in the Fixed Priority column.

The Rate Monotonic - Least Upper Bound option uses rate-monotonic scheduling with the least upper bound check. The validation process verifies that the total CPU utilization is less than an upper bound that is dependent on the number of tasks:

$U = \sum_{i = 1}^{n} U_{i} = \sum_{i = 1}^{n} \frac{C_{i}}{T_{i}} \leq n (2^{\frac{1}{n}} - 1)$

$U$ is the total CPU utilization, $C_{i}$ is the computation time for task $i$ , $T_{i}$ is the sample period for task $i$ , and $n$ is the number of tasks that require scheduling. For two tasks, the validation process verifies that the total CPU utilization is less than 82%. As the number of tasks becomes large, the upper bound converges to 69%. For more information, see Rate-Monotonic Scheduling.

The Rate Monotonic – Response Time Analysis option uses rate-monotonic scheduling with the response time analysis check, which verifies that the worst-case response time for each task is not greater than the task period. The task response time is the interval between the time at which the task is ready for execution and the time at which execution is complete, taking into account execution of the task and all higher priority tasks. The worst-case execution assumes that all tasks are ready at the same time. Higher priority tasks preempt the task under analysis, which increases the task response time. The validation process iteratively computes the response time $R_{i}$ for task $i$ :

$R_{i}^{(k + 1)} = C_{i} + \sum_{j \in hp (i)} ⌈ \frac{R_{i}^{(k)}}{T_{j}} ⌉ C_{j}$

$C_{i}$ is the worst-case execution time of task $i$ and $hp (i)$ is the set of tasks with priorities higher than task $i$ . The iterations continue until $R_{i}^{(k + 1)} = R_{i}^{(k)}$ .

The Fixed Priority – Response Time Analysis option uses fixed-priority scheduling with the response time analysis check.

Clean Up

Close the model.

close_system(gcs,0);