From 2e307d00e89cf1e52fa65a3c2de539ee147cf42f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=C3=89der=20F=2E=20Zulian?= Date: Thu, 5 Jul 2018 08:09:36 +0200 Subject: [PATCH] Doc improved --- README.md | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/README.md b/README.md index ed4b1a61..74a1cde4 100644 --- a/README.md +++ b/README.md @@ -887,18 +887,19 @@ 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 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 tRFC. -The advantage of pulling-in refreshes is that they will not issued in the -near future (in their actual times), allowing for more efficient accesses to -the memory. +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 +will not issued in the near future (in their actual times), allowing for more +efficient accesses to the memory. **Postpone Refresh** Similarly, the decision to postpone a refresh is done if there are pending requests on the buffer. Given that having requests might mean a hit, we want -to postpone the refresh to minimize the PREA commands needed. If the memory -enters an idle state, a burst is issued for the same number of REF commands -that were postponed. +to postpone the refresh to avoid breaking row hit sequences and reducing 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. **The Flexible Refresh FSM**