Refresh Bandwidth Impact

Four chapters have established what refresh requires, what a command retires, what the specification permits, and where the interval comes from. None of them has said what it costs.

The arithmetic is one division:

  unavailable fraction  =  refresh cycle time  /  refresh interval

That is the whole formula. What makes it worth a chapter is that this module has accumulated enough verified figures to evaluate it properly — and doing so produces three results that are not obvious, one of which contradicts the name of the feature it describes.

1. The Formula, and What It Does Not Mean

The fraction of a resource's time consumed by refresh is occupancy divided by interval. Both quantities are published, so the calculation needs no modelling at all.

2. The Verified Inputs

Everything in this chapter is computed from two tables, both from the same primary document.

Two observations before the arithmetic.

The occupancy is defined against two different following commands. REFRESH-to-ACTIVATE or REFRESH — so the same period governs both resuming normal traffic and issuing the next refresh. That matters for Chapter 15.3's catch-up bursts: back-to-back refresh commands are separated by the same occupancy, so a burst of 8 costs 8 × tRFC and not less.

The occupancy shrinks with the finer mode and the interval shrinks faster. tRFC4 is 160 ns against tRFC1's 350 ns — under half — while tREFI4 is a quarter of tREFI. §4 is where those two rates collide.

3. The Fraction, by Density

Normal temperature band, 1X mode.

The cost grows with density, from 3.33 % to 4.49 % — a 35 % relative increase — because a denser device has more rows to service per command and takes longer to do it.

And it plateaus between 8Gb and 16Gb, because those two densities share a tRFC1 of 350 ns in this table. That is worth noticing rather than smoothing over: the relationship between density and refresh cost is not a clean proportionality, it is whatever the device's own table says. A design that extrapolated 4Gb's 3.33 % linearly to 16Gb would predict something well above 4.49 % and be wrong in the safe direction — which is still wrong.

4. Fine Granularity Increases the Aggregate Cost

Here is the result that contradicts the intuition its name invites.

16Gb device, normal temperature band, across the three refresh modes:

The aggregate cost nearly doubles — 4.49 % to 8.21 % — while each individual blocking event shrinks by more than half.

And one more consequence, connecting back to Chapter 15.3. The finer modes also quadruple the postponement allowance — 8, 16, 32 commands — and Chapter 15.3 §3 computed that the absolute worst-case gap nonetheless shrinks slightly, from 70.2 to 64.35 µs. So the finer mode offers more deferral flexibility in commands, a shorter worst-case gap, a shorter per-block stall, and a higher total cost. Four axes, moving in three different directions. No single sentence summarises it, which is exactly why it needs a table.

5. Temperature Is the Expensive Variable

Chapter 15.4 §3 verified that the interval halves twice across the case-temperature bands while the occupancy does not change at all. So the fraction scales directly.

16Gb device, 1X mode, across the bands:

Nearly eighteen percent of the resource's time, in the hottest supported band.

Combining the two variables gives the range the whole module has been building toward:

  cheapest configuration   4Gb,  1X, cool band     3.33 %
  most expensive           16Gb, 1X, hottest      17.95 %

  a 5.4× range, from published parameters alone

6. What Narrower Scope Changes — and What It Does Not

Chapter 15.2 established that DDR5 adds a same-bank refresh scope. Its effect on this arithmetic is worth stating carefully, because it is different in kind from §4's and §5's.

Narrower scope does not primarily change the fraction. It changes what the fraction applies to.

  device-wide refresh    the whole device is unavailable
                         → the fraction applies to everything

  narrower scope         only the named resources are unavailable
                         → the rest of the device remains available

So the same occupancy blocks less. That is an availability improvement that the tRFC / tREFI fraction does not capture at all, because the fraction is dimensionless and says nothing about how much of the device it covers.

7. The Occupancy Boundary

The fraction is an average. The boundary is exact, and it is a safety property rather than an accounting one.

Chapter 7.5 owns the occupancy guard and ref_precondition_check enforces it. Restating the boundary here because §8's monitor measures against it and because §2's definition has a detail worth extracting.

  REFRESH accepted (sampled) on cycle  R
  occupancy                            D  cycles  =  ceil(tRFC / tCK)

  a conflicting command at M is LEGAL   ⟺   M − R ≥ D
  earliest legal M  =  R + D
  forbidden cycles  =  R … R+D−1        exactly D of them

Identical in shape to every minimum separation in Module 14 — and note the conversion is a ceiling, because the occupancy is a minimum in absolute time, unlike Chapter 15.1's interval which is a maximum and rounds down. Two refresh parameters, two opposite rounding directions, and §13's fifth misconception is about conflating them.

And §2's detail: the period is defined as REFRESH-to-ACTIVATE or REFRESH. So the same boundary governs the next refresh command, which means Chapter 15.3's catch-up burst of 8 postponed commands occupies 8 × D cycles and cannot be compressed. A controller that defers to the allowance limit is committing to a contiguous block of unavailability eight times the single-refresh cost — which is the clustering §1 excluded from the average, made concrete.

