Refresh - 1.1 English - PG313

Versal Adaptive SoC Programmable Network on Chip and Integrated Memory Controller 1.1 LogiCORE IP Product Guide (PG313)
Document ID
PG313
Release Date
2024-11-13
Version
1.1 English

The Versal Memory Controller issues refreshes to the DRAM automatically. The controller will issue refreshes as needed to maintain data integrity of the DRAM.

Note: The Versal Memory Controller does not automatically adjust refresh rate in response to temperature changes. When configuring the AXI NoC parameters on the DDR Memory tab, you must set tREFI (ps) according to the DRAM refresh interval requirement at the maximum intended operating temperature. Consult the DRAM vendor datasheet for tREFI requirements.

For LPDDR4/4X, the Versal Memory Controller supports all-bank or per-bank refreshes; however, per-bank refresh is only supported for single-rank systems running at 1250 Mb/s or faster. Dual-rank systems do not support per-bank refresh.

For DDR4, fine granularity refresh modes of 1x, 2x, and 4x are supported in the following configurations:

1x
All configurations
2x
Configurations with equal or less than eight logical ranks (ranks * stacks)
4x
Configurations with equal or less than four logical ranks (ranks * stacks)

On-the-fly refresh for DDR4 is not supported.

During normal DDR4 operation and when operating LPDDR4/4x in all-bank refresh mode the Versal DDRMC will block accesses to the rank which requires the refresh. Next it will issue a Precharge All command to the rank and then it will issue the Refresh command. The Versal DDRMC does not support Auto Precharge for Write/Read commands to opportunistically Precharge Banks before a Refresh command.

User Refresh and ZQ Periodic Calibration

The MC has two main refresh modes, internal and user, the default being internal. There is no support for switching between these two modes on the fly. User refresh mode can be enabled from the GUI while configuring the memory IP. Refer to the DDR Advanced Tab in Configuring the Memory Controller. This will create additional ports that can be controlled through PL.

Table 1. User Refresh Port List
Port Name IO
ref_req_* Obsolete input - unused
ref_rank_en_<channel>_<controller>[3:0] input
ref_ack_<channel>_<controller>[3:0] output
ref_usr_port_available/cal_done output

After DDRMC calibration, the DDRMC is initially left in internal refresh mode. This is to ensure that DRAM refresh requirements are handled to maintain any data in DRAM before the user's PL and software are ready to assume responsibility for refresh. Examples of this could be memory fill that was done to initialize ECC check bytes, or PS system software.

When you are ready to take over refresh, the software must disable refresh, enable user refresh mode, and reenable refresh. To disable refresh, set DDRMC_MAIN.reg_config1.ref_en_0 and ref_en_1 to 0. To switch to user refresh mode, change DDRMC_MAIN.reg_config1.ref_mode from 0 to 1. To reenable refresh, set DDRMC_MAIN_reg_config1.ref_en_0 to 1, and for a dual-channel DDRMC, also set DDRMC_MAIN.reg_config1.ref_en_1 to 1.

Note: This changeover must be completed by software within a limited time so as not to violate the DRAM refresh postponement specification of 9*tREFI. For example, if the LPDDR4 temperature requires a 4x refresh rate, the allowed postponement time is 9*tREFI/4 = 9*3.9 us/4 = 8.7 us. Further, you are required to be aware of the postponement, to issue extra refreshes to catch up before postponing any additional refreshes.

In user mode, the refresh request can be made in rank-wise granularity, with separate controls for each channel. A four-bit request vector can be used to implement this from PL. The ref_rank_en interface controls when the controller’s per-rank “pending refresh counters” are incremented.

Each request/acknowledge pair corresponds to a single DDRMC channel, with one bit per physical rank. Each pair operates independently of the other pairs. The ref_rank_en signals are driven by PL and are asynchronous to the DDRMC clock. The ref_ack signals are driven by the DDRMC and are asynchronous to the PL clock. It is up to the receiving clock domain to synchronize the signals before use to avoid metastability problems.

After the ref_usr_port_available/cal_done is asserted then ref_rank_en can be asserted high by the PL and needs to stay asserted until it detects a high on the corresponding ref_ack. Completing this handshake signifies that the DDRMC has incremented the associated “pending refresh counter” by one and will schedule the refresh as soon as the controller can halt system traffic and DRAM timing is safe. To initiate another user request, the PL must deassert ref_rank_en, wait for ref_ack to deassert, and then assert ref_rank_en again to start the handshake cycle over again. This process is broken down into the following individual steps:

Following is the handshake flow to request one refresh command:

  1. PL waits for ref_usr_port_available / cal_done to assert
  2. PL asserts ref_rank_en
  3. PL waits for corresponding ref_ack bit to assert
  4. PL de-asserts ref_rank_en
  5. PL waits for corresponding ref_ack bit to de-assert
  6. PL can loop back to step 2 to request another refresh

The following timing diagram shows two refresh request handshake cycles, with two timing parameters, t_EN_HOLD and t_ACK_DLY. t_EN_HOLD is a requirement for the PL, and t_ACK_DLY is a requirement for the DDRMC.

Figure 1. Timing Diagram
Table 2. Timing Parameters
Timing Parameter Minimum Maximum
t_EN_HOLD 0 n/a
t_ACK_DLY 0 16 mc_clk cycles
Note:
  1. In user mode the MC does not track tREFI or postponed Autorefreshes. Instead, it issues refreshes when it receives a request to a target rank through the PL.
  2. The maximum interval to schedule a refresh is 7*tREFI, namely the maximum number of postponed refreshes for a target is 6. Failure to meet this requirement will possibly violate the tRAS max.
  3. In user refresh mode with LPDDR4, per-bank refresh is not allowed.
  4. For a multi-rank system made up of DDR4 3DS devices, you must make a refresh request to all the ranks during every request.
  5. While under single channel configuration, enable the clock gate for channel 1 or make a refresh request to both channels (even when channel 1 is not configured) to work successfully under the user refresh mode.
  6. The number of refresh requests made to each of the ranks should be the same by every (tREFI/refresh_rate).
  7. When ref_usr_port_available/cal_done are deasserted, the DDRMC will not execute any user requested refreshes.
  8. The ZQCS/ZQCal_START command will be issued internally at ZQ interval following a refresh command requested through PL. If you do not want periodic ZQ calibration then block_periodic_cal_* should be asserted.