32 lines
1.7 KiB
TeX
32 lines
1.7 KiB
TeX
|
\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.
|