Static Timing Analysis

Static timing analysis techniques obtain the execution time bounds by combining the task code with an abstract system model [44, 106]. Under the assumption that the sys- tem model is correct, static timing analysis provides a safe estimate for a task’s execution bounds [25]. There are various phases that can be used to acquire WCET and BCET esti- mates. These include value analysis, control flow analysis, processor-behaviour analysis, estimate calculation and symbolic simulation.

Value Analysis

A value analysis is used to identify the memory addresses a task might require access to during its execution [106]. The purpose of determining the effective addresses of a task is to extract information regarding the amount of time required to perform each memory access. In their approach, Ferdinand et al. [44] perform value analysis by calculating an interval of possible values for each processor register. Having calculated the effective address range, it is possible to identify some infeasible execution paths, further informing the subsequent stages of the timing analysis.

Control-flow Analysis

Another method used for the evaluation of WCET is the analysis of execution paths in order to gather information about them [106]. This is referred to as Control-flow Analysis (CFA). A key requirement of hard real-time systems is that every job of a task must terminate. This implies that there is a finite set of possible execution paths, some of which are not feasible. In general, this distinction is challenging, however it is possible to eliminate some paths from the analysis. This results in having to analyse a superset of the exact set of tasks, which still returns a safe WCET estimate.

An example of CFA is presented by Engblom et al. [36], using an automatic flow analysis based on abstract interpretation. Specifically, run-time behaviour properties are extracted by interpreting the program using abstract values instead of concrete ones, as well as using abstract semantics. Using this method, the program can be proven to be safe with respect to its run-time behaviour, provided that the abstraction of values and semantics are also safe. The analysis is performed on intermediate code representation, which suggests that the possible flows are identified in the executed code [48].

Processor-behaviour Analysis

The timing behaviour of the hardware that the code is running on must also be taken into consideration when performing timing analysis. As identified in Section 2.1, it is a difficult undertaking, especially with advanced processors, due to the timing behaviour being dependent on the execution history. This requires for processor behaviour analysis to improve the accuracy of the WCET estimates by including the hardware’s properties with the task’s source code [106]. The processor’s occupancy state is analysed for all execution paths of the task in question.

Cousot P. and Cousot R. [28] introduce the notion of abstract interpretation. Abstract interpretation uses approximate semantics of the underlying structure of computations in order to obtain some information about the program behaviour without actually ex- ecuting it. The principles of abstract interpretations are used in processor behaviour analysis. In general, with processor behaviour analysis an abstract processor model is used, which overestimates the timing requirements of each instruction. The overesti- mate is to ensure the calculation of safe WCETs. An invariance about these states is calculated using the results of the analysis. On relatively simple processors with some

2.1. Timing Predictability

(a) Control-flow

graph with timing. (b)tion.Path-based calcula- (c)IPET-based calculation.

(d)Tree-based calculation.

Figure 2.2: Different calculation methods [37].

performance features the analysis can be performed in a modular manner, where differ- ent processor features are analysed in isolation before combining the findings. In their paper, Heckmann et al. [50] argue that a modular approach is not suitable for more complex processor architectures because the high level of dependency of the different processor components require large safety margins during the analysis. A direct result of these conservative margins is a largely overestimated WCET, which is often not useful in practice.

Estimate Calculation

Bound calculation is used to produce an estimate of the WCET using the upper bound of the results of value analysis, control flow analysis and processor-behaviour analysis [37,

106]. As stated by Ermedahl [37], the WCET calculation methods are split in three main categories: tree-based, path based and Implicit Path Enumeration Technique (IPET). Examples of these are illustrated in Figure 2.2.

Tree-based calculation is performed by first generating a control-flow graph, whose nodes contain timing information. An example of a control-flow graph is shown in Figure 2.2a. In order to obtain timing timing information for the whole program, a bottom-up traversal of the control-flow graph is performed, as shown in Figure 2.2d. Although this approach is computationally cheap, it is not able to deal with dependen- cies between statements and with unstructured, possibly optimised code.

Path-based calculation methods produce a WCET estimate by calculating the max- imum execution time of all the identified possible execution paths. This approach is generally straightforward, unless the code has loops. In the case of a loop the WCET of the loop’s body is calculated. The body’s WCET is then combined with the loop’s flow information to obtain the overall WCET. An example of this approach is shown in Figure 2.2b.

IPET was first introduced by Li and Malik [66] as an efficient method for producing the execution time bounds of a program running on a given processor. With IPET, the WCET estimates are calculated by combining the execution time bounds of the basic blocks and the program flow into linear constraints. Every block in the control-flow graph of the task is allocated a time coefficient (tentity) and a count variable (xentity) [106]. The time coefficient represents the upper time bound of the entity. The count variable the maximum number of times the entity will be executed. WCET is then estimated by calculating the sum of products of the time coefficients and count variables of each entity (∑i∈entitiesxiti).

Symbolic Simulation

With a symbolic simulation approach the WCET is calculated by running the task on an abstract processor model [106]. No input is used during the task’s execution, which requires a combination of control-flow analysis, processor behaviour analysis and bound calculation. A drawback of this approach is that the time required for the time bound estimates to be calculated is proportional to the task’s execution time.

2.1. Timing Predictability C-Source Analysis phase Measurement phase Calcula�on phase WCET bound Analyser tool Execu�on �me measurement framework Calcula�on tool

Figure 2.3: The three phases of measurement-based analysis [104].