breaking down complexity for reliable system level timing
play

Breaking down Complexity for reliable System-level Timing - PDF document

Breaking down Complexity for reliable System-level Timing Validation Dirk Ziegenbein INSTITU TE OF Marek Jersak COMPUTER AND Kai Richter COMMUNICATION NETWORK ENGINEERING Rolf Ernst Technical University of Braunschweig, Germany Marek


  1. Breaking down Complexity for reliable System-level Timing Validation Dirk Ziegenbein INSTITU TE OF Marek Jersak COMPUTER AND Kai Richter COMMUNICATION NETWORK ENGINEERING Rolf Ernst Technical University of Braunschweig, Germany Marek Jersak, TU Braunschweig 1 Outline • Complexity of embedded systems • Current limitations for timing validation • Proposed methodology • Breaking down system complexity • Single process analysis • Single resource analysis • Combining results • Conclusion Marek Jersak, TU Braunschweig 2 1

  2. Embedded System Design Industry Needs • High performance, low cost, low power � Specialized languages, optimized architectures • More and more features, short time-to- market � Platform-based design, application and architecture reuse, IP integration System size and heterogeneity result in huge system complexity Marek Jersak, TU Braunschweig 3 Application Complexity • Multi-language design, e.g. Dataflow (voice processing), FSMs (protocol), legacy code • Complex dependencies (contexts, scenarios) Legacy Code Language 1 Language 2 Marek Jersak, TU Braunschweig 4 2

  3. Architecture Complexity • Heterogeneous platforms and SoC • Complex on-chip and distributed networks • System software (RTOS, drivers) RISC MEM DSP CoPro platform SYSTEM BUS HW architecture IP IP VLIW MEM MEM System Software Marek Jersak, TU Braunschweig 5 Integration Complexity • Heterogeneous component and language integration [VSIA, Accellera] Legacy Code Language 1 Language 2 RISC DSP MEM CoPro SYSTEM BUS IP IP VLIW MEM MEM Marek Jersak, TU Braunschweig 6 3

  4. Timing Validation Complexity • Process execution time intervals • Complex run-time interdependencies Legacy Code Language 1 [ ] [ ] [ ] [ ] [ ] [ ] Language 2 RISC MEM DSP CoPro SYSTEM BUS IP IP VLIW MEM MEM Marek Jersak, TU Braunschweig 7 Limits of Simulation-based Validation • System performance corner cases different from component performance corner cases Best-case execution time Worst-case execution time � high bus load � low bus load RISC SYSTEM BUS • Simulation limited to problems with known corner cases or when full coverage is feasible Marek Jersak, TU Braunschweig 8 4

  5. Reliable vs. Unreliable Timing Validation Application Complexity A A P 1 P 2 Homogeneous Complex Complex Multiprocessor Heterogeneous Heterogeneous Single B Platforms Platforms TDMA + Resource B C & SoCs & SoCs Static priorities C P 3 P 4 RMA eliable single unreliable Single resources timing validation Resource reliable EDF TTP timing validation segment pipeline A A B C Single single P 1 Single P 2 P 3 P 4 BB cache processes Process Process Architectural Complexity Marek Jersak, TU Braunschweig 9 Single-Process Timing Analysis Separation of path analysis and architecture modeling • Mok, Puschner, Park (Iteration bounds for loops) • Gong and Gajski (Branching probabilities) • Li and Malik (Implicit path enumeration) • Ye, Wolf, Ernst (Segment-based analysis) • First commercial approaches (AbsInt) Marek Jersak, TU Braunschweig 10 5

  6. Single-Resource Timing Analysis Separation of scheduling strategy and activation static priority scheduling • Rate-monotonic analysis e.g. [Liu/Lay73] • activation: jitter, burst, etc. e.g. [Spr89, Tin94] • arbitrary deadlines (buffering) e.g. [Leh90] dynamic priority scheduling • earliest deadline first (EDF) e.g. [Liu/Lay73] time driven scheduling • time division multiple access (TDMA) [Kop93] • round robin Marek Jersak, TU Braunschweig 11 Idea: Combine Reliable Results Application Complexity A A P 1 P 2 Complex Heterogeneous Single B Platforms Resource B C & SoCs C P 3 P 4 single unreliable eliable resources timing validation reliable timing validation A A B C single Single P 1 P 2 P 3 P 4 Process processes Architectural Complexity Marek Jersak, TU Braunschweig 12 6

  7. System Representation Application abstraction 1 1 A • Processes communicate P 1 P 2 via channels • Externally visible behavior B C P 3 P 4 (activation conditions, amount of communicated data) • SPI [CODES’00, ICCAD’00, DAC’01] • Capture multi-language specifications into homogeneous representation • [Simulink - ISSS’01, SDL - CODES’02] Mapping, scheduling decisions Marek Jersak, TU Braunschweig 13 Breaking Down Application Complexity 2 Process interaction A [ ] [ ] abstraction P 1 P 2 • contexts B C P 3 P 4 3 Single-process analysis [ ] [ ] • execution time intervals 4 • communication intervals 2 3 4 Back-annotation A A B C single P 1 P 2 P 3 P 4 processes [ ] [ ] [ ] [ ] Marek Jersak, TU Braunschweig 14 7

  8. Breaking Down Architecture Complexity A [ ] [ ] A P 1 P 2 B B C C P 3 P 4 5 [ ] [ ] 5 Resource interaction abstraction Marek Jersak, TU Braunschweig 15 Event Models Available timing-analysis techniques require activation abstraction into event models periodic with burst periodic b b T T T t t periodic with jitter sporadic T T x � t x � t x � t J J J Marek Jersak, TU Braunschweig 16 8

  9. Single-Resource Analysis 6 A [ ] [ ] EM A EM A ‘ A P 1 P 2 EM AB [ ] B B C C P 3 P 4 5 [ ] [ ] 6 Single-resource analysis Requires Generates • input event models • Worst/best-case response times • core execution time intervals • Output event models Marek Jersak, TU Braunschweig 17 Example: Static Priority Scheduling Given: Periodic input events with period T x , Core Execution Times T 1 T 1 T 1 P 1 T 2 T 2 t response t response t response t response P 2 T 3 t response t response t response P 3 t response t response priority Response: Periodic with jitter Marek Jersak, TU Braunschweig 18 9

  10. Propagation of Event Models 6 A 7 [ ] [ ] EM A EM A ‘ A P 1 P 2 EM AB [ ] EM AB EM BC 8 B [ ] EM AB [ ] B C EM BC EM C C P 3 P 4 5 [ ] [ ] [ ] [ ] [ ] 7 Back-annotation 8 • Output event models serve as input event models for analysis of the next resource • Iterate steps , and 6 7 8 Marek Jersak, TU Braunschweig 19 Event Model Interface analysis result: [Sprunt’89] assumes periodic (T) with jitter (J) [Sprunt’89] sporadic input events (t) P 1 t = T - J P 2 P 4 P 3 Event Model Interface RISC RISC T T T J J x � t x � t x � t x � t Marek Jersak, TU Braunschweig 20 10

  11. Event Adaptation Function (EAF) RMA: assumes rate monotonic analysis result: analysis [Liu/Lay73] periodic input (T Y ) periodic (T X ) with jitter (J) P 1 ? EMIF P 2 P 4 P 3 T Y= T X RISC RISC EAF: timed buffer derive properties of EAF from event models: • required buffer size: 1 • maximum buffering delay: T X Marek Jersak, TU Braunschweig 21 Everything Together 1 Application Complexity 6 A [ ] [ ] 7 EM A EM A ‘ A P 1 P 2 EM AB Complex [ ] EM AB EM BC Heterogeneous 8 [ ] Single B EM AB Platforms Resource [ ] B C & SoCs EM BC EM BC EM C C P 3 P 4 5 [ ] [ ] [ ] [ ] [ ] single unreliable Reliable resources timing validation timing validation 4 reliable 2 timing validation 3 A A B C single Single P 1 P 2 P 3 P 4 Process processes [ ] [ ] [ ] [ ] Architectural Complexity Marek Jersak, TU Braunschweig 22 11

  12. Breaking down Complexity for reliable System-level Timing Validation Dirk Ziegenbein INSTITU TE OF Marek Jersak COMPUTER AND Kai Richter COMMUNICATION NETWORK ENGINEERING Rolf Ernst Technical University of Braunschweig, Germany Marek Jersak, TU Braunschweig 23 Conclusion • Ever increasing embedded system complexity • System-level validation not reliable with current simulation-based techniques • Reliable approaches exist for single-process and single-resource analysis • Simple rules to couple single-process and single-resource analysis techniques • Together enables reliable system-level timing validation of complex embedded systems Marek Jersak, TU Braunschweig 24 12

  13. Single-Process Timing Analysis (SYMTA) • Analysis of control structures (path classification) • Obtain execution number interval for each path 1 • Execution of segments to obtain for j=1 1 cost intervals j<15 15 (execution time, communication ...) if 14 a[j]>lim • Conservative [0,14] Send(c2,a[j]) combination 14 considering state of j++ pipeline, cache ... Marek Jersak, TU Braunschweig 25 Application Capture: Example Simulink • Coordination model: Time-driven, idealized timing B1 ts=4 B3 B4 B2 ts =1 ts =3 ts =2 B4 B1 B3 B2 t sim 0 1 2 3 4 5 6 7 8 9 Coordination abstraction Host model • capture relative rates and • Use RTW to generate data-dependencies into C-code dataflow representation • Use target-specific • relax timing constraints compiler Marek Jersak, TU Braunschweig 26 13

Recommend


More recommend