emmtrix Performance Estimator

The emmtrix Performance Estimator (ePE) is a static analysis tool for estimating the execution time of embedded C code. It determines timing characteristics of a software system without executing the code on the target hardware.

Unlike measurement-based approaches, which rely on instrumented code, simulators, or real hardware, ePE performs a purely static analysis. The estimation is based on the program structure, control flow, and target-specific execution models. As a result, performance characteristics can be assessed early in the development process, even when the final hardware platform is not yet available.

The primary goal of ePE is to provide reproducible and analyzable execution time estimates, including minimum, maximum, and average values. These estimates can be evaluated on different levels of granularity, ranging from individual functions up to complete applications.

ePE is designed for embedded software development where timing behavior is a critical system property. Typical application domains include real-time and safety-critical systems, such as automotive ECUs and industrial control units. In particular, ePE is commonly used in projects targeting Infineon microcontroller families, including the Infineon's AURIX™ TC2xx / TC3xx/ TC4x microcontroller family.

The tool supports different estimation techniques with varying levels of accuracy, ranging from source-code-based analysis to assembly-level estimation with microarchitectural modeling. For supported Infineon architectures, this includes processor-specific timing models that reflect relevant architectural features.

In addition, ePE integrates into automated build and verification workflows and can be combined with model-based development environments. This enables continuous performance assessment and early detection of timing regressions during software evolution.

Problem Statement and Motivation

In embedded and real-time software systems, execution time is a critical non-functional property. Tasks and functions must meet strict timing constraints in order to guarantee system correctness, schedulability, and safety. Violations of these constraints may result in missed deadlines, degraded system behavior, or safety hazards.

Cost of defect remediation across the software development life cycle

Traditional performance evaluation techniques are predominantly measurement-based. They rely on executing instrumented software on simulators, hardware-in-the-loop (HIL) setups, or real target hardware. While such approaches can provide accurate measurements, they also introduce several practical limitations:

• Target hardware is often unavailable or not yet representative in early development phases.
• Measurements are influenced by instrumentation overhead and runtime environment effects.
• Results may vary across toolchains, compiler versions, or hardware revisions.
• Performance issues are typically detected late in the software development life cycle.

Early development phases, however, require performance feedback at a time when software architecture, algorithms, and scheduling concepts are still subject to change. At this stage, late detection of execution time problems can lead to costly redesigns, as architectural modifications become increasingly difficult once system integration has progressed.

This general principle is well known from software quality engineering. Defects are typically introduced early during development, but often detected much later, while the effort required to correct them increases significantly over time. Although originally formulated for functional defects, this observation applies analogously to timing- and performance-related issues in embedded systems. Late detection of timing violations frequently requires invasive changes, such as restructuring software components, modifying scheduling strategies, or adapting hardware configurations. In contrast, early performance estimation enables developers to assess timing risks at a point where corrective actions are comparatively inexpensive.

Static execution time estimation addresses this challenge by analyzing software without executing it. By deriving execution frequencies from the program structure and combining them with target-specific execution models, performance characteristics can be estimated deterministically and reproducibly. This allows systematic performance assessment early in the development process and supports continuous evaluation as the software evolves.

The emmtrix Performance Estimator (ePE) is designed to support this approach. It provides a static, analyzable, and reproducible method for estimating execution time, complementing measurement-based techniques used in later development stages and enabling early detection of timing-related risks.

Fundamental Estimation Model

The emmtrix Performance Estimator (ePE) is based on a static execution time model that decomposes the overall runtime of a software system into two orthogonal components:

• the execution frequency of a code block, and
• the execution duration of a single execution of that block.

For a given code block $b$ (e.g. a basic block, function, or task), the estimated execution time $t_{exec}(b)$ is defined as:

$t_{exec}(b)=f(b)\cdot d(b)$

where:

• $f(b)$ denotes the execution frequency of block $b$, i.e. how often the block is executed during one invocation of the surrounding context (task, function, or application),
• $d(b)$ denotes the estimated execution duration of a single execution of block $b$.

The overall execution time of a larger software entity is obtained by aggregating the execution times of its constituent blocks.

Execution Frequency

The execution frequency $f(b)$ is derived statically from the program structure and control flow. ePE analyzes the control flow graph (CFG) of the application and determines execution frequencies based on:

• loop bounds and iteration counts,
• conditional branches,
• call relationships between functions,
• structural properties of the control flow.

Whenever possible, loop bounds and conditions are evaluated using constant folding and static evaluation. This enables deterministic frequency estimates without executing the code. For blocks that are executed conditionally, frequency ranges or bounds may be derived depending on the available information.

Execution frequencies form the structural part of the estimation model and are independent of the target architecture.

Execution Duration

The execution duration $d(b)$ represents the time required to execute block $b$ once on a given target architecture. ePE determines this duration using target-specific execution models.

At the most basic level, the duration is computed by mapping program instructions to abstract timing costs (e.g. processor cycles) and summing these costs over the block. More advanced estimation methods additionally consider:

• compiler optimizations,
• instruction scheduling,
• pipeline effects and microarchitectural behavior.

The level of detail used for duration estimation directly influences the accuracy of the result and depends on the selected estimation technique.

Aggregation and Granularity

The estimation model is compositional. Execution time estimates can be aggregated across different levels of granularity, including:

• individual basic blocks,
• functions,
• tasks or runnables,
• complete applications.

This enables performance analysis and comparison at multiple abstraction levels, supporting both detailed investigations and high-level assessments.

Determinism and Reproducibility

Since both execution frequencies and execution durations are derived statically, the estimation results produced by ePE are deterministic and reproducible. Given identical source code, configuration, and target model, repeated analyses yield identical results. This property is essential for systematic performance evaluation, regression analysis, and integration into automated build and verification workflows.

Estimation Methods

In general, the execution time of a task or block can be modelled as:

t_exec = execution_frequency_block* single_duration_block

The C code based static code analysis derives the execution frequency by analyzing loop boundaries using constant folding. For the duration, each instruction in the code is modeled as the number of cycles of an abstract hardware model of the processor, and then summed.

ePE offers three accuracy levels:

• analysis of C code
• generically compiler-optimized code
• assembly code from the target compiler.

Method 1 yields results with minimum effort while method 3 takes the timing of the processor pipeline into account. All methods offer excellent reliability when tracking the tendency of changes in software runtimes e.g. when used in a continuous integration environment.

Static Code Analysis:

Processor Pipeline:

emmtrix Performance Estimator (ePE) supports different ways to acquire the duration of the tasks of an application. These methods vary in accuracy and additional software or hardware requirements. Static code analysis provides basic information without the need for hardware or special software and may thus be seamlessly incorporated into early stages of the Software Development Life Cycle (SDLC). More accurate numbers can be collected with interfaces to simulators or the hardware. Depending on the requirements, the methods can be combined as desired.

Addressing performance issues at the onset of the SDLC is not only proactive but also cost-efficient. Early estimation and intervention, as suggested by the below graph, can drastically reduce the complexities and expenses associated with fixing defects post-deployment. Although early estimates may not be as precise as measurements taken during later stages, they serve as a crucial checkpoint to prevent potential timing issues from escalating. This preemptive approach aligns with the principle that the cost to repair defects increases exponentially as they progress through the SDLC, as shown by the sharp rise in cost depicted in the graph. Hence, initial performance estimations are a strategic investment, minimizing the risk of facing a steep climb in remediation costs and efforts at later stages.

Interested?

Interested in applying this coverage workflow to your own projects? → Contact us at emmtrix.com/company/contact.