university of kansas douglas niehaus information and telecommunication technology center electrical...
Post on 21-Dec-2015
214 views
TRANSCRIPT
University of Kansas
Douglas NiehausInformation and Telecommunication Technology Center
Electrical Engineering and Computer Science DepartmentUniversity of [email protected]
Current Research Efforts in Real-time and Embedded Systems
University of Kansas
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
University of Kansas
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
University of Kansas
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
University of Kansas
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
University of Kansas
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
University of Kansas
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
University of Kansas
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
University of Kansas
Basic KURT Architecture
Hardware
UTime
KURT Programming ModelOS
User
RT SchedulingService
Application Application
Logging
DSKIPlan Scheduler
University of Kansas
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
University of Kansas
Programming Model Framework
Hardware
UTime
OS
User
Logging
DSKI
SchedulersS1 S2 S3 S4 S5
KURT Programming Models
M1 M2 M3 M4 M5
A A A AA A A A
Real-TimeNon-Real-Time
Interrupts DF1 DF2
University of Kansas
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
University of Kansas
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)
University of Kansas
CPU-FPGA Cooperation for OS Support
CPU
FPGA
Jiffy Sub-JiffyTimeStandard
NextEventINTR
JiffyMatch
Sub-JiffyMatch
Memory
Event Data
Thread Data Event Queue
Thread Scheduling
Interrupt Subsystem
University of Kansas
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
University of Kansas
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
University of Kansas
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
University of Kansas
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