8. RTL — An Availability Monitor

Collision check. Chapter 7.5's ref_precondition_check owns the precondition and the occupancy guard — it decides legality and is reused. Chapter 15.1's refresh_rate_obligation measures the service rate. Chapter 15.3's refresh_credit_ledger holds debt. Chapter 12.4's burst_efficiency_monitor counts data-bus slot utilisation.

burst_efficiency_monitor is the closest in shape and measures a different quantity — data-bus slots used against slots available, with no notion of a resource being withdrawn for maintenance. Nothing in the corpus measures availability lost to refresh, separating occupancy from preparation, which §1 established are different costs that a single figure hides.

The engineering problem. Over an observation window, account for every cycle as available, lost to refresh occupancy, or lost to refresh preparation — and keep the last two apart, because §1 established the second is invisible to the published fraction and is often the larger.

Classification: verification-oriented availability accounting. Counts cycles. No physical modelling, no guard behaviour — it measures and never blocks.

// ─────────────────────────────────────────────────────────────────────
//  refresh_availability_monitor
//
//  CLASSIFICATION
//    Verification-oriented availability accounting. Counts cycles and
//    classifies each one. Measures; never gates.
//
//  WHAT IT MODELS
//    §1's cost decomposition, kept separate:
//      occupancy cycles     the resource withdrawn AFTER a refresh
//      preparation cycles   cycles spent draining and precharging
//                           BEFORE a refresh could be issued
//      available cycles     everything else
//    The published tRFC/tREFI fraction captures only the first. §1
//    argues the second is often larger and always invisible to it.
//
//  WHAT IT DOES NOT MODEL
//    No physical process -- no charge, leakage, retention or cells;
//    Chapter 2.2 owns the physics and a controller observes none of it.
//    No guard behaviour: Chapter 7.5's ref_precondition_check decides
//    legality and this block does not gate anything.
//    No workload model, no bandwidth prediction, no scheduler --
//    Modules 17 and 23 own those. It reports three cycle counts.
//
//  WHY SEPARATE PREPARATION FROM OCCUPANCY
//    §1: the published fraction is tRFC/tREFI, which counts only the
//    post-refresh unavailability. Chapter 15.3 §8 showed preparation
//    costing 11 cycles against an occupancy of 4 in its educational
//    trace. A monitor that summed them would report a single loss
//    figure and could not tell a design that refreshes efficiently
//    from one that spends its life draining.
//
//  CONVENTION (§7)
//    A refresh accepted on cycle R occupies cycles R .. R+D-1, so the
//    first available cycle is R+D and exactly D cycles are lost.
//    Preparation is counted from the cycle the controller first
//    stopped admitting work on refresh's behalf, which is an INPUT --
//    this block cannot infer intent.
//
//  SIMULTANEITY
//    preparation and occupancy asserted together -> OCCUPANCY wins the
//        classification, because once refresh is accepted the
//        preparation is over. Counting both would double-count a cycle
//        and make the three categories fail to sum to the window.
//    window roll-over and a classified cycle together -> the cycle is
//        credited to the CLOSING window, matching Chapter 15.1 §6's
//        rule so the two monitors agree.
//    reset -> counts cleared; no verdict for a partial window.
// ─────────────────────────────────────────────────────────────────────
module refresh_availability_monitor #(
  // Observation window in cycles. EDUCATIONAL sizes expected --
  // Chapter 15.1 §7 explains why a real tREFI must not be simulated.
  parameter int WINDOW_CYCLES = 64,
  // Occupancy, in cycles: ceil(tRFC / tCK). §7's conversion, a
  // CEILING because the occupancy is a minimum in absolute time.
  parameter int OCCUPANCY     = 8,
  parameter int CNT_W = (WINDOW_CYCLES <= 1) ? 1 : $clog2(WINDOW_CYCLES + 1)
) (
  input  logic               clk,
  input  logic               rst_n,

  // ── A refresh command was ACCEPTED this cycle. Starts occupancy.
  input  logic               refresh_accepted,
  // ── The controller is preparing for refresh: it has stopped
  //    admitting work on refresh's behalf and is draining or
  //    precharging. AN INPUT -- this block cannot infer intent, and a
  //    monitor that guessed would misattribute ordinary idle cycles.
  input  logic               preparing_for_refresh,

  // ── Three counts that must sum to the elapsed window.
  output logic [CNT_W-1:0]   cycles_available,
  output logic [CNT_W-1:0]   cycles_occupied,
  output logic [CNT_W-1:0]   cycles_preparing,
  output logic [CNT_W-1:0]   window_cycle,

  // ── Live classification of THIS cycle, published so §9's trace and
  //    §11's checker can align without re-deriving it.
  output logic               now_occupied,
  output logic               now_preparing,

  // ── End-of-window verdict. Meaningful only while window_complete.
  output logic               window_complete,
  // The counts sum to the window. A self-check: if this ever fails the
  // classification has a gap or an overlap and every figure the
  // monitor reports is suspect.
  output logic               accounting_balanced,

  // ── A refresh accepted while occupancy from a previous one is still
  //    outstanding. Chapter 7.5's guard should prevent it; reported
  //    rather than assumed, because §7 notes the same boundary governs
  //    refresh-to-refresh and a catch-up burst walks right up to it.
  output logic               occupancy_overlap
);

  // ── Elaboration guards.
  if (WINDOW_CYCLES < 1) begin : g_win
    initial $fatal(1, "refresh_availability_monitor: WINDOW_CYCLES must be >= 1");
  end
  if (OCCUPANCY < 0) begin : g_occ
    initial $fatal(1, "refresh_availability_monitor: OCCUPANCY must be >= 0");
  end
  if (OCCUPANCY > WINDOW_CYCLES) begin : g_order
    // An occupancy longer than the window makes every window fully
    // unavailable and the measurement meaningless. Refused rather than
    // silently reporting 100% loss.
    initial $fatal(1, "refresh_availability_monitor: OCCUPANCY must be <= WINDOW_CYCLES");
  end

  localparam int OCC_W = (OCCUPANCY <= 1) ? 1 : $clog2(OCCUPANCY + 1);

  logic [OCC_W-1:0]  occ_cnt;
  logic [CNT_W-1:0]  wcnt, avail_q, occ_q, prep_q;
  logic              rolling;

  always_comb begin
    // Occupancy is active while the countdown is running OR on the
    // acceptance cycle itself -- §7's boundary counts R as the first
    // of D forbidden cycles.
    now_occupied  = refresh_accepted || (occ_cnt != '0);
    // §8's simultaneity rule: occupancy wins. Once refresh is
    // accepted the preparation is over, and counting both would
    // double-count the cycle and break the balance check.
    now_preparing = preparing_for_refresh && !now_occupied;

    window_cycle     = wcnt;
    cycles_available = avail_q;
    cycles_occupied  = occ_q;
    cycles_preparing = prep_q;

    rolling         = (wcnt == CNT_W'(WINDOW_CYCLES - 1));
    window_complete = rolling;

    // Self-check: the three categories must partition the elapsed
    // cycles exactly. Includes THIS cycle's classification, since the
    // registers do not yet contain it.
    accounting_balanced =
      ( (avail_q + occ_q + prep_q + CNT_W'(1)) == (wcnt + CNT_W'(1)) );

    occupancy_overlap = refresh_accepted && (occ_cnt != '0);
  end

  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      occ_cnt <= '0;
      wcnt    <= '0;
      avail_q <= '0;
      occ_q   <= '0;
      prep_q  <= '0;
    end else begin
      // ── Occupancy countdown. Loaded with OCCUPANCY-1 because the
      //    acceptance cycle is itself the first forbidden cycle (§7).
      if (refresh_accepted) begin
        occ_cnt <= (OCCUPANCY >= 1) ? OCC_W'(OCCUPANCY - 1) : '0;
      end else if (occ_cnt != '0) begin
        occ_cnt <= occ_cnt - 1'b1;
      end

      // ── Classify this cycle into exactly one bucket. Written as one
      //    if/else chain so the three counts cannot double-count.
      if (rolling) begin
        // Credit this cycle to the closing window, then restart --
        // Chapter 15.1 §6's rule, so the two monitors agree.
        wcnt    <= '0;
        avail_q <= '0;
        occ_q   <= '0;
        prep_q  <= '0;
      end else begin
        wcnt <= wcnt + 1'b1;
        if (now_occupied) begin
          occ_q <= occ_q + 1'b1;
        end else if (now_preparing) begin
          prep_q <= prep_q + 1'b1;
        end else begin
          avail_q <= avail_q + 1'b1;
        end
      end
    end
  end

endmodule

Interface contract. preparing_for_refresh is an input because intent cannot be inferred — a controller that is idle and a controller that is deliberately draining look identical from the outside, and a monitor that guessed would misattribute ordinary idle cycles as refresh cost. The three counts are meaningful continuously; accounting_balanced is the self-check that says whether to trust them.

Parameter contract. OCCUPANCY is ceil(tRFC / tCK) — a ceiling, per §7, because the occupancy is a minimum in absolute time. It must not exceed the window, enforced at elaboration, since an occupancy longer than the window makes every window fully unavailable and the measurement meaningless.

Why the three counts must partition. accounting_balanced exists because a classification with a gap or an overlap makes every figure the monitor reports wrong, and silently. A cycle counted in two buckets inflates the loss; a cycle in none understates it. The self-check is cheap and it is the only thing standing between a plausible number and a wrong one.

Corner cases. OCCUPANCY == 0: no cycles are ever occupied — not a realistic device, and legal so the degenerate case is structural. OCCUPANCY == 1: only the acceptance cycle is occupied. refresh_accepted during occupancy: occupancy_overlap fires and the countdown reloads; Chapter 7.5's guard should have prevented it, and §7 notes a catch-up burst walks right up to that boundary. Preparation and occupancy together: occupancy wins. Window roll-over: counts restart and the closing cycle is credited to the closing window.

Synthesis implications. Four counters and a small adder chain for the balance check. Trivial, and it would normally live in a verification environment rather than in a shipped controller.

Failure modes. Summing preparation into occupancy — produces one loss figure and destroys the distinction §1 argued is the point. Counting both categories on a shared cycle — double-counts, accounting_balanced catches it. Loading the countdown with OCCUPANCY rather than OCCUPANCY − 1 — over-counts the loss by one cycle per refresh, which at a realistic refresh rate is a small but permanent overstatement. Using a floor instead of a ceiling for OCCUPANCY — understates the loss and, worse, would represent a guard that under-blocks if the same value fed Chapter 7.5's guard.

9. Availability, in Cycles

This chapter's registry annotation carries a diagram and no waveform, so the accounting is shown as a solved table.

  WINDOW = 24, OCCUPANCY = 4, preparation asserted cycles 6..10

  cycle  prep  refresh  classification   avail  occ  prep
  ──────────────────────────────────────────────────────────
   0-5     ·      ·      available          6     0    0
   6-10    Y      ·      preparing          6     0    5
   11      ·     REF     occupied           6     1    5
   12-14   ·      ·      occupied           6     4    5
   15-23   ·      ·      available         15     4    5
  ──────────────────────────────────────────────────────────
  totals                                   15  +  4  +  5  = 24  ✓ balanced

  published fraction would report   4 / 24  =  16.7 %
  actual availability lost          9 / 24  =  37.5 %

The two figures at the bottom are the whole point of separating the buckets.

The published tRFC / tREFI fraction sees 4 cycles of loss. That is what §3's, §4's and §5's tables compute, and it is correct for what it measures.

The controller actually lost 9. The preparation cost 5 cycles — more than the occupancy — and §1's second exclusion said this would happen. Chapter 15.3 §8's educational trace had preparation at 11 cycles against an occupancy of 4, an even wider ratio.

So the published fraction understated the real cost by more than a factor of two here. That is not a criticism of the specification — tRFC is a device parameter and preparation is a controller behaviour, so no device table could include it. It is an argument for measuring both, which is what §8's block exists to do, and a caution against treating §3's percentages as the answer rather than as a floor.

10. Four Assertions Worth Writing

// ── P1. THE self-check: the three categories partition the elapsed
//    cycles exactly. Catches a classification gap or overlap, which
//    would make every reported figure wrong and silently. This is the
//    property that protects all the others.
property p_accounting_partitions;
  @(posedge clk) disable iff (!rst_n)
    accounting_balanced;
endproperty
a_accounting_partitions: assert property (p_accounting_partitions);

// ── P2. §8's simultaneity rule: occupancy and preparation are never
//    both counted for one cycle. Catches the double-count directly,
//    at the classification rather than at the totals.
property p_buckets_are_exclusive;
  @(posedge clk) disable iff (!rst_n)
    !(now_occupied && now_preparing);
endproperty
a_buckets_are_exclusive: assert property (p_buckets_are_exclusive);

// ── P3. §7's boundary: exactly OCCUPANCY cycles are marked occupied
//    per accepted refresh, counting the acceptance cycle. Catches the
//    off-by-one that permanently overstates or understates the loss.
//    $past with an explicit 1; guarded so OCCUPANCY >= 2 where the
//    countdown is observable.
property p_occupancy_is_exactly_D;
  @(posedge clk) disable iff (!rst_n)
    ( $past(refresh_accepted, 1) && (OCCUPANCY >= 2) )
      |-> (occ_cnt == OCC_W'(OCCUPANCY - 1));
endproperty
a_occupancy_is_exactly_D: assert property (p_occupancy_is_exactly_D);

// ── P4. A refresh accepted during outstanding occupancy is REPORTED.
//    Chapter 7.5's guard should prevent it, and §7 notes the same
//    boundary governs refresh-to-refresh so a catch-up burst walks up
//    to it -- "should" is not a guarantee.
property p_overlap_is_reported;
  @(posedge clk) disable iff (!rst_n)
    (refresh_accepted && (occ_cnt != '0)) |-> occupancy_overlap;
endproperty
a_overlap_is_reported: assert property (p_overlap_is_reported);

// ── C1. All three categories are REACHED, and a window completes.
//    The PREPARING cover is the one people omit, and it is the
//    category §9 shows dominates -- a run that never asserts
//    preparation measures only the cost the datasheet already told
//    you about.
c_saw_available: cover property (@(posedge clk) disable iff (!rst_n)
                                   (!now_occupied && !now_preparing));
c_saw_occupied:  cover property (@(posedge clk) disable iff (!rst_n) now_occupied);
c_saw_preparing: cover property (@(posedge clk) disable iff (!rst_n) now_preparing);
c_window_done:   cover property (@(posedge clk) disable iff (!rst_n) window_complete);

What these prove. That the classification partitions the window — which is what makes any reported figure trustworthy; that the buckets are exclusive; that the occupancy boundary is exactly D cycles; and that an overlap is reported.

What these do not prove. Three gaps.

Nothing proves OCCUPANCY matches the device. It is a parameter, and §2's verified table shows it depends on density and refresh mode — 350, 260 or 160 ns for a 16Gb part. A monitor configured with tRFC4 while the device runs in 1X mode understates the loss by more than half, with every property passing.

Nothing proves preparing_for_refresh is honest. It is an input reflecting controller intent. A design that never asserts it produces a monitor that measures only the occupancy — reporting exactly the published fraction and none of §9's larger cost. C1's preparing cover is the only thing that tells you whether it was ever driven.

And nothing here is a bandwidth measurement. §1's three exclusions stand: this counts cycles a resource was withdrawn, not requests that were delayed. Module 23 owns the step from one to the other.

Vacuity. P3 requires an accepted refresh and an occupancy of at least 2. P1 and P2 are unconditional, which is unusual in this curriculum and deliberate: a self-check that could pass vacuously would be worthless.

11. DV — Measuring What the Datasheet Cannot

Invert the representation. The monitor holds three incrementing counters. A checker should hold a list of refresh acceptance timestamps and compute the occupied cycles as count × OCCUPANCY, comparing against the monitor's total — a multiplication against an accumulation, which cannot share an increment bug.

Derive the occupancy from the density and mode independently. This is the chapter-specific obligation, and §10's first limitation is the reason: tRFC depends on both the device density and the active refresh mode, and the mode is set by a mode-register write. A checker should decode the mode from observed MRS traffic, look up tRFC for the device's density, and convert with its own ceiling — rather than reading the monitor's parameter.

Measure preparation independently if you can. The honest position is that this is hard: preparation is controller intent, and an external observer sees only an absence of new work. What an observer can do is bound it — the interval between the last non-refresh command accepted and the refresh acceptance is an upper bound on preparation, and comparing that against the design's asserted preparing_for_refresh catches a design that under-reports its own cost.

  REFRESH AVAILABILITY REPORT
    generation        : DDR4
    device            : 16Gb                        [datasheet table]
    refresh mode      : 1X                          [decoded from MRS]
    tRFC              : 350 ns  → 560 cycles @ DDR4-3200   (ceil)
    tREFI             : 7.8 µs  → 12480 cycles             (floor, MAX)
    ─────────────────────────────────────────────────────────────────
    published fraction    : 350/7800     =  4.49 %
    measured occupancy    : 4.51 %       ← matches, as expected
    measured preparation  : 6.802 %      ← NOT in any device table
    total unavailable     : 11.31 %      = 2.5× the published figure
    ─────────────────────────────────────────────────────────────────
    worst observed prep   : 940 cycles before one refresh
    blocker at that point : write recovery on bank 2
    root question         : is the preparation cost or the occupancy
                            the thing worth optimising here?

The line to steal is total unavailable beside published fraction. They differ by 2.5× in this report, and the difference is entirely the category no device table contains. A team that budgeted from the datasheet's 4.49 % would be short by a factor they never had a reason to suspect.

And the root question is the right closing line, because it is actionable in a way a percentage is not: if preparation dominates, the fix is in admission and draining policy (Module 17); if occupancy dominates, the fix is the refresh mode or the device choice.

12. Debugging

Symptom. Memory availability lower than the refresh budget predicted, with no refresh violations anywhere.

The discriminator that defines this chapter is the ratio of preparation to occupancy. It is the one quantity no device table contains, §9 and §11 both show it dominating, and it routes the fix to a completely different module: preparation-dominated means Module 17's admission policy; occupancy-dominated means the refresh mode, the density, or the thermal design.

The second discriminator is whether the measured loss matches the published fraction too well. An exact match means the monitor is measuring only what the datasheet already told you — which almost certainly means preparing_for_refresh was never driven.

Responsible layer. If the loss matches the sum of a correctly-computed occupancy and an honestly-measured preparation, nothing is broken. The remaining question is whether that cost is acceptable, which is a system-architecture decision informed by §5's thermal arithmetic and owned by Module 23.

13. Common Misconceptions

“Refresh only affects idle systems.” Tempting because a refresh during an idle period genuinely costs nothing, and that is the easy case to picture. Why it is wrong: §5 computes up to 17.95 % of a resource's time withdrawn in the hottest band, and §9 shows the real cost exceeding the published figure. Under load, every withdrawn cycle is a cycle a request waited. Consequence: refresh omitted from a memory budget entirely. Replacement model: refresh is a floor on lost availability; load determines how much of it you feel. Debugging clue: Chapter 34.2 is a whole chapter on refuting this, which is a fair indication of how common it is.

“Fine-granularity refresh reduces refresh overhead.” Tempting because “finer” sounds like “less” and each blocking event genuinely is shorter — 160 ns against 350. Why it is wrong: §4 — the count quadruples and the duration more than halves, so the product rises 1.83×, from 4.49 % to 8.21 %. Consequence: a mode selected to reduce overhead that nearly doubles it. Replacement model: it trades total availability for a shorter worst-case stall. Debugging clue: availability worse after enabling a mode intended to improve it.

“A larger refresh interval is always better for performance.” Tempting because the interval is the denominator, so a larger one obviously reduces the fraction. Why it is wrong: the interval is not a design variable — Chapter 15.1 §2 verified it is a device MAX set by retention and temperature. A controller cannot choose a larger one; it can only fail to meet the one it has. Consequence: a “tuning” discussion about a parameter that is not tunable, and in the worst case a configured interval longer than the device permits. Replacement model: the interval is given; the levers are mode, scope and thermal design. Debugging clue: a configuration file with the refresh interval in a performance-tuning section.

“If tRFC is honoured, refresh is correct.” Tempting because tRFC is the parameter with a clean boundary and a guard to enforce it. Why it is wrong: Chapter 15.1 §3 — tRFC is service cost and the interval is service pressure, and they fail independently. Honouring the occupancy perfectly while never issuing refresh often enough loses data. Consequence: a verification plan with one refresh property. Replacement model: two obligations, two checks. Debugging clue: a refresh test suite that passes and a system that corrupts.

“Both refresh parameters round the same way.” Tempting because both are times converted to cycles, and Module 14 established a ceiling habit. Why it is wrong: §7 — the occupancy is a minimum and rounds up; the interval is a maximum and rounds down. Opposite directions, in the same chapter, for two parameters in the same table. Consequence: rounding the interval up under-refreshes, and rounding the occupancy down under-blocks. Both are unsafe, from the same habit. Replacement model: the rounding direction follows from min-versus-max, never from habit. Debugging clue: a single conversion helper used for both.

“The published fraction is the bandwidth you lose.” Tempting because it is a percentage of time and bandwidth is a rate, so the units seem to line up. Why it is wrong: §1's three exclusions — it ignores whether traffic wanted those cycles, it omits preparation, and it averages away clustering. §9 measured the real loss at more than twice the published figure. Consequence: a memory budget short by a factor nobody suspected. Replacement model: a floor on the mechanism's cost, not a prediction of delivered bandwidth. Debugging clue: measured availability worse than the budget with no violations anywhere.

“Narrower refresh scope reduces the cost the same way a finer mode does.” Tempting because both are mechanisms for reducing refresh's impact and both appear in the same discussions. Why it is wrong: §6 — a finer mode changes duration and frequency and trades against the total; a narrower scope changes what is blocked and does not. They are independent levers with different trade profiles, and only one of them is free. Consequence: a design that adopts both expecting additive benefit, or that substitutes one for the other. Replacement model: three levers — duration, frequency, scope — of which frequency is not available and scope is the only one without a trade. Debugging clue: an availability improvement smaller than the sum of two mechanisms predicted.

14. Interview Reasoning

“How much bandwidth does refresh cost?” The honest answer starts by refusing the question's framing. The computable quantity is the fraction of a resource's time withdrawn — occupancy over interval — which for a 16Gb DDR4 part in the normal temperature band is about 4.5 %. That is not bandwidth loss: it ignores whether traffic wanted those cycles, it omits the preparation cost of draining in-flight work before refresh can be issued, and it averages away clustering. Measured properly, the preparation term can exceed the occupancy, so the real availability cost can be twice the published figure.

“Does fine-granularity refresh reduce refresh overhead?” No — it increases it, and this is worth being specific about. For a 16Gb DDR4 part the 1X mode gives 350 ns every 7.8 µs, about 4.5 %. The 4X mode gives 160 ns every 1.95 µs, about 8.2 %. Four times the commands at under half the duration is 1.83 times the total. What the mode buys is a shorter worst-case stall — 160 ns instead of 350 — which is a good trade for a latency-sensitive workload and a bad one for a throughput-bound system.

“What is the most expensive refresh configuration you can construct from published numbers?” A dense part in the hottest supported temperature band. For a 16Gb DDR4 device, tRFC1 is 350 ns and the interval in the 95–105°C band is 1.95 µs, giving nearly 18 % of the resource's time withdrawn. The reason that figure matters is that the band is fully supported rather than a fault condition, so a system that can reach it has to work there — which puts refresh cost into the thermal budget, since cooling into the 85°C band buys back about 13 percentage points of availability.

“Why can a controller not just refresh less often?” Because the interval is a device maximum, not a tunable. It is set by retention and by the temperature band, and a controller that exceeds it loses data with no violation reported by anything. The three levers a designer actually has are the refresh mode, which trades total cost for stall duration; the refresh scope, where a generation offers a narrower one; and the thermal design, which selects which row of the interval table applies. Refreshing less often is not among them.

“Why does refresh cost grow with density?” A refresh command advances the device's internal pointer over some number of rows, so a denser device either covers more rows per command — taking longer — or needs more commands. Either way the product rises. The verified figures show 260 ns at 4Gb against 350 ns at 8Gb, so about 3.3 % versus 4.5 %. Worth adding: it is not a clean proportionality — 8Gb and 16Gb share the same 350 ns in that table — so extrapolating from one density to another gives the wrong answer even when it errs safely.

“Your measured availability loss exactly matches the datasheet's tRFC over tREFI. Is that good?” It is suspicious rather than reassuring. The published fraction accounts only for the post-refresh occupancy, and a real controller also loses the cycles it spends draining and precharging before refresh can be issued — a term no device table contains and which measurements show can exceed the occupancy. An exact match to the datasheet most likely means the measurement never captured the preparation at all.

“Which refresh parameters round up and which round down?” The occupancy rounds up, because it is a minimum separation in absolute time — the same as every parameter in Module 14. The interval rounds down, because it is a maximum. They sit in the same table in the same document and round in opposite directions, and a shared conversion helper used for both is a real and easy bug: rounding the interval up under-refreshes and rounding the occupancy down under-blocks. The direction follows from min-versus-max, never from habit.

15. Engineering Exercises

1. Compute the fraction for three configurations. Using §2's verified figures, give the unavailable fraction for: (a) 4Gb, 1X, normal band; (b) 16Gb, 2X, normal band; (c) 8Gb, 1X, the 85–95°C band.

Worked: (a) 260 / 7800 = 3.33 %. (b) 260 / 3900 = 6.67 %. (c) 350 / 3900 = 8.97 %. Note that (b) and (c) are close but arise from completely different causes — a mode change and a temperature band — which is why a bare percentage is not a diagnosis.

2. Work the mode trade. For an 8Gb part, compute the fraction and the per-block duration in all three modes. Then state which workload you would choose each for.

Worked: 1X is 350/7800 = 4.49 % with 350 ns blocks; 2X is 260/3900 = 6.67 % with 260 ns; 4X is 160/1950 = 8.21 % with 160 ns. 1X for a throughput-bound workload that tolerates stalls; 4X for a tail-latency-sensitive workload that can pay 3.7 points of throughput to more than halve the worst stall; 2X as the middle. The choice depends on which axis the workload is sensitive to, which is the only honest answer.

3. Price the thermal design. A 16Gb part can run in any of the three bands in 1X mode. Compute the availability recovered by cooling from the hottest band to the coolest, and express it as a multiple.

Worked: hottest is 350/1950 = 17.95 %, coolest is 350/7800 = 4.49 %. Cooling recovers 13.46 percentage points, and the hottest band costs 4× the coolest. Whether that justifies the cooling is a system-cost comparison — but it cannot be made at all without the arithmetic, which is the point.

4. Find the understated budget. A team budgets 4.49 % for refresh on a 16Gb part and measures 11.3 %. Enumerate every mechanism from this chapter that could account for the gap, and give the one measurement that distinguishes them.

Worked: candidates are preparation cost (§1, §9), a hotter band than assumed (§5 — 8.97 % would nearly explain it alone), a finer mode than assumed (§4 — 6.67 % or 8.21 %), and clustering inflating the observed window. The distinguishing measurement is §8's monitor with both buckets driven: if cycles_preparing is substantial the cause is preparation; if cycles_occupied alone exceeds 4.49 % the cause is the mode or the band, and decoding the mode from MRS separates those two.

5. Compute the catch-up burst. Using §7's boundary and a 16Gb 1X part at DDR4-3200, give the contiguous unavailability of a catch-up burst of 8 postponed refresh commands, in cycles and in microseconds.

Worked: tRFC1 of 350 ns is ceil(350 / 0.625) = 560 cycles. Eight of them back to back is 4,480 cycles, or 2.8 µs of contiguous unavailability. For context, that is over a third of the nominal 7.8 µs interval spent entirely in refresh — which is what Chapter 15.3's allowance permits and §1's clustering exclusion warned the average hides.

6. Get the rounding right. At DDR4-3200, convert tRFC1 = 350 ns and tREFI = 7.8 µs to cycles. State the rounding direction for each and what goes wrong if you swap them.

Worked: at DDR4-3200 both divide exactly — 350 / 0.625 = 560 and 7800 / 0.625 = 12,480 — which conceals the issue entirely, and that is the first lesson: a conversion tested only at a speed grade where the arithmetic is exact is untested. DDR4-2400 is no better, giving 420 and 9,360 exactly. Take DDR4-2933, where tCK is about 0.6819 ns: tRFC gives 513.3 → ceil 514, and tREFI gives 11,438.7 → floor 11,438. Swapping the directions yields 513 and 11,439 — the first under-blocks by a cycle, which is a contract violation, and the second over-refreshes by one interval, which is merely wasteful. Same habit, two very different consequences.

7. Justify the three buckets. §8 separates preparation from occupancy. Argue that a single “lost cycles” counter would be simpler and adequate, then rebut using §12's discriminator.

16. Summary

Refresh cost is one division — occupancy over interval — and with this module's verified figures it can be evaluated exactly rather than estimated.

It grows with density: 3.33 % at 4Gb against 4.49 % at 8Gb and 16Gb, and not proportionally, since those two densities share a tRFC1 of 350 ns.

Fine-granularity refresh increases the aggregate cost, from 4.49 % to 8.21 % at 16Gb — four times as many commands at under half the duration is 1.83× the total. What it buys is a shorter worst-case stall, 160 ns instead of 350. The name does not say which way the total moves, and this is the module's most counter-intuitive verified result.

Temperature is the expensive variable: 4.49 %, 8.97 % and 17.95 % across the three case-temperature bands, because the interval halves twice while the occupancy does not move. And Chapter 15.4 §4 established the hottest band is fully supported, so a system that can reach it must work there — which puts refresh cost in the thermal budget, where cooling into the coolest band buys back 13.5 percentage points.

Narrower scope is a third and independent lever. It changes what is blocked rather than how long or how often, and is the only one of the three that does not trade against the total. Its DDR5 figures are reported and not retrieved, so the structural claim is made and no arithmetic is built on them.

The published fraction is a floor, not a prediction. It ignores whether traffic wanted those cycles, averages away clustering — a catch-up burst of 8 costs 8 × tRFC contiguously, 2.8 µs at DDR4-3200 — and omits preparation entirely, which §9 measured at more than the occupancy itself and §11's report showed making the real cost 2.5× the published figure. No device table could contain preparation, because it is a controller behaviour.

refresh_availability_monitor keeps the three categories apart and self-checks that they partition the window, because a classification with a gap or an overlap makes every figure wrong and silently. Its most useful diagnostic is the ratio of preparation to occupancy, which routes the fix to a different module in each case.

And one rounding trap worth carrying: the occupancy is a minimum and rounds up; the interval is a maximum and rounds down. Two parameters, one table, opposite directions.

17. Module 15 in One Chain

The module set out to answer why DRAM must be refreshed, what obligation that creates, how refresh interacts with bank state and traffic, how a controller schedules it without violating retention, and how DV proves it is both timely and legal.

Refresh is a service-rate obligation over a population, not one deadline — and the specification announces it by inverting: the interval is published as MIN = N/A; MAX, the first maximum in the curriculum, which puts the obligation on the controller and makes over-refreshing always legal. Nothing refuses a late refresh, which is why it is the one obligation where the device cannot protect you from yourself. (Chapter 15.1)

A refresh command retires one unit of one obligation per resource its scope covers, and nothing for the rest. Device-wide scope needs one counter; narrower scope multiplies the state, adds a selection decision, and makes the compliance question per-resource — so an adequate aggregate rate distributed unevenly starves a resource while every aggregate check passes. (Chapter 15.2)

The specification permits bounded deferral, verified: 8, 16 or 32 postponed commands by mode, with the resulting gap bounded at 9, 17 or 33 intervals, and each pulled-in command reducing the number required later by one — a credit ledger in a datasheet. The count and the gap are separate requirements, and the module's sharpest lesson is that a deadline missed at cycle 24 became unavoidable at cycle 14, when work was admitted that made it unreachable while the ledger still read merely DUE. (Chapter 15.3)

The interval comes from the weak tail of a retention distribution, reduced to one number by the specification and selected by case-temperature band — a step function, not a curve, with device-specific boundaries. And a band change invalidates accounting, not just a parameter: the allowance and the gap bound are denominated in the interval, and the debt already accumulated was measured in the old one. (Chapter 15.4)

And the cost is computable, larger than the datasheet's figure, and dominated by variables the controller does not choose. (This chapter)

The refresh-semantics ledger, stated once so nothing in the module contradicts it:

And the verification frame the module contributed: safety-shaped properties fail at a cycle — no command during occupancy, no refresh before its precondition. Bounded-service properties fail by an absence — the rate was not met, the debt grew. The second kind needs a window and a counter rather than an assertion, and needs its completion covered, because “no violations” and “never evaluated” look identical in a report and mean opposite things.

Module 16 takes up banks and bank groups — the architecture this module has repeatedly needed and deliberately not asserted, from Chapter 15.2's scope masks to the grouping that Chapter 14.6 and 14.7 left to it.