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.