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-12 08:30:51 +02:00
parent 10723f588f
commit a3ce6f3d26
1 changed files with 14 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

26
README.md
View File

@@ -884,10 +884,10 @@ granular refresh (RGR).
**Pull-In Refresh**
A Pull-In is started when there are no pending requests in the buffer, meaning
the memory is in an idle state. Therefore, in order to prepare for possible
accesses that might happen in the future, a burst of REF commands is
initiated. If, at any point, requests start coming in, the burst is
A pull-in starts when there are no pending requests in the memory controller's
buffer, meaning the memory is in idle state. Therefore, in order to prepare
for possible accesses that might happen in the future, a burst of REF commands
is initiated. 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 (tRFC). The advantage of pulling-in refreshes is that they
@@ -896,14 +896,16 @@ efficient accesses to the memory.
**Postpone Refresh**
Similarly, the decision to postpone a refresh is done if there are pending
requests on the 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. If the memory enters an idle state, a burst is issued for the same
number of REF commands that were postponed. When the maximum allowed
number of postponed refreshes is reached a burst is issued in the next
refresh interval despite the memory state (busy or idle).
Similarly, the decision to postpone a refresh is done if by the time of a
refresh due there are pending requests on the 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 (accesses that are row-hits consume less time). If the memory is
idle, in the next refresh interval (tREFI) a burst is issued for the same
number of REF commands postponed plus the actual refresh for that tREFI. When
the maximum number of postponed refreshes is reached a burst is issued in the
next tREFI despite the memory state (busy or idle).
**The Flexible Refresh FSM**