Current Research Efforts in Real-time and Embedded Systems

1. Current Research Efforts in Real-time and Embedded Systems Douglas Niehaus Information and Telecommunication Technology Center Electrical Engineering and Computer Science Department University of Kansas niehaus@ittc.ku.edu

2. Overview • Real-time and Embedded Systems • KURT-Linux • Real-Time in Linux • Component support for embedded configuration • HW/SW Co-Design for Real-Time • Future • Integrated HW/SW Implementation Environment • Group Scheduling • Distributed Real-Time and Embedded Services

3. Real-Time and Embedded Systems • Change many of the assumptions underlying conventional computer system design • Real-time requires finer resolution time keeping and resource allocation because they must control when actions occur • Precise control of events on real-time line • When a computation executes is part of its correctness • Execution time predictions are required in many cases • Embedded systems are often special purpose • Application semantics differ widely • Specialized & Restricted semantics  specialized programming models • No single programming model is best match for all application semantics  multiple models or lowest common denominator • Majority of all computers (80%+) are embedded, increasing number must satisfy real-time constraints

4. Collaborators • Douglas Niehaus • Real-time, distributed, programming environments, systems • David Andrews • Real-time, embedded, architecture, HW design, sensor webs • Jerry James • Distributed, programming environments and models, formal methods • Perry Alexander • Formal Methods • Rosetta (Modeling) • Engineering of Computer Based Systems

5. KU Real-Time (KURT) Linux • Long term effort to improve the suitability of Linux for real-time applications • Modification for real-time within Linux • Not a separate underlying executive as RTLinux and RTAI • Three parts • Time keeping and event scheduling (UTIME) • KURT programming model • Interrupt service (recent extension) • Linux patch size is minimized

6. UTime: Time Keeping & Event Scheduling • Portable High Resolution API • Time Standard: Pentium Time Stamp Counter • CPU clock (nanosecond) resolution • Next Event Interrupt: microsecond resolution • PC timer Chip (8159) or Pentium PIC • Useful in its own right • Often used without KURT component • Starting point of Linux High Resolution Timers Project • Multiple Platforms • StrongARM, XScale/FPGA SBC, AMD Elan (x86+), Power PC (PPC) Virtex II Pro SBC (future) • Time Standard and Next Event Interrupt methods vary

7. Data Streams • Resolution of performance data must exceed that of the desired system behavior, not true of most aggregate data • General method for representing and gathering data related to system status and performance • Originally conceived for OS performance data (DSKI) • Generalized to application programs (DSUI) • Applications present significant interface challenges • Data sources: Several types, multiple groupings • Data Stream is generated by selected data sources • Users choose which data sources to activate for a given experiment • Configuration options on some data sources

8. DSKI Control and Data Flow

9. KURT: Programming Model • Simple: explicitly designate execution intervals • Using UTIME capabilities for time keeping and next event scheduling • Primary Interface: Cyclic real-time execution plan • Cyclic schedule repeats until deleted or replaced • Easy to implement periodic computations • Used to provide CPU percentage in a specific usage pattern (ANTS) • Useful to guarantee event response times • KURT module can switch dynamic schedules • RTSS Scheduling server builds and submits new schedules in response to computation requests • Conventional Linux Scheduler for non-real-time tasks • Dynamically generated events in general timer queue

10. Application Application RT Scheduling Service Plan Scheduler DSKI Hardware Basic KURT Architecture User Logging OS KURT Programming Model UTime

11. Programming Model Framework • Single programming model insufficient for the full range of real-time and embedded systems’ semantics • Recent KURT-Linux extensions support creation of multiple components and configuration selection • Scheduling decision functions • Programming models • Interrupt handling semantics • System architects can select among existing components or implement their own • Set of selected components determines system behavior

12. A A A A A A A A Non-Real-Time Real-Time Logging DSKI Hardware Programming Model Framework User OS Schedulers KURT Programming Models M2 M3 M4 M5 M1 S2 S3 S4 S5 S1 UTime Interrupts DF1 DF2

13. Improving Interrupt Handling • As Fast As Specified • Rather than as fast as possible • Interrupt handling currently manifests as noise in many RT programming models • Interrupts are “always” enabled • Handler notes which interrupts occurred • Interrupt Decision function decides when handlers run • Existing interrupt handlers supported for compatibility • Exposes concurrency among interrupt handlers • Currently one semaphore, but could be per-driver or per-data structure

14. Kernel Handler-Without ISR Mods

15. Kernel Handler – With ISR Mods

16. HW/SW Co-Design Supporting OS Functions • Moving low level OS functions into hardware can: • Increase quality of service, while • Decreasing system overhead, and • Increasing accuracy/predictability • Several stages of CPU  FPGA migration • Targets: • Time Keeping and Event Scheduling (working) • Event Queue (current) • Thread scheduling (future) • Interrupt Processing (future)

17. Jiffy Sub-Jiffy Jiffy Match Sub-Jiffy Match Event Data Event Queue Thread Data CPU-FPGA Cooperation for OS Support FPGA Time Standard CPU Next Event INTR Thread Scheduling Interrupt Subsystem Memory

18. Conclusion • System support for real-time and embedded programming environments is lacking in many ways • KURT-Linux development has improved programming model support in several ways and improvement is continuing along several paths • Current and future proposals in several areas • DARPA PCES II award beginning now

19. Future • Extend and generalize interrupt processing • Minimize interrupt response time • Parameterize speed/generality tradeoffs • Modularize interrupt decision function • EDF for as fast as specified • FPGA support • HW/SW Co-Design programming environment • NSF E&HS Proposal • Group Scheduling • DARPA PCES II Award • Middleware • System State Information Service • Data Streams extension for OS and application state data • DARPA PCES II Award

20. Future: HW/SW Co-Design Programming • Integrated HW/SW programming environment • Computations can flow easily across the HW/SW boundary • FPGA based threads of computation have a simple standard interface for I/O and control • Standard atomic semaphore operations are key • CPU  FPGA • FPGA  CPU • Programming model will (largely) conceal support for a thread by CPU or FPGA • HW/SW support choice can move later in the design and implementation flow

21. Future: Group Scheduling • Generalized decision procedure for choosing a process (thread) to run next • Linux uses one decision function and one group • Our approach • Decision function chooses among group members • Threads are members of one or more groups • Groups can be members of groups • Decision Tree • Start at the top and continue running group decision functions until next thread selected • Should be able to integrate thread and interrupt scheduling in the operating system: fully integrated computation scheduling

22. More Information • KURT-Linux Home Page: www.ittc.ku.edu/kurt • Data Streams Home Page: www.ittc.ku.edu/datastream • My Home page: www.ittc.ku.edu/~niehaus • Several Posters in ITTC Lobby