Add final version of master thesis.

content/validation_intro.tex

@@ -0,0 +1,31 @@
+\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.