SystemC

doc.bib

@@ -43,4 +43,33 @@
   year   = {2007},
 }
 
+@InProceedings{Antonino2018,
+  author    = {Antonino, Pablo Oliveira and Jung, Matthias and Morgenstern, Andreas and Fa{\ss}nacht, Florian and Bauer, Thomas and Bachorek, Adam and Kuhn, Thomas and Nakagawa, Elisa Yumi},
+  booktitle = {Software Architecture},
+  title     = {Enabling Continuous Software Engineering for Embedded Systems Architectures with Virtual Prototypes},
+  year      = {2018},
+  address   = {Cham},
+  editor    = {Cuesta, Carlos E. and Garlan, David and P{\'e}rez, Jennifer},
+  pages     = {115--130},
+  publisher = {Springer International Publishing},
+  abstract  = {Continuous software engineering aims at orchestrating engineering knowledge from various disciplines in order to deal with the rapid changes within the ecosystems of which software-based systems are part of. The literature claims that one means to ensure these prompt responses is to incorporate virtual prototypes of the system as early as possible in the development process, such that requirements and architecture decisions are verified early and continuously by means of simulations. Despite the maturity of practices for designing and assessing architectures, as well as for virtual prototyping, it is still not clear how to jointly consider the practices from these disciplines within development processes, in order to address the dynamics imposed by continuous software engineering. In this regard, we discuss in this paper how to orchestrate architecture drivers and design specification techniques with virtual prototypes, to address the demands of continuous software engineering in development processes. Our proposals are based on experiences from research and industry projects in various domains such as automotive, agriculture, construction, and medical devices.},
+  isbn      = {978-3-030-00761-4},
+}
+
+@Article{IEEE2012,
+  journal = {IEEE Std 1666-2011 (Revision of IEEE Std 1666-2005)},
+  title   = {IEEE Standard for Standard SystemC Language Reference Manual},
+  year    = {2012},
+  doi     = {10.1109/IEEESTD.2012.6134619},
+}
+
+@InProceedings{Menard2017,
+  author    = {Menard, Christian and Castrillon, Jeronimo and Jung, Matthias and Wehn, Norbert},
+  booktitle = {2017 International Conference on Embedded Computer Systems: Architectures, Modeling, and Simulation (SAMOS)},
+  title     = {System simulation with gem5 and SystemC: The keystone for full interoperability},
+  year      = {2017},
+  pages     = {62-69},
+  doi       = {10.1109/SAMOS.2017.8344612},
+}
+
 @Comment{jabref-meta: databaseType:bibtex;}

doc.tex

@@ -156,21 +156,38 @@
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%{{{%
 %\onehalfspacing % Stelle 1.5er Abstand ein
 %\setstretch{1.1} 
-% \input{inc/1.introduction}
+\input{inc/1.introduction}
-% \newpage
+\newpage
-% \clearpage
+\clearpage
 
 \input{inc/2.dynamorio}
 \newpage
 \clearpage
 
+\input{inc/3.systemc}
+\newpage
+\clearpage
+
 \input{inc/4.caches}
 \newpage
 \clearpage
 
+\input{inc/5.dramsys}
+\newpage
+\clearpage
+
 \input{inc/6.implementation}
 \newpage
 \clearpage
+
+\input{inc/7.simulation_results}
+\newpage
+\clearpage
+
+\input{inc/8.future_work}
+\newpage
+\clearpage
+
 %\input{2.usw.usw}
 %\newpage
 %\clearpage

img/thesis.tikzstyles

@@ -26,6 +26,8 @@
 \tikzstyle{cache data}=[fill={rgb,255: red,230; green,230; blue,230}, draw=black, shape=rectangle, minimum width=10cm]
 \tikzstyle{block address}=[fill={rgb,255: red,200; green,200; blue,255}, draw=black, shape=rectangle, minimum height=0.75cm, minimum width=3.5cm]
 \tikzstyle{valid}=[fill={rgb,255: red,200; green,200; blue,255}, draw=black, shape=rectangle, minimum height=0.75cm, minimum width=0.6cm]
+\tikzstyle{generic block}=[fill=white, draw=black, shape=rectangle, minimum height=1.25cm, minimum width=1.75cm, align=center]
+\tikzstyle{payload}=[fill=white, draw=black, shape=rectangle, dashed, align=center]
 
 % Edge styles
 \tikzstyle{dashed line}=[-, dashed]
@@ -42,3 +44,5 @@
 \tikzstyle{thin}=[-, very thin]
 \tikzstyle{virtual page number}=[-, fill={rgb,255: red,179; green,179; blue,179}]
 \tikzstyle{page offset}=[-, fill={rgb,255: red,247; green,247; blue,247}]
+\tikzstyle{dashed arrow}=[dashed, ->]
+\tikzstyle{latex double arrow}=[-, latex-latex]

img/tlm.tikz

@@ -0,0 +1,32 @@
+\begin{tikzpicture}
+	\begin{pgfonlayer}{nodelayer}
+		\node [style=generic block] (0) at (0, 0) {Initiator};
+		\node [style=generic block] (1) at (10, 0) {Inter-\\connect};
+		\node [style=generic block] (2) at (20, 0) {Target};
+		\node [style=payload] (3) at (10, 4) {Generic\\Payload};
+		\node [style=initiator socket] (4) at (2, 0) {};
+		\node [style=target socket] (5) at (8, 0) {};
+		\node [style=target socket] (6) at (18, 0) {};
+		\node [style=initiator socket] (7) at (12, 0) {};
+		\node [style=none] (8) at (5, 0.5) {Forward Path};
+		\node [style=none] (9) at (15, 0.5) {Forward Path};
+		\node [style=none] (10) at (8, -2) {};
+		\node [style=none] (11) at (2, -2) {};
+		\node [style=none] (12) at (18, -2) {};
+		\node [style=none] (13) at (12, -2) {};
+		\node [style=none] (14) at (5, -1.5) {Backward Path};
+		\node [style=none] (15) at (15, -1.5) {Backward Path};
+	\end{pgfonlayer}
+	\begin{pgfonlayer}{edgelayer}
+		\draw [style=dashed arrow, bend left=15] (0) to (3);
+		\draw [style=arrow] (4) to (5);
+		\draw [style=arrow] (7) to (6);
+		\draw (5) to (10.center);
+		\draw (11.center) to (10.center);
+		\draw (6) to (12.center);
+		\draw (12.center) to (13.center);
+		\draw [style=arrow] (13.center) to (7);
+		\draw [style=arrow] (11.center) to (4);
+		\draw [style=dashed arrow, bend left=15] (3) to (2);
+	\end{pgfonlayer}
+\end{tikzpicture}

img/tlm_at.tikz

@@ -0,0 +1,42 @@
+\begin{tikzpicture}
+	\begin{pgfonlayer}{nodelayer}
+		\node [style=none] (0) at (0, 1) {};
+		\node [style=none] (1) at (0, -12) {};
+		\node [style=none] (2) at (12, 1) {};
+		\node [style=none] (3) at (12, -12) {};
+		\node [style=none] (4) at (0, 1.75) {Initiator};
+		\node [style=none] (5) at (12, 1.75) {Target};
+		\node [style=none] (6) at (-1, 0) {};
+		\node [style=none] (7) at (-1, -11) {};
+		\node [style=align text] (8) at (-1.5, -6) {Time};
+		\node [style=none] (9) at (0, -1) {};
+		\node [style=none] (10) at (12, -1) {};
+		\node [style=none] (11) at (12, -2) {};
+		\node [style=none] (12) at (0, -2) {};
+		\node [style=none] (13) at (0, -6) {};
+		\node [style=none] (14) at (12, -6) {};
+		\node [style=none] (15) at (0, -10) {};
+		\node [style=none] (16) at (12, -10) {};
+		\node [style=none] (17) at (2.5, -0.5) {BEGIN\_REQ};
+		\node [style=none] (18) at (9.75, -1.5) {END\_RESP};
+		\node [style=none] (19) at (9.5, -5.5) {BEGIN\_RESP};
+		\node [style=none] (20) at (2.25, -9.5) {END\_RESP};
+		\node [style=none] (21) at (15.25, -6) {};
+		\node [style=none] (22) at (15.25, -10) {};
+		\node [style=align text] (23) at (15.75, -8) {Back Pressure};
+		\node [style=none] (24) at (15, -6) {};
+		\node [style=none] (25) at (15, -10) {};
+	\end{pgfonlayer}
+	\begin{pgfonlayer}{edgelayer}
+		\draw (0.center) to (1.center);
+		\draw (2.center) to (3.center);
+		\draw [style=latex arrow] (6.center) to (7.center);
+		\draw [style=latex arrow] (9.center) to (10.center);
+		\draw [style=latex arrow] (11.center) to (12.center);
+		\draw [style=latex arrow] (14.center) to (13.center);
+		\draw [style=latex arrow] (15.center) to (16.center);
+		\draw [style=dashed line] (22.center) to (16.center);
+		\draw [style=dashed line] (21.center) to (14.center);
+		\draw [style=latex double arrow] (24.center) to (25.center);
+	\end{pgfonlayer}
+\end{tikzpicture}

inc/1.introduction.tex

@@ -1,22 +1,3 @@
 \section{Introduction}
+\label{sec:introduction}
 
-Lorem ipsum dolor sit amet, consectetur adipiscing elit. Duis sit amet ante elit. Etiam vel pharetra orci. Integer mollis auctor ante, non lacinia turpis lacinia eget. Vestibulum in orci ligula, tempor fringilla ipsum. Phasellus scelerisque elementum mauris iaculis euismod. Morbi a neque cursus turpis varius lobortis nec sed lorem. Nullam non nisi purus, eget ullamcorper urna. Proin dignissim, lacus id convallis tristique, metus felis pellentesque purus, at hendrerit lacus turpis eu justo. Quisque semper pretium turpis eu tempus. Nunc vehicula, erat et auctor blandit, elit augue ultrices tortor, id lacinia mi ligula et risus. Praesent mauris massa, porttitor ac rhoncus vitae, porta vitae elit.
-
-Morbi in quam dolor, nec eleifend turpis. Phasellus consequat scelerisque purus, eget iaculis leo condimentum eu. Curabitur non augue non enim adipiscing interdum a a risus. Morbi commodo magna ultrices nisi adipiscing eu laoreet ante molestie. In hac habitasse platea dictumst. Sed nulla nulla, gravida eu ultricies vitae, venenatis quis dui. Nam cursus lectus eu nisi facilisis tristique. Praesent vulputate neque ut ligula convallis nec consequat enim semper. Nullam at lorem sit amet est rutrum convallis non eu ligula. Proin gravida tincidunt nibh, quis suscipit lacus convallis eget. Aenean id mi in lorem accumsan fermentum. Fusce.
-\cite{Bruening2004}
-\cite{Bruening2003}
-
-\begin{listing}[H]
-  \begin{cppcode}
-   static void vTask1( void *pvParameters );                 // Prototype for task function
-
-   int main()
-   {
-	xTaskCreate( vTask1, "Task1", 100, NULL, 1, NULL );  // Configure Task
-	vTaskStartScheduler();                               // Starting scheduler
-   }
-  \end{cppcode}
-  \caption{Test}
-\end{listing}
-
-Test test test \abbr{Transaction Level Modeling}{TLM}

inc/2.dynamorio.tex

@@ -64,6 +64,8 @@ It is important to note that hooks like the basic block creation function do not
 
 The table \ref{tab:dynamorio_api} lists the most important hooks that a client can implement.
 
+A client that already comes with DynamoRIO is DrCacheSim with the DrMemtrace-Framework, which will be further explained in section \ref{sec:analysis_tool}.
+
 \begin{table}[!ht]
 \caption{Client routines that get called by DynamoRIO \cite{Bruening2003}.}
 \begin{center}
@@ -92,5 +94,3 @@ The table \ref{tab:dynamorio_api} lists the most important hooks that a client c
 \end{center}
 \label{tab:dynamorio_api}
 \end{table}
-
-A client that already comes with DynamoRIO is DrCacheSim with the DrMemtrace-Framework, which will be further explained in section \ref{sec:analysis_tool}.

inc/3.systemc.tex

@@ -0,0 +1,71 @@
+\section{SystemC}
+\label{sec:systemc}
+
+This section covers the basics of virtual prototyping, SystemC and transaction level modeling.
+
+\revabbr{Virtual prototypes}{VPs} are software models of physical hardware systems, that can be used for software development before the actual hardware is available.
+They make it easier to test the product as VPs provide visiblity and controllability across the entire system and therefore reduce the time-to-market and development cost\cite{Antonino2018}.
+
+SystemC is a C++ class library with an event-driven simulation kernel, used for developing complex system models (i.e. VPs) in a high-level language.
+It is defined under the IEEE 1666-2011 standard \cite{IEEE2012} and provided as an open-source library by Accellera.
+
+SystemC supports numerous abstraction levels for modeling systems, namely \textit{cycle-accurate}, which is the most accurate abstraction but also the slowest, \textit{approximateley-timed} and \textit{loosley-timed}.
+The latter two abstraction levels belog to \revabbr{transaction level modeling}{TLM}, which will be discussed in the next section \ref{sec:tlm}.
+One further abstraction level, \textit{untimed}, will not be topic of this thesis.
+
+\subsection{Transaction Level Modeling}
+\label{sec:tlm}
+
+TLM abstracts the modeling of the communication between modules using so-called transactions, which are transferred through function calls \cite{Menard2017}.
+In contrast to pin and cycle accurate models, this greatly reduces the simulation overhead at the cost of reduced accuracy.
+
+Modules communicate with each other through \textit{initiator} sockets and \textit{target} sockets.
+A processor for example sends requests to a memory using its initiator socket, whereas the memory responds trough its target socket.
+Interconnect modules, which can be used to model a bus, use both sockets to communicate with both the initiator and the target modules.
+This concept is illustrated in figure \ref{fig:tlm}.
+
+The transaction object itself is a \revabbr{generic payload}{GP}, which consists of address, command, status and other information as well as the actual data to transfer.
+GPs are transferred as references, avoiding the need to copy them between the modules.
+
+\input{img/thesis.tikzstyles}
+\begin{figure}[!ht]
+\begin{center}
+\tikzfig{img/tlm}
+\caption{Forward and backward path between TLM sockets\cite{Menard2017}. $\blacksquare$ denotes a initiator socket, $\square$ denotes a target socket.}
+\label{fig:tlm}
+\end{center}
+\end{figure}
+
+In the \revabbr{loosley-timed}{LT} coding style, a transaction is blocking, meaning it will be modeled by only one function call.
+This comes at the cost of limited timing accuracy as only the beginning and the end of the transaction are modeled as timing points and no other module can initiate transcations during this time.
+
+The \revabbr{approximateley-timed}{AT} coding style is non-blocking and consists of a four-phase handshake:
+\texttt{BEGIN\_REQ},
+\texttt{END\_REQ},
+\texttt{BEGIN\_RESP} and
+\texttt{END\_RESP}.
+
+When an initiator requests certain data from a target, it starts the transaction with the \texttt{BEGIN\_REQ} phase using its \texttt{nb\_transport\_fw()} method.
+The target now enqueues the payload into its \revabbr{payload event queue}{PEQ} and pretends it has received the payload after the delay, the initiator has specified.
+When the target is not ready yet to accept the requests, it defers its \texttt{END\_REQ} until it is.
+During this time, the initiator is blocked from sending further requests to other modules as the target applies \textit{back pressure} on the initiator.
+This concept is called the \textit{exclusion rule}.
+
+The target now prepares the response and sends the \texttt{BEGIN\_RESP} phase through its \texttt{nb\_transport\_bw()} method when the data is available.
+The initiator can now also apply back pressure to the target by deferring its \texttt{END\_RESP} phase.
+When the \texttt{END\_RESP} phase is received by the target, the transaction is completed.
+Figure \ref{fig:tlm_at} shows an exemplary handshake sequence diagram with all four phases.
+
+\begin{figure}[!ht]
+\begin{center}
+\tikzfig{img/tlm_at}
+\caption{Sequence diagram of an exemplary transaction.}
+\label{fig:tlm_at}
+\end{center}
+\end{figure}
+
+SystemC also supports additional user-defined phases through its \texttt{DECLARE\_EXTENDED\_PHASE()} macro.
+In contrast to the TLM-LT protocol, TLM-AT makes it possible model pipelining of transactions; multiple transactions can be processed by a target at one time.
+The responses also do not need to be in the same order as the initiator has sent them: they can be \textit{out out order}.
+
+The TLM-AT protol is the used protocol to model the initiator and the cache model in section \ref{sec:implementation} of this thesis.

inc/5.dramsys.tex

@@ -0,0 +1,2 @@
+\section{DRAMSys}
+\label{sec:dramsys}

inc/6.implementation.tex

@@ -1,4 +1,5 @@
 \section{Implementation}
+\label{sec:implementation}
 
 In this section, the new components that were developed that enable the tracing of an arbitrary application in real-time, as well as the replay of those traces in DRAMSys, will be introduced.
 
@@ -96,10 +97,10 @@ In the case of the DbiPlayer, an additional interconnect module will bundle up a
 \end{center}
 \end{figure}
 
-As the memory accesses are directly extracted from the executed instructions, simply sending a transaction to the DRAM subsystem for every data reference would neglect the caches todays processors completely.
+As the memory accesses are directly extracted from the executed instructions, simply sending a transaction to the DRAM subsystem for every data reference would neglect the caches today's processors completely.
-Therefore, also a cache model is required whose implementation will be explained in more detail in section \ref{sec:cache}.
+Therefore, also a cache model is required whose implementation will be explained in more detail in section \ref{sec:caches}.
 Modern cache hierarchies compose of 3 cache levels: 2 caches for every processor core, the L1 and L2 cache, and one cache that is shared across all cores, the L3 cache.
-(vlt hier Literaturreferenz)
+% (vlt hier Literaturreferenz)
 This hierarchy is also reflected in the DbiPlayer as shown in Figure \ref{fig:dbiplayer_with_caches}.
 
 \begin{landscape}

inc/7.simulation_results.tex

@@ -0,0 +1,2 @@
+\section{Simulation Results}
+\label{sec:simulation_results}

inc/8.future_work.tex

@@ -0,0 +1,2 @@
+\section{Future Work}
+\label{sec:future_work}