Misconceptions and Challenges on Embedded Software: From Hardware Engineers’ Perspectives

1. Misconceptions and Challenges on Embedded Software:From Hardware Engineers’ Perspectives 홍 성 수 서울대학교 전기컴퓨터공학부 실시간 운영체제 연구실

2. 話 頭

3. 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.

4. 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

5. 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

6. EE Engineers’ Misconceptions about (Embedded) Software

7. 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

8. 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

9. Specific Misconceptions (2) • In embedded systems development, performance is always the No. 1 issue except cost

10. How to Deal with Software Design Complexity

11. 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

12. IEEE1394 FORMAT Converter AUDIO Decoder Dolby AC3 VIDEO Decoder TS CPU OSGM Decoder EQ. Sources of the Crisis (2) MEMORY MEMORY VIDEO Decoder CPU HDTV Channel EQ. MPEG2 TS FORMAT Converter HDTV Channel Decoder OSGM

13. Sources of the Crisis (3) • Solid-state file systems. • Flash, battery-backed CMOS RAMs • Custom I/O devices • Image sensors, LCDs, key pads.

14. 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

15. 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 Sources of the Crisis (5)

16. 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

17. Internet Home Banking • Multimedia browsing • Emailing • Surfing • And many more Sources of the Crisis (7) Broadcasting • Interactive advertisement • On-line shopping • Stock quotes, weather, traffic, news, sports • Enhanced EPG • And many more • PC applications • Utilities • Games VoD Home Shopping Virtual Games

18. 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

19. 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

20. Decomposition • Solve a problem in “divide-and-conquer” way • RTOS supports decomposition through multi-tasking

21. Abstraction (1) • Hides complicated details behind abstraction interfaces and only shows the minimum amount of information • Results in layered structures • Yields performance slow down

22. Abstraction (2) User Programs User Programs User level Libraries Kernel level System Call Interface File System Management Task Management IPC Buffer Cache Context Device Drivers Memory Management Hardware Control (Interrupts handling, etc) HW level Hardware (Source : The design of the UNIX OS)

23. Abstraction (3) file file file system drive byte block physical block block # fp

24. RTOS as an Example

25. Motivations for RTOS • Abstracting complex hardware idiosyncrasies • Run-time predictability (real-time guarantee) • Multi-tasking

26. Without RTOS Programmers should write everything. Video cardinitialization Memorymanagement Video cardoperation Motivations for RTOS With RTOS #include <stdio.h> void main() { printf(“Hello, World\n”); } Operating System

27. 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.

28. 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.

29. Wait for I/O Event Display data Enter event to DB AD converter Search DB Wait for command DB Example: Data Acquisition System

30. Requirement Specification (1) • 16-bit digital input signal level의 변화를 검출하고, RAM-resident database에 event로 시간과 함께 기록한다. • 이 입력은 Digital Interface로 명명한다. • 9600-baud의 두 serial port를 통해서 두 interactive operator console을 서비스 한다. • 이 입력은 Serial Interface로 명명한다.

31. Requirement Specification (2) • 두 serial port에 물려있는 console에 시간을 display 하며 매초 마다 시간을 갱신한다. • 두 serial port에 물려있는 console을 통해 RAM-resident database에 대한 검색 요구가 입력되면 이를 처리한다.

32. 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 발생)

33. 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

34. (1) Infinite Polling Loop w/o Interrupts (1) • A single main loop services all I/O sequentially. • Check all I/O to detect incoming events. • 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.

35. (1) Infinite Polling Loop w/o Interrupts (2) • Example code structures 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++; ｝ ｝ Main ( ) { for (;;) ｛ check_inputs( ); check_digital_interfaces( ); application( ); ｝ ｝ 〈Existing code〉 〈Split code〉

36. (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.

37. (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.

38. (2) Infinite Polling Loop with Interrupts (2) • Example code structures main ( ) { for (;;) ｛ service_operator( ); update_time_on_display( ); handle_queued_events( ); ｝ } 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); } 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.

39. (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,...

40. (3) Multi-Tasking (2) • Multi-tasking in a data acquisition system: Wait for I/O Event Display data Enter event to DB AD converter Search DB Wait for command DB

41. (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( ); ｝ ｝

42. Introduction to Real-Time Systems

43. 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.

44. 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.

45. release time deadline period period timer service Forms of Timing Constraints (2) • Details of periodic constraints

46. Scale of Timing Constraints 100 ms 20 ms 10 ms 5 ms 1 ms 500 µs Cycle Time (Period) 90% Products 0 100 1,000 5,000 10,000 Cycle Variation (Jitter) in µs

47. 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.

48. 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.

49. I. Predictable Reaction in Real-Time Operating Systems

50. alarm signal What’s Happening insideResidential Gateway? Residential Gateway Gas Detector Response time really matters!