DRAM servicing policy: During DRAM maintenance, can a burst refresh operation and normal memory accesses be interspersed (i.e., mixed) with each other?

Introduction / Context:
Dynamic RAM (DRAM) periodically requires refresh cycles to retain data in its capacitive cells. Controllers can schedule refresh using different policies, including burst refresh (many rows back-to-back), distributed/hidden refresh, or self-refresh. Whether normal reads/writes can occur during a burst refresh affects latency and system design.

Given Data / Assumptions:

• Focus on the burst refresh policy, where multiple refresh cycles are issued consecutively.
• Normal CPU/DMAC memory operations contend for the same DRAM interface and banks during refresh.
• We use conventional synchronous DRAM behavior at a high level.

Concept / Approach:
During a burst refresh window, the controller dedicates the bus to issuing refresh commands for successive rows. Normal read/write commands are deferred until the burst completes. Hence they are not interleaved within that burst window. In contrast, a distributed refresh issues refresh commands periodically between normal commands, but that is a different policy from burst refresh.

Step-by-Step Solution:

Verification / Alternative check:
Timing diagrams from DRAM controllers show refresh “blocks” with no concurrent read/write activity. Hidden/auto-refresh features similarly block user commands for the duration of each refresh transaction.

Why Other Options Are Wrong:

• Correct: Would imply mixing operations inside the burst, which is not how burst refresh is defined.
• Ambiguous / Applies only to SRAM: SRAM does not need refresh; the statement concerns DRAM and is not ambiguous under standard definitions.

Common Pitfalls:
Confusing burst refresh with distributed refresh; assuming QoS schedulers allow overlap when the DRAM command bus is actually dedicated to refresh cycles.

Final Answer:
Incorrect