Timing Analysis of Real-Time Software

Size: px

Start display at page:

Download "Timing Analysis of Real-Time Software"

Joleen Paulina McKenzie
7 years ago
Views:

1 Timing Analysis of Real-Time Software Raimund Kirner Vienna University of Technology Austria This is joint work with Peter Puschner and the CoSTA and ForTAS project teams.

2 From RTS Design to Implementation T1 Task set with precedence constraints and deadline t T2 T4 T3 T1 T2 T3 T4 Can we guarantee that: response time < deadline? Task sequence: execution times, response time t Grenoble, QA'09 2

T4 Can we guarantee that: response time < deadline?

3 WCET: Timing Analysis Abstraction In general it is infeasible to model all possible execution scenarios and combinations of task execution times T1 T2 T3 T4 T1 T3 T2 T4 T1 T2 T3 T4 Ti Ti xt < WCET xt = WCET WCET analysis abstracts the different execution times of each task to one single value WCET bound T1 T2 T3 T4 t Grenoble, QA'09 3

T4 T1 T2 T3 T4 Ti Ti xt < WCET xt = WCET WCET analysis abstracts the different

4 WCET vs. calculated WCET bound frequency BCET WCET WCET Bound t Grenoble, QA'09 4

5 Remarks on WCET Analysis Computes upper bounds Bounds are application-dependent Assesses time that processor is actually executing the code WCET result is hardware-dependent WCET bounds must be safe WCET bounds should be tight Grenoble, QA'09 5

actually executing the code WCET result is

6 Requirements on WCET Analysis Tools Find feasible abstractions and analysis methods such that: 1. development effort of WCET tool is affordable 2. the calculated WCET estimates are sufficiently precise 3. analysis problems are tractable with acceptable resource requirements, and 4. the WCET tool is easy to use Acceptance depends on application domain Tradeoffs required: there is no single WCET analysis technique that is well-suited for all application domains!! Grenoble, QA'09 6

analysis problems are tractable with acceptable resource requirements, and 4.

7 The Path Problem The path problem: calculate a description or enumeration of the (in)feasible paths of a program Any brute-force approaches like executing or simulating the program with all possible input data are intractable (the different values of input data are even more than different paths exist) Problem is shifted to the user: request for manual path descriptions (requires experts, high effort, is error-prone) Program analyzes with right abstractions help to reduce the needed manual code annotations. Grenoble, QA'09 7

