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 detected automatically by aiT, e.g. for dynamic program properties.
The amount of required annotations is dramatically reduced by advanced
techniques such as automatic 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.
- 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.
- 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.
- 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
- 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
alloc family (such as
calloc) must not occur in the analyzed code.
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
- 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,
- 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.