IDEC KAIST March 28 2003 Misconceptions and Challenges

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 So. C 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 So. C 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) Diverse hardware platforms and components Microprocessors and microcontrollers • Instruction set architectures – ARM, Power. PC, x 86, MIPS, SH 5 • 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 CPU HDTV Channel EQ. HDTV Channel Decoder VIDEO Decoder IEEE 1394 Decoder MPEG 2 FORMAT TS Converter EQ. AUDIO Decoder VIDEO Decoder CPU FORMAT Converter Dolby AC 3 TS 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 • Home. PNA, IEEE 802. 3, Powerline Control networks • RS 485, X-10, CE Bus, Lon. Works Mobile networks • Home. RF, IEEE 802. 11, Bluetooth 14

IDEC KAIST, March 28, 2003 Sources of the Crisis (5) Public networks PSTN, Internet Network camera Home. PNA 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, x. DSL 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 Vo. D 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 … drive # cylinder # head # sector # file system 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, Worldn”); } 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. 3 ms 마다 입력) Interrupt-driven mode (ISR이 1. 3 ms 이내에 수행 종료) 매초 마다 1회씩 console의 시간을 update하며, database의 내용을 검색할 수 있게 한다. Polled mode Interrupt-driven mode (1 ms 한번 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 : application 0( ); break; case 1 : application 1( ); break; case 2 : application 2( ); 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 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 preemptive response time interrupt ISR scheduling iret 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 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 t 1, t 2; while(1) { time(&t 1); /* do something */ time(&t 2); if((t 2 t 1)>deadline){ /* handle deadline miss */ } sleep(period-(t 2 t 1)); } } 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 – (t 2 -t 1)) 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 reate(); c _ d a e r h rt rthread_ create() ; rth rea d_c rt rea hr te( ea ); d_ cr ea te () ; while(1) { /* do something */ rthread_wait_next_period(&pinfo); } Periodic thread Deadline Handler thread dhandler 1(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 interrupt vectors callback functions 1 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) Vx. Works 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 Win 32 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: Win. CE 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 Win 32 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 Strong. ARM Power. PC xscale i 386 VFS target processor ARM 7 TCP/IP start core 1999. 12 2000. 3 web server window system 2000. 7 2000. 5 JVM 2001. 2 2000. 10 web camera applications Velos DLL 2001. 10 IPv 6 Qo. S 2001. 11 PDA (i. Feel) current mobile phone set-top box future 89

IDEC KAIST, March 28, 2003 Key Features Library kernel POSIX 1003. 13 PSE 51 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 Real-Time Embedded Applications user task source + Velos library kernel + libraries … embedded web server JAVA API pthread API socket API Win 32 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 10 K 450 K 320 K 780 K 92

IDEC KAIST, March 28, 2003 Velos Timing (1) Non-preemptive code sections in Velos ( s) KS 32 C 50100 ARM 7 50 Mhz 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) KS 32 C 50100 ARM 7 50 Mhz 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) KS 32 C 50100 ARM 7 50 Mhz 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 95