0% found this document useful (0 votes)
58 views

Realtime Operating Systems For Embedded Computing

This document discusses real-time operating systems (RTOS) for embedded computing. It outlines trends driving new RTOS needs, including increasing device complexity, data-intensive applications with tight deadlines, and systems-on-chip. The document summarizes traditional RTOS research focusing on scheduling, and emerging directions like system-level synthesis and behavioral modeling. It concludes that RTOS will play a key role in isolating applications from hardware and enabling software reuse for advanced embedded systems.

Uploaded by

Rishabh Desai
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
58 views

Realtime Operating Systems For Embedded Computing

This document discusses real-time operating systems (RTOS) for embedded computing. It outlines trends driving new RTOS needs, including increasing device complexity, data-intensive applications with tight deadlines, and systems-on-chip. The document summarizes traditional RTOS research focusing on scheduling, and emerging directions like system-level synthesis and behavioral modeling. It concludes that RTOS will play a key role in isolating applications from hardware and enabling software reuse for advanced embedded systems.

Uploaded by

Rishabh Desai
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 5

Real-Time Operating Systems for

Embedded Computing
Yanbing Lit, Miodrag Potkonjakt, and Wayne Wolf?
?Department of Electrical Engineering, Princeton University
$Department of Computer Science, UCLA

Abstract conferencing, are intrinsically defined by a need for high

mentations. Convergence of applications, technology, and As a result of these trends, there is a growing consensus that

for new generation of RTOS. Th


thesis problem areas, notably ditional design productivity'. Software
and synthesis for systems-on- is a major element of reuse strategies and real-time

We conclude by outlining fut While this was a viable option for synthesis of low com-
RTOS. plexity application-specific systems, it does not address
needs of more complex emerging designs. Figure 1 illus-
1 Introduction trates the new system-level synthesis flow. RTOS provides
Recently, a convergence of applications, technology, and isolation and interface to application and algorithm devel-
market trends of embedded systems has resulted in drastic
quantitative and qualitative change in synthesis of applica-
tion-specific systems. The size of average embedded con-
sumer electronics applications has been approximately 5 4
doubling each year. At the same time the average size, in
terms of number of gates, of the integrated circuits has been
doubling every three years, while the clock period has been System
steadily decreasing at just slightly lower pace. For example, Design
the state of the art general-purpose processor in 1971 (Intel
4004) had 2,300 transistors and had clock rate 0.1 MHz.
Today the latest-generation processor, the Intel Pentium-11,
has 7.5 million transistors and a clock rate of 300 MHz '.
These trends imply that, in each new generation of technol-
ogy, higher levels of hardware sharing are required, feasi-
ble, and economically desirable. FIGURE 1 RTOS, the backbone of new system-level design
process
From the qualitative point of view, new application are
characterized by high volume of data, cost sensitivity, and
very short market windows. Many popular applications, opers and compilation tools from one side and to architec-
such as wireless telephony, internet browsing, and video- ture and integrate circuits designs from the other. Our goal

