On the False Path Problem in Hard Real-Time Programs

On the False Path Problem in Hard Real-Time Programs Peter Altenbernd C-LAB D-33095 Paderborn, Germany peter@cadlab.de, http://www.cadlab.de/peter/ Abstract This paper addresses the important subject of estimating the worst-case execution time (WCET) of hard real-time programs essentially needed for further evaluation of realtime systems. Purely structure oriented methods, analysing the control flow of the program without taking into account functional dependencies, tend to overestimate the execution time. An exact solution of this NP-complete problem is impossible for larger applications. In this paper, we propose a new heuristic of finding an estimate on the WCET. It provides a reasonable trade-off between analysis results and analysis efforts: the results will still be better than purely structure oriented methods without spending too much time on finding an exact solution. For this purpose our approach does not need any user annotations except for maximum loop counts and maximum recursion depths. The actual algorithm combines pruned path enumeration with the concept of symbolic execution. 1. Introduction Predicting the execution times of programs by static timing analysis tools is a fundamental problem in hard realtime systems. It is important for system design, especially with respect to schedulability testing, (e.g. [17, 1]) which relies on the values delivered by the static timing analysis. Most of the recent work on this subject focusses on analytical methods to extract the worst-case execution time (WCET) from a given program. One simple approach to deal with the problem is to find the longest structural path in the control flow of the program, and to assume its length to be the worst-case execution time. The disadvantage of this method is that it ignores mutual exclusive control flow branches, resulting in overestimated values, as demonstrated by the example of Fig.1. Due to the two if-statements, where the second one depends on the first, the program will run either through block a and then through d, or through b and then through c. Howbegin if E < 0 then /* block a=251 */ end; condition := F ALSE; x := E + 45; else /* block b=229 */ condition := T RU E; x :=?E; if condition then /* block c=412 */ result := x DIV y; else /* block d=352 */ result := y; Figure 1. A simple example program ever, a purely structure oriented analysis would compute the worst-case execution time as M AX(a; b) + M AX(c; d) = 663, instead of 641 = M AX(a + d; b + c), the true value. Hence, the value is not given by the longest structural path (a; c), but by the longest executable path (sometimes referred to as feasible path) (b; c). In the following, we will refer to non-executable paths, like (a; c) or (b; d), as false paths (sometimes referred to as dead path), and to the problem of finding the longest executable path in a realtime program as the false path problem. The false path problem is NP-complete, i.e. for the exact solution all possible input value combinations would have to be considered, so that exact approaches are excluded from use when dealing with larger applications. In this paper, we propose a new heuristic of dealing with the false path problem without the need of user annotations on mutual exclusive control flow branches. It provides a reasonable trade-off between analysis results and analysis efforts: the results will still be better than purely structure oriented methods without spending too much time on find-

