A Model-Based Approach to System Specification for Distributed Real-time and Embedded Systems *

1. A Model-Based Approach to System Specification for Distributed Real-time and Embedded Systems * Radu Cornea1, Shivajit Mohapatra1, Nikil Dutt1, Rajesh Gupta2, Ingolf Krueger2, Alex Nicolau1, Doug Schmidt3, Sandeep Shukla4, Nalini Venkatasubramanian1 1 UC Irvine 2 UC San Diego 3 Vanderbilt 4 Virginia Tech *This work is supported in part by NSF award ACI-0204028

2. Outline • FORGE: DRE System Design • System Specification • Compiler-Runtime Interaction • Case Studies • Automatic Target Recognition • Quality-driven Video Streaming

3. Motivation • New portable devices • Substantial capabilities • DRE applications • Video Streaming • Avionics • Biomedical • Remote sensing • Space exploration • Command and control • Autonomous systems • Networked, heterogeneous • Performance, power, and reliability constraints • DRE development process • Mostly manually driven • Evolving end-to-end software architectures for complex systems

4. FORGE: DRE System Design • Systematic method for DRE application development • Integrated specification of system requirements • Behavior, performance/QoS/Power/RT constraints • Specification of heterogeneous platforms across levels • Formalized through description languages • Flexible and optimized middleware solutions and operating systems • Adaptive and reflective middleware • Integration with application code • Compiler/runtime tools for hardware abstraction layers • Particularly critical for power/performance management

5. Application Functional Specification (including timing, power and other constraints) Middleware Service objects Capture resource constraints ADL capturing the platform architecture RDL describing resource constraints Capture Platform architecture Compiler Heterogeneous computing platform DB DSP -proc Xscale Application Development Model

6. Middleware: Adaptation and Reflection • Adaptive • Statically • Reduce memory • Minimize dependencies • Dynamically • Optimize response • Reflective • Self-adjust capabilities • QoS • Reallocate resources/change strategies for desired QoS • Need integration with lower levels!

7. Behavior Specification Structure Specification EXPRESSION Operation Specification Arch.Components Instruction Description Pipelining, Data Routing Operation Mappings Memory Subsystem Hardware Abstraction Layer Specification • Processor ADLs • Traditionally used for synthesizing compilers and simulators • Abstractions for micro-architectural resources • Structure • Behavior • E.g., EXPRESSION • Need System-Level Extensions! • Interfaces with OS and middleware

8. Resource and Architecture Description • Extend Processor ADL to complex systems • Heterogeneous hardware/abstraction • Communication Structure • System Constraints/Requirements • power, reliability,.. • deadlines, periodicity,… • Constructs for system composition • Couple with middleware abstraction • Use Extended ADL • Generate service specifications • Check feasibility of meeting constraints • Code mapping, given constraints/tradeoffs

9. Interactions Between Levels • OS/hardware -> Middleware • Computing power • Available memory • Specialized functional units (coprocessors) • Power budget (efficient discharge profile) • Middleware -> OS/hardware • Part of the global view made available to OS • Better profiling (time, power) • Future schedule changes • Relative task importance => Middleware can then make better decisions => Hardware can then make better decisions

10. Target Detection FFT Filter/IFFT Compute Distance Case Study 1: ATR • ATR: Automatic Target Recognition • 4 main tasks per frame • Mainly independent • Can be parallelized • Pipelined version • Distributed world • Hundreds of nodes (drones) • Geographically distributed • Heterogeneous network • Various capabilities • Wireless • Sensors (IR, visible) • Motion capable • Complex decisions at runtime • Application pipeline

11. ATR System Specification • Application • Task decomposition • Main tasks: TARG, FFT, IFFT, DIST • System level constraints • Task characterization (requirements) • Resource description • Nodes • Capabilities (processing power, memory) • Timing and power profiles (per each task) • Network layout

