WCET analysis

The soundness of real-time systems not only depends on the exactness
of the results but also on their delivery according to given timing
constraints. Real-time schedulers need an estimation of the worst-case
execution time (i.e., the longest possible run time) of each process
to guarantee that all the deadlines will be met. In addition to be
necessary to guarantee the correctness of soft- and hard-real-time
systems, the worst-case execution time is also useful in multimedia
systems where it can be used to better distribute the computing
resources among the processes by adapting the quality of service to
the current system load.

This dissertation presents a set of static compile-time analyses to
estimate the worst-case execution time of Java processes focusing on
the approximation of the WCET of fairly large soft-real-time
applications on modern hardware systems.

In a first phase the program is analyzed to extract semantic
information and to determine the maximal (and minimal) number of
iterations for each basic block, by possibly bounding every cyclic
structure in the program. As a first step, the semantic analyzer,
embedded in an ahead-of-time bytecode-to-native Java compiler,
performs an abstract interpretation pass of linear code segments
delimiting the set of possible values of local variables at a given
program point and discovering a subset of the program's infeasible
paths.  This step is followed by a loop-bounding algorithm based on
local induction variable analysis that, combined with structural
analysis, is able to deliver fine-grained per-block bounds on the
minimum and maximum number of iterations. To resolve the target of
method calls the compiler performs a variable type based analysis
reducing the call-graph size.

In a second phase the duration of the different program's instructions
or basic blocks is computed with respect to the used hardware platform
and the computational context where the instructions are executed.
Modern systems with preemption and modern architectures with
non-constant instruction duration (due to pipelining, branch
prediction and different level of caches) hinder a fast and precise
computation of a program's WCET.  Instead of simulating the CPU
behavior on all the possible paths we apply the principle of locality,
limiting the effects of a given instruction to a restricted period in
time and allowing us to analyze large applications in asymptotically
linear time.

We describe the effectiveness in approximating the worst-case
execution time for a number of programs from small kernels and
soft-real-time applications.

A fundamental area of software engineering that remains a challenge for software developers is the delivery of software with the minimum of remaining defects. While progress is constantly being made in the provision of static analysis tools to partly address this problem, the complementary dynamic testing approach, which remains an essential technique in the software industry for the verification and validation of software, has received less attention. Within the software testing activity, the actual generation of test data for the purpose of automated software testing is still mainly a manual task. We present CSET (C Symbolic Execution Tool) which automatically generates test data from C source code to fulfil code coverage criteria. CSET implements the symbolic execution technique with an intermediate path traversal conditions checker and a test data generation facility. We examine how the traditional problems associated with the symbolic execution technique have been overcome using Logic Programming and Constraint Logic Programming (CLP). The approach used to handle pointer manipulations is detailed. Interprocedural results on previously published sample code and industrial embedded C code with pointers are presented.

The most significant difference distinguishing real-time systems from other computer systems is the importance of correct timing behaviour. Each hard real-time task has a computation deadline1 associated with it; the deadline has to be met, otherwise the real-time system fails. This con- straint must always hold, even in the worst case, i.e. when the task's execu- tion takes a maximum amount of run time. It is therefore obvious that the maximum execution time, or the maximum duration2, of a task is of great importance for the construction and validation of real-time systems.
In many classic articles about scheduling in real-time systems, the maxi- mum execution time is assumed to be known; unfortunately this is often not the case. The deadline is something an application programmer can easily specify, because it is usually part of the real-time implementation, but the duration is very hard to compute: it is often guessed, with the aid of experience, and then adjusted according to the results of various tests.
A standard, empiric method, consists in actually running a program on representative test data, and measure its execution time. While this approach is clearly useful, it has the same flaws as debugging: the test set may not cover the whole input-domain, maybe leaving the one yielding to the worst execution time untested.

The ideal solution would be a profiler/analyser that could automati- cally determine the maximum execution time of a given program at compile time, but unfortunately this will remain a chimera. The mod- ern operating systems’ and processors’ complexity, and theoretical limitations, prevents us from computing the exact and deterministic maximum duration of a given process.
The goal of this work, is to empower the user with an automatic tool that computes a good approximation of the maximum execution time of a given task. The profiler/analyser should automatize and speed-up one of the most error-prone developing phase of a real-time applica- tion, thus reducing the probability of faults.
We strongly believe, that the user interaction, in tools for predicting the timing behaviour of programs coded in high level languages, should be minimized. Real-time systems are used in research and industry fields, where noncomputer scientists are the vast majority of the users and programmers. To expect from the user a complete knowledge of the underlying system and hardware is not compatible with the goal of XOberon, which is about providing a framework for implementators looking for a rapid application development tool.
The work is divided in two major and distinct parts. First, we perform a syntactical analysis of the program source in order to retrieve its structure, using compiler optimization techniques. Particular atten- tion is paid to the automatic computing of the number of iterations within a loop, allowing the transformation of the program’s data flow into an acyclic graph. In a second phase, the processor architecture is analysed for computing the length of a code block. The instruction length is refined with run-time statistical information, to bring the worst-case results to values that one can expect when actually run- ning the program.