388
1063-6404/97 $10.00 0 1997 IEEE
in this paper is to analyze opportunities and challenges 2.2 Systems-on-Silicon
posed by the emerging field. RTOS have been used in many
applications from car, ship, and airplane electronics to wire- Integrated circuits with 20 millions or more transistors
less and optical communication equipment, medical instru- allow truly significant systems, such as HDTV, video cam-
mentations, multimedia, internet, and even home coder, and software radio, to be placed on a single chip.
appliances, factory automation, process control, financial Systems-on-silicon may contain multiple CPUs, special-
transaction processing, and video games machines. purpose function units, and large amounts of embedded
RAM.They find important uses in areas as diverse as wire-
Even without strict space limitations of a conference paper, less, multimedia, and mechanotronics.
it would be impossible to provide a comprehensive survey
of RTOS research and industrial state-of-the-art. Rather Systems-on-silicon demand more careful design because
than aim for comprehensiveness, we focus attention on a design revisions are both costly and time-consuming. They
selected subset of key issues and key new directions which also require very high-quality software for several reasons:
characterize well emerging filed of RTOS for SOS. the software will definitely be hard to observe and therefore
debug due to pin limitations; the software may be hard to
The reminder of the paper is organized as follows. We first change after fabrication; and the hardware cannot be easily
very briefly summarize operating system basics. After that changed to accommodate software performance problems.
we summarize the key results from the traditional RTOS
research and discuss RTOS development efforts from the Design of systems-on-silicon pose many qualitatively new
industrial point of view. Next, we present some of the first problems such as intellectual property protection, debug-
RTOS behavioral and system-level synthesis efforts. We ging using incomplete information about hardware and/or
conclude by outlining the directions for the merging field of software, and one which we address here, a need for
system-on-silicon, in particular from RTOS point of view. embedded operating system layer.

2 Preliminaries 3 lladitional RTOS Research


In this section we briefly outline the basic facts about real-
time operating systems and systems-on-silicon.

2.1 [Real Time] Operating Systems Basics


An operating system is a system program which provides
an interface between application programs (an often a user)
and the computer hardware. They have two primary func- FIGURE 2. A pair of tasks.
tions: to make the computer system convenient to use and to
organize efficient and correct use of the computer A real-time operating system can supply many valuable
resources. There are four main tasks of an operating sys- functions to an embedded application, but the central pur-
tem: process management, interprocess communication pose of an RTOS is scheduling of the CPU. The application
and synchronization, memory management, and input/ is structured as a set of processes, each of which has its
output (YO) management. The process management com- own program code and state consisting of register and
ponent is responsible for process creation, process loading memory values. The process is as well-known and almost
and execution control, the interaction of the process with universal model. Some operating systems support an addi-
signal events, process monitoring, CPU allocation and pro- tional level of structure known as the task.A task is a set of
cess termination. Interprocess communication covers issues processes with data dependencies between them, as shown
such as synchronization and coordination, deadlock and in Figure 2. This example contains two tasks-processes
livelock detection and handling, process protection, and which have no path of data dependencies between them are
data exchange mechanisms. Memory management includes in separate tasks. A process or task may be executed peri-
services for file creation, deletion, reposition, and protec- odically or aperiodically.
tion. I/O management handles request and release subrou-
tines for a variety of peripherals and read, write, and Processes and tasks generally have some sort of temporal
reposition programs. constraints on their behavior. The exact nature of these con-
straints depends on the scheduling model, but several types
Real-time systems are systems where the proper functional- of temporal measurements of process/task performance are
ity assumes both the correctness of the output as well as the used. A deadline is the time at which a process must finish
correct timing behavior of the system.

389
execution after being initia system meets all its deadlines under all conditions.
process or task is the interva
executions.
3.1 Recent Directions
The RTOS considers a process to be in one of three states:
waiting, ready, and executing. In a uniprocessor system, Recently, there has been a number of new RTOS- and
only one process can be executing at any time. Some pro- embedded system-related research results which open new
cesses may be for data or other events. Processes rand important development directions. We mention only a
which are not for external events but are not cur- subset of them: profile-based load balancing14, lottery
rently executing are considered ready. The transfe schedulingI8, dynamic code generationlg, embedding of
from one process to another is called a security and authentication mechanisms", jitter hiding2',
, To execute a context switch
~erification'~,
and CQRBA-related efforts16.
the state of the old process, determine Bestvarsos14 demonstrated significant advantages of using
tain the CPU, and then set the CPU s the profile-based balancing over traditional balancing tech-
tate. Context switch overhead niques for optimization of distributed soft real-time sys-
not a major factor in performance; sc tems. Set of promising scheduling technique which address
artitioning, memory performance a number of important issues has been also developed by
are often more critical to obtaining good performance. utilizing randomization18. There has bee
Stankovic et al. provide a g urvey of real-time schedul- ensure satisfaction of real-time constraint
ere are several types of scheduling poli- ented CORBA, an important first step in
real-time large software systems.

