A SystemC-Based RTOS Model for Multiprocessor Systems-on-Chips: Part 2 - Uniprocessor SystemsFollowing the discussion in Part 1 on basics and terminology, in this part in this three part series we present the basics of uniprocessor scheduling, which are the prerequisites for understanding multiprocessor scheduling.
We will describe how a uniprocessor system may be modeled using SystemC and, in particular, compare two widely used on-line schedulers for uniprocessor scheduling; RMS and EDF.
Our basic system model consists of three types of components: task, RTOS, and link, with the
link providing communication between the tasks and the RTOS. Here we
present the scheduling service of the RTOS model, and later extend the
RTOS service model to include synchronization and resource allocation.
Tasks can send the messages (ready and finished) to the scheduler, which, in turn, can send one of the three commands to the tasks (run, preempt, and resume). We start by describing how each of the three components and their interactions can be modeled in SystemC.
The communication between the tasks and the scheduler is modeled as two channels: one to send messages from the tasks to the scheduler and one to send commands from the scheduler to the tasks, as illustrated in Figure 10-3 in Part 1.
Our objective is to develop a convenient way to add tasks and schedulers to the system without having to create separate communication channels for each task/scheduler communication, i.e., new tasks and/or schedulers should be added by creating and connecting them.
The Master-Slave library of SystemC provides an elegant solution to this problem. The sc_link_mp component is a high-level implementation of a channel, providing a bus-like functionality, i.e., allowing the scheduler to communicate with n tasks through a single port, but without the complexity of a bus cycle-accurate implementation.
For each master port on one side of the link, there has to be at least one slave port on the other side. In our model, we have multiple master ports connected from the tasks to the slave port in the scheduler through link1 and multiple master ports on the schedulers connected to the slave port in the tasks through link2.
From the Master-Slave library, we use the in-lined execution semantics (Remote Procedure Call) of the sc_link_mp channel. Here, a slave method executes in line with the caller process and returns to the caller after execution. The caller invokes the slave by writing a data value of type message_type to its master port.
In our model, each of the tasks and the scheduler have a master port and a slave port, whereby each task writes messages to its master port invoking the slave method of the scheduler, and the scheduler writes commands to its master port invoking the slave method of each task (Fig. 10-3).
If two tasks (or schedulers in a multiprocessor system) try to send a message at the same time, there will be two master ports writing to the same slave port of the scheduler.
This is handled by the sc_link_mp as follows: two concurrent processes accessing the same link over the master ports access the link in a sequential but undetermined order. This allows the abstraction of any relationship of simultaneity between the two concurrent processes.
The sc_link_mp object does not provide built-in arbitration or privatization functions. It is a primitive (atomic) object that allows abstraction of such refinements. If any arbitration is needed, it has to be implemented in the channel interface.
In our model, we do not use explicit arbitration; it is implicit in the behavior. This means that the scheduler just handles one request at a time (in real time), giving the feeling of arbitration at the time of simulation and making the implementation of a scheduler more intuitive, i.e., it is written as one would write the scheduling algorithm in pseudo-code.