We present a technique to approximate the worst-case execution time that combines structural analysis with a loop-bounding algorithm based on local induction variable analysis. Structural analysis is an attractive foundation for several reasons: it delivers better bounds on the number of executions for each basic block than previous approaches, its complexity is well understood, and it allows the compiler to easily work on Java bytecode without requiring access to the original program source. There are two major steps. We first compute (min, max) bounds on the number of iterations for each loop. Then we use precise structural information to propagate these bounds to the whole control-flow graph and compute a bound for each basic block. Such a fine-grained result eases the identification of infeasible paths and improves the approximation of the worst-case execution time of a function or method. This analysis was successfully implemented in an ahead-of-time Java bytecode to native compiler and produces input for a worst-case execution time estimator. We describe the effectiveness in reducing the worst-case execution time for a number of programs from small kernels and soft-real-time applications.

The control system of many complex mechatronic products requires for each task the Worst Case Execution Time (WCET), which is needed for the scheduler's admission tests and subsequently limits a task's execution time during operation. If a task exceeds the WCET, this situation is detected and either a handler is invoked or control is transferred to a human operator. Such control systems usually support preemptive multitasking, and if an object-oriented programming language (e.g., Java, C++, Oberon) is used, then the system may also provide dynamic loading and unloading of software components (modules). Only modern, state-of-the art microprocessors can provide the necessary compute cycles, but this combination of features (preemption, dynamic un/loading of modules, advanced processors) creates unique challenges when estimating the WCET. Preemption makes it difficult to take the state of the caches and pipelines into account when determining the WCET, yet for modern processors, a WCET based on worst-case assumptions about caches and pipelines is too large to be useful, especially for big and complex real-time products. Since modules can be loaded and unloaded, each task must be analyzed in isolation, without explicit reference to other tasks that may execute concurrently. To obtain a realistic estimate of a task's execution time, we use static analysis of the source code combined with information about the task's runtime behavior. Runtime information is gathered by the performance monitor that is included in the processor's hardware implementation. Our predictor is able to compute a good estimation of the WCET even for complex tasks that contain a lot of dynamic cache usage, and its requirements are met by today's performance monitoring hardware. The paper includes data to evaluate the effectiveness of the proposed technique for a number of robotics control kernels that are written in an object-oriented programming language and execute on a PowerPC 604e-based system.

Due to the complexity of today’s micro-architectures, the micro-architectural analysis usually constitutes the most time-consuming step in worst-case execution time (WCET) analysis. In this paper, we investigate the influence of the design of the load-store unit (LSU) in the PowerPC 7448 on WCET analysis. To this end, we introduce a simplified variant of the existing design of the LSU by reducing its queue sizes. Using AbsInt's aiT WCET analysis toolchain we determine the resulting WCET bounds and analysis times. For the modified version of the LSU with reduced queue sizes, analysis time is reduced by more than 50% on a set of benchmarks from the Mälardalen suite, while there is little change in the WCET bound.

Hard and soft real time systems require, for each process, the worst-case execution time (WCET), which is needed by the scheduler's admission tests and subsequently limits a task's execution time during operation. A worst-case execution time analysis is usually performed in two distinct steps: first the program is analyzed to extract semantic information and determine maximal bounds on the number of iterations for each basic block. In a second step the duration of the different program's instructions is computed with respect to the used hardware platform. Modern systems with preemption and modern architectures with non-constant instruction duration (due to pipelining, branch prediction and different level of caches) hinder a fast and precise computation of a program's WCET. We present a technique to approximate the instruction duration on modern processors using precise block bounds. Instead of simulating the CPU behavior on all the possible paths we apply the principle of locality limiting the effects of a given instruction to a restricted time allowing us to analyze large applications in linear time.

Testing is the most important Quality Assurance (QA) measure which consumes a significant portion of budget, time and effort in the development process. For real time systems, temporal testing is as crucial as functional testing. An important activity in dynamic testing is the test case design. Evolutionary testing has shown promising results for the automation of test case design process at a reasonable computational cost. The disadvantage of evolutionary testing is that its time consuming and it depends on the parameter settings. Evolutionary algorithms can be used to find the optimal parameter settings of another evolutionary algorithm. In this research paper, a Meta level Evolutionary Algorithm (Meta-EA) is utilized to tune the parameters of evolutionary algorithm for Worst Case Execution Time (WCET) analysis. A number of experiments have been conducted for analysis using X32 (32-bit soft processor core implemented on FPGA) as the target hardware. Famous sorting algorithms have been used as programs under test for these experiments. Results have shown an average improvement of 25% in finding WCET by an evolutionary algorithm with tuned parameters compared to evolutionary algorithm with standard parameters. Furthermore, performance gap was found to be increasing with increase in test input size.

Current processors are optimized for average case performance, often leading to a high worst-case execution time (WCET). Many architectural features that increase the average case performance are hard to be modeled for the WCET analysis. In this paper we present Patmos, a processor optimized for low WCET bounds rather than high average case performance. Patmos is a dualissue, statically scheduled RISC processor. The instruction cache is organized as a method cache and the data cache is organized as a split cache in order to simplify the cache WCET analysis. To fill the dual-issue pipeline with enough useful instructions, Patmos relies on a customized compiler. The compiler also plays a central role in optimizing the application for the WCET instead of average case performance.