work on implementation and previous work

.latexmkrc

@@ -1 +1,12 @@
-@default_files = ('main.tex');
+@default_files = ('main.tex');
+
+add_cus_dep( 'acn', 'acr', 0, 'makeglossaries' );
+add_cus_dep( 'glo', 'gls', 0, 'makeglossaries' );
+$clean_ext .= " acr acn alg glo gls glg";
+sub makeglossaries {
+  my ($base_name, $path) = fileparse( $_[0] );
+  pushd $path;
+  my $return = system "makeglossaries", $base_name;
+  popd;
+  return $return;
+}

chapters/abstract.tex

@@ -1 +1,2 @@
 This is an abstract.
+ \Gls{latex}

chapters/implementation.tex

@@ -164,7 +164,7 @@ \subsection{Measure of replay harness}
 kind of trace it is. If it's a task or resource breakpoint it needs to record
 the current clock cycle at the breakpoint and also figure out what the name
 of the object is. To figure out the name of the task or resource where the
-breakpoint has been inserted into, RAUK reads the DWARF[reference here!] debug
+breakpoint has been inserted into, RAUK reads the DWARF\cite{dwarfspec} debug
 data of the flashed binary. DWARF debug data contains much information
 necessary for debuggers, such as memory locations of variables and information
 about which instructions in the binary belongs to which functions etc.
@@ -174,23 +174,23 @@ \subsection{Measure of replay harness}
     \begin{tikzpicture}[node distance=2cm]
         \node (measure) [redrectangle]
         {\texttt{measure}};
-        \node (probe-rs) [orangerectangle,below of=measure, xshift=-5cm]
+        \node (probe-rs) [orangerectangle,below of=measure, xshift=-4cm]
         {\texttt{probe-rs}};
-        \node (chip) [orangerectangle,below of=probe-rs]
-        {\texttt{chip}};
+        %\node (chip) [orangerectangle,below of=probe-rs]
+        %{\texttt{chip}};
         \node (trace) [orangerectangle,below of=measure]
         {\texttt{trace}};
-        \node (utils) [orangerectangle,below of=measure, xshift=5cm]
-        {\texttt{utils}};
+        \node (utils) [orangerectangle,below of=measure, xshift=4cm]
+        {\texttt{binary utilities}};
         \node (dwarf-parser) [orangerectangle, below of=utils,xshift=-2cm]
         {\texttt{dwarf-parser}};
         \node (disassembler) [orangerectangle, below of=utils,xshift=2cm]
         {\texttt{disassembler}};
 
         % midpoints for the lines
         \node (f1) [below of=measure, yshift=1cm]{};
-        \node (f2) [below of=measure, yshift=1cm, xshift=-5cm]{};
-        \node (f3) [below of=measure, yshift=1cm, xshift=5cm]{};
+        \node (f2) [below of=measure, yshift=1cm, xshift=-4cm]{};
+        \node (f3) [below of=measure, yshift=1cm, xshift=4cm]{};
 
         \node (f4) [below of=utils, yshift=1cm]{};
         \node (f5) [below of=utils, yshift=1cm, xshift=-2cm]{};
@@ -200,7 +200,7 @@ \subsection{Measure of replay harness}
         \draw (flash) -- (trace);
         \draw (f1.center) -- (f2.center);
         \draw (f2.center) -- (probe-rs);
-        \draw (probe-rs) -- (chip);
+        %\draw (probe-rs) -- (chip);
 
         \draw (f1.center) -- (f3.center);
         \draw (f3.center) -- (utils);
@@ -214,4 +214,57 @@ \subsection{Measure of replay harness}
     \label{fig:measureparts}
 \end{figure}
 
