Fixes from Niklas, Johannes, Hendrik
This commit is contained in:
@@ -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}
|
||||
|
||||
Reference in New Issue
Block a user