\begin{figure}[]
 \centering
 \includegraphics[width=\textwidth]{./media/eval/eval_idea.pdf}
 \caption[Mapping validation concept]{The general idea for the validation of
 the software event to \gls{btf} event mapping.  A model that represents a
 certain system is created.  Based on the model, a simulation, and a hardware
 trace are generated.  By comparing those traces errors in the transformation
 process can be detected.}
 \label{fig:eval_idea}
\end{figure}

In this chapter the software to system mappings are validated as depicted in
\autoref{fig:eval_idea}.  A timing model of an application is created and a
\gls{btf} trace is generated from this model via discrete event simulation.
The simulated trace represents the expected result for the trace
recorded from hardware.

Next, C code is generated from the model.  The code is compiled, executed on
hardware, and the runtime behavior is recorded via hardware tracing.  The
resulting software level trace is transformed to system level according to
the respective mappings.  The \gls{btf} trace recorded from hardware is then
compared to the simulated trace.  Since both traces result from the same timing
model they are expected to represent the same system behavior.

Nevertheless, two kinds of deviations are expected.  Firstly, timestamps of
otherwise identical events might differ.  This is unavoidable because
simulation is an abstraction of reality and is not capable of taking all subtle
effects influencing the timing on real hardware into consideration.  Secondly,
events may indicate a different software behavior.  For example, a task starts
a runnable in one trace but not in the other.   In this case, the deviation
must be examined because it might point to a mapping error.