University of Kansas Douglas Niehaus Information and Telecommunication Technology Center Electrical...

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


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


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


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


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


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


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


DSKI Control and Data Flow


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


Basic KURT Architecture

Hardware

UTime

KURT Programming ModelOS

User

RT SchedulingService

Application Application

Logging

DSKIPlan Scheduler


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


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


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


Kernel Handler-Without ISR Mods


Kernel Handler – With ISR Mods


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)


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


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


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


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


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


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

University of Kansas Douglas Niehaus Information and Telecommunication Technology Center Electrical...

Documents

Transcript of University of Kansas Douglas Niehaus Information and Telecommunication Technology Center Electrical...