Analyzing execution time with aiT

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 de­tected automatically by aiT, e.g. for dynamic program properties. The amount of required annotations is dramatically reduced by advanced techniques such as auto­matic loop-bound and array-call recognition. It can be reduced further still by running an initalization analysis using the ValueAnalyzer add-on.

  “aiT is very easy and straightforward to use. While it does provide a lot of configuration options, one can get to a first WCET computation result very quickly. Advanced configuration through annotations can be added later. [… It also] has by a wide margin the best capabilities to resolve dynamic calls automatically.”

  Independent study by University of Stuttgart (PDF)

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

aiT outputs:

• A tight upper bound of the task’s runtime.
• Visualization of the analysis results providing detailed infor­ma­tion about key timing aspects, e.g. the worst-case path or the machine state at any given program point.
• Various statistics, interactive tables, graphs and charts that let you quickly identify bottlenecks and other areas of interest.
• Analysis report files for documentation and certification purposes, as well as for integration with numerous software development tools.

Restrictions

• 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.

Your benefits

• 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 graph browser 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 the same GUI.
• 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, e.g. your nightly Jenkins build.
• 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.

Why do you need aiT?

• 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.