From ed5b0c30fe909f4f0212a9a2371103126e5dcbcf Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=C3=89der=20F=2E=20Zulian?= Date: Fri, 20 Jul 2018 09:42:04 +0200 Subject: [PATCH] doc improved --- README.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/README.md b/README.md index d6f99a44..165b505a 100644 --- a/README.md +++ b/README.md @@ -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**