A cooperative scheduler r on the current process to Inferno, the real-time version of the Plan 9 operating sys-
give up the CPU before tem from AT&T Bell Labs, is the first RTOS which pro-
another process. Cooper vides a number of cryptographic, authentication, and
as digital filters with protection mechanism17. The first techniques for jitter hid-
t used in sophisticated ing show significant advanta es in handling relative small
embedded systems. variation in throughput rate2! Finally, a number of recent
studies shows that a great advantages in throughput,
A static priority-driven scheduler can preempt the latency, and memory requirements can be achieved by
current process to start a new process. The highest-pri- applying the dynamic code generation techniques".
ority ready process is always the currently executing
process. Priorities are set before the system begins exe- 4 Commercial RTOS Offerings
cution.
Leading estimates that a few tens of millions copies of
A dynamic priority-driven scheduler can redefine the have been installed. Some of large RTOS industrial
process priorities at run time. The highest-priority ready s include Integrated Systems (pSOS Systems), Wind
ntly-executing process, but since River Systems (VxWorks), Microtec Research (VRTX),
the RTOS can redefine priorities, the scheduling policy Microware Systems (OS-9), Spectron Microsystems
is embodied in the dynamic choice of priorities. (SPOX), QNX (QNX software), Hewlett-Packard (HP-RT),
best-known static priority-driven scheduling methodol- stems (LynxOS). Among the most
is rate-monotonic scheduling (RMS)3. Liu and Lay- notable recent entries include Lucent (Inferno) and Eonic
land showed that the optimal scheduling policy for one Systems (Virtouso RTOS). Recently Microsoft entered the
of real-time systems is to assig market with their Windows-CE embedded operating sys-
r of deadline-the shortest-dead tems. While Windows-CE does not directly address
cess receives the highest priority. requirements for re me constraints, at least one company
already announce its real-time version.
A well-known dynamic prior
deadline-first (EDF). This While traditional academic RTOS research is dominated by
time left until each pr scheduling efforts, the industrial efforts have been mainly
cess facing the nearest de focused on optimization for three design me
priority. EDF results in higher requirements and two performance metrics: context switch
ble with RMS, but since pri time and interrupt latency. Table 1 shows area requirements
during execution, it is more difficult to prove that an EDF and delay for 3 different cache configuration and five differ-

390
ent cache sizes obtained using the Flynn's cache modeling omputers,and,Internet/Operating-S ystemsmealtime

