Refresh - Refresh - 1.0 English - PG456

Integrated DDR5/LPDDR5/5X Memory Controller LogiCORE IP Product Guide (PG456)

Document_ID
PG456
Release_Date
2026-08-07
Version
1.0 English

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

For LPDDR5/5X, the Memory Controller supports all-bank or per-bank refreshes; however, per-bank refresh is only supported for single-rank systems running at 1600 Mb/s or faster. Refresh intervals of 1x, 0.5x, 0.25x, and 0.125x are supported. No refresh rate slower than 1x is supported.

For DDR5, Normal refresh is supported at tREFI and tREFI/4. Fine Granularity all-bank refresh is supported at tREFI/2 and tREFI/4. Fine Granularity same-bank refresh is supported at tREFI/16 and tREFI/32.

The Memory Controller supports dynamically adjusting the refresh interval in response to changes in DRAM temperature. The controller periodically reads DRAM mode register 4 to determine the required refresh interval. It then adjusts the refresh rate accordingly.

During normal DDR5 operation and when operating LPDDR5/5X in all-bank refresh mode the DDRMC5 blocks accesses to the rank which requires the refresh. Next it issues a Precharge All command to the rank and then it issues the Refresh command.

User Refresh and ZQ Periodic Calibration

The memory Controller 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.

Table 1. User Refresh Port List
Port Name IO
ref_rank_en_* Input
ref_ack_* Output
ref_usr_port_available Output

After DDRMC5 calibration, the DDRMC5 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 the user is ready to take over refresh, their software must disable refresh, enable user refresh mode, and re-enable refresh. To disable refresh, set DDRMC5_MAIN.reg_config1.ref_en_0 and ref_en_1 to 0. To switch to user refresh mode, change DDRMC5_MAIN.reg_config1.ref_mode from 0 to 1. To re-enable refresh, set DDRMC5_MAIN.reg_config1.ref_en_0 to 1, and for a dual-channel DDRMC5, also set DDRMC5_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 LPDDR5/5X temperature requires an 8x refresh rate, the allowed postponement time is 9*tREFI/8 = 9*3.906μs/8 = 4.39μs. Further, the user is required to be aware of the postponement, and 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, a four-bit request vector can be used to implement this from PL. In user refresh mode a PL interface controls when the controller’s per-rank “pending refresh counters” are incremented.

Each request/acknowledge pair corresponds to a single physical rank. Each pair operates independently of the other pairs. The ref_rank_en signals are driven by PL and are asynchronous to the DDRMC5 clock. The “ref_ack” signals are driven by the DDRMC5 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 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 DDRMC5 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 de-assert ref_rank_en, wait for ref_ack to de-assert, and then assert ref_rank_en again to start the handshake cycle over again. This process is broken down into individual steps below:

Following is the handshake flow to request one refresh command:

  1. PL waits for ref_usr_port_available 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 memory controller.

Figure 1. Timing Diagram
Table 2. Minimum/Maximum 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 5*tREFI(non FGR mode), namely the maximum number of postponed refreshes for a target is 4. Failure to meet this requirement will possibly violate the tRAS max.
  3. In user refresh mode with LPDDR5/5X, per-bank refresh is not allowed.
  4. The number of refresh requests made to each of the ranks should be the same by every (tREFI/refresh_rate).
  5. When ref_usr_port_available is de-asserted, the DDRMC5 will not execute any user requested refreshes.
  6. User refresh mode is automatically disabled when memory fill is enabled.
  7. PSX-only designs require internal refresh mode. Validate design will flag an error if user refresh mode is selected with a PSX-only design.