\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 device.
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
Several initiators can be connected to DRAMSys at the same time, sending requests independently to the DRAM subsystem.
An initiator can either be a sophisticated processor model like the gem5 out of order processor model \cite{Binkert2011} or a trace player that simply replays a trace file containing a sequence of memory requests and timestamps.

To support a large variety of DRAM standards robustly and error-free, DRAMSys uses a formal domain specific language based on Petri nets called DRAMml.
This language includes a standards timing dependencies between all DRAM commands and compiles to source code of the internal timing checkers that 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.
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 used DRAM standard.

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

The channel controller is the centerpiece 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 get placed into the scheduler.
The purpose of the scheduler is to group transactions by their accessed 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 a completed memory request.

With the fetched transaction, the bank machine then selects the command that it needs to send to its memory bank to enforce its policy.
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 obey those timing constraints, the bank machine verifies through the so-called \textit{timing checker} that the selected command is allowed to be sent to the memory.
The bank machine then tries to enque the command, so that the controller can send it out.

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 commands individual priorities.
The selected command then will be sent out to the DRAM by the controller.

The last important module to mention is the response queue.
The completed DRAM transactions are enqueued into the response queue to send the responses back to the initiators.
In the response queue, the responses can either be passed to the initiator using the \textit{first-in, first-out} scheme, or firstly be reordered in the queue itself.
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 shows 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}%[!ht]
\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 the new special traffic generator for DRAMSys will be developed.