OrganleetionProperty 1KB 2KB 8KB 96KB 5 RTOS and [Computer Aided] Design
Direct Area (mm') 2.107036 3.807370 13.962853 161.704666 Research and Development
Mapped Latency (B) 3.79491 3.97239 4.50642 6.78866 In this section, we survey the recent RTOS-related CAD
Sway Area (mm') 2.385426 4.021449 13.799528 156.061787 efforts. The results are mainly due to an impetus provided
Latency (p) 5.67454 5.74781 6.22891 8.53658 by two new important trends: hardwarehoftware co-design
4-way Area (nun') 3.042479 4.645923 14.245449 154.000343 and synthesis techniques for systems-on-silicon.
Latency (p) 6.04178 6.23715 6.57738 8.83248
Recent interest in hardwarehoftware CO-design'has opened
up new avenues in RTOS research. The ability to simulta-
neously design the hardware platform and software allows
for new trade-offs and poses new challenges in system
architecture. The move toward systems-on-silicon, moti-
vated by the ability to put one or more sophisticated CPUs
Clock Technolog Area Power dish and embedded RAM on a single chip, will make RTOSs
- -- -266-0.35 - 4.3
Microproeearorcore (MHz) MIPS y (p) (mm')
StrongARM 233
(mW)(Volt.)
300(1.65)
increasingly important over the next several years. Good
design and use of an RTOS can help increase the efficiency
with which scarce hardware resources are used, while a bad
RTOS can kill performance and reliability. And because
LSI Logic, TR4101 0.35 81 (3.3) systems-on-silicon are much harder and significantly more
expensive to fix than printed circuit boards, performance
280 (3.3)
and reliability are at a premium.
DSPGroup,Oak 80 80 0.6 8.4 190(5) The RTOS CAD efforts can be classified in four groups:
NEC, R4100 40 40 0.35 5.4 lZO(3.3) behavioral synthesis results, system-level synthesis results,
Toshiba,R3900 50 50 0.6 15 400(3.3) design studies, and theoretical and simulation efforts.
Motorola,68000 33 16 0.5 4.4 35 (3.3) Potkonjak and Wolf addressed synthesis of a system of
PowerPC, 403 33 41 0.5 7.5 40(3.3) multifunctional ASICs where individual tasks are under
hard real-time constraints21. They also introduced a heuris-
tic approach for the design and optimization of ASIC
implementations which realize multiple computational
tasks under hard real-time constraints on a single multi-
functional ASIC22. Kim et al. 2o developed a set of tech-
niques to minimize context switching time using the
behavioral synthesis techniques.
System-level techniques can be grouped into two catego-
ries: uniprocessor and multiprocessor. One major trend in
next-generation embedded systems is multiprocessors
which may contain devices and special-purpose accelera-
tors as well as a CPU; although these devices may not be
programmable, they still allow parallel execution that must
be taken into account by the RTOS. Furthermore, many
embedded systems include several CPUs, often of different
types. Coordination between the processing elements in the
system is essential for both performance and correctness.
While there have been a high interest in the multiprocessor
real-time system-level synthesis, only a few efforts have
been dedicated. Lee et al.'developed a synthesis algorithm
which generates an application-based real-time multipro-
cessor. The algorithm uses a three-step synthesis methodol-
ogy of resource allocation, assignment, and scheduling. Li

391
and Wolf2 developed a hierarchical algorithm for schedul- work to compilerRTOS based design m
ing and allocating processes on a multiprocessor. The syn- e interaction between RTOS and s
of the task structure to systems-on-silicon as well as between
asks to meet deadlines. embedded real-life applications will be
the key issues in synthesis of systems using cores.
Technology, pricing and applications trends,
ation goal is to sat-
emerging integration of DRAMS and processor logic and
popularity of large data volu
likely alleviate the industrial e
mization. On other hand, it is re
executed on core-based sys
switching time, and in partic
important design metrics.
The increasing complexity of both hardware an
will accentuate a strong need for both software
ware debugging. benchmarking will receive signifi-
cantly hgher att Flexibility and scalability will be
ing algorithms, include the inclusion of rate-monotonic
important. Applications trends indicate that both security,
g as the scheduling p the IEEE POSIX
privacy, authentication, and intellectual property protection
operating system stan IEEE Futurebus+
mechanisms as well as rich I/O features for interaction with
6,27,29,and the use o
ators, and humans, will gain importance. Soft
c scheduling techniques in
tems will also gain popularity.
nology projects such as Space Station Program and the
European Space Agency on-board operating system3'. The for adopting a new computational and
f several research and development will form sound the0
. New technical i
dynamic code generation and profile-based resource bal-

have a dominant share of the market.

nclusions
Real-time operating systems have long been critical compo-

systems-on-silicon, RTOS
thesis approach or conduct any synthesis optimization.
Atlenbernd32 generalized deadline monotonic scheduling
, but
. Bal real-time operating systems. We
automaticaIly control1

Acknowledgments

said, it is difficult to predict, i the OKAWA Foundation.


less, it seems that some trends
There is a pending change of behavioral and system level
from the algorithm to architecture frame-

392

You might also like