The determination of upper bounds on execution times, commonly called worst-case execution times (WCETs), is a necessary step in the development and validation process for hard real-time systems. This problem is hard if the underlying processor architecture has components, such as caches, pipelines, branch prediction, and other speculative components. This article describes different approaches to this problem and surveys several commercially available tools1 and research prototypes.

/pdf/the-worst-case-execution-time-problem-overview-of-methods-2kdq3gxkoy.pdf

The worst-case execution-time problem—overview of methods and survey of tools

Until the late eighties, information processing was associated with large mainframe computers and huge tape drives. During the nineties, this trend shifted towards information processing with personal computers, or PCs. The trend towards miniaturization continues. In the future, most of the information processing systems will be quite small and embedded into larger products such as transportation and fabrication equipment. Hence, these kinds of systems are called embedded systems. It is expected that the total market volume of embedded systems will be significantly larger than that of traditional information processing systems such as PCs and mainframes. Embedded systems share a number of common characteristics. For example, they must be dependable, efficient, meet real-time constraints and require customized user interfaces (instead of generic keyboard and mouse interfaces). Therefore, it makes sense to consider common principles of embedded system design. Embedded System Design starts with an introduction into the area and a survey of specification languages for embedded systems.A brief overview is provided of hardware devices used for embedded systems and also presents the essentials of software design for embedded systems. Real-time operating systems and real-time scheduling are covered briefly.Techniques for implementing embedded systems are also discussed, using hardware/software codesign. It closes with a survey on validation techniques. Embedded System Designcan be used as a text book for courses on embedded systems and as a source which provides pointers to relevant material in the area for PhD students and teachers. The book assumes a basic knowledge of information processing hardware and software.

Embedded System Design

Traditional approaches for worst case execution time (WCET) analysis produce values which are very pessimistic if applied to modern processors. In addition, end to end measurements as used in industry produce estimates of the execution time that potentially underestimate the real worst case execution time. We introduce the notion of probabilistic hard real-time systems which have to meet all the deadlines but for which a (high) probabilistic guarantee suffices. We combine both measurement and analytical approaches into a model for computing probabilistically bounds on the execution time of the worst case path of sections of code. The idea of the technique presented is based on combining (probabilistically) the worst case effects seen in individual blocks to build the execution time model of the worst case path of the program (such case may have not been observed in the measurements). We provide three alternative operators for the combination based on whether the information of their dependency is known. Experimental evaluation of a two case study shows extremely low probabilities of the values obtained by traditional analysis.

WCET analysis of probabilistic hard real-time systems

The architecture of tools for the determination of worst case execution times (WCETs) as well as the precision of the results of WCET analyses strongly depend on the architecture of the employed processor. The cache replacement strategy influences the results of cache behavior prediction; out-of-order execution and control speculation introduce interferences between processor components, e.g., caches, pipelines, and branch prediction units. These interferences forbid modular designs of WCET tools, which would execute the subtasks of WCET analysis consecutively. Instead, complex integrated designs are needed, resulting in high demand for memory space and analysis time. We have implemented WCET tools for a series of increasingly complex processors: SuperSPARC, Motorola ColdFire 5307, and Motorola PowerPC 755. In this paper, we describe the designs of these tools, report our results and the lessons learned, and give some advice as to the predictability of processor architectures.

The influence of processor architecture on the design and the results of WCET tools

Embedded computer systems are characterized by the presence of a processor running application-specific dedicated software. A large number of these systems must satisfy real-time constraints. This paper examines the problem of determining the extreme (best and worst) case bounds on the running time of a given program on a given processor. This has several applications in the design of embedded systems with real-time constraints. An important aspect of this problem is determining which paths in the program are exercised in the extreme cases. The state-of-the-art solution here relies on an explicit enumeration of program paths. This solution runs out of steam rather quickly since the number of feasible program paths is typically exponential in the size of the program. We present a solution for this problem that does not require an explicit enumeration of program paths, i.e., the paths are considered implicitly. This solution is implemented in the program cinderella (in recognition of her hard real-time constraint-she had to be back home at the stroke of midnight), which currently targets a popular embedded processor-the Intel i960. The preliminary results of using this tool are also presented here.