+If the RTIC application reads any hardware peripherals or memory addresses
+during its runtime, there will be test vectors generated for those reads. For
+primitive resources, they are set as global variables and usually have an
+associated memory address in flash and are easy to overwrite. But for direct
+memory readings, they are read directly into a register on the MCU. Therefore
+the test vectors for memory reads needs to overwrite the register, the actual
+value is loaded into. This is done by inserting a breakpoint inside of the
+patched fork of the \texttt{vcell} library, where a memory read is made. Once
+reaching that breakpoint and by disassembling the binary, RAUK checks which
+register the read of the memory address is loaded into. Then sets a hardware
+breakpoint after the load has been made. When reaching that breakpoint RAUK
+will overwrite the register with the corresponding test vector and resume the
+program execution.
+
+After completing all traces, RAUK will convert them to a new set of traces where
+there is a single trace for each test vector tested which most importantly
+contains the cycle counter at the start and end of the trace. The complete
+contents of a final trace can be seen in Table \ref{tab:tracecontents}.
+\begin{table}[h]
+    \centering
+    \begin{tabular}{|c | c|}
+        \hline
+        \multicolumn{2}{| c |}{Trace contents}\\ [0.5ex]
+        \hline
+        Label & Description\\ [0.5ex]
+        \hline
+        \texttt{name} & Name of the object trace  \\
+        \hline
+        \texttt{ttype} & The type of trace (task, resource lock etc.) \\
+        \hline
+        \texttt{start} & Cycle count at the start of this trace  \\
+        \hline
+        \texttt{inner} & List of traces inside this trace \\
+        \hline
+        \texttt{end} & Cycle count at the end of this trace  \\
+        \hline
+    \end{tabular}
+    \caption{Description of the final trace data.}
+    \label{tab:tracecontents}
+\end{table}
+
+
 \subsection{Schedulability analysis}
+After collecting the traces, the final step is to run the schedulability analysis as
+detailed in Section \ref{theory:schedulability}. Assuming that the traces are correct
+and they contain the WCET of all tasks. The \texttt{analysis} subcommand needs
+additional information about each user task to complete the analysis, which can
+be supplied via a TOML file. This file needs to specify for each user task,
+the name of the task and its priority, as well as the relative deadline and the
+period (inter-arrival) of the task.
+
+Then from the list of traces in the previous step, the WCET for each task is
+chosen and the WCRT for each task will be calculated from it. RAUK will then
+confirm whether the system is schedulable or not.

chapters/introduction.tex

@@ -80,7 +80,7 @@ \section{Motivation}
 
 % something bugs?
 
-\section{Problem Definition}
+\section{Problem definition}
 This thesis explores the possibility of developing a tool to automatically
 calculate the worst-case response times (WCRT)  for tasks in an RTIC
 application in order to check if the system is schedulable or not. This by

chapters/previouswork.tex

@@ -1,7 +1,43 @@
+\section{Measurement-based WCET analysis}
 A measurement-based worst-case execution time (WCET) analysis with KLEE has
-been tried in an earlier revision of the RTIC framework\cite{lindner} when it was
-called RTFM. In the paper the authors presented their approach for using KLEE on
-RTFM applications in order to measure the WCET for all tasks. 
+been tried in an earlier revision of the RTIC framework\cite{lindner} when it
+was called RTFM. In the paper the authors presented their approach for using
+KLEE on RTFM applications in order to measure the WCET for all user tasks as a
+Python script.
 
