\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, 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 \textit{IEEE 1666-2011} standard \cite{IEEE2012} and is provided as an open-source library by Accellera.

All SystemC modules inherit from the \texttt{sc\_module} base class.
Those modules can hierarchically be composed of other modules or implement their functionality directly.
Ports are used to connect modules with each other, creating the system structure of the simulation.
There are two options to implement a process in a module:
\begin{itemize}
 \item
    An \texttt{SC\_METHOD} is sensitive to \texttt{sc\_event}s or other signals.
    Methods are executed multiple times, each time they are triggered by their sensitivity list.
 \item
    An \texttt{SC\_THREAD} is started at the beginning of the simulation and should not terminate.
    Instead, threads should contain infinite loops and should explicitly call \texttt{wait()} to wait a specific time or for events.
\end{itemize}
Moreover, there is the event queue type \texttt{sc\_event\_queue}, which makes it possible to queue multiple pending events, where as an \texttt{sc\_event} ignores further notifications until it is waited on.

The concepts presented are used in Section \ref{sec:implementation}, where the implementation of various SystemC modules will be discussed.

SystemC supports a number of abstraction levels for modeling systems, namely \textit{cycle-accurate}, the most accurate but also the slowest abstraction, \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}.
Another level of abstraction, \textit{untimed}, will not be the subject 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 data packets transferred by function calls \cite{Menard2017}.
In comparison to pin and cycle accurate modeling, 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.
For example, a processor sends requests to a memory through its initiator socket, while the memory responds through its target socket.
Interconnection modules, which can be used to model a bus, use both socket types to communicate with both 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 the target address, whether the transaction is a read or write command, status information and other transaction parameters, the actual data to transfer as well as user-defined payload extensions.
GPs are passed as references, so they do not need to be copied between modules.

\input{img/thesis.tikzstyles}
\begin{figure}
\begin{center}
\tikzfig{img/tlm}
\caption[Forward and backward path between TLM sockets \cite{Menard2017}.]{Forward and backward path between TLM sockets \cite{Menard2017}. $\blacksquare$ denotes an initiator socket, $\square$ denotes a target socket.}
\label{fig:tlm}
\end{center}
\end{figure}

SystemC defines two coding styles for the use of TLM, called \revabbr{loosley-timed}{LT} and \revabbr{approximateley-timed}{AT}.
In the LT coding style, a transaction is blocking, meaning that the transaction will be modeled by only one function call.
This comes at the cost of limited temporal accuracy, as only the start and end times of the transaction are modeled, and the initiator must wait until the transaction is complete before making the next request.
However, the fast simulation time, especially when the so-called concept of \textit{temporal decoupling} with \textit{timing quantums} is used, makes it possible to use this coding style for rapid software development; LT is suitable for developing drivers for a simulated hardware component.

The AT coding style is non-blocking and therefore can be used to model with a higher timing accuracy than LT.
This high accuracy makes it possible to use AT for hardware-level design space exploration.
With AT, a special protocol is used that uses a four-phase handshake:
\texttt{BEGIN\_REQ},
\texttt{END\_REQ},
\texttt{BEGIN\_RESP} and
\texttt{END\_RESP}.

When an initiator requests data from a target, it starts the transaction with the \texttt{BEGIN\_REQ} phase by calling its \texttt{nb\_transport\_fw()} method.
This method in turn calls the receiving module's target socket and the target module then enqueues the payload into its \revabbr{payload event queue}{PEQ}.
The PEQ pretends it has received the payload after the delay, that the initiator has specified with its call to the transport method.
If the target is not yet ready to accept a new request, it defers its \texttt{END\_REQ} phase until it is ready.
During this time, the initiator is blocked from sending further requests either to this or other modules as the target applies \textit{backpressure} on the initiator.
This concept is called the \textit{exclusion rule}.
Otherwise, the target directly responds the \texttt{END\_REQ} phase back to the initiator.

The target then 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 backpressure 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.
% hier komplexeres handshake beispiell
Figure \ref{fig:tlm_at} shows an exemplary handshake sequence diagram of three different transactions.

\begin{figure}[!ht]
\begin{center}
\tikzfig{img/tlm_at}
\caption{Sequence diagram of exemplary transactions.}
\label{fig:tlm_at}
\end{center}
\end{figure}

SystemC defines various special cases and shortcuts that can be used troughout the protocol.
In the \texttt{BEGIN\_REQ} phase, it is possible for the target to directly send the \texttt{END\_REQ} phase using the return value of the forward transport function call.
This requires setting the return type \texttt{tlm\_sync\_enum} to \texttt{TLM\_UPDATED} instead of \texttt{TLM\_ACCEPTED} in the normal case.
Analogously, it is also possible for the initiator to directly respond with the \texttt{END\_RESP} phase using the return value during the \texttt{BEGIN\_RESP} phase.

Besides this, it is also possible for the target to directly respond with the \texttt{BEGIN\_RESP} phase after it has received the \texttt{BEGIN\_REQ} phase and therefore skip the \texttt{END\_REQ}.
The initiator has to react accordingly and must detect that the \texttt{END\_REQ} has been skipped.
However, since the initiator is blocked due to backpressure during this period, this shortcut should only be used if the response is ready to send after a short delay.
Another form of this shortcut is the combination with return path of the forward transport function call.
Here, the return path is used to directly send the \texttt{BEGIN\_REQ} phase, without invoking the backward transport function altogether, reducing the required number of transport calls to only two.

The last shortcut, that can be made is the so-called \textit{early completion}.
When the target receives the \texttt{BEGIN\_REQ} phase, it can already place the requested data into the payload and pass \texttt{TLM\_COMPLETED} as the return value back to the initiator.
This notifies that the whole transaction is already completed at this point, so no further transport calls are required.
Note that this form of early completion is very similar to the LT coding style, where a transaction also is modeled using only one function call.
Early completion can also be used by the initiator to skip the \texttt{END\_RESP} phase.
Here, \texttt{TLM\_COMPLETED} is returned during the backward transport call of the \texttt{BEGIN\_RESP} phase.

SystemC also supports additional user-defined phases through its \texttt{DECLARE\_EXTENDED\_\\PHASE()} macro for special cases.

In contrast to the TLM-LT protocol, TLM-AT allows to model the pipelining of transactions; multiple transactions can be processed simultaneously by one target.
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 coding style is the protocol used to implement the processor model and the cache model in Section \ref{sec:implementation} of this thesis.
Some of the earlier described shortcuts are taken advantage of throughout those models.