\section{DRAMSys}
\label{sec:dramsys}

DRAMSys is an open-source design space exploration framework, capable of simulating the latest \revabbr{Joint Electron Device Engineering Council}{JEDEC} DRAM standards.
It is optimized to achieve high simulation speeds and utilizes the TLM-AT coding style while still achieving cycle-accurate results \cite{Steiner2020}.

DRAMSys is composed of an arbitration \& mapping unit (also called arbiter) and independent channel controllers, each driving one DRAM channel.
The general architecture of DRAMSys is illustrated in Figure \ref{fig:dramsys}.

\begin{figure}[!ht]
\begin{center}
\includegraphics{img/dramsys.pdf}
\caption{Structure of DRAMSys \cite{Jung2017}.}
\label{fig:dramsys}
\end{center}
\end{figure}
% doch noch über interne funktionen schreiben
Multiple initiators can be connected to DRAMSys simultaneously and send requests to the DRAM subsystem independently.
An initiator can either be a sophisticated processor model like the gem5 out of order processor model \cite{Binkert2011} or a more simple trace player that replays a trace file containing a sequence of memory requests with timestamps.

To support a variety of DRAM standards in a robust and error-free manner, DRAMSys uses a formal domain-specific language based on \textit{Petri nets} called \textit{DRAMml}.
Using this language, all timing dependencies between DRAM commands of a standard can be defined.
From this formal description, the source code of internal timing checkers is generated, which ensure compliance to the specific standard \cite{Jung2017a}.

Since a single memory access can result in the issuance of multiple commands (e.g. a precharge (\texttt{PRE}), an activate (\texttt{ACT}), a read (\texttt{RD}) or a write (\texttt{WR})), the four-phase handshake of the TLM-AT protocol is not sufficient to model the communication between the DRAM controller and the DRAM device.
Therefore, a custom TLM protocol called DRAM-AT is used as the communication protocol between the channel controller and the DRAM device \cite{Steiner2020}.
This custom protocol introduces a \texttt{BEGIN} and \texttt{END} phase for every available DRAM command.
Which commands can be issued depends on the DRAM standard used.

Some of the internal modules of DRAMSys and their functionalities will now be explained.
The task of the \textit{arbiter} is to accept the incoming transactions from the various initiators and to decode the address according to the configured address mapping.
From there, the transactions are passed to the channel controller.

The channel controller is the most important module of the DRAM simulation, consisting of a \textit{scheduler}, \textit{bank machines}, \textit{refresh managers}, \textit{power down managers}, a \textit{response queue} and a \textit{command multiplexer}.
New incoming requests are placed into the scheduler.
The purpose of the scheduler is to group transactions by their corresponding memory bank and reorder the payloads according to a predefined policy.
Available policies are, for example, the \textit{first-in, first-out} or the \textit{first-ready - first-come, first-served} policy.
The former policy does not reorder payloads and therefore optimizes for a short response latency and whereas the latter policy does reorder payloads and optimizes for a high memory bandwidth.

A bank machine, whose responsibility is to manage the state of its corresponding memory bank, then fetches the next transaction from the scheduler.
There are also a number of available policies for the bank machines, each of which determine in which state the bank is being held after memory request is completed.

With the fetched transaction, the bank machine then selects the command that it needs to send to its memory bank.
However, the selected command can not be sent instantaneously to the DRAM, as complex timing constraints need to be satisfied before the issuance of a specific command.
To meet these timing requirements, the bank machine uses the so-called \textit{timing checker} to check whether the selected command may be sent to memory.
The bank machine then tries to enque the command, so that the controller can send it to the DRAM.

The task of the command multiplexer is to select one command out of all commands that have been enqueued by the bank machines, the refresh managers or the power down managers.
The command multiplexer also has a set of configurable policies, that determine the individual priorities of the commands.
The selected command is then sent to the DRAM by the controller.

The last important module to mention is the response queue.
A completed DRAM transaction is enqueued into the response queue by the controller to send the responses back to the initiators.
In the response queue, transactions can either be returned to the initiator according to the scheme \textit{first-in, first-out} or be reordered in the queue.
A reordering might be necessary to be able to support initiators that can not handle \textit{out-out-order} responses.

% Evtl TA falls Bilder genutzt werden?
DRAMSys also provides the so-called \textit{Trace Analyzer}, a graphical tool that visualizes database files created by DRAMSys.
% It makes visible the \texttt{REQ} and \texttt{RESP} phases between the initiator and the arbiter, the occupation of the command bus and data bus as well as representations of the different phases in the DRAM banks.
An example trace database, visualized in the Trace Analyzer is shown in Figure \ref{fig:traceanalyzer}.
Furthermore, the Trace Analyzer is capable of calculating numerous metrics and creating plots of interesting characteristics.

\begin{figure}
\begin{center}
\includegraphics[width=\linewidth]{img/traceanalyzer.pdf}
\caption[Exemplary visualization of a trace database in the Trace Analyzer.]{Exemplary visualization of a trace database in the Trace Analyzer. The used DRAM consists of one rank and eight bank groups with two banks each.}
\label{fig:traceanalyzer}
\end{center}
\end{figure}

In Section \ref{sec:implementation} of this thesis, a new simulation frontend for DRAMSys will be developed.
