1 / 42

Synchronous Reactive Communication: Generalization , Implementation, and Optimization

Synchronous Reactive Communication: Generalization , Implementation, and Optimization. Guoqiang Gerald Wang PhD Candidate Committee in charge: Prof . Alberto Sangiovanni-Vincentelli , Chair Prof. Robert K. Brayton Prof. Zuojun Shen December 9, 2008. Outline.

Download Presentation

Synchronous Reactive Communication: Generalization , Implementation, and Optimization

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Synchronous Reactive Communication: Generalization, Implementation, and Optimization GuoqiangGerald Wang PhD Candidate Committee in charge: Prof. Alberto Sangiovanni-Vincentelli, Chair Prof. Robert K. Brayton Prof. ZuojunShen December 9, 2008

  2. Outline • Background and previous work • Methodology and implementation framework • SR semantics preserving communication protocols • Protocol implementation under OSEK OS standard • Memory optimization under timing constraints • Automatic code generation • Conclusions • Background and previous work • Methodology and implementation framework • SR semantics preserving communication protocols • Protocol implementation under OSEK OS standard • Memory optimization under timing constraints • Automatic code generation • Conclusions

  3. System-Level Design • On the edge of a revolution in the way electronic products are designed • Increasing design complexity • High product quality • Stronger market pressure • System-level design is the key to success • Start with the highest possible level of abstraction (e.g. control algorithm) • Establish properties at the right level • Use formal models • Leverage multiple scientific disciplines Background

  4. Models of Computation • Process Networks (PN) • Undecidable: deadlocks and buffer boundedness • Synchronous Reactive (SR) • WRT model time • computation doesn’t take time • All actors execute simultaneously and instantaneously • Has strong formal properties: decidable termination & boundedness • Good for specifying periodic real-time tasks • Discrete Event (DE) • Signals are time-stamped events • Events are processed in chronological order • Good for modeling and design of time-based systems • Dataflow process networks • Dataflow processes are Kahn processes composed of atomic firings Background

  5. Implementation Tools • Academia: • MetroPolis (ASV, UCB) • Meta model • Communication refinement • Ptolemy (E. Lee, UCB) • Started with static dataflow for DSP • Mixed model verification • Industry: • LabVIEW • Statically schedulable dataflow (Synchronous dataflow) • Simulink • Synchronous reactive Support multiple models of computation Background

  6. Model-Based Design • An instance of system-level design • Very popular • Tool support • Design time simulation/verification • Short development cycle • Predictable performance • Flexibility of new design evaluation • Design reuse • The rest of the presentation • Synchronous reactive model-based design Background

  7. SR Semantics Donald, I am sending $5 and an apple. Get $5 and an apple. Thanks, Mickey! My turn to run! Now I am done. Time for me to run I finished. $5 prioritym > priorityd periodm < periodd Simulation time t0 t1 During simulation, writer and reader respond instantaneously (computation takes zero time) Background

  8. base rate time 0 2 8 16 Task 1 time 0 2 8 16 Task 2 time 0 2 8 16 Implementation Options of Multi-Rate systems • Single-task option • Multiple-task option unschedulable -> 6.1 Background

  9. Model Implementation (Case I) I need to yield to Mickey. Donald, I send $1 and a banana this time. Now, I can start. Time for me to run again. Now I am done. I can resume. My turn to run. But need to wait. Start receiving. Now I am done. Get $1 and a banana. Donald, I am sending $5 and an apple. $1 $5 I finished. Time for me to run real time prioritym> priorityd periodm< periodd t0 t1 t2 t3 t4 t5 Communication is not atomic Uni-processor and priority-based preemptive scheduling Background

  10. Model Implementation (Case II) Start receiving. Got $5! Not finished yet. Have to yield. Donald, I send $1 and a banana this time. Now, I can start. Time for me to run again. Now I am done. My turn to run. But need to wait. Resume receiving. Now I am done. A banana. Wow, $5 and a banana!! Donald, I am sending $5 and an apple. $1 $5 I finished. Time for me to run real time t0 t1 t2 t3 t4 t5 Background

  11. What Is the Difference $5 SR Semantics simulation time $5 $5 $1 data determinism problem real time Case I $1 first second $1 $5 data integrity problem Case II real time $5 Background

  12. Current Approach Limitations and Solutions • Rate transition buffering scheme from The MathWorks • Limitations • One to one communication • Double buffering scheme • No memory optimization • For periodic communicating tasks: • Periods must be harmonic • Tasks must be activated with the same phase • Solutions • One to many communication • Dynamic buffering and temporal currency control protocols • For periodic communicating tasks: • Raise the implementation up to the kernel level • Furthermore, • Generalization with support of arbitrary link delay and multiple activations per task • Memory optimization through automatic protocol selection Background

  13. Outline • Background and previous work • Methodology and implementation framework • SR semantics preserving communication protocols • Protocol implementation under OSEK OS standard • Memory optimization under timing constraints • Automatic code generation • Conclusions

  14. Methodology • Platform-based design • Automatic generation of • application tasks • communication protocol implementation • Automatic configuration of RTOS procedures and data structures • Flexibility of choice of RTOS API standard Methodology

  15. Meet-in-the-Middle Approach Application Functional Model • Application domain • Time-critical applications • Modeled as SR tasks • Platform • Task/resource model platform • Task’s characteristics and interaction • RTOS platform • Priority-based scheduling policies • Inter-task comm. protocols • lock-based, lock-free, wait-free • Middle meeting point • RTOS API • OSEK/VDX, POSIX, μITRON • Execution architecture • Uni-processor • Priority-based preemptive scheduling Task Model; Communication Resource Model Mapping RTOS API Export Scheduling Policy: FP, DP; Communication Resource Management Policy Execution Architecture Methodology

  16. Design Flow Specification of SR models Model-based design tool Application configuration files (OIL) C code OSEK OS Kernel OSEK COM System Generator (SG) Files produced by SG User’s source code C code C code compiler linker Object libraries Executable file Methodology

  17. τi · · · · NIP NOP · · Task Model τi • Parameter characterization • Priority: • Period: • Activation time: • Start time: • Worst-case computation time: • Finish time: • Worst-case response time: • Relative deadline: time Methodology

  18. Outline • Background and previous work • Methodology and implementation framework • SR semantics preserving communication protocols • Protocol implementation under OSEK OS standard • Memory optimization under timing constraints • Automatic Code Generation • Conclusions

  19. SR Semantics with Link Delay j ri time in out w ··· time SR Protocols

  20. One to Many Communication: Single-Writer Multiple-Reader • General case: and • Special case: and HPR: ··· ··· Link delay: design parameter ··· LPR: ··· SR Protocols

  21. SR Semantics Preserving Communication mechanisms • Wait-free scheme • Buffer sizing mechanisms • Spatially-out-of-order writes • Spatially-in-order writes • Buffer indexing protocols • Dynamic Buffering Protocol (DBP) • Temporal Concurrency Control Protocol (TCCP) SR Protocols

  22. LPR HPR Spatially-out-of-Order Writes • Buffer sizing: Buf[] Read[] prev 0 2 0 0 5 5 1 cur 1 1 0 1 2 2 3 4 3 3 4 4 2 5 2 5 2 6 SR Protocols

  23. Spatially-in-Order Writes • Offset • Buffer sizing I finished. activated Unit delay buffer index writer instance SR Protocols

  24. How to Guarantee SR Semantics • Handle communication at two levels • Buffer indices defined at activation time by kernel • Data reading/writing at execution time by application tasks SR Protocols

  25. The Protocols FreeHd 2 3 0 4 1 1 2 1 3 5 4 -1 5 UseFreeL[6] SR Protocols

  26. Outline • Background and previous work • Methodology and implementation framework • SR semantics preserving communication protocols • Protocol implementation under OSEK OS standard • Memory optimization under timing constraints • Automatic code generation • Conclusions

  27. OSEK/VDX • A series of standards particularly for automotive designs • Basic and extended tasks • Four Conformance Classes • BCC1, BCC2, ECC1, ECC2 • Portability • Minimum requirement of CC • Kernel services: • Task management, alarm, hook mechanism • OIL • Modular configuration for system generation OSEK Implementation

  28. DispHd size tick TickL[LCMR] DispT[TSize] An OSEK/VDX Implementation • Portable implementation • BCC1 • Minimum Requirement • Only one alarm • Task dispatcher • GCD of rates OSEK Implementation

  29. Implementation (cont) • Application task OSEK Implementation

  30. Comparison of CTDBP & TCCP OSEK Implementation

  31. Outline • Background and previous work • Methodology and implementation framework • SR semantics preserving communication protocols • Protocol implementation under OSEK OS standard • Memory optimization under timing constraints • Automatic code generation • Conclusions

  32. Mathematical Formulation • Fixed given priority • Parameters: • Variables: Buffer sizing mechanisms: Optimization

  33. Complete Formulation Reformulate: MILP Schedulability constraint Buffer size Lifetime WCRT Protocol flag Partial cost of dispatcher Cost of context switches Optimization

  34. Experimental Setup • Performance evaluation environment • PIC18F452 • Performance up to 10 MIPS • ePICos18 • Multi-task, preemptive, O(1) kernel scheduler • OSEK compliant • Task graphs generated by TGFF • 809 systems (158 unschedulable) • On average, 12 tasks/graph; execution time: 6•104ICs; task period: 106ICs • ≤ 4(8) writers(readers)/task; ≤ 2-unit delay; Optimization

  35. Experimental Results 4.8% 14% 24% Optimization

  36. Outline • Background and previous work • Methodology and implementation framework • SR semantics preserving communication protocols • Protocol implementation under OSEK OS standard • Memory optimization under timing constraints • Automatic code generation • Conclusions

  37. Real-Time Workshop • Simulink system functions (S-Functions) • Extend capability of Simulink environment • Coded in C or MATLAB • Target Language Compiler (TLC) • From graphical model to intermediate form • Eventually into target specific code • RTW Embedded Coder (E-Coder) • Framework for development of embedded software Code Generation

  38. SR Implementation Library Code Generation

  39. Example of DyB Given: sampling rates, buffer initial value (8) Period of task dispatcher? How many buffer slots? How many tasks? GCD(2,3,5) = 1 NLPR + 1 + 1 = 3 5 Code Generation

  40. Simulation/Emulation Results RTW MPLAB(PIC18F452) + ePICos18 Period = 3 Period = 5 Period = 2 Code Generation

  41. Conclusions • Generalized theory on SR semantics preserving communication • Implemented protocols with portability consideration under the OSEK OS standard • Optimized memory and supported a wider range of applications under timing constraints with automatic protocol selection • Supported automatic code generation for SR communication protocols

  42. Thank you

More Related