-Limitations of their approach were that it only worked on simple resource types and
-did not model I/O.
+In their approach they modified the RTFM application by forking the library and
+adding two additional compilation flags. One which modified the application to be
+able to execute KLEE on the application to generate test vectors, and another
+to modify the application to make it possible to replay said test vectors on
+the target hardware.
+
+KLEE was used to generate test vectors for all resources that the user tasks
+had access to. On the target hardware the modified RTFM application would be
+running with software breakpoints inserted at the start and end of all tasks
+and resource locks. By using the \texttt{gdb} debugger they would for each test
+vector on a single task, write the corresponding test vector values to the
+memory locations of the resources. Then execute the program and step through the
+breakpoints until the task has finished its execution. On each breakpoint
+they would record the cycle counter. By doing this they would get the execution
+times of all tasks and their resource claims. Since the KLEE interpreter
+executes all feasible paths in the program, one of the test vectors should
+in theory yield the WCET of a task.
+
+
+Some limitations of their approach include
+\begin{enumerate}
+    \item it only worked on simple resource types,
+    \item it did not model I/O.
+\end{enumerate}
+In the paper they only showed their work on an RTFM application where all
+resources were integers and they mentioned that it did not model I/O. I.e.\
+it did not create tests or measure resources which were connected to any I/O
+such as access to hardware peripherals. Although they mentioned schedulability
+analysis in the paper, they did not showcase any such examples where their
+results were used to run a schedulability analysis.
+
+The paper by Lindner et al.\ has served as the main inspiration to this thesis.
+Thus this thesis can be seen as an evolution of their work.
+
+\section{Schedulability analysis}
+Cheddar, TIMES 

chapters/theory.tex

@@ -130,7 +130,8 @@ \section{RTIC}
 interrupt controller (NVIC).  The overhead RTIC has mostly concerns context switching
 as well as task dispatching.
 
-\section{Schedulability Analysis}
+\section{Schedulability analysis}
+\label{theory:schedulability}
 For a system with fixed priority preemptive scheduling, the response time for
 a task $\tau_i$ can be calculated from the recurrence relation by Audsley et
 al.\ \cite{audsley93} and extended with the blocking time for the
@@ -146,9 +147,10 @@ \section{Schedulability Analysis}
 relation is the possible preemption from higher priority tasks that can occur.
 
 
-A system is said to be schedulable if all tasks $\tau_i$ are responding within their respective
-deadlines $D_{\tau_i}$. Thus an RTIC system will be schedulable if the following holds
-true
+A system is said to be schedulable if all tasks $\tau_i$ are responding within
+their respective relative deadlines $D_{\tau_i}$. A relative deadline in this
+context is the deadline counted from when the task was requested. Thus an RTIC
+system will be schedulable if the following holds true
 \begin{equation}
     R_{\tau_i} \leq D_{\tau_i}, \quad \forall i.
 \end{equation}

glossary.tex

@@ -0,0 +1,10 @@
+% ACRONYMS
+\newacronym{wcet}{WCET}{Worst-Case Execution Time}
+
+% GLOSSARIES
+\newglossaryentry{latex}
+{
+    name=latex,
+    description={Is a markup language specially suited for 
+scientific documents}
+}

main.tex

@@ -13,6 +13,7 @@
 \usepackage{float}
 \usepackage{tikz}
 \usetikzlibrary{shapes.geometric, arrows}
+\usepackage[acronym]{glossaries}
 \usepackage{listings}
 \usepackage[titles]{tocloft}
 \usepackage[
@@ -55,6 +56,18 @@
 \input{definitions.tex}
 \input{tikz.tex}
 
+%%
+% Glossary
+%%
+\makeglossaries
+%\loadglsentries{glossary}
+
+\newglossaryentry{latex}
+{
+    name=latex,
+    description={Is a markup language specially suited for 
+scientific documents}
+}
 \begin{document}
 %------------------------------------------------
 % Titlepage
@@ -130,6 +143,13 @@ \chapter{Discussion} \label{chapter:discussion}
 \chapter{Conclusion} \label{chapter:conclusion}
 \import{chapters/}{conclusion.tex}
 
+%------------------------------------------------
+% Glossary 
+%------------------------------------------------
+\addcontentsline{toc}{chapter}{Glossary}
+\printglossary[type=\acronymtype]
+\printglossary
+
 %------------------------------------------------
 % References
 %------------------------------------------------

references.bib

@@ -127,3 +127,12 @@ @TECHREPORT{rapita
     note = {Accessed on 2021-06-29}
 }
 
+
+" Manuals
+@manual{dwarfspec,
+    title = {DWARF Debugging Information Format
+Version 5},
+    author = {{DWARF Committee}},
+    organization = {DWARF Debugging Information Format Committee},
+    year = {2017},
+}