The UI can be configured by the Vivado IDE to enable two DRAM Refresh modes. The default mode configures the UI and the Memory Controller to automatically generate DRAM Refresh and ZQCS commands, meeting all DRAM protocol and timing requirements. The controller interrupts normal system traffic on a regular basis to issue these maintenance commands on the DRAM bus.
The User mode is enabled by checking the Enable User
Refresh and ZQCS Input option in the Vivado IDE. In this mode, you are responsible for issuing Refresh and
ZQCS commands at the rate required by the DRAM component specification after
init_calib_complete asserts High. You use the
app_ref_req and app_zq_req signals on the UI to
request Refresh and ZQCS commands, and monitor app_ref_ack and
app_zq_ack to know when the commands have completed. The controller
manages all DRAM timing and protocol for these commands, other than the overall Refresh
or ZQCS rate, just as it does for the default DRAM Refresh mode. These
request/ack ports operate independently of the
other UI command ports, like app_cmd and app_en.
The controller might not preserve the exact ordering of maintenance transactions presented to the UI on relative to regular read and write transactions. When you request a Refresh or ZQCS, the controller interrupts system traffic, just as in the default mode, and inserts the maintenance commands. To take the best advantage of this mode, you should request maintenance commands when the controller is idle or at least not very busy, keeping in mind that the DRAM Refresh rate and ZQCS rate requirements cannot be violated.
The following figure shows how the User mode ports are used and how they affect
the DRAM command bus. This diagram shows the general idea about this mode of operation
and is not timing accurate. Assuming the DRAM is idle with all banks closed, a short
time after app_ref_req or app_zq_req signals are asserted High for one system clock cycle, the
controller issues the requested commands on the DRAM command bus. The app_ref_req and app_zq_req
signals can be asserted on the same cycle or different cycles, and they do not have to
be asserted at the same rate. After a request signal is asserted High for one system
clock, you must keep it deasserted until the acknowledge signal asserts.
The following figure shows when the app_en is asserted and
read transactions are presented continuously to the UI when the
app_ref_req and app_zq_req are asserted. The
controller interrupts the DRAM traffic following DRAM protocol and timing requirements,
issues the Refresh and ZQCS, and then continues issuing the read transactions. Note that
the app_rdy signal deasserts during this sequence. It is likely to
deassert during a sequence like this because the controller command queue can easily
fill up during tRFC or tZQCS. After the maintenance commands are issued and normal
traffic resumes on the bus, the app_rdy signal asserts and new
transactions are accepted again into the controller.
The previous figure also shows the operation for a single-rank. In a multi-rank system, a single refresh request generates a DRAM Refresh command to each rank, in series, staggered by tRFC / 2. The Refresh commands are staggered because they are relatively high power consumption operations. A ZQCS command request generates a ZQCS command to all ranks in parallel.