ing the exact solution. Basically our method is a combination of path enumeration with pruning (for structural analysis) and symbolic execution (for executability analysis). Our paper addresses the determination of the worst-case execution time with the following assumptions: We use the term program in the sense of a sequential program. Our method is devoted to hard real-time programs, i.e. the code to be analysed is quite restrictive: Maximum loop counts must be known in advance, as well as maximum function recursion depths. Since we deal with programs automatically generated from differential equations, we can easily fulfill these restrictions. Our analysis will run on the abstract description of the program: the control flow graph (CFG) to be generated at compile time. It is assumed that the computation time of all blocks of basic statements is known in advance. Caching and pipelining effects are beyond the scope of the paper. In this paper we will focus on worst-case times only. Our method is applicable to get the best-case times as well. The remainder of the paper is structured as follows: the next section illustrates how our approach is related to others. In Section 3, we introduce our new method of finding the longest executable path. In Subsection 3.1, our model of the control flow graph is described. Subsections 3.2 and 3.3 deal with the particular problems of loops and function calls. In Section 4 some experimental results are presented. Finally, Section 5 gives some conclusions. 2. Related Work Early work in the field of determinating the worst-case execution time focussed mainly on measuring the program runtimes on the target machine, like [9], or like the dual loop benchmark paradigm [4]. Within this method the program to be analysed is embedded into a loop, which is executed for a number of times. This way it is possible to measure a maximum/average runtime of the program. The disadvantages of this approach are obvious: the results are input dependent and the system overhead cannot be accurately determined. The simulation of the target processor including its software [5] is another non-analytical approach, which mainly suffers from the same disadvantages as the loop benchmark paradigm and additionally from the quite slow computation speed of the simulator. Approaching analytical methods, the simplest technique is to find the longest structural path in the control flow graph (e.g. [15]). As mentioned in Section 1, this method tends to overestimate the worst-case execution time, resulting in severe processor underutilisations, which is considerably improved by our method. More sophisticated analytical methods which try to find the longest executable path have to cope with the huge complexity of the false path problem. Techniques which try solve the problem exactly, like [16], are only applicable to very limited program sizes. To overcome the complexity problem, some methods, like [7], which tries to simultaneously consider functional and timing analysis, require timing annotations to be added by the user. These methods typically improve the runtime behaviour of the analysis while concurrently delivering very accurate results. Their disadvantage is that the user has to be an expert on the insights of the static timing analysis tool and of the program code. However, our approach does not need any user knowledge about the timing of the real-time program, or vice versa, i.e. it takes into consideration that many of todays real-time programs are automatically synthesised. In [12] another user-annotated method, which is based on integer linear programming (ILP), is proposed. This method is very well-suited for modelling the whole system including the processor architecture and the annotations. Nevertheless, the computational results are not better than the results of a purely structural method, where the annotations are used to manipulate the control flow graph. Furthermore, this method is only applicable to relatively small examples, since larger examples create huge ILPs, which are difficult to solve with reasonable costs. In contrast, our method is based on the control flow graph, and its heuristical behaviour guarantees its applicability to larger examples as well. Most of the recent work in the field of static timing analysis of real-time programs focusses on the impact of pipelining [11] and caching [14] strategies. Though these are also imported problems, our approach emphasises the false path problem. However, the concepts of handling pipelines and caches can be included into our method as well. There is a similar false path problem in the field of hardware development, where it is of interest to find the longest executable path in a network of logic gates. This problem was firstly addressed in 1987 [6], and proved to be NPcomplete in [13]. In contrast to the real-time field, this problem also has to deal with signal delay times, which makes it more difficult to solve. On the other hand, a digital circuit only has to deal with logic signal values (variables), and not with more complex data types as in real-time programs, which makes the problem easier to solve. Conceptionally, our heuristic is slightly similar to the digital circuit analysis of [3].

3. False Path Problem Heuristic Basically, our method is a combination of path enumeration with pruning and symbolic execution. We use a branchand-bound algorithm to perform the actual path search in the control flow graph. The algorithm is bounded at each node (block) of the search by early rejecting alternatives, which will not improve the currently best solution. Symbolic execution is a sort of simulated execution of the program. It is used to maintain a virtual memory representing current variable values, as far as they are known. It evaluates program statements concurrently to the path search algorithm. The symbolic execution will not try to evaluate each statement perfectly: It will only try its best. Our algorithm behaves heuristicly, since it is started with no knowledge about the input data values. However, values (or at least value ranges) are assigned when approaching certain branches as in if-statements, i.e. if the entrance condition for a certain branch is E < 0 for example, then it is assumed for the control flow following the branch that E is negative. This can be demonstrated by the example of Fig. 1. The path search will start with visiting block a due to the longer execution time of a compared to b. The symbolic execution will then store that E is negative. Furthermore, it will assign FALSE to condition and the value of E plus 45 to x, i.e. x is now known to be below 45. In the next step, the path search is forced to visit block d, not c, due to condition = FALSE. Using this method the false paths (a,c) and (b,d) are excluded. Hence, our heuristical symbolic execution is sufficient to avoid many false paths, though it does not take into account the input values. 3.1. Control Flow Graph Our algorithm is based on an attributed control flow graph, a directed graph G = (V; E), where the set of hierarchical vertices V represents blocks of program statements, and the set of edges E represents the actual control flow including branches. Each (hierarchical) vertex is of one of the following types: atomic, complex, function, or loop. Complex vertices are used to represent hierarchy and loop bodies, whereas atomic vertices are used to represent basic statement blocks at the lowest level. Atomic vertices are annotated by an attribute C giving the total maximum computation effort, necessary to run the statements inside. Function vertices are further decomposed by an internal lower-level complex vertex, representing the function body. Similarly, loop vertices are further decomposed by an internal lower-level complex vertex, representing the loop body. An example involving all mentioned vertex types is shown in Fig. 2. complex atomic atomic atomic atomic function complex atomic loop complex Figure 2. Example of a control flow graph 3.2. Loops Since we are dealing with hard real-time systems, we presume that loops behave deterministically, i.e. the maximum loop count is known in advance. This is quite restrictive, but our concern are hard-real time programs automatically generated from differential equations, so that we can easily fulfill this restriction. During the analysis, loops are treated as follows: whenever the algorithm reaches a loop vertex, it will first analyse the loop body (i.e. compute the worst-case execution time of the loop body) before continuing with the rest of the current level. The loop body analysis is repeated either until the symbolic execution evaluates the termination condition to true, or until the maximum loop count is reached. Variables which have been set inside of the loop have to be cleared after processing the loop. If not done so, all possible combinations of processing all loops would have to be considered. This is important when the variable is evaluated at a later instant outside the loop. Similarly, variables, which are embedded in an if-statement adn which have been set inside of the loop, are cleared at the end of each loop. If not done so, all possible combinations of processing this loop would have to be considered. This is important when the variable is evaluated at a later instant inside the loop. A loop vertex is annotated by an attribute M giving the maximum loop count and by an attribute C giving the maximum costs for evaluating the loop exit condition.

