| Line 141... |
Line 141... |
\chapter{Architecture}
|
\chapter{Architecture}
|
|
|
% This section describes the architecture of the block. A block level diagram
|
% This section describes the architecture of the block. A block level diagram
|
% should be included describing the top level of the design.
|
% should be included describing the top level of the design.
|
|
|
|
\section{Strategies}
|
|
\subsection{Bank}
|
|
Currently, banks are activated (opened) when needed and only precharged
|
|
(closed) upon refresh request. Further, upon any read or write from one bank,
|
|
the next bank is activated as well, under the assumption that the next bank
|
|
will be needed soon. This is necessary to allow pipeline access with no stalls
|
|
through the memory controller.
|
|
|
|
This means that, upon any bank miss, a bank precharge followed by bank activate
|
|
command will be necessary.
|
|
|
|
\subsection{Refresh}
|
|
The current build will pause all operations for four subsequent refreshes,
|
|
at roughly every 4 refresh intervals, and then allow operations to resume.
|
|
This pause is independent of anything going on, and includes a mandatory
|
|
wait for any writes to finish, followed by a precharge command---regardless of
|
|
whether or not such is required.
|
|
|
|
This is non-optimal, and ripe for optimizing later. A better strategy might
|
|
be to do singular refreshes after any single refresh period assuming the bus
|
|
is free, to only issue a precharge if the bus is busy, and to only wait
|
|
prior to that precharge if a write is busy. This will be a later optimization.
|
|
|
\chapter{Operation}
|
\chapter{Operation}
|
|
|
% This section describes the operation of the core. Specific sequences, such
|
% This section describes the operation of the core. Specific sequences, such
|
% as startup sequences, as well as the modes and states of the block should be
|
% as startup sequences, as well as the modes and states of the block should be
|
% described.
|
% described.
|
