Scheduling Analysis for Multicore SoC Applications

This example uses:

This example shows how to maintain real-time rate-monotonic (RM) task scheduling by finding a mapping between application tasks and processor cores. To maintain real-time scheduling, each task must complete within the deadline defined by the period of the task.

The example workflow comprises these steps.

Set the software architecture by defining the attributes of the tasks, such as their periods and durations.
Perform timing analysis of the scheduling by using static analysis.
Map the tasks to the processor cores.
Fine tune the scheduling by using a numerical simulation.

Software Architecture

This System Composer model representation defines and captures the software architecture of the application. The components in this model represent application tasks and the connections represent data exchanges. The model applies the SoftwareTask System Composer stereotype to the relevant software tasks. The Period property of this stereotype determines the period of the software task. The WCET property designates the worst-case execution time of the task. You can view the values of these properties in the Simulink Property Inspector.

systemcomposer.openModel('soc_schedulability_sw');

Hardware Architecture

The choice of hardware architecture is usually based on a preliminary performance/cost analysis. The hardware architecture can be represented in a System Composer model. The components in this model represent hardware elements. This example supports only processor cores as its hardware elements. The model applies the ProcessorCore System Composer stereotype to the relevant hardware architecture model components. The CoreNum property of this stereotype determines the processor core number.

systemcomposer.openModel('soc_schedulability_hw');

Mapping Software to Hardware Architecture Using Static Analysis

In this example, you specify the mapping of software tasks to the hardware architecture by using static scheduling analysis. The analysis requires the WCET value of each task. To determine the WCET, use the socModelAnalyzer tool. This tool requires each task to have a Simulink behavior. This MATLAB function calculates and sets the WCET for each task. If the task model behavior is not yet defined, you can mark the WCET as fixed.

soc_schedulability_characterization;

Perform the scheduling analysis for a set of candidate mappings that are captured in the systemcomposer.allocation.editor (System Composer). You can select the candidate mappings are selected based on an initial estimate.

Open the systemcomposer.allocation.editor and view the candidate mappings.

systemcomposer.allocation.editor;

systemcomposer.allocation.load('soc_schedulability_sw_to_hw');

Run the scheduling analysis based on the worst-case response time (WCRT) analysis method. Analyze all task-to-core mapping scenarios specified in the allocation set.

soc_schedulability_coreanalysis;

The soc_schedulability_coreanalysis function indicates whether each task can be scheduled. For a mapping to be a valid solution, all tasks must be schedulable. These results show that the MulticoreBalanced mapping is a valid solution, but the other two mappings are not valid.

Scenario: MulticoreBalanced

      Name       Period     WCET        Core       Schedulable
    {'Task3'}     0.02     0.00011    {'Core1'}         1     
    {'Task4'}     0.04       0.035    {'Core1'}         1     
    {'Task1'}    0.001     9.6e-07    {'Core0'}         1     
    {'Task2'}     0.01     0.00122    {'Core0'}         1

Scenario: MulticoreUnbalanced

      Name       Period     WCET        Core       Schedulable
    {'Task2'}     0.01     0.00122    {'Core1'}         1     
    {'Task3'}     0.02     0.00011    {'Core1'}         1     
    {'Task4'}     0.04       0.035    {'Core1'}         0     
    {'Task1'}    0.001     9.6e-07    {'Core0'}         1

Scenario: SingleCore

      Name       Period     WCET        Core       Schedulable
    {'Task1'}    0.001     9.6e-07    {'Core0'}         1     
    {'Task2'}     0.01     0.00122    {'Core0'}         1     
    {'Task3'}     0.02     0.00011    {'Core0'}         1     
    {'Task4'}     0.04       0.035    {'Core0'}         0

Optimizing Mapping Using Task Simulation

The static scheduling analysis assumes that the execution times of the application functions are constant and equal to WCET. This assumption ensures that the application tasks never overrun, which satisfies the main requirement. However, this mapping may be too pessimistic to efficiently use the processor resources.

Task execution times vary, and many systems tolerate occasional overruns and can support a task schedule that more efficiently uses processor resources. You can analyze task schedule efficiency by simulating task execution.

Accounting for Variable Execution Times

This model simulates a set of software tasks with variable execution times. For illustration, the software tasks in this model have normally distributed execution times, but their WCET is the same as in the soc_schedulability_hw model.

open_system('soc_schedulability_simulation_variable')

Run the simulation and use the Performance Report tool to inspect the task execution statistics. As in the static analysis, no task overruns occur.

Inspect the average hardware usage statistics. Both processor cores remain idle for a substantial portion of execution, with core 0 idle for 11.9% and core 1 idle for 22.2% of the execution time. These results indicate the chosen task schedule may be overly pessimistic.

Accounting for Modified Task Schedule

The task and hardware usage statistics show that you can decrease the period of some tasks, which typically results in a more efficient use of the processor resources. Confirming that the model still meets the task scheduling requirements requires additional analysis. Assume the period of Task2 is 0.002 seconds, and the period of Task4 is 0.034 seconds. Change the task period values in the Task Manager block. Run the simulation and inspect the task execution statistics.

Task4 overruns twice corresponding to an overrun rate of 0.8%. Hard real-time systems do not tolerate overruns. The period of Task4 would need to be increased until no overruns occur. Soft real-time systems tolerate this overrun rate, and the specified task period can be implemented. Inspect the hardware usage statistics. The idle period decreases for both processor cores, which indicates a more efficient use of the processor resources at the expense of the system not meeting hard real-time system requirements.

Further Exploration

Extend the analysis to applications that contain periodic and aperiodic tasks. Treat an aperiodic task as a periodic task with the period equal to the shortest expected repetition task time.