3.3. Function Calls Function or procedure calls are treated with the help of the function vertices. They express the hierarchical structure of the real-time program. For recursive functions the maximum recursion depth must be known in advance for the same reasons as the maximum loop count. During the worst-case-execution-time analysis, function vertices are handled by first analysing the function body before continuing with the rest of the current level. Recursive functions are only analysed as often as stated by the maximum recursion depth. Function vertices are annotated by an attribute C giving the maximum costs for calling (not executing) the function. Recursive functions are additionally annotated by an attribute M, the maximum recursion depth. 3.4. The Algorithm example condition:=false x:=e+45 if E < 0 C=30 mdts=663 if condition condition:=true x:= E C=221 mdts=633 C=199 mdts=611 result:=x/y C=382 mdts=382 C=30 mdts=412 result:=y C=322 mdts=322 Figure 3. Control flow graph of the example program The control flow graph will be extracted at compile time from the real-time program, including all vertex attributes described in the previous subsections. Then, in a preprocessing step, the maximum-delay-to-sink (mdts) values are computed for all vertices. The mdts-value of a vertex is the length of the longest structural path from the vertex to a vertex with no successor. The control flow graph of the example of Fig. 1 is shown in Fig. 3 including all mdts-values. The mdts-value of the source vertex of a graph is equal to the length of the longest structural path of the program. The mdts-values are needed to bound the path enumeration as far as possible. These values help to detect quite early whether an alternative leads to a better solution than the current best or not. The computational costs for the mdts-values grow proportional to the number of vertices, using a breath-firstsearch technique. function WCET(integer wcet, vertex V, memory M) begin! (memory, integer) switch (V:type) case atomic: for all statements S i in V do M.eval(S i); wcet += V:C; break; case loop: M.eval(exit condition); wcet += V:C while (not loop end(m, V:M)) do /* V =loop body */ (M; wcet) = WCET(wcet; V 0 ; M); wcet += V:C; M.eval(exit condition); break; case function: if (not max recurs depth(v:m)) then /* V =function body */ (M; wcet) = WCET(wcet; V 0 ; M); wcet += V:C; M.eval(call stmt); break; end switch; if (no successor(v )) then max := MAX(max, wcet); else M.eval(branch condition); for all successors V i of V do if (M.possible(V i) and wcet + V i:mdts > max) /* branch access and still better solution */ then WCET(wcet, V i, M); /* recursion */ return (M, wcet); end; function main() begin max := 0; /* current maximum wcet */ WCET(0, program, free memory); end. Figure 4. The WCET algorithm A pseudo-code of the simplified algorithm is given in Fig. 4. It is basically a recursive branch-and-bound algorithm enriched by the concept of symbolic execution, which is represented by the function M.eval(S). This function is used to transfer the result of the execution of a statement S into the virtual memory M. The recursive function WCET(), representing the worst-case-execution-time analysis, returns a tuple consisting of the virtual memory and the resulting worst-case execution time. The edges at each vertex are sorted in descending order by the mdts-values of the corresponding vertices. This gives the algorithm the

