Knowing the Worst-Case Execution Time (WCET) of a program is necessary when designing and verifying real-time systems. The WCET depends both on the program ow (like loop iterations and function calls), and on hardware factors like caches and pipelines.

Current development tools for embedded systems donot efficiently support the timing aspect of embedded real-time systems. The most important timing parameter for scheduling and system analysis is the WorstCase Execution Time (WCET) of a program. This paper presents a fast and effective WCET cal-culation method that takes account of low-level machine aspects like pipelining and caches, and high-level pro-gram flow like loops and infeasible paths. The method is more efficient than previous path-based approaches,and can easily handle complex programs. By separating the pipeline analysis from the calculation, the methodis easy to retarget. Experiments confirm that speed does not sacrifice precision, and that programs with extreme numbers of potential execution paths can be analyzed quickly.

We have used a modified C compiler to analyze a large number of commercial real-time and embedded applications written in C for 8- and 16-bit processors. Only static aspects of the programs have been studied, i.e. such information that can be obtained from the source code without running the programs. The purpose of the study is to provide guidance for the development of worst-case execution time (WCET) analysis tools, and to increase the knowledge about embedded programs in general. Knowing how real programs are written makes it easier to focus research in relevant areas and set priorities. The conclusion is that real-time and embedded programs are not necessarily simple just because they are written for small machines. This indicates that real-life WCET analysis tools need to handle advanced programming constructions, including function pointer calls and recursion. 1.# Introduction This paper describes the results of a study undertaken by the hard real-time systems...

When building an embedded real-time systems, the choice of hardware platform is very important to create an analyzable and predictable system. Also, the quality of the models of the hardware used in software tools is very important to the correctness of timing analysis and the integrity of the system.

When developing real-time systems, the worst-case execution time (WCET) is a commonly used measure for predicting and analyzing program and system timing behavior. Such estimates should preferrably be provided by static WCET analysis tools. Their analysis is made difficult by features of common processors, such as pipelines and caches.

Knowing the Worst-Case Execution Time (WCET) of a program is necessary when designing and verifying real-time systems. A correct WCET analysis method must take into account the possible program flow, such as loop iterations and function calls, as well as the timing effects of different hardware features, such as caches and pipelines. A critical part of WCET...

Worst-Case Execution Time (WCET) analysis has been around for some time now, but has so far not been much used to analyse real production codes. Here, we present a case study where static WCET analysis was used to find upper time bounds for time-critical regions in a commercial real-time operating system. We report on practical experiences from the work, like the reverse engineering required to find these regions and prepare them for the analysis. We give the results of the WCET analysis and discuss the precision. We also present some qualitative and quantitative data on the program structure of the regions. This information is useful to judge whether WCET analysis could provide any useful results for this class of real codes, without excessive manual labour. Finally, we present a “wishlist” for features of WCET analysis tools, which has emerged during the project, and comment on the feasibility of implementing these features.

Abstract. This paper introduces a set of design principles that aim to make processor architectures amenable to static timing analysis. Based on these principles, we give a design of a hard real-time processor with predictable timing, which is simultaneously capable of reaching respectable performance levels. The design principles we identify are recoverability from information loss in the analysis, minimal variation of the instruction timing, non-interference between processor components, deterministic processor behavior, and comprehensive documentation. The principles are based on our experience and that of other researchers in building timing analysis tools for existing processors.

Knowing the Worst-Case Execution Time (WCET) of a program is necessary when designing and verifying realtime systems. A correct WCET analysis method must take into account the possible program flow, such as loop iterations and function calls, as well as the timing effects of different hardware features, such as caches and pipelines. A critical

: In real-time systems, the temporal performance of the implementation is a key issue. Since this temporal performance depends not only on the functions and structure of the application software, but also on the services of the operating system, and the architecture and performance of the hardware, we argue that a node, i.e., a complete hardware software unit, is a proper unit of abstraction when building large distributed fault-tolerant real-time systems. Key words: distributed systems, real-time systems, object orientation, fault tolerance, replica determinism 1 Introduction In a hard real-time environment, the properties in the temporal domain are as important as the properties in the value domain. The object oriented design techniques will only be successful in the area of real-time systems if the design and analysis of the temporal properties of an object oriented system are supported by the object technology. The issues in the design of performance sensitive objects are yet to ...