Tool Mentor: Absint aiT
aiT determines safe and precise upper bounds for the worst-case execution times (WCETs) of tasks in real-time systems. Here, a task means a sequentially executed piece of code (no threads, no parallelism, no waiting for external events, and assuming no interference from the outside). aiT operates on binary executables for selected target architectures and produces results valid for all program runs with all inputs.
Relationships
Main Description

Abstraction level

Implementation

Use Case Tasks

·         UC#0001 - Specify Time Budgets

·         UC#0002 - Specify Mode Dependent Timing Information

·         Capture, Analyze, and Utilize Worst Case Timing Information

·         Perform timing analysis on code level

Covered aspect

aiT determines safe and precise upper bounds for the worst-case execution times (WCETs) of tasks in real-time systems. Here, a task means a sequentially executed piece of code (no threads, no parallelism, no waiting for external events, and assuming no interference from the outside). aiT operates on binary executables for selected target architectures and produces results valid for all program runs with all inputs.

aiT solves the following subtasks of the verification of timing constraints: A timing constraint refers to an event chain. aiT can compute the parts of the event chain that refer to execution of the software on a processor. The other parts of the event chain like blocking times or message transfer times are beyond the scope of the code level analysis by aiT.

aiT is intended to be used for timing verification in late stages of the system development when the code is already developed and the target processor and its configuration have been fixed. The design goal for aiT was to avoid any underestimation of the WCETs, which requires a detailed model of the underlying hardware and its timing behavior. Therefore, aiT tends to require more analysis time and space than the related TimingExplorer tool, which is intended for usage in earlier design phases and usually requires less resources, but may underestimate the WCET.

Algorithm

Static WCET analysis covering all possible program executions to obtain safe upper bounds of the WCET

Inputs

Hardware configuration, binary code, annotations on loop bounds, number of recursive calls, targets of computed calls etc. that cannot be found by static analysis.

Particular constraints on inputs

Binary code for one of the following targets: Am486, C16x/ST10, C33, ERC32, HC11, HCS12, i386DX, LEON2, LEON3, M68020, PowerPC 5xx, 55xx, 56xx, 603e, 7448, 7448s, 750, 755, 755s, TriCore, NEC V850E

Preparation of input

The hardware configuration can be specified by GUI options, textual descriptions, or specification of the contents of configuration registers (details depend on the target architecture). Names of executable and annotation files are entered in the GUI. From this information, a project file can be formed.

Invocation of the algorithm

By starting the AbsInt a3 tool framework, loading a project file, and starting a WCET analysis. The tool can also be started in batch mode without user interaction.

Alternatively, the a3 tool can be invoked from dSPACE’s TargetLink tool.

Outputs

One WCET for each runnable, call graphs showing the structure of the analyzed code, tables showing the distribution of the WCET to routines, textual report file, XML report file

Visualization of results

Graphs showing the structure of the analyzed program with analysis results attached to the structure elements, tables showing the distribution of the WCET to routines