capability to find quite long paths very early. The mdtsvalues are further used to bound the current branch decision: whenever the current worst-case execution time wcet plus the mdts-value of the considered edge is less than the current maximum worst-case execution time max, it is not necessary to further explore the vertices following this edge. The algorithm is demonstrated in a more detailed manner than before by the example of Fig. 3. It starts by processing the if E<0 vertex, i.e. 30 is assigned to wcet. It carries on with the left branch of the vertex due to its greater mdtsvalue, i.e. E<0 is stored in M, the variables condition and x are set respectively, and 251 is assigned to wcet. The next vertex to process is if condition (wcet:=281). condition evaluates to FALSE, so that the right branch is processed next (wcet:=603). The maximum is set to 603. The algorithm steps back now to the beginning if E<0, i.e. the memory is cleared, and wcet is 30 again. Then the algorithm tries to visit the right branch, which is possible since the bound condition of the algorithm allows to carry on, i.e. E0 is stored in M, the variables condition and x are set respectively, and 229 is assigned to wcet. The next vertex to process again is if condition (wcet:=259). condition evaluates to TRUE, so that the left branch is processed next, i.e. wcet is set to 641, which is the final result. 4. Experimental Evaluation id #if #loop mdts wcet CPU reduce [s] factor GespAut 12 0 653 646 8-1.1% Pendel 13 0 3579 3523 59-1.6% AZsphp6 12 0 1366 1227 98-10.2% Trajec 15 0 123 61 113-50.4% R3Tempo 15 0 407 401 498-1.5% dhrystone 14 5 41503 36003 70-13.3% Figure 5. Experimental results Some experimental results are shown in Fig.5, comparing the results of purely structural analysis (row mdts) with our new method (row wcet). The first five examples are mechatronical applications, all having no loops inside. The last example ( dhrystone ) is usually taken for benchmarking compiler optimisations, i.e. the dhrystone program does not compute anything meaningful. The effectivity of our algorithm highly depends on the internal structure of the considered example, i.e. the estimated bound on the worstcase execution time is reduced to between 1% and 50%. After intensively studying the code of the considered examples, we can state that in all cases our estimated value is equal to the true value of the worst-case execution time to be delivered by an exact method. The computational effort of our method mainly grows with the number of if-statements (O(2 #if )) and with the number of loop counts. A check on executability of a certain path is about linear to the CFG size. The large grows in complexity due to if-statements limits the applicability of our current algorithm to about 15 to 20 if-statements. However, this can easily be overcome by using the k-longest path search [18] instead of path enumeration as in our case, in connection with the concepts on executability analysis presented in this paper. Then the path search complexity is only O(k (jv j + jej) log k). The use of this concept is as follows: first, the k longest paths (k=#if should be adequate) are searched for. Then the longest of these paths is checked for executability using the concept of symbolic execution. If this is a false path, it will be continued with the second longest and so on, until an executable path is found. Considering the examples of Fig. 5 it is likely to find an executable path within the k longest ones. The estimate on the worst-case execution time is the length of the first executable path. If all k longest paths are false, then the worst-case execution time is bound by the length of the k-longest path. 5. Conclusions and Future Work This paper is a contribution to the important subject of estimating the worst-case execution time of hard real-time programs essentially needed for further evaluation of realtime systems. It especially addresses the false path problem, i.e. it overcomes the problem of overestimation of purely structure oriented methods. Due to the huge complexity of the false path problem, our method does not try to find an exact solution. It provides a reasonable trade-off between analysis results and analysis efforts: the results will still be better than purely structure oriented methods without spending too much time on accuracy. For this purpose our approach does not need any user annotations except for maximum loop counts and maximum recursion depths. The actual algorithm combines pruned path enumeration with the concept of symbolic execution. Our future work will mainly deal with changing the path search strategy from path enumeration to k-longest path search as suggested in Section 4. Since the runtime behaviour of our method highly depends on the number of if-statements, it is desirable only to consider if-statements related on former if-statements during the path search. To identify parts of a program whose executions are correlated with one another, compiler techniques, like [10], can be included in our method. Furthermore, the effects of caching and pipelining are important to be considered as well. The work presented in this paper will be used in the mechatronic project METRO granted by the German Ministry of Education and Research (BMBF). Within this

