In Figure 3 of https://www.systemverilog.io/understanding-ddr4-timing-parameters#refresh , why tRAS
is defined as the max timing between two REFRESH commands ? This seems contradicts with Micron document.
1 Answer
tRAS specifies the minimum and maximum window that a row can be ACTIVATEd for access. The maximum value is bounded by the limitations imposed by refresh.
Every row in the DRAM needs to be refreshed periodically. tREFI specifies the average interval between refresh operations (each operation refreshes one row). All rows need to be refreshed within some specified time (which is usually temperature dependent - hotter operation requires more frequent refresh to guarantee data integrity). This time might be 64ms for commercial temp range. Meaning, typically, that 8192 refresh operations need to occur within 64ms.
The datasheet allows you to defer a scheduled refresh up to 9 x tREFI (this can be helpful for performance, since you can keep accessing that row during that interval (instead of incurring the overhead of shutting down and re-opening the row). The timing parameters in the datasheet are very conservative. Meaning, if you don't violate them, data will never be corrupted. Overclockers take advantage of the conservative specmanship and violate these parameters, eating into the margin up until the point that it breaks, and then back off to their own level of comfort.
If the refresh operation is deferred, the controller needs to make up for that lost time somehow, such that the average refresh interval does not exceed tREFI. This can be done by issuing more refresh commands than necessary during idle times, but when things get busy, the controller will absolutely preempt access to keep refresh on track.
For DDR3, I think JEDEC specifies the amount of time debt as follows: controller must issue 8 refresh commands in 8*tREFI time window. In the limit, one could wait almost 8 full tREFIs, and then issue 8 refreshes in a row. It is similar in DDR4, although I think there are some new refresh features available there.
-
\$\begingroup\$ but Micron document defines
tRAS
as the timing betweenACTIVATE
command andPRECHARGE
command. \$\endgroup\$ Feb 17, 2021 at 16:33 -
1\$\begingroup\$ That is true. PRECHARGE is the complement to ACTIVATE. Meaning, you open a row with ACTIVATE and close it with PRECHARGE. This is what I was referring to in the first sentence above. It is necessary to close any open rows before issuing a refresh command. PRECHARGE command can close either one open bank or all open banks (each of which could have at most one row activated). \$\endgroup\$– TroutdogFeb 17, 2021 at 16:41
-
\$\begingroup\$ I understand that
tRC = tRAS + tRP
, why the tRC mentioned that no PRECHARGE is allowed in between ? \$\endgroup\$ Feb 18, 2021 at 0:43 -
1\$\begingroup\$ I suspect there is a misunderstanding there (I mean the mindshare doc is wrong, or they meant something else). tRC applies to successive ACTIVATES to the same bank. So, by definition, there is a PRECHARGE between the two ACTIVATES. Similarly, the open bank must be closed to issue a REFRESH, so there is a PRECHARGE there too. The timing numbers add up. \$\endgroup\$– TroutdogFeb 19, 2021 at 18:46
-
1\$\begingroup\$ No. It would be valid to add 1 extra to each tREFI for 8 cycles, or any other arrangement such that all pages are refreshed within 64ms. However, for performance reasons, it makes sense to make up the deficit all at once while the DRAM is idle if the opportunity presents itself. \$\endgroup\$– TroutdogMay 17, 2021 at 16:16