Transcript What is Real-Time System? - VLSI Systems Lab

IDEC KAIST, March 28, 2003
Misconceptions and Challenges
on Embedded Software:
From Hardware Engineers’
Perspectives
홍성수
서울대학교
전기컴퓨터공학부
실시간 운영체제 연구실
IDEC KAIST, March 28, 2003
話頭
2
IDEC KAIST, March 28, 2003
Future Deep Submicron Technology
Prof. Hugo de Man predicts
200 million transistors on a chip by 2005
SoC Design faces new challenges due to DST
Complexity really matters
Isolated design technology does not work out well
• Hardware design knowledge
• Software design knowledge
• Application (domain) specific knowledge
– Communication, automotive, etc.
3
IDEC KAIST, March 28, 2003
System Design Guru
System design guru is a design engineer who
understands and deals with system complexity and
possesses skills and knowledge in electrical
engineering, computer science, and communication
Extremely difficult to raise system design guru
The need is grossly underestimated
Current educational organizations are not suitable
• EE dept., CS dept, etc.
Current curricula are not suitable
• Toy class projects are not complex enough
Lack of industry and academia collaboration for education
4
IDEC KAIST, March 28, 2003
You, EE Engineer Must Learn CS
In 2005 and beyond, only system design guru can
make significant contributions to SoC design
From my eight years of experience as CS faculty
member in EE department, I know
There are differences between EE and CS disciplines
Engineers are educated differently in EE and CS dept.
Most EE engineers fail to be decent CS engineers since they
do not know of such differences
5
IDEC KAIST, March 28, 2003
EE Engineers’ Misconceptions
about (Embedded) Software
6
IDEC KAIST, March 28, 2003
General Misconceptions
Software writing is art, not science
Due to ignorance
Software terminology is too abstract – I don’t know
what the heck this guy is talking about
Software bus, event channel, semaphore, etc.
There are very few systematic design methodologies
for software writing
Even if there are some, I believe my way of writing code is
much better than them since I learned it hard way - through
painful experience over numerous sleepless nights
7
IDEC KAIST, March 28, 2003
Specific Misconceptions (1)
There is no science in embedded systems design
Advances in microprocessor technology will take care
of all timing issues in embedded systems design
Real-time computing is equivalent to fast computing
Embedded programming is assembly programming,
priority tuning, and device driver writing
Real-time systems research is performance
engineering
RTOS is used in embedded systems since it makes a
more efficient run-time than the one w/o RTOS
8
IDEC KAIST, March 28, 2003
Specific Misconceptions (2)
In embedded systems development, performance is
always the No. 1 issue except cost
9
IDEC KAIST, March 28, 2003
How to Deal with Software
Design Complexity
10
IDEC KAIST, March 28, 2003
Sources of the Crisis (1)
(1) Diverse hardware platforms and components
Microprocessors and microcontrollers
• Instruction set architectures
– ARM, PowerPC, x86, MIPS, SH5
• Word lengths
– 8, 16, 32, and 64 bits
Digital signal processors
• Lucent, TI, and custom in-house DSPs
Application specific IC
• Hardware components implemented in ASICs and FPGAs
Media processors
11
IDEC KAIST, March 28, 2003
Sources of the Crisis (2)
MEMORY
MEMORY
CPU
VIDEO
Decoder
IEEE1394
HDTV
Channel
EQ.
HDTV
Channel
Decoder
Decoder
MPEG2 FORMAT
TS
Converter
EQ.
AUDIO
Decoder
VIDEO
Decoder
CPU
FORMAT
Converter
Dolby
AC3
TS
OSGM
OSGM
12
IDEC KAIST, March 28, 2003
Sources of the Crisis (3)
Solid-state file systems.
• Flash, battery-backed CMOS RAMs
Custom I/O devices
• Image sensors, LCDs, key pads.
13
IDEC KAIST, March 28, 2003
Sources of the Crisis (4)
(2) Heterogeneous network standards
Digital audio/video networks
• USB, IEEE 1394
Data networks
• HomePNA, IEEE 802.3, Powerline
Control networks
• RS 485, X-10, CE Bus, LonWorks
Mobile networks
• HomeRF, IEEE 802.11, Bluetooth
14
IDEC KAIST, March 28, 2003
Sources of the Crisis (5)
Public networks
PSTN, Internet
Network
camera
HomePNA
Phone Line Network
Power Line
Network
Home Net Hub
Web
phone
Printer
IEEE 1394
Entertainment
Center
Camera
Scanner
15
IDEC KAIST, March 28, 2003
Sources of the Crisis (6)
(3) Diversified services
Interactive digital broadcasting
• E-commerce, browsing, emailing, unified messaging
Home networking
• ISP sharing routers, cable modems, xDSL modems
Home automation
• Embedded networking, remote monitoring
Multimedia services
• Video on demand services, web caching, streaming
16
IDEC KAIST, March 28, 2003
Sources of the Crisis (7)
Broadcasting
PC applications
• Utilities
• Games
Interactive
advertisement
On-line shopping
Stock quotes, weather,
traffic, news, sports
Enhanced EPG
And many more
VoD
Home
Banking
Home
Shopping
Virtual
Games
Internet
Multimedia browsing
Emailing
Surfing
And many more
17
IDEC KAIST, March 28, 2003
Software is the Key (1)
Software complexity increases in an exponential
manner as hardware complexity increases.
Code size in embedded systems drastically increases.
Extremely difficult to locate and fix bugs during the
development of embedded systems.
Software becomes the determining factor of
Time-to-market
Product quality
Product features
Product performance
18
IDEC KAIST, March 28, 2003
Software is the Key (2)
Embedded systems often require
Time-critical services.
• Both real-time and time-sharing applications co-exist.
Network transparent, or network-aware at the least,
computing.
However, component-based software market has not
been matured, yet.
Roll it yourself – Decomposition and Abstraction
Real-time operating systems
Embedded middleware
19
IDEC KAIST, March 28, 2003
Decomposition
Solve a problem in “divide-and-conquer” way
RTOS supports decomposition through multi-tasking
20
IDEC KAIST, March 28, 2003
Abstraction (1)
Hides complicated details behind abstraction
interfaces and only shows the minimum amount of
information
Results in layered structures
Yields performance slow down
21
IDEC KAIST, March 28, 2003
Abstraction (2)
User Programs
User level
User Programs
Libraries
Kernel level
System Call Interface
File System Management
Task
Management
Buffer Cache
IPC
Context
Device Drivers
Memory Management
Hardware Control (Interrupts handling, etc)
HW level
Hardware
(Source : The design of the UNIX OS)
22
IDEC KAIST, March 28, 2003
Abstraction (3)
User’s View
Kernel’s View
Device Driver
file name + byte offset
ino + logical block #
physical block #
file
byte
….
fp
file
block
…
file system
drive #
cylinder #
head #
sector #
drive
physical
block
…
block #
Device
.
.
.
23
IDEC KAIST, March 28, 2003
RTOS as an Example
24
IDEC KAIST, March 28, 2003
Motivations for RTOS
Abstracting complex hardware idiosyncrasies
Run-time predictability (real-time guarantee)
Multi-tasking
25
IDEC KAIST, March 28, 2003
Motivations for RTOS
With RTOS
#include <stdio.h>
void main()
{
printf(“Hello, World\n”);
}
Operating System
Without RTOS
Programmers should
write everything.
Video card
initialization
Memory
management
Video card
operation
26
IDEC KAIST, March 28, 2003
Multi-Tasking (1)
What is a task?
A piece of code that can run independently of others.
Has a collection of states (run-time context) in memory so
that it can stop and resume its execution.
Usually denotes an independently executable component of
an application.
What is multi-tasking?
The process of scheduling and switching CPU between
several tasks.
Increases the concurrency of an application.
Helps increase the CPU utilization.
27
IDEC KAIST, March 28, 2003
Multi-Tasking (2)
Different types of multi-tasking
Non-preemptive scheduling
Preemptive scheduling
Embedded system design process involves splitting
the work to be done into tasks which are responsible
for a portion of the problem.
28
IDEC KAIST, March 28, 2003
Example: Data Acquisition System
Wait for
I/O Event
AD converter
Enter event
to DB
Display
data
Search
DB
Wait for
command
DB
29
IDEC KAIST, March 28, 2003
Requirement Specification (1)
16-bit digital input signal level의 변화를 검출하고,
RAM-resident database에 event로 시간과 함께 기록
한다.
이 입력은 Digital Interface로 명명한다.
9600-baud의 두 serial port를 통해서 두 interactive
operator console을 서비스 한다.
이 입력은 Serial Interface로 명명한다.
30
IDEC KAIST, March 28, 2003
Requirement Specification (2)
두 serial port에 물려있는 console에 시간을 display
하며 매초 마다 시간을 갱신한다.
두 serial port에 물려있는 console을 통해 RAMresident database에 대한 검색 요구가 입력되면 이를
처리한다.
31
IDEC KAIST, March 28, 2003
Requirement Specification (3)
16-bit external sensor의 입력은 16-bit register로 표현
된다.
Polled mode (매 1.3ms 마다 입력)
Interrupt-driven mode (ISR이 1.3ms 이내에 수행 종료)
매초 마다 1회씩 console의 시간을 update하며,
database의 내용을 검색할 수 있게 한다.
Polled mode
Interrupt-driven mode (1ms 한번 interrupt 발생)
32
IDEC KAIST, March 28, 2003
Three Design Architectures
Three different ways to construct a real-time system
Design by infinite polling
• Infinite polling loop without interrupts
• Infinite polling loop with interrupts
Design by task decomposition
• Multi-Tasking
33
IDEC KAIST, March 28, 2003
(1) Infinite Polling Loop w/o Interrupts
(1)
A single main loop services all I/O sequentially.
1. Check all I/O to detect incoming events.
2. Execute functions in response to the arrived events.
Good for
•
•
Regularly (predictably) varying inputs.
(ex) 9600-baud serial ports.
Bad for
•
•
•
Irregularly varying inputs possibly requiring fast responses.
Systems with a large number of inputs.
(ex) Alarm signals, asynchronous inputs from a keyboard.
34
IDEC KAIST, March 28, 2003
(1) Infinite Polling Loop w/o Interrupts
(2)
Example code structures
Main ( )
{
for (;;) ｛
check_inputs( );
check_digital_interfaces( );
application( );
｝
｝
〈Existing code〉
Main ( )
{
i=0;
for (;;)｛
check_inputs( ) ;
check_digital_interfaces( ) ;
switch (i) ｛
case 0 : application0( ); break;
case 1 : application1( ); break;
case 2 : application2( ); break;
case 3 : i = 0; break;
}
i++;
｝
｝
〈Split code〉
35
IDEC KAIST, March 28, 2003
(1) Infinite Polling Loop w/o Interrupts
(3)
Problems of infinite polling loops with code splitting.
Render real-time software extremely difficult to understand.
Waste CPU cycles for polled mode I/O processing.
Require correctness check of the algorithm and timing after
code is split.
Require repetitive code splitting and timing/functional checks
whenever code is modified.
36
IDEC KAIST, March 28, 2003
(2) Infinite Polling Loop with Interrupts
(1)
A single main loop services all I/O sequentially, but
critical I/O processing is separated from the loop.
Problems
•
•
If event processing is excessive, it possesses the same
problem as infinite polling loop w/o interrupts.
Processing of some events may be unnecessarily delayed.
–
Functions in the main loop are invoked in a predefined order,
which may not accord with the actual event occurrences.
37
IDEC KAIST, March 28, 2003
(2) Infinite Polling Loop with Interrupts
(2)
Example code structures
main ( )
{
for (;;) ｛
service_operator( );
update_time_on_display( );
handle_queued_events( );
｝
}
ISR that gets called each time
a char arrives at serial port.
ISR that gets called each time
a transition is defected on one
of parallel interfaces.
serial_ISR( )
{
read_char_from_port( );
put_char_into_buf( );
if (complete_line) ｛
send_buf_to_appl ( );
get_new_buf( );
}
}
digital_ISR( )
{
event = read_digital_interface( );
time = read_system_clock( );
enqueue_event(event, time);
}
38
IDEC KAIST, March 28, 2003
(3) Multi-Tasking (1)
What is a task?
A unit of execution, resource allocation, and scheduling.
Has a collection of states (run-time context) in memory so
that it can stop and resume its execution.
Often implemented as an infinite loop in a real-time
application.
May have a priority.
Run-time context of a task:
Task Code, Data Segment, Stack, CPU Registers,...
39
IDEC KAIST, March 28, 2003
(3) Multi-Tasking (2)
Multi-tasking in a data acquisition system:
Wait for
I/O Event
AD converter
Enter event
to DB
Display
data
Search
DB
Wait for
command
DB
40
IDEC KAIST, March 28, 2003
(3) Multi-Tasking (3)
Example task code
service_operator( )
{
for(;;) ｛
wait_for_cmd( ) ;
search_database( );
｝
｝
handle_queues_events( )
{
for(;;) ｛
wait_for_event( );
enter_event_in_database( );
｝
｝
update_time_on_display( )
{
for(;;) ｛
wait_one_second( );
display_time_1( );
｝
｝
41
IDEC KAIST, March 28, 2003
Introduction to
Real-Time Systems
42
IDEC KAIST, March 28, 2003
What is Real-Time System?
Definitions
A system where its correctness depends not only on the
correctness of the logical result of the system but also on the
result delivery time.
A system where the programs for the processing of data
arriving from the outside are always ready, so that their
results will be available within predetermined period of time.
The arrival times of the data may be randomly distributed or
may already be determined depending on the difference
applications.
A real-time system responds in a (timely) predictable way to
unpredictable external stimuli arrivals.
A system which possesses timing constraints.
43
IDEC KAIST, March 28, 2003
Forms of Timing Constraints (1)
Periodic constraints
External stimuli occur repeatedly in a certain interval.
Sampling period in a digital controller
30 frames/sec in a MPEG player
Aperiodic constraints
External stimuli arrive in a randomly distributed manner.
Response time of an emergency signal, system fault, etc.
44
IDEC KAIST, March 28, 2003
Forms of Timing Constraints (2)
Details of periodic constraints
release time
deadline
period
period
timer service
45
IDEC KAIST, March 28, 2003
Scale of Timing Constraints
100 ms
Cycle Time
(Period)
20 ms
10 ms
5 ms
90%
Products
1 ms
500 µs
0
100
1,000
5,000
10,000
Cycle Variation
(Jitter) in µs
46
IDEC KAIST, March 28, 2003
Classification of Real-Time Systems
Hard real-time system
Missing a deadline has catastrophic results for the system.
Firm real-time system
Missing a deadline entails an unacceptable quality reduction
as a consequence.
Soft real-time system
Deadlines may be missed and can be recovered. The
reduction in system quality is acceptable.
Non-real-time system
No deadline has to be met.
47
IDEC KAIST, March 28, 2003
Real-Time System Support
Hard real-time performance in an embedded system
is achieved through the integrated design of three
key areas:
Hardware capable of supporting real-time
A real-time operating system sits on top of the hardware
A real-time application
All three are required to offer real-time performance.
48
IDEC KAIST, March 28, 2003
I. Predictable Reaction in
Real-Time Operating Systems
49
IDEC KAIST, March 28, 2003
What’s Happening inside
Residential Gateway?
Residential
Gateway
Gas Detector
alarm signal
Response time really matters!
50
IDEC KAIST, March 28, 2003
Actions Happening inside the Gateway
Stop execution of current task
Dispatch interrupt
Execute ISR
Pick handler task
Switch context
Return from interrupt
Run the task
Interrupt (Alarm)
Response
51
IDEC KAIST, March 28, 2003
Sources of Latency
ISR
scheduling
ctx
Task
iret
Task
interrupt
latency
Task
scheduling
latency
response time
interrupt
52
IDEC KAIST, March 28, 2003
Features of
Real-Time Operating Systems
for Predictable Responses
53
IDEC KAIST, March 28, 2003
Essential Features
In a practical sense, a real-time operating system is
(Fully) preemptive,
Priority-based operating system, with
Bounded interrupt latency (interrupt off time)
Bounded scheduling latency
54
IDEC KAIST, March 28, 2003
1. Preemptive CPU Scheduling
Preemptive vs non-preemptive scheduling
ISR
scheduling
ctx
iret
Task
Task
Task
preemptive response time
interrupt
ISR
scheduling
iret
Task
Task
Task
Non-preemptive response time
interrupt
55
IDEC KAIST, March 28, 2003
2. Priority-based Scheduling
Priorities are an effective means to denote criticality.
IEEE POSIX style priority system
256 priority levels
Round-robin or FIFO in the same priority level
56
IDEC KAIST, March 28, 2003
3. Bounded Interrupt Latency
Interrupt latency:
Time from interrupt occurrence to the execution of the first
instruction of user ISR
Depends on interrupt off time and kernel’s interrupt
dispatching mechanism
ISR
scheduling
ctx
Task
iret
Task
interrupt
latency
Task
scheduling
latency
response time
interrupt
57
IDEC KAIST, March 28, 2003
4. Bounded Scheduling Latency (1)
Scheduling latency:
Time from the end of ISR to the execution of the first
instruction in the task
Depends on kernel scheduler implementation
ISR
scheduling
ctx
Task
iret
Task
interrupt
latency
Task
scheduling
latency
response time
interrupt
58
IDEC KAIST, March 28, 2003
4. Bounded Scheduling Latency (2)
Unsorted task list vs bitmap task queue
3-level bitmap table
thread_ready_q[256]
(highest) 255
254
TCB
253
…
FIFO or RR
at the same priority level
1
(lowest)
0
idle task (reserved)
59
IDEC KAIST, March 28, 2003
II. Jitter Control in
Real-Time Operating Systems
60
IDEC KAIST, March 28, 2003
What is Jitter?
Variation in cycle time
cycle time
period
timer service
Harmful effect on real-time systems
Deteriorate control performance, output quality, and
perception.
61
IDEC KAIST, March 28, 2003
Sources of Jitter (1)
Scheduling interference
Preemption by higher priority tasks
Higher priority task
cycle time
period
timer service
62
IDEC KAIST, March 28, 2003
Sources of Jitter (2)
Execution time variation
clock ISR
cycle time
clock interval
timer service
63
IDEC KAIST, March 28, 2003
Sources of Jitter (3)
Inadequate API
periodic_thread(void* data) {
time_t t1, t2;
while(1) {
time(&t1);
/* do something */
time(&t2);
if((t2 -t1)>deadline){
/* handle deadline miss */
}
sleep(period-(t2-t1));
}
}
Overhead
Late handling of
Deadline miss
64
IDEC KAIST, March 28, 2003
Sources of Jitter (4)
Sleep( ) system call
Bounds minimum duration of sleeping
Unable to bound maximum duration of sleeping
cycle time
period = sleep(period – (t2-t1))
65
IDEC KAIST, March 28, 2003
Features of
Real-Time Operating Systems
for Jitter Control
66
IDEC KAIST, March 28, 2003
Strict Timer Management
Timer service enforces task periods.
cycle time
period
timer service
67
IDEC KAIST, March 28, 2003
Real-Time API
The Velos way
int rthread_set_period(thread_t t, unsigned int period);
int rthread_set_deadline(thread_t t, unsigned int deadline);
int rthread_set_releasetime(thread_t t, unsigned int release_time);
int rthread_get_period(thread_t t, unsigned int *period);
int rthread_get_deadline(thread_t t, unsigned int *deadline);
int rthread_get_releasetime(thread_t t, unsigned int *release_time);
68
IDEC KAIST, March 28, 2003
RT API: Periodic Thread Functions
int rthread_create(thread_t *thread_id,
const pthread_attr_t *attr,
void * (*start_func)(void *pd), void *args,
int period, const struct deadline_param *dparam,
int release_time)
struct rdeadline_param {
int
deadline;
pthread_attr dattr; /* dhandler thread attribute */
void* (*dhandler)(void *pd);
void* args; /* argument for dhandler */
};
int rthread_wait_next_period(period_info_t *time_info);
typedef struct period_info {
int request_point;
int sched_delay;
int response_time;
int miss;
} period_info_t;
• barrier
int rthread_barrier_init(barrier_t *br);
unsigned int rthread_barrier_wait(barrier_t *br
, unsigned int phase);
unsigned int rthread_barrier_release(barrier_t *br);
69
IDEC KAIST, March 28, 2003
Deadline Handler
main thread
Periodic
thread
Deadline
Handler thread
while(1) {
/* do something */
rthread_wait_next_period(&pinfo);
}
dhandler1(void *data,thread_t owner)
/* handle deadline miss */
70
IDEC KAIST, March 28, 2003
Example
#include <stdio.h> #include <pthread.h>
#define WORKER_PERIOD 1000
void Worker(int *idp){ int i, j, x, k; period_info_t time_info;
rthread_barrier_wait(&br,0);
while(1) {
…
rthread_wait_next_period(&time_info);
}
pthread_exit(0);
}
void main(){ int i;
pthread_t threads[3];
pthread_attr_t thread_attrs[3];
int worker_ids[3] = {0,1,2};
for( i = 0 ; i < 3 ; i++ ){
rthread_create(&threads[i],&thread_attrs[i],(void *) Worker,
&worker_ids[i], NULL, WORKER_PERIOD, NULL);
}
rthread_barrier_release(&br);
pthread_exit(0);
}
71
IDEC KAIST, March 28, 2003
III. Avoiding Priority Inversion in
Real-Time Operating Systems
72
IDEC KAIST, March 28, 2003
What is Priority Inversion?
Priority inversion
Execution of a higher priority task is blocked by a lower
priority tasks for a bounded or unbounded amount of time.
Types of priority inversion
1. Thru hardware interrupts
2. Thru semaphores
73
IDEC KAIST, March 28, 2003
Priority Inversion thru Interrupts
Types of priorities
Software priority
• Task priority maintained by the operating systems
Hardware priority
• IRQ priority hard-coded thru PIC (programmable interrupt
controller)
Hardware priority is always greater than software
priority.
(Ex) Interrupt from disk controller interrupts time critical task.
74
IDEC KAIST, March 28, 2003
Priority Inversion thru Semaphore
Case: Dining room in a military camp
＊
★★
◆
◆
◆
＊
★★
◆
◆
◆
★★
◆
◆
◆
＊
◆◆
＊
★◆★
◆◆
★★
＊
＊
75
IDEC KAIST, March 28, 2003
Features of
Real-Time Operating Systems
for Priority Inversion
76
IDEC KAIST, March 28, 2003
Reducing Interrupt Response Time (1)
Reduce duration of priority inversion using IST
(interrupt service threads).
chaining
0
callback
functions
1
interrupt
vectors
31
threads
77
IDEC KAIST, March 28, 2003
Reducing Interrupt Response Time (2)
Reduce duration of priority inversion using separate
interrupt stack from task stack when possible
Allows for avoiding task context switches
(Ex) VxWorks 5.4
78
IDEC KAIST, March 28, 2003
Priority Inheritance
Basic priority inheritance protocol (BPI)
May incur deadlock
Simpler than IIP
Work well if there is no nested critical section
Immediate priority ceiling protocol (IIP)
Work well without incurring deadlocks
79
IDEC KAIST, March 28, 2003
Other Features of
Real-Time Operating Systems
80
IDEC KAIST, March 28, 2003
Desired Features of RTOS (1)
Supporting industrial standards
IEEE POSIX 1003.4, 1003.13
Win32 APIs
Offering development tools
GUI-based integrated development kits
Remote debuggers and in-circuit emulators
Board support packages
Dealing with proliferation of communications
Drivers for a variety of network interface adaptors
Complete implementation of TCP/IP networking
81
IDEC KAIST, March 28, 2003
Desired Features of RTOS (2)
Avoiding priority inversions
Sufficient priority levels (Counter example: WinCE 2.x)
Interrupt processing based on kernel threads
Priority inheritance and ceiling protocols
Providing low power consumption
Dynamic voltage scaling
Dynamic power management
Supporting solid state file systems
Journaling flash file systems (JFFS)
82
IDEC KAIST, March 28, 2003
Architecture
Real-Time Operating Systems
83
IDEC KAIST, March 28, 2003
OS Components
File System
CPU
Scheduler
Memory
Management
System
Network
System
I/O System
84
IDEC KAIST, March 28, 2003
Essential Components in RTOS
Initial Program Loader (IPL)
The Kernel
File system components
Highly available file systems
85
IDEC KAIST, March 28, 2003
Architecture of Typical RTOS
dynamic loadable modules
kernel
module
kernal
module
Real-Time Embedded Applications
user
task
…
embedded
web server
JAVA API
pthread API
socket API
Win32 API
JAVA
(KVM)
thread
manager
protocol
stack
window
system
IPL
user
task
JFFS
scheduler
monitoring
shell
device
drivers
hardware
86
IDEC KAIST, March 28, 2003
The Velos
Real-Time Operating Systems
A Case Study
87
IDEC KAIST, March 28, 2003
What is Velos?
Velos
Real-time operating system for embedded applications
Developed by RTOS Lab. at Seoul National University
Velos applications
web camera
PDA
settop box
residential gateway
88
IDEC KAIST, March 28, 2003
Evolution
StrongARM
PowerPC
xscale
i386
VFS
target
processor
ARM7
TCP/IP
start
core
window
system
JVM
2001. 2
2000. 10
2000. 7
2000. 5
1999. 12 2000. 3
web
server
web
camera
Velos
DLL
2001. 10
IPv6
QoS
2001. 11
PDA
(iFeel)
mobile
phone
set-top
box
applications
current
future
89
IDEC KAIST, March 28, 2003
Key Features
Library kernel
POSIX 1003.13 PSE51 minimal real-time system
profile support
Multi-tasking
Dynamic application loading
Real-time scheduling
TCP/IP network protocol stack – linux
Window system – micro windows
JAVA support – KVM
90
IDEC KAIST, March 28, 2003
Architecture of Velos
dynamic loadable applications
user
task
user
task
Real-Time Embedded Applications
user
task
task
source
+
Velos
library
kernel
+
libraries
…
embedded
web server
JAVA API
pthread API
socket API
Win32 API
JAVA
(KVM)
thread
manager
protocol
stack
window
system
boot-up
user
task
interrupt
service
scheduler
monitoring
shell
device
drivers
hardware
91
IDEC KAIST, March 28, 2003
Memory Footprint
(byte)
text
data
bss
total
core
17216
1564
652
19432
driver
7012
2264
0
9276
thread
20284
124
0
20408
C library
60496
1320
4100
65916
network library
178528
6396
476
185400
window library
52496
2088
2604
57188
total
336032
13756
7832
357620
font
English
Korean
Chinese +
Japanese
total
size
10K
450K
320K
780K
92
IDEC KAIST, March 28, 2003
Velos Timing (1)
Non-preemptive code sections in Velos
(s)
KS32C50100 ARM7 50Mhz cache on
non-preemptive section
time
maximum interrupt
disabled interval
20
maximum scheduling
locked interval
39
93
IDEC KAIST, March 28, 2003
Velos Timing (2)
Interrupt delivery performance in Velos
(s)
KS32C50100 ARM7 50Mhz cache on
average
stdev
min
max
interrupt latency
(no interrupt disabled
section)
3.52
0.130
3.40
3.74
interrupt thread latency
(no interrupt disabled
section, 1 thread)
24.94
0.005
24.94
25.44
94
IDEC KAIST, March 28, 2003
Velos Timing (3)
Scheduling performance in Velos
(s)
KS32C50100 ARM7 50Mhz cache on
average
stdev
min
max
scheduling latency
6.64
0.000
6.64
6,64
context save
2.15
0.089
2.08
2.30
select
4.00
0.004
4.00
4.34
context restore
1.72
0.000
1.72
1.72
95