uMCTL2-Refresh Controls

2024-12-13

uMCTL2手册2.17，DDR控制器中的刷新（Refresh）控制机制

2.17.1 刷新控制概述

1. 刷新控制的两种方式

刷新操作可以通过以下两种方式进行：

自动刷新（Auto-Refresh）：这是一种由uMCTL2内部自动执行的刷新方式。
直接软件请求（Direct Software Request）：这是一种由软件直接请求的刷新方式。

在uMCTL2中，选择刷新方式的控制是通过寄存器 RFSHCTL3.dis_auto_refresh 来配置的。具体行为如下：

当 RFSHCTL3.dis_auto_refresh 设置为 1 时，控制器使用 直接软件请求刷新，也就是说，刷新操作需要由软件手动发起。
当 RFSHCTL3.dis_auto_refresh 设置为 0 时，控制器将使用 自动刷新 功能，即uMCTL2会根据内部的机制自动发起刷新操作。

2. 刷新机制与电源管理

尽管在某些情况下不需要保留DRAM内容，但有些设备仍然可能要求在特定的电源状态下执行刷新操作。这包括当：

VDDQ, VDD, 和 VPP 电源被激活时（即电源仍然存在），
DRAM处于空闲或断电状态（IDLE 或 Powerdown） 时。

换句话说，即使在不需要保留数据的情况下，某些设备仍需要周期性地执行刷新操作，以确保DRAM的内容不会因为长时间未访问而丢失。具体要求可以查看DRAM的相关文档。

3. 刷新控制的目的

刷新控制有几个主要的目的：

减少刷新周期对带宽的影响：刷新周期会占用一定的内存带宽，因此需要通过优化刷新控制来减少这一影响，避免不必要的带宽浪费。
提高在空闲期执行刷新的可能性：理想情况下，当系统处于空闲状态时，刷新操作可以在这段时间内完成，从而不会干扰正常的数据访问。
精细控制刷新与延迟的权衡：刷新操作需要消耗一定的时间和带宽，因此有时候必须在“收集刷新”的优势（尽量将刷新操作集中执行以减少带宽浪费）和“最坏情况下的延迟”之间进行权衡。通过细粒度的控制，能够根据系统的需求做出合适的选择。
允许在进行单个rank的刷新时，其他rank可以继续访问：对于多rank配置的uMCTL2，刷新操作通常会对某一个rank进行，而其他rank可以继续进行正常的数据读写。这有助于提高系统的并行性和效率。

2.17.2 Refresh Using Direct Software Request of Refresh Command

关于DDR4模式和细粒度刷新（FGR）的注意事项

在DDR4模式下，如果启用了细粒度刷新（Fine Granularity Refresh, FGR），那么当采用直接软件请求的方式进行刷新时，需要确保刷新命令的总数符合特定的倍数要求：

在固定2x模式下，总刷新命令数必须是2的倍数。
在固定4x模式下，总刷新命令数必须是4的倍数。

这种要求是为了确保在进入自刷新模式（Self Refresh）之前，刷新命令的数量能够正确地满足硬件的要求。

步骤：将uMCTL2设置为直接软件请求刷新模式

为了将uMCTL2设置为通过软件直接请求刷新命令的模式，需按以下步骤操作：

步骤1：设置RFSHCTL3寄存器的 dis_auto_refresh 位
- 将寄存器 RFSHCTL3.dis_auto_refresh 设置为 1 时，uMCTL2会检查是否有待处理的刷新请求。如果有，它会立即使用内部的“关键刷新（critical refresh）”功能发出这些刷新命令。刷新命令发出后，uMCTL2的所有刷新定时器将被重置为0，只有当自动刷新功能重新启用时，定时器才会被重新激活。
步骤2：系统需要跟踪SDRAM的刷新需求
- 系统（SoC）需要管理和跟踪内存的刷新需求，包括刷新间隔等信息。
步骤3：发出刷新命令
- 通过设置 DBGCMD.rank*_refresh 寄存器位为 1，可以发起刷新命令。每个rank的刷新请求会被存储在uMCTL2的寄存器中，控制器在 DBGSTAT.rank*_refresh_busy 位为低电平时，才能发出刷新命令。uMCTL2会尽早地向SDRAM发出刷新命令。
- 如果DIMM的控制器（DIMMCTL.dimm_stagger_cs_en）启用了且 MSTR.ddr4 == 0，并且刷新命令目标是偶数和奇数rank时，uMCTL2会分别向偶数rank和奇数rank发出两条刷新命令。
步骤4：软件驱动的刷新命令
- 每个rank的刷新命令会被加载到一个9个条目的缓冲区中。当uMCTL2认为合法时，它会通过DFI（DRAM接口）发出这些命令。刷新请求之间必须遵守最小刷新间隔 tRFC(min)。如果刷新命令的缓冲区被填满，DBGSTAT.rank*_refresh_busy 会被置为高电平，这样软件就无法再发起新的刷新命令，直到缓冲区有空闲空间。

关于刷新命令的批量操作

你可以发出一系列连续的刷新命令，而不需要每次都轮询 DBGSTAT.rank*_refresh_busy 寄存器字段。这种做法可以将刷新命令之间的时间间隔缩短到最小，但存在一定的风险：
- 如果刷新缓冲区在开始批量刷新时已经满了，或者刷新命令的数量超过了9个命令，刷新缓冲区将会饱和，此时 DBGSTAT.rank*_refresh_busy 会被置为高电平，意味着一些命令将无法添加到缓冲区。这样，实际发出的刷新命令数量就可能少于软件请求的数量。