Fixes from Niklas, Johannes, Hendrik

This commit is contained in:
2022-08-05 10:54:38 +02:00
parent 98add62119
commit 27ec50fab7
8 changed files with 48 additions and 53 deletions

View File

@@ -4,7 +4,7 @@
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.
DRAMSys is composed of an arbitration and 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]
@@ -35,7 +35,7 @@ The channel controller is the most important module of the DRAM simulation, cons
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.
The former policy does not reorder payloads and therefore optimizes for a short response latency, whereas the latter policy reorders 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.
@@ -52,12 +52,12 @@ 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.
A reordering might be necessary to be able to support initiators that can not handle \textit{out-of-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}.
An exemplary 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}