M3-SCoPE: Performance Modeling of Multi-Processor Embedded Systems for Fast Design Space Exploration - Multi-objective Design Space Exploration of Multiprocessor SoC Architectures - page 34

Fig. 2.10 Architecture of the
OS model. The model is
divided in three parts: the
upper part contains the
implementation of the
services directly called by the
application software. The
middle part contains the
model kernel, where all the
internal OS services are
implemented. Finally, the
lower part is in charge of
enabling the interconnection
of the software with the rest
of the simulation

Application
SW code

Application
SW code

Application
SW code

OS API (POSIX)
Scheduling

...

Communic.

OS kernal

OS
model

...

Scheduler IPC

HAL
Interruptions I/O ...

Hardware platform model

the layers oriented to hide the HW platform details (Hardware Abstraction Layer,
HAL) from the rest of the system, such as low-level functions to access the bus, the
interruption management or the context switch infrastructure. Thus, the proposed OS
model will provide support for all of these common OS sections, as can be seen in Fig.
2.10 . In order to simplify the models, all the possible layers have been grouped into
three layers, following the classification above. To model the execution time of the
OS itself, a delay is associated to all system calls and some internal functionalities,
such as context switches or interrupt handlers.
The kernel core is mainly in charge of process and thread execution management,
memory management and task communication and synchronization. To model task
scheduling characteristics, a new scheduler is placed on top of the original SystemC
scheduler. The OS model scheduler controls task execution by maintaining only one
unblocked thread per processor. This scheduler manages the priorities and policies
as indicated in POSIX, integrating a two-level scheduler: process scheduling and
thread scheduling. The scheduler is called when a task is blocked or unblocked as an
effect of a system call, or when an interrupt resumes a task preempting the current
running task.
This functionality has been implemented with use of the SystemC features. Each
thread in the application SW is associated with a SystemC thread ( SC_THREAD )
running the corresponding code. In this way, the SystemC scheduler is in charge
of managing the thread context switches. To model the OS thread scheduling the
SystemC scheduler is hidden. All the SystemC threads are suspended with SystemC
wait statements. When the scheduler selects one of these threads, a notify call
is performed to awake the corresponding thread. When the thread is preempted
or blocked, it returns to the wait statement and a new thread is scheduled. Thus,