T ENDENCIAS Y T ECNOLOGÍAS

As an execution environment, this work adopted an abstract Real-Time Op-erating System (RTOS) simulation framework described in [ZMG09]. The simulator is implemented using SystemC, which is a C++ based system level design language. SystemC [Ass] was initiated by the Open SystemC Initia-tive (OSCI) consortium (now merged with Accellera [Ini]) and later approved as an IEEE standard. Technically, SystemC is implemented as a C++ library providing an event-driven simulation semantic. The primary usage of the SystemC language is for system-level modeling and simulation.

The basic idea of abstract RTOS simulation is to utilize the advantage of SystemC to omit unnecessary information and only concentrates on real-time scheduling aspects. More specifically, the abstraction is mainly made in two aspects:

• The actual task execution on a target processor is abstracted to the sim-ulation of required execution time.

• The details of RTOS behavior, such as task management, memory man-agement and resource manman-agement, are abstracted to a real-time sched-uler, which dispatches real-time tasks at the proper time.

The key benefit of this abstraction enables early evaluation of scheduling behavior, i.e., the impacts and effects of different retime scheduling al-gorithms can be investigated without knowing a concrete target processor architecture and RTOS in advance. This feature perfectly matches the needs of the evaluation process in the context of this dissertation, because the pro-posed approaches are independent of concrete target platforms. As inputs, the abstract RTOS simulator accepts a set of software tasks with specified real-time properties including deadlines, periods and task WCETs. The well-established real-time scheduling strategies like EDF and RM are already im-plemented in the simulation framework and can be simply selected through a configuration file. As outputs, the simulator produces, on one side, a human readable log file and on the other side a Value Change Dump (VCD) [Bey]

file of signal traces. The VCD file can be shown graphically using popular tools like GTKWave [GTK].

Unfortunately, the original abstract RTOS simulator lacks the ability of power aware simulation, i.e., DPM and DVS are not available. Therefore, some extensions and modifications are made in the implementation. In short, two C++ classes are essentially declared for processors and devices, respectively.

For each concrete processor or device, an object of the corresponding class with proper power characteristics is created at run-time. In fact, the objects represent the power model of processors and devices. As shown in Chapter 3, the power model is defined in form of a finite state machine, based on which the behavior part of the objects is implemented. For instance, there is a state variable inside the processor class always indicating the current running frequency. This variable can be changed by a power aware real-time scheduler and the respective task WCETs need to be scaled up or down accordingly. In case of the device class, there is a variable representing the current DPM state. Moreover, as this dissertation deals with non-negligible state switching overhead, they are implemented as a delay of simulation time.

In order to make the evaluation more realistic, the power model of processors and devices are not arbitrarily generated, but rather taken from either data

State F P(mW) T_{on→o f f} T_{o f f→on} P_{on→o f f}⁴ P_{o f f→on}⁴

Table 8.1: The power model of the Intel XScale^®processor [Inte]

State F P(mW) T_{on→o f f} T_{o f f→on} P_{on→o f f}⁴ P_{o f f→on}⁴ Table 8.2: The power model of ARM Cortex^™-A8 [OMA][Insa]

sheets or other related studies. The processors used in the test are the Intel XScale^® processor and the ARM Cortex^™-A8 processor. The power model of the former, which is shown in Table 8.1, is taken from [Inte]. The power model of the latter, which is shown in Table 8.2, is taken from [OMA] and [Insa]. In fact, this model is the one used in OMAP3530 [Insb] from Texas Instruments. More concretely, [Insa] provides a spreadsheet, which is able to estimate chip power consumption in different DVS and DPM states. Note that the OMAP3530 chip contains more than one power domain and the most interesting part is the MPU power domain, which mainly contains the ARM core. Furthermore, the state switching latency is obtained from [OMA].

In order to build a cluster-based multi-core processor, the power model of the two aforementioned processors are adopted and simply multiplied. In other words, each processor core either has the power model of the Intel XScale^® processor or the power model of the ARM Cortex^™-A8 processor.

Formally, they are referred to as I-core and A-core, respectively. Note that the processor cores inside a cluster must share the same power model. To simplify the evaluation, this work concentrates on the symmetry architecture,

4This value is not given in the data sheet, therefore it is arbitrarily chosen between the power consumption of the active state and the low power state.

5The operating frequency without normalization is 624 MHz.

6not applicable.

7The operating frequency without normalization is 600 MHz.

Device P(D₀) P(D₁) T_{on→o f f}/T_{o f f→on} P_{on→o f f}/P_{o f f→on}

MSWM 750 mW 5 mW 40 ms 100 mW

IBMM 1300 mW 100 mW 12 ms 500 mW

SSTF 125 mW 1 mW 1 ms 50 mW

STFC 225 mW 20 mW 2 ms 100 mW

REC 190 mW 85 mW 10 ms 125 mW

FHD 2300 mW 1000 mW 20 ms 1500 mW

Table 8.3: The power model of applied I/O devices [CG06]

i.e., each cluster contains the same number of processor cores and the number of clusters is power of two. However, it is worth mentioning that the proposed approaches are not only constraint to the symmetry architecture.

A quad-core processor with two clusters may be built by using two I-cores in the first cluster and two A-cores in the second cluster. This multi-core processor is denoted by I2A2. In general, the letters indicate the type of processor cores in the cluster and the digits give the size of the cluster. To further simplify the notation, same clusters are merged and its number is denoted by index. For instance, (I1)⁴ denotes a platform with 4 cores in total that are grouped into 4 clusters, i.e., a per-core platform and all the cores are I-cores. In this evaluation work, the investigated variants are shown below.

• Processor with 2 cores: (I1)²and I2

• Processor with 4 cores: (I1)⁴, (I2)², I2A2 and I4

Since this dissertation addresses system-wide power consumption, where I/O peripherals are taken into consideration, the following devices are applied in the evaluation scenario.

• MaxStream Wireless Module (MSWM)

• Realtek Ethernet Chip (REC)

• IBM Microdrive (IBMM)

• SST Flash SST39LF020 (SSTF)

• SimpleTech Flash Card (STFC)

• Fujitsu 2300AT Hard Disk (FHD)

Their power models are taken from [CG06] and shown in Table 8.3.

Platforms Number of tests Size Utilization With 2 cores 1600 [5, 12] [0.4, 1.6]

With 4 cores 1600 [7, 14] [0.8, 3.2]

Table 8.4: Properties of generated task sets for multi-core processor plat-forms