12. (Application ATR (Contains TARG FFT IFFT DIST) (Paths (TARG FFT) (FFT IFFT) (IFFT DIST) ) (Deadline 16ms) ... (Task TARG (FloatingPoint NO) (Scalable YES) (Memory 1Mb) ... ) (Task FFT (FloatingPoint YES) (Scalable YES) (Memory 1Mb) ... ) ... ) (Node MOBILE1 (Processor 400MIPS) (Memory 32Mb) (DPMCapable NO) (DVSCapable YES) (DVSModes (m0 600Mhz 2.2V) (m1 500Mhz 1.8V) (m2 400Mhz 1.5V) (m3 300Mhz 1.1V) ) (PowerSource (Battery 50Wh) (SolarCell 5Wh (Period 24h) (Duration 9h) ) ) (TaskProfile (Task TARG (m0 0.66ms 7W) (m1 0.79ms 4W) (m2 0.99ms 2W) (m3 1.32ms 0.9W) ) (Task FFT (m0 0.29ms 6W) (m1 0.34ms 3.5W) (m2 0.43ms 1.8W) (m4 0.57ms 0.75W) ) ... ) (Sensors (Video (Spectra Visible) ) ) ... ) Specification (application and node description) (Node MAIN1 (Processor 800MIPS 800MIPS) (Memory 1000Mb) (DPMCapable NO) (DVSCapable NO) (PowerSource (Line NOLIMIT) ) (TaskProfile ... ) ) ATR Specification Example

13. ATR Decision Tradeoffs • Reflective middleware: global view • Decides on migrating components to free resources on constrained nodes • Reshape network topology • Requires info from architecture (OS) level • Receives periodic status updates from lower level • OS/Hardware level: local view • Handles operating modes, DVS • Interacts with higher levels for control decisions

14. ATR Scenarios • Component migration between nodes • Middleware decision (decrease load) • Information about hardware helps • E.g. Integer/FP tasks vs node FP capabilities • Network activation • Target identified by a node • Middleware wakes up nodes in the region • Sends commands to OS/hardware level (global info) • OS/hardware decides on new power state • Low OoS - power saving, high QoS – full power • Dependent on target proximity

15. Case Study 2: Quality Driven Video Streaming • MPEG4 streams to mobile handhelds (iPAQs) • Problem: high energy requirements • Short lifetime, user experience greatly affected • Video stream cannot be viewed to completion • Partly affected by interference w/ other users • Goal: tradeoff quality vs power for the best user experience • Maximize QoS while ensuring full service • Main objective is not power minimization! • Problem: Human perception of video quality • Subjective, different perception on small devices

16. Middleware/Hardware Integration • Aggregate techniques at different levels, for cumulative joint power gains • Middleware: coarse grain • Controls quality of multimedia content and network transmission • Proxy-based admission control + video transcoding • Intelligent network streaming • Hardware/OS: fine tuning • Architectural adaptation • Low-level performance knobs • Optimized cache configuration • Dynamic voltage scaling • Compiler techniques at device • Integration: feedback based QoS control

17. Experimental Results: CPU + Memory • Setup: • Wattch/Simplescalar • Berkeley MPEG tools • 8 video qualities • Video content • Slow “news” to fast “action” type content • 30 point cache search space • Size: 4-64 • Associativity: 1-32 • Cache Results • 10-15% energy savings • Cache + DVS • Up to 60% savings Search Space for Cache Optimization Cache/DVS Best Operating Points + Savings

18. Experimental Results: Network Card & System • Network card: • Burst transmission • “Sleep” between transmissions • Other users in the network modeled as noise • Savings: 70% • Integrated framework • Utility factor improvement by a few quality levels • Conclusion: improved user experience from integrated approach Optimizing Burst Time Integrated QoS Based Simulation

19. Summary • FORGE: • Brings together advances in • Architecture/Hardware abstraction modeling • Software architecture • Distributed / real-time systems • Provides capabilities for DRE development • Conceptualization of design knowledge • Exploitation of design knowledge across development phases for DRE systems • Cross-optimization across disjoint abstractions • Current focus on Hardware and Middleware Abstractions • Particularly critical for meeting power and QoS in DRE applications using mobile devices