derek/DRAMSys
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

doc improved

Browse Source
This commit is contained in:
Éder F. Zulian
2018-07-20 09:42:04 +02:00
parent 82d4c164f0
commit ed5b0c30fe
1 changed files with 10 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files

20
README.md
View File

@@ -909,10 +909,10 @@ there are no pending requests in the memory controller's buffer. This can be
done in order to prepare for possible accesses that might happen in the
future. When a burst of REF commands is initiated a REF command is issued (due
to the current tREFIx) followed by one or more REF commands separated in time
by tRFCx. If, at any point, requests start coming in, the burst is
interrupted, meaning that the maximum amount of time, considering the worst
case scenario (a request arrives at the same time a REF was issued), is a
refresh cycle time (tRFCx).
by tRFCx. The burst is interrupted if requests arrive, meaning that the
maximum additional delay for a request (considering the worst case scenario in
which a request arrives at the same time a REF is issued) is a refresh cycle
time (tRFCx).
The advantage of pulling-in refreshes is that they will not be issued in the
near future, i.e., in their actual times multiples of tREFIx, allowing for
@@ -926,12 +926,12 @@ controller's buffer. Buffered requests may generate row-hits, so postponing
refreshes may be beneficial for it avoids breaking row-hit sequences what
reduces the number of commands (e.g., ACT, PRE) to carry out the memory
accesses and improves the overall system preformance because accesses that are
row-hits consume less time. If the memory is idle, in the next refresh
interval (tREFIx) a burst is issued for the same number of REF commands
postponed plus the actual refresh for that tREFIx. When the maximum number of
postponed refreshes is reached a burst is issued in the next tREFIx despite
the state of the memory controller's buffer (empty or not). A burst of
postponed refreshes cannot be interrupted.
row-hits consume less time. After postponing refreshes, if there are no
pending requests in the next refresh interval (tREFIx) a burst is issued for
the same number of REF commands postponed plus the actual refresh for that
tREFIx. When the maximum number of postponed refreshes is reached a burst is
issued in the next tREFIx despite the state of the memory controller's buffer
(empty or not). A burst of postponed refreshes cannot be interrupted.
**The Flexible Refresh FSM**