Update on Overleaf.
This commit is contained in:
@@ -308,7 +308,7 @@ This disables parts of the core and interface.
|
||||
However, in order to perform refreshes for data retention, it is necessary to interrupt the power down mode periodically.
|
||||
To avoid this, the self refresh mode can be entered where data retention is managed by the device itself and no refresh commands need to be provided by the memory controller.
|
||||
%
|
||||
\subsection{Interface}
|
||||
\subsection{Interface}\label{subsec:background_interface}
|
||||
%
|
||||
All modern DRAM subsystems use a bidirectional single-ended \textit{data bus} (DQ) to transfer data from the memory controller to the DRAM devices or the other way round.
|
||||
To sample the data at the correct time, a differential \textit{data strobe} pair (DQS\_t/DQS\_c) is provided by the driving side.
|
||||
@@ -983,7 +983,7 @@ Figure~\ref{fig:power_comp} shows the total power dissipation at different opera
|
||||
%
|
||||
While Equation~\ref{eq:fourier} always provides the same results as SPICE, Equation~\ref{eq:approx} is accurate at low frequencies, but overestimates the power dissipation at higher frequencies, e.g., by \SI{15}{\percent} at \SI{3200}{\mega\hertz} (DDR5-6400) and even \SI{27}{\percent} at \SI{4200}{\mega\hertz} (DDR5-8400, the highest specified data rate in the standard).
|
||||
|
||||
The impact of the transmission line can be handled in different ways.
|
||||
\todo{The impact of the transmission line can be handled in different ways.}
|
||||
In \cite{holsta_19}, the authors have analyzed various physical DRAM interfaces, i.e., multi DIMM, package on package, PCB trace and silicon interposer.
|
||||
They show that the channels have very distinct insertion loss characteristics, which need to be taken into consideration for an accurate power estimation.
|
||||
A linear loss characteristic can be approximated with matching capacitances, while more complex loss characteristics can be approximated with frequency-dependent resistance values in the Fourier series based calculation.
|
||||
@@ -1106,21 +1106,21 @@ This section provides a short introduction to the internal software architecture
|
||||
Afterwards, the simulation speed and simulation accuracy are evaluated.
|
||||
%
|
||||
\subsection{Simulator Architecture}
|
||||
\todo{multi-rank simulation, voltage domains!!!}
|
||||
%
|
||||
The new version of DRAMPower is not designed as a standalone simulator, but as a library that is coupled to a DRAM subsystem simulator which models the DRAM controller and translates incoming read and write requests into DRAM commands.
|
||||
Alternatively, a DRAM command trace can be provided as an input file.
|
||||
For the interface power calculation, the provided commands, addresses and data are translated into equivalent bit patterns using the command truth table of the simulated standard.
|
||||
Based on this data, the number of transmitted zeros $n_0$, transmitted ones $n_1$ and zero to one transitions $n_{0 \rightarrow 1}$ can be calculated.
|
||||
To achieve high simulation speeds, bit manipulation instructions including the population count (\texttt{POPCNT}) instruction are used if available.
|
||||
To achieve high simulation speeds, bit manipulation instructions including the population count (\texttt{POPCNT}) instruction are used.
|
||||
If no data is provided, a switching activity $\alpha$ and a ratio between both logic levels \todo{name} has to be provided.
|
||||
In addition to the command/address and data bus, the remaining signals like the clock signal pair, data strobe pairs or chip select need to be considered.
|
||||
As explained in Section~\ref{sec:interface_power_modeling}, the interface power calculation can become very complex and can depend on lots of parameters.
|
||||
\todo{In order to avoid handling all these cases within DRAMPower, the tool receives only receives the termination and dynamic power values for all signals as inputs.}
|
||||
These calculations need to be carried out externally using the provided equations.
|
||||
In addition to the command/address and data bus, the remaining signals like the clock signal pair, data strobe pairs or chip select need to be considered (see Section~\ref{subsec:background_interface}).
|
||||
%As explained in Section~\ref{sec:interface_power_modeling}, the interface power calculation can depend on lots of parameters and, thus, can become very complex.
|
||||
%\todo{In order to avoid the complexity within DRAMPower, the tool only receives the precalculated termination and dynamic power values for all signals as inputs.}
|
||||
%These calculations need to be carried out externally using the provided equations.
|
||||
|
||||
The core power calculation is more complex because in addition to counting the number of issued commands of each type, DRAMPower needs to count the clock cycles that each DRAM device is in a specific state (i.e., 0 - B banks active, active/precharge power down, self refresh).
|
||||
This counting is made even more difficult by the fact that the internal state is not always changed immediately by an external command, but it can also change after a certain delay.
|
||||
The core power calculation is more complex because in addition to counting the number of issued commands of each type, DRAMPower needs to keep track of the clock cycles that the DRAM is in a specific state (i.e., 0 - B banks active, active/precharge power down, self refresh).
|
||||
If a configuration with multiple ranks is simulated, the counting has to be done separately for each rank.
|
||||
A further difficulty arises from the fact that the internal state is not always changed immediately by an external command, but it can also change after a certain delay.
|
||||
An example for this behavior is shown in Figure~\ref{fig:implicit_commands}.
|
||||
%
|
||||
\begin{figure}
|
||||
@@ -1134,12 +1134,12 @@ An example for this behavior is shown in Figure~\ref{fig:implicit_commands}.
|
||||
%
|
||||
When a read with auto precharge command (\texttt{RDA}) is issued, the target bank is automatically precharged after the read to precharge delay $t_{RTP}$ has expired.
|
||||
This means that the DRAM will internally issue what we call an \textit{implicit command} in the future.
|
||||
Unfortunately, DRAMPower is not based on an event-driven simulation kernel like SystemC where an event can be notified in the future.
|
||||
Instead, it is only triggered from the outside when issuing new commands, so the implicit commands need to be handled differently.
|
||||
Unfortunately, DRAMPower is not based on an event-driven simulation kernel like SystemC where an event can be directly notified in the future.
|
||||
Instead, it is only triggered from the outside when new commands are issued, so the implicit commands need to be handled differently.
|
||||
The actions that are performed by one implicit command are formulated as a lambda expression, which is stored in an internal list ordered by the time stamp of execution.
|
||||
Whenever DRAMPower is triggered from the outside, first, the list is searched from the beginning for implicit commands with time stamps less than or equal to the current simulation time.
|
||||
The lambda expressions of these list entries are then evaluated first before the external command is handled.
|
||||
The total power consumption can be calculated at any time and also during a simulation that is still running, which allows to analyze the power consumption over time.
|
||||
The total power consumption can be queried at any time even when the simulation is still running, which allows to analyze the power consumption over time.
|
||||
%
|
||||
%\subsection{Simulation Kernel}
|
||||
%%
|
||||
@@ -1196,6 +1196,14 @@ The total power consumption can be calculated at any time and also during a simu
|
||||
%
|
||||
\subsection{Simulation Speed}
|
||||
%
|
||||
As in the common use case DRAMPower is coupled to a behavioral
|
||||
|
||||
|
||||
|
||||
As DRAMPower is not intended as a standalone simulator, we evaluate the simulation speed
|
||||
|
||||
|
||||
|
||||
\begin{figure}
|
||||
\centering
|
||||
\resizebox{\linewidth}{!}{%
|
||||
|
||||
Reference in New Issue
Block a user