aiT Worst-Case Execution Time Analyzers: Features

aiT takes as input:

The executable to be analyzed.
The start address of the task to be analyzed.
A simple textual description of the memories and buses of your particular microprocessor model (i.e. a list of memory areas with minimum and maximum access times) along with its clock rate.
Optional user annotations such as targets of indirect function calls, upper bounds on loop iteration counts, recursion depth, code snippets that should not be analyzed, infeasible code, etc.

Annotations are only required if the information cannot be detected automatically by aiT, e.g. for dynamic program properties. Furthermore, the amount of required annotations is dramatically reduced by several advanced techniques such as automatic loop-bound and array-call recognition.

Annotations for library functions (RT, communication) and RTOS functions can be provided by the respective developers either on source level or in separate files.

A tight upper bound of the task’s runtime.
Visualization of the analysis results providing detailed information about key timing aspects, e.g. the worst-case path or the machine state at any given program point. The visualization is generated by the award-winning aiSee graph visualization tool.
An analysis report file, providing for seamless integration with numerous software development tools.

aiT computes an upper bound of the WCET of a task. A task must be a sequentially executed piece of code, i.e. there must not be any threads, parallelism, or external events. aiT assumes no interference from the outside. Effects of exceptions, interrupts, DRAM refreshes, input/output, timers and other processors or co-processors are not reflected in the predicted runtime and have to be considered separately, e.g. via quantitative analysis.
The code of the analyzed task must have been generated by the specified compiler from the specified high-level language (normally a restricted subset of ANSI C, in selected cases C++ or ADA).
Dynamic data structures are not supported. Functions from the alloc family (such as malloc and calloc) must not occur in the analyzed code.
setjmp and longjmp statements must not be used in the analyzed code.
The standard calling conventions described by the embedded application binary interface EABI must be observed. The analysis relies on these calling conventions.
Return addresses must not be modified.
The code must not contain any task switches.

aiT directly analyzes binary executables. This means no modification of the program’s operational behavior and performance is required.
Selectable start points enable the program sections of interest to be focused on.
Interprocedural analysis enables cache and pipeline behavior to be precisely predicted taking all procedures of your task into account.
Complex interactions between cache and pipeline behavior are taken into account. For example, on some architectures the empty cache does not represent the worst-case cache configuration.
An intuitive graphical user interface puts everything right at your fingertips.
The integrated award-winning graph browser aiSee supports the visualization of the worst-case program path and enables interactive inspection of all pipeline and cache states at arbitrary program points.
aiT can be combined with other analyzers from AbsInt (e.g. StackAnalyzer for stack usage analysis) in a single intuitive user interface.
aiT supports tight integration with many state-of-the-art development tools, such as SCADE, ASCET, and SymTA/S.
The analyzer can also be run in batch mode, enabling seamless integration into established toolchains.
The computed WCET bounds are valid for all possible inputs and each execution of a task under any circumstances. Manually determining worst-case inputs is a thing of the past.

The worst-case execution time of each task in a real-time system has to be known prior to its execution. In event-triggered or periodic systems (e.g. RMA) it is required for schedulability analysis, in time-triggered systems (e.g. TTA, FlexRay,…) it is required for determining a static schedule.

aiT WCET Analyzers can replace the error-prone methods based on measuring and testing. Thus, aiT enhances safety.
The increasing performance of microcontrollers enables more and more functionality to be implemented by a single embedded control unit. The software is complex and the timing behavior of the interacting software components is rarely known. Typically, it is not practical — or even possible — to test the system with all potential inputs.

aiT WCET Analyzers compute the results automatically. The computed WCET bounds are valid for all possible inputs and each execution of a task under any circumstances. No longer do you have to manually determine worst-case inputs and to measure execution time over and over again. Thus, aiT saves valuable development time.