From a3ce6f3d264311fe85363b5df04a8c1ae75af564 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=C3=89der=20F=2E=20Zulian?= Date: Thu, 12 Jul 2018 08:30:51 +0200 Subject: [PATCH] Doc improved --- README.md | 26 ++++++++++++++------------ 1 file changed, 14 insertions(+), 12 deletions(-) diff --git a/README.md b/README.md index 11d12777..e61c5a51 100644 --- a/README.md +++ b/README.md @@ -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**