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

the SystemC scheduler executes the only one runnable thread each time. This way
scheduling is completely managed by the OS model scheduler through wait and
notify statements. Note that SystemC wait statements are used for two purposes:
thread blocking for scheduling purposes, as explained here, and for time annotations
as explained in the previous section.
However, SW code refinement implies more than optimizing task scheduling
characteristics. The proposed OS model provides a wide set of OS facilities, in
order to allow the transformation of high-level descriptions into real executable SW
codes. High-level features for communication, synchronization or time management
have to be substituted by real OS features. In our proposal, a POSIX API has been
implemented for communication (e.g. message queues or sockets), synchronization
(e.g. semaphores, mutex or conditional variables), signals, timers, sleeps and many
other functionalities. Thus, the designer can simulate the real SW code together with
the rest of the system before moving to more accurate but time consuming simulation
infrastructures, such as ISS-based simulations.
To support several independent OS models the OS model information has been
encapsulated in a C++ class. Thus, modeling several OSs only require instantiating
an OS class several times. Multiprocessor management is supported by maintaining
as many running threads as processors. When a process is created or preempted, the
presence of an idle processor is verified. When a processor is delivered, a new thread
is scheduled to run on this processor. In this way, all processes are maintained active,
and tasks are scheduled as soon as a processor becomes empty.
As all threads are SystemC threads, and the SystemC kernel activates the threads
sequentially, there is no real parallelism during the simulation. Parallelism is only
emulated. As a consequence, no additional mechanism is required to ensure safe
concurrency inside the OS model, in contrast to real Symmetric Multi-Processing
(SMP) OSs, where mechanisms such as spinlocks are critical to handle concurrency
safety. Furthermore, the OS modeling technique is flexible enough to cover the most
usual OS architectures. Each OS is associated to a memory space independently
of the underlying processing architecture (bus or network). The complete MPSoC
may contain as many memory spaces as needed. The HW platform model creation
presented above easily enables that feature.
More complex is the modeling of memory space separation among processes of
the same OS. As the SystemC simulation is a single host process, the management of
memory spaces in the simulation requires additional mechanisms. Reusing names of
functions and global variables among component codes or loading several instances
of the same task is not possible without a memory space separation infrastructure.
Nevertheless, this problem is not limited to processes of the same OS. As the entire
simulation is a single host process, name duplication between SW process of differ-
ent nodes, running in different OS, or between SW and HW components provokes
the same error. A general solution has been implemented in M3-SCoPE. It will be
presented hereafter when describing how all the system components are integrated in
the SystemC model. Finally, the technology has also proven to be accurate enough to
model dual General-Purpose/Real-Time Operating Systems, such as RTLinux. More
information can be found in [ 52 ].