Skip to content
DenseChip
Learn
PracticeCode labInterview

DenseChip

Navigate

Menu

LearnPracticeCode labInterview

Tools

All toolsSV editorCode repoResume
DenseChip

Practice, courses, and chip-design tools in one focused workspace.

LearnPracticeCode labInterviewToolsLearning paths

© 2026 DenseChip

AboutRoadmapCareersInternshipsFAQContactPrivacyTerms
Skip to lesson

Course contents

  • How to Use This Course
  • Protocol Metrics Reference
  • Protocols Glossary
  • Reading Path
  • Protocol Fundamentals25
  • AMBA Family (APB / AHB / AXI)17
  • Coherence Fabrics (ACE / CHI)17
  • Memory Interfaces (DDR / LPDDR / HBM)17
    • DDR Controller / PHY Split
    • Training & Timing Modes
    • Refresh & Bandwidth Efficiency
      • Refresh & Bandwidth Efficiency: Concepts
      • Refresh & Bandwidth Efficiency: Integration
      • Refresh & Bandwidth Efficiency: Debug
      • Refresh & Bandwidth Efficiency: Interview
    • Memory Interface Debug
    • Memory Interfaces (DDR / LPDDR / HBM): Tricky Q&A
  • PCIe & CXL17
  • Embedded Peripherals (I2C / SPI / UART)17
  • High-Speed I/O (USB / Ethernet / MIPI)17
  • Protocol Verification & Compliance17
  • Protocols Interview Prep5
  • Interface Protocols Cheatsheet
Loading lesson

←Refresh & Bandwidth Efficiency
  1. Topics
  2. Bus Protocols
  3. Memory Interfaces (DDR / LPDDR / HBM)
  4. Refresh & Bandwidth Efficiency
  5. Refresh & Bandwidth Efficiency: Concepts
On this page

    Interface ProtocolsAll levels

    Refresh & Bandwidth Efficiency: Concepts

    Concepts for Refresh & Bandwidth Efficiency.

    Core concepts

    Refresh mechanics

    DRAM cells leak charge, so the controller must meet the selected device's refresh requirements. tREFI is the average interval between refresh commands, not the time in which every row is refreshed. For a concrete DDR4 example, Frontgrade UT8SD4MQ2G72 datasheet version 0.0.3, page 47, specifies 8,192 refresh cycles over 64 ms at 0–85°C, with tREFI approximately 7.8 µs. A single refresh command covers only part of that overall work.

    tRFC is the refresh recovery interval, a different timing parameter from tREFI. Which banks or ranks are unavailable depends on the selected device and refresh mode. Do not assume a per-bank refresh option exists just because a device is DDR4. Any refresh postponement must stay within its specified limits; the controller cannot defer required refresh indefinitely.

    Diagram
    REFRESH TIMESCALES (not to scale)
    
    REF command -> recovery tRFC -> service -> next REF
    |<---------- average interval tREFI ---------->|
    
    Many REF commands cover the full refresh window.
    tREFI is not that window and is not the stall duration.
    
    Example question: is the 64 ms window one continuous stall?
    No. Commands and their recovery intervals are distributed over it.
    • Estimate refresh occupancy from the selected mode's tRFC and refresh schedule; measure workload delay separately.

    • All-bank refresh makes the selected rank unavailable; other-rank scheduling depends on the controller and shared channel constraints.

    • Low-power self-refresh has its own entry/exit latency cost.

    Bank conflicts and row buffer policy

    A row hit finds the requested row already active, so the controller can schedule a column READ or WRITE when timing permits. An idle bank has no active row and needs ACTIVATE before the column command. A row conflict finds a different row active in that bank and therefore needs PRECHARGE, ACTIVATE and then the column command, subject to the selected device's timing values.

    Sequential requests can create row hits when address mapping and row boundaries keep them in the same active row. Strided or random requests may create conflicts, but bank interleaving, scheduler reordering and the exact address map determine the result. Measure command counts and latency for the actual replay rather than assigning generic nanosecond ranges.

    Diagram
    BANDWIDTH LOSS WATERFALL
    
    peak              ████████████████████████
    - refresh           █████████████████████
    - turnaround        ██████████████████
    - row miss          ██████████████
    effective           ██████████████

    Key takeaways

    • Estimate refresh occupancy from the selected mode's tRFC and refresh schedule; measure workload delay separately.

    • All-bank refresh makes the selected rank unavailable; other-rank scheduling depends on the controller and shared channel constraints.

    • Low-power self-refresh has its own entry/exit latency cost.

    Previous

    72 / 154

    Next: Refresh & Bandwidth Efficiency: Integration

    Up next

    Up nextRefresh & Bandwidth Efficiency: Integration

    Sign in to save progress

    Practice this lessonPrevious lessonReport an error

    See also

    • Refresh & Bandwidth Efficiency: Debug
    • Refresh & Bandwidth Efficiency: Interview