From 7ca63967660e8faf882c5e37c0ee918a05a6f245 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=C3=89der=20F=2E=20Zulian?= Date: Thu, 5 Jul 2018 13:12:39 +0200 Subject: [PATCH] Doc improved --- README.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index cf8df867..b14bbbd6 100644 --- a/README.md +++ b/README.md @@ -889,7 +889,7 @@ 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 -will not issued in the near future (in their actual times), allowing for more +will not be issued in the near future (in their actual times), allowing for more efficient accesses to the memory. **Postpone Refresh** @@ -899,7 +899,9 @@ 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. +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). **The Flexible Refresh FSM**