# tRAS definition for DDR memory

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.

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.

• but Micron document defines tRAS as the timing between ACTIVATE command and PRECHARGE command. Feb 17, 2021 at 16:33
• 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). Feb 17, 2021 at 16:41
• I understand that tRC = tRAS + tRP, why the tRC mentioned that no PRECHARGE is allowed in between ? Feb 18, 2021 at 0:43
• 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. Feb 19, 2021 at 18:46
• 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. May 17, 2021 at 16:16