doc updated

README.md

@@ -890,6 +890,12 @@ by four in 4X mode. The maximum number of refresh commands that can be
 postponed or pulled-in is affected in the same manner. The number of rows per
 refresh command is divided by two and by four in 2X and 4X mode respectively.
 
+The nomenclature tREFIx is used to denote the refresh interval which value
+changes accordingly to the operation mode, e.g., in 2X mode tREFIx corresponds
+to tREFI/2. Similarly tRFCx denotes the refresh cycle time which value changes
+accordingly to the operation mode. Nevertheless, the values of tRFCx must be
+obtained from memory specifications, estimated, measured, etc.
+
 **Flexible Refresh**
 
 The feature can be used together with regular refresh, bankwise refresh and
@@ -898,29 +904,34 @@ with all refresh modes are possible.
 
 **Pull-In Refresh**
 
-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
+A pull-in starts when a refresh is triggered (in a multiple of tREFIx) and
+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 (tRFC). The advantage of pulling-in refreshes is that they
-will not be issued in the near future (in their actual times), allowing for more
-efficient accesses to the memory.
+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
+more efficient accesses to the memory.
 
 **Postpone Refresh**
 
 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). A burst of postponed
-refreshes cannot be interrupted.
+refresh due (multiple of tREFIx) there are pending requests on the memory
+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.
 
 **The Flexible Refresh FSM**