\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.

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 then used to connect modules with each other, creating the structure of the simulation.
There are two ways to implement a process in a module:
% \begin{itemize}
%  \item
    An \texttt{SC\_METHOD} are sensitive to \texttt{sc\_event}s or other signals.
    They can be executed multiple times.
%  \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 call explicitly \texttt{wait()} to wait a specific time or on events.
% \end{itemize}
Moreover, there is \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.

Those concepts being introduced will become important in Section \ref{sec:implementation} where the implementation of several SystemC modules will be discussed.

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 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 as well as the actual data to transfer.
GPs are passed along 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}.]{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 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 the initiator has to wait for the transaction to complete until it can make the next request.
However, the fast simulation time, especially when \textit{temporal decoupling} with \textit{quantums} is used, makes it possible to use this coding style for rapid software development, like developing drivers for a simulated hardware component.
For such a task the timing accuracy is sufficient.

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 to conduct design space exploration on a hardware level.
With AT, a special protocol is used that 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 yet ready to accept a new request, it defers its \texttt{END\_REQ} phase until it is.
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}.

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 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.
Both in the \texttt{BEGIN\_REQ} phase as well as in the \texttt{BEGIN\_RESP} phase, it is possible for the target to skip the \texttt{END\_REQ} phase or for the initiator to skip the \texttt{END\_RESP} phase respectively using the return value of the forward or backward transport function call.
For this the return type \texttt{tlm\_sync\_enum} has to be set to \texttt{TLM\_UPDATED} instead of \texttt{TLM\_ACCEPTED} in the normal case.

Besides using the return path to skip the \texttt{END\_REQ} phase, it is possible for the target to directly respond with the \texttt{BEGIN\_RESP} phase.
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, this shortcut should only be used if the response is ready to send after a very short delay.
Another form of this shortcut, is the combination with the 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, 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 is modeled using only one function call.
Early completion can also be used by the initiator to skip the \texttt{END\_REQ} phase.
Here, \texttt{TLM\_COMPLETED} is returned during the backward transport call and thus, the target experiences no backpressure from the initiator.

SystemC also supports additional user-defined phases through its \texttt{DECLARE\_EXTENDED\_\\PHASE()} macro.
In contrast to the TLM-LT protocol, TLM-AT allows model 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 used protocol to implement the processor model and the cache model in Section \ref{sec:implementation} of this thesis.
Also, some of the earlier described shortcuts are taken advantage of throughout those models.
