A SystemC-Based RTOS Model for Multiprocessor Systems-on-Chips: Part 1 - Basic Concepts and TerminologyWith the increasing complexity of embedded systems and the capacity of modern silicon technology, there is a trend toward heterogeneous architectures consisting of several programmable as well as dedicated processors, implemented on a single chip, known as systems-on-chips (SoCs).
As more applications are implemented in software that in turn is growing larger and more complex, dedicated operating systems will have to be introduced as an interface layer between the application software and the hardware platform.
Global analysis of such heterogeneous systems is a big challenge. Typically, two aspects are of interest when one is considering global analysis: the system functionality, in general, and the system timing and resource sharing, in particular.
As many embedded applications are reactive in nature and have real-time requirements, it is often not possible to analyze them statically at compile time. Furthermore, for single-chip solutions, we may need to use nonstandard real-time operating systems (RTOS) in order to limit the code size and hence the memory requirements, or to introduce special features interacting with the dedicated hardware, such as power management.
When implementing an RTOS, we may wish to experiment with different scheduling strategies in order to tailor the RTOS to the application. For a multiprocessor platform, we may wish to study the system-level effects of selecting a particular RTOS implementation on one of the processors.
To study these effects at the system level, before any implementation has been done, we need a system-level model that is able to capture the behavior of running a number of RTOS on a multiprocessor platform.
We refer to such a system-level model as an abstract model. In this first part on concepts and terminology and followed by succeeding parts on uniprocessors (Part 2) and then multiprocessors (Part 3), we describe an approach to modeling embedded applications represented as multithreaded applications executed on a multiprocessor platform running a number of, possibly different, RTOS.
Figure 10-1 below illustrates a possible SoC design flow in which the application, modeled as a set of tasks, is mapped onto a heterogeneous multiprocessor platform.
During the mapping, each task is assigned to an appropriate processor, and the scheduling policies of the RTOS are determined. By executing the application, properties of the system such as latency and resource utilization can be analyzed.
Validation of multiprocessor RTOS is typically done after implementation through an interactive process of experimentation on prototypes, measurement of performance, tuning of various parameters, and so on, until the performance meets the system requirements. In a more desirable development process, an extra step of modeling and simulation before (or during) implementation would shorten the time required for validation.
However, there is a lack of complete methodologies and tools that cover all the aspects pertaining to the modeling of modern heterogeneous systems in a satisfactory manner. Several approaches have been devised that tend to provide the designers with suitable modeling tools.
For example, one approach uses a methodology based on the principles of composition for modeling real-time systems, although the challenges implied by the modeling of real-time systems implemented on multiprocessor platforms are not mentioned.
Another approach is based on the functional description of multiprocessor real-time systems giving modeling capabilities and automatic generation of different system components, including the operating system.
However, the focus of both of these methods is at an abstraction level lower than the one we propose and uses a high-level performance model for multithreaded multiprocessor systems. It is based on modeling the layer of schedulers in an abstract manner, which resembles the aim of our approach.
Others have focused on providing RTOS modeling on top of existing system-level design languages (SLDLs), either for open languages such as SpecC and the RTOS library of SystemC 3.0 or for proprietary languages such as SOCOS of OCAPI and TAXYS. All these approaches offer functional models of the RTOS, allowing its emulation, on top of which functional models of software applications can be implemented.
In the early stages of design, even before a functional implementation exists, we can benefit from a methodology that can provide us with design strategy guidelines, in our specific case, helping us to select the right combination of scheduling, synchronization, and allocation algorithms for the RTOS running on multiprocessor platforms.
One methodology, based on abstract modeling, uses SpecC but it is limited to modeling preemptive schedulers for single-processor systems.
Our approach is based on an abstraction of the functionality of the system. We logically partition a multiprocessor system into its components and devise a simple model for each component that will simulate its functionality using a set of parameters. A framework to model abstract application software is them execited on a multiprocessor platform under the supervision of abstract RTOS.
The framework is based on SystemC, by the use of which we inherit all its properties, such as multiple abstraction levels, synchronous and asynchronous modeling facilities, predefined components, and progressive refinement of models.
The rest of the series is organized as follows. In this first part, we introduce the basic concepts and terminology of real-time systems, with special emphasis on scheduling as well as an overview of our abstract RTOS model.
In Part 2 in this series, there is a detailed description of the model based on the classical uniprocessor system. In Part 3 in this series , the uniprocessor model is extended to a more general multiprocessor model.
We will start the discussion in succeding pages with a presentation of the basic principles of scheduling, as well as, in particular, a model for the tasks to be scheduled and a model of the platform architecture on which to schedule those tasks.