Performance analysis of embedded software using implicit path enumeration

Predicting the execution time of code segments in real-time systems is challenging. Most recently designed machines contain pipelines and caches. Pipeline hazards may result in multicycle delays. Instruction or data memory references may not be found in cache and these misses typically require several cycles to resolve. Whether an instruction will stall due to a pipeline hazard or a cache miss depends on the dynamic sequence of previous instructions executed and memory references performed. Furthermore, these penalties are not independent since delays due to pipeline stalls and cache miss penalties may overlap. This paper describes an approach for bounding the worst and best case performance of large code segments on machines that exploit both pipelining and instruction caching. First, a method is used to analyze a program's control flow to statically categorize the caching behavior of each instruction. Next, these categorizations are used in the pipeline analysis of sequences of instructions representing paths within the program. A timing analyzer uses the pipeline path analysis to estimate the worst and best-case execution performance of each loop and function in the program. Finally, a graphical user interface is invoked that allows a user to request timing predictions on portions of the program. The results indicate that the timing analyzer efficiently produces tight predictions of worst and best-case performance for pipelining and instruction caching.

/pdf/bounding-pipeline-and-instruction-cache-performance-2gdiqdciip.pdf

Bounding pipeline and instruction cache performance

The use of caches poses a difficult rradeoff for architects of real-time systems. While caches provide signifreant performance advantages, they have also been viewed as inherently unpredictable since the behavior of a cache ref- erence depends upon the history of the previous refer- ences. The use of caches will only be suitable for real- time systems if a reasonably tight bound on the perfor- mance of programs using cache nzemory can be predirterl. This paper describes an approach for bounding the worst- case instruction cache performanre of large code seg- ments. First, a new method called Static Cache Sitnula- tion is used to analyze a program's control flow to stati- cally categorize the caching behavior of each instruction. A timing analyzer, which uses the Categorization informa- tion, then estimates the worst-case instruction cache per- formance for each loop and function in the program.

/pdf/bounding-worst-case-instruction-cache-performance-2i8kiplj1o.pdf

* Bounding Worst-case Instruction Cache Performance

Real-time programmers have to deal with the problem of relating timing constraints associated with source code to sequences of machine instructions. This paper describes an environment to assist users in the specification and analysis of timing constraints. A user is allowed specify timing constraints within the source code of a C program. A user interface for a timing analyzer was developed to depict whether these constraints were violated or met. In addition, the interface allows portions of programs to be quickly selected with the corresponding bounded times, source code lines, and machine instructions automatically displayed The result is a user-friendly environment that supports the user specification and analysis of timing constraints at a high (source code) level and retains the accuracy of low (machine code) level analysis.

/pdf/supporting-the-specification-and-analysis-of-timing-4e5et96fpy.pdf

Supporting the specification and analysis of timing constraints

Real-time programmers have to deal with the problem of relating timing constraints associated with source code to sequences of machine instructions. This paper describes an environment to assist users in the specification and analysis of timing constraints. A timing analyzer predicts the best and worst case bounds for these constrained portions of code. A user interface for this timing analyzer was developed to depict whether these constraints were violated or met. A user is allowed to specify timing constraints within the source code of a C program. The user interface also provides three different methods for interactively selecting portions of programs. After each selection the corresponding bounded times, source code lines, and machine instructions are automatically displayed. Users are pre vented from only selecting portions of the program for which timing bounds cannot be obtained. In addition, a technique is presented that allows the timing analysis to scale efficiently with complex functions and loops. The result is a user-friendly environment that supports the user specification and analysis of timing constraints at a high (source code) level and retains the accuracy of low (machine code) level analysis.

/pdf/timing-constraint-specification-and-analysis-3rggxyj3rh.pdf

Robert D. Arnold

Papers

Bounding pipeline and instruction cache performance

* Bounding Worst-case Instruction Cache Performance

Supporting the specification and analysis of timing constraints

Timing constraint specification and analysis