are even more than different paths exist) Problem is shifted to the user: request for manual path descriptions (requires experts,

8 Program Annotations for WCET Analysis Explicit flow information required to guide WCET analysis: intractable program complexity description of execution modes or input data 1 f m1 == [N (N+1)/2] f SCOPE scope { for (i=0; i<n; i++) { maximum N iterations; for (j=0; j<i; j++) { maximum N iterations; marker m1; } } restriction m1 == N (N+1) / 2; } loop bound loop bound flow variable linear flow constraint Grenoble, QA'09 8

scope { for (i=0; i<n; i++) { maximum N iterations; for (j=0; j<i; j++) { maximum N iterations; marker

9 Challenge: Correctness of Flow Information after Code Optimization for (i=0; i<n; i++) maximum 10 iterations { f(i); } additional knowledge assumed: N 10 (flow fact given as code annotation) loop unrolling (unrolling factor 3) for (i=0; i<(n-2); i=i+3) { f(i); f(i+1); f(i+2); } for (;i<n; i++) { f(i); } Q: what flow information is known of the transformed code? Grenoble, QA'09 9

loop unrolling (unrolling factor 3) for (i=0; i<(n-2); i=i+3) { f(i); f(i+1); f(i+2); } for

10 Challenge: Correctness of Flow Information after Code Optimization for (i=0; i<n; i++) maximum 10 iterations { f(i); } additional knowledge assumed: N 10 (flow fact given as code annotation) loop unrolling (unrolling factor 3) scope { for (i=0; i<(n-2); i=i+3) maximum 3 iterations { } marker m1; f(i); f(i+1); f(i+2); } for (;i<n; i++) maximum 2 iterations { marker m2; f(i); flow variable flow variable } restriction 3*m1 + m2 <= 10; linear flow constraint Automatic update of flow information in parallel to code transformation loop bound loop bound Grenoble, QA'09 10

{ } marker m1; f(i); f(i+1); f(i+2); } for (;i<n; i++) maximum 2 iterations { marker m2; f(i); flow variable flow variable } restriction 3*m1

11 Universal Flow-Information Update We developed a framework that allows to update flow information for arbitrary code transformations using rules composed of the following operations: Update of loop bound information ( L ): (create, modify, or delete loop bound information) Update of flow constraints ( R ): (transform terms of the form const flowvariable of a linear flow constraint into a new term respectively a sum of terms, creation of new flow constraints) Grenoble, QA'09 11

modify, or delete loop bound information) Update of flow constraints ( R ): (transform terms of the form const

12 Example: Loop Unrolling (3 Times) L1 A?:? B 1 L1 A 0:10 B 2 B C B 3 C S L2 D?:? B 4 E Grenoble, QA'09 12 S

13 Example: Loop Unrolling (3 Times) L1,0:10 L L1,0:3, L2,0:2 L1 A B 1 0:3 L1 A B C S 0:10 Σ 3 L2 B 2 B 3 C D 0:2 = B 4 n f AS R n f DS E n f AB R 3n f A B1 + n f DB4 Grenoble, QA'09 13 S

14 Universal Flow-Information Update Advantages: Manual code annotations: Reduced cognitive complexity (no need anymore to annotate machine code) Automatic calculation of flow information: Platform-independent calculation with reduced effort (information more explicit available at source code) Grenoble, QA'09 14

Automatic calculation of flow information: Platform-independent calculation

15 The State Explosion Problem Processor behavior modeling faces the problem of state explosion instruction timing depends on context (execution history) caches, pipelines, etc. even, when using the timing relevant dynamic processor state (TRDPS) The desired solution: decompose the timing analysis problem using divide and conquer Grenoble, QA'09 15

etc. even, when using the timing relevant dynamic processor state (TRDPS) The desired

16 Series Decomposition Analysis on control-flow graphs instead on the set of execution traces Grenoble, QA'09 16

17 Parallel Composition The execution time T(I,s) of an instruction sequence I depends on the TRDPS s: Grenoble, QA'09 17

18 Parallel Composition (TRDPS Partitioning) Partitioning the TRDPS between HW component A and HW component B: TRDPS: A B Example: A cache state B pipeline state Grenoble, QA'09 18

19 Is it that simple? Example Using Newton s of Timing world Anomalies view together with an inadequate observation system may cause underestimation of the timing effects at a local system! Grenoble, QA'09 19

20 Pitfall: Series Timing Anomalies Grenoble, QA'09 20

21 Pitfall: Parallel Timing Anomalies Grenoble, QA'09 21

22 Pitfall: Parallel Timing Anomalies Grenoble, QA'09 22

23 Pitfall: Parallel Timing Anomalies Grenoble, QA'09 23

24 Pitfall: Parallel Timing Anomalies Grenoble, QA'09 24

25 Example of TA-S-A and TA-P-A out-of-order pipeline + cache + data dependencies: Grenoble, QA'09 25

26 Example of TA-S-I and TA-P-I out-of-order pipeline + cache + data dependencies: Grenoble, QA'09 26

27 Our Contribution so far against the State Explosion Problem Providing a precise definition of Timing Anomalies (formal but without unnecessary details) Formalizing the different types of decomposition techniques for WCET analysis Proofs of which types of TAs are incompatible with which type of decomposition technique [Kirner,TR ], [Kirner,ECRTS 09] Grenoble, QA'09 27

28 Measurement-Based Timing Analysis Research project: ForTAS (Formal Timing Analysis Suite) Cooperation with TU Darmstadt Learning the Hardware Timing Model by systematic execution time measurements Grenoble, QA'09 28

29 The ForTAS Refinement Loop Testing for Timing Analysis Program Test Cases Model SUT Expected Time System (ETS) Measured Timed System (MTS) Environment Richer timing information than just WCET: probabilistic timing model Grenoble, QA'09 29

30 The Next Steps: Getting Out of the Complexity Mess Take a pro-active approach to advance timing analysis: construction of embedded systems that support: Predictability (with reasonable margins) Composability Scalability Predictable access to shared resources Timing-predictability requires a HW/SW co-design ( patterns of predictability ). Grenoble, QA'09 30

31 Thank You! Grenoble, QA'09 31

HVM TP : A Time Predictable and Portable Java Virtual Machine for Hard Real-Time Embedded Systems JTRES 2014

HVM TP : A Time Predictable and Portable Java Virtual Machine for Hard Real-Time Embedded Systems JTRES 2014 : A Time Predictable and Portable Java Virtual Machine for Hard Real-Time Embedded Systems JTRES 2014 Kasper Søe Luckow 1 Bent Thomsen 1 Stephan Erbs Korsholm 2 1 Department of Computer Science Aalborg