project our new technique will be used to support the mapping of periodic hard real-time tasks to a parallel computer [2], resulting in the configuration of an operating system [8]. References [17] K. Tindell. Adding Time-Offsets To Schedulability Analysis. Report YCS221, Department of Computer Science, University of York, 1994. [18] S. H. C. Yen, D. H. C. Duand, and S. Ghanta. Efficient Algorithms for Extracting the K Most Critical Paths in Timing Analysis. In Proceedings of the 26th Design Automation Conference, pages 649 654, 1989. [1] P. Altenbernd. Deadline-Monotonic Software Scheduling for the Co-Synthesis of Parallel Hard Real-Time Systems. In Proceedings of the European Design and Test Conference, pages 190 195, 1995. [2] P. Altenbernd and C. Ditze. Allocation of Periodic Hard Real-Time Tasks. In Proceedings of the IFAC/IFIP Workshop on Real-Time Programming, 1995. [3] P. Altenbernd and J. Strathaus. Solving the Path Sensitization Problem in Linear Time. In Proceedings of the European Design Automation Conference, pages 378 382, 1992. [4] N. Altman and N. Weideman. Timing Variations in Dual Loop Benchmarks. CMU/SEI-87-TR-22, Software Enginieering Institute, Carnegie Mellon University, 1987. [5] C. N. Arnold. Using the ETA System Multiprocessor Simulator to Prepare for the ETA. I/O, 1(1):9 12, 1987. [6] J. Benkoski, E. VandenMeersch, L. Claesen, and H. DeMan. Efficient Algorithms for Solving the False Path Problem in Timing Verification. In Proceedings of International Conference on Computer Aided Design, pages 44 47, 1987. [7] R. Chapman. Static Timing Analysis and Program Proof. Ph.D. Thesis, Computer Science, University of York, 1995. [8] C. Ditze. DReaMS Concepts for a D)istributed Rea)l-Time M)anagement S)ystem. In Proceedings of the IFAC/IFIP Workshop on Real-Time Programming, 1995. [9] P. Gopinath and R. Gupta. Applying Compiler Techniques to Scheduling in Real-Time Systems. In IEEE Real-Time Symposium, pages 247 256, 1990. [10] R. Gupta and P. Gopinath. Correlation Analysis Techniques for Refining Execution Time Estimates of Real-Time Aplications. In IEEE Workshop on Real-Time Operating Systems and Software, pages 54 58, 1994. [11] M. G. Harmon, T. P. Baker, and D. B. Whalley. A Retargetable Technique for Predicting Execution Time of Code Segments. Journal of Real-Time Systems, 7(x):159 182, 1994. [12] Y.-T. S. Li and S. Malik. Performance Analysis of Embedded Software Using Implicit Path Enumeration. In Proceedings of the 32th Design Automation Conference, pages 456 461, 1995. [13] P. C. McGeer and R. K. Brayton. Integrating Functional and Temporal Domains in Logic Design. Kluwer, 1991. [14] M. K. Milligan and H. G. Cragon. Techniques to Support the Use of Cache Memory in Hard Real-Time Systems. In Proceedings of the IFAC/IFIP Workshop on Real-Time Programming, 1995. [15] A. Mok. Evaluating Tight Execution Time Bounds of Programs by Annotations. In IEEE Workshop on Real-Time Operating Systems and Software, pages 74 80, 1989. [16] C. Y. Park. Predicting Deterministic Executions Times of Real-Time Programs. Seatle 98195, University of Washington, 1992.