Retention Time

Chapter 2.2 established the physics and one fact this chapter has to reconcile: retention is a distribution, not a constant. Every cell has its own retention time, and the population has a spread.

Chapters 15.1 through 15.3 then spent three chapters counting against a single number. A controller's ledger holds one interval. Its allowance is denominated in that interval. Nothing anywhere in a controller represents a distribution.

So:

How does a distribution become one number a controller can count against — and what happens to all that accounting when the number changes?

The second half is the part nobody expects. The verified interval halves twice across the operating temperature range, and a controller that changes bands does not merely need a new interval. It needs to recompute accounting it already did, because the debt it is carrying was denominated in the old one.

1. A Distribution Cannot Be Counted Against

State the problem precisely, because the resolution is less obvious than it first appears.

Chapter 2.2 §4 established that retention times across a device's cells form a distribution — most cells hold charge far longer than the weakest, and the weakest is what matters. A controller, meanwhile, holds one interval and counts cycles against it (Chapter 15.1 §6).

The gap between those two statements is not a simplification a controller gets away with. It is bridged by the specification, and the bridge has a specific shape:

  physical reality        a distribution of per-cell retention times
       ↓                  device measures, bins, and guarantees
  specification           ONE interval, published as a MAXIMUM
       ↓                  controller reads and counts
  controller              one number, one counter, no distribution

So the answer to §1's first question is: the specification does the reduction, by publishing a bound over the worst case, and the controller never sees the distribution at all. That is the same physics-determines / specification-publishes / controller-counts boundary Chapter 13.2 §1 drew for every timing parameter — but with a step that is genuinely different in kind, because here the reduction is from a population rather than from a single process.

2. Temperature Is Not a Model You Build

Now the variable, and the first thing to get right is what kind of thing it is.

Retention depends on temperature — that is physics, and Chapter 2.2 owns it. What a controller does about it is not to model that dependence. A controller has no thermal model, no activation energy, no leakage curve. What it has is a specified operating condition and a table.

Four things to read off that table carefully.

It is a step function, not a curve. Three bands, three values. A controller does not interpolate; it selects. Whatever the underlying physics is doing continuously, the contract is discrete, and that is what makes it implementable.

It is case temperature. Not ambient, not junction, not a number from a sensor somewhere else on the board. The band is defined against a specific measurement point, and a design that reads a different point is selecting bands from the wrong variable.

The interval halves, then halves again. 7.8 → 3.9 → 1.95 µs. That is a four-fold increase in refresh rate from the coolest band to the hottest, and Chapter 15.5 computes what it costs.

The bands are bounded at both ends. Below −40°C and above 105°C there is no row in the table. Outside the specified range the device is not specified — the question stops being “how often should I refresh” and becomes “this part is out of its operating conditions”, which is a system problem and not a refresh one.

3. What “Full Specifications Are Supported” Means

§3's second quote is easy to skim and worth unpacking, because it rules out an interpretation many designs implicitly adopt.

The datasheet says the extended range supports full specifications, with additional conditions. That means the device does not degrade in the extended range — timings do not relax, capacity does not shrink, and the part is not operating out of specification. It is operating in specification, under a different row of the table.

So the extended range is not an exception path. It is a supported operating mode with its own parameters, and a controller that treats it as a fault condition has misread the contract.

4. The Band Change Problem

Here is the part that has nothing to do with physics and everything to do with accounting, and it is this chapter's genuinely new contribution.

Chapter 15.3 built a ledger whose debt increments once per interval. Its allowance — 8 postponed commands in 1X mode — is denominated in intervals. Its gap bound is (allowance + 1) × interval cycles.

Every one of those quantities is a function of the interval. So when the band changes, they all change at once — and the debt already accumulated was measured in the old unit.

Work an example with the verified values.

  Band: normal.  interval = 7.8 µs.

  last service at   t = 0
  now               t = 7 µs
  elapsed / 7.8     = 0.90 intervals   →  debt 0.  On schedule.

  ── case temperature crosses 85°C at t = 7 µs ──

  Band: extended.  interval = 3.9 µs.

  elapsed / 3.9     = 1.79 intervals   →  debt should be 1.  DUE.

The controller did nothing wrong and is now behind. Not because it failed to act, but because the measure changed underneath the accounting it had already done. Its debt register says 0 and the correct value is 1.

And one more consequence, which is the hook Chapter 15.3 §17 left:

A controller configured for the wrong band is not merely refreshing at the wrong rate. Its entire postponement allowance is denominated in the wrong unit. Eight postponed commands at 7.8 µs is a gap of up to 70.2 µs; the same eight at 3.9 µs is 35.1 µs. A design that kept the 70.2 µs figure while the device required 35.1 µs would exceed the gap bound by a factor of two while its command count stayed within the allowance — passing exactly the check most designs implement and failing the one they omit.

5. Self-Refresh in the Extended Range

One verified detail worth including, because it shows the temperature condition reaching beyond the interval.

Three observations, and the third is the interesting one.

The temperature condition is not only about tREFI. It also constrains how self-refresh must be configured, via mode-register bits. So a design that handles the interval correctly and leaves the self-refresh mode at its default is still non-compliant in the extended range.

There are two acceptable answers, and they place responsibility differently. The manual mode with extended-range capability keeps the decision with the system; the auto self-refresh mode lets the device manage its own rate according to its temperature. Who owns the refresh rate is itself configurable.

That second option is the boundary this chapter stops at. In auto self-refresh the device adapts its own refresh behaviour, which means the controller is no longer the party tracking the rate. Module 24 owns low-power features, and self-refresh mechanics beyond this configuration requirement belong there. What matters here is only that the temperature band changes an obligation the controller might otherwise assume is unconditional.

6. RTL — Selecting an Interval and Repairing the Accounting

Collision check. Chapter 2.3's refresh_deadline_tracker and Chapter 15.3 §6's refresh_credit_ledger both take an interval as a fixed parameter or input and neither handles a change to it. Chapter 15.1's refresh_rate_obligation likewise. Chapter 13.2's timing_spec_resolver converts one specification into cycles and has no notion of bands.

Nothing in the corpus changes an interval mid-operation, and nothing repairs accounting that was denominated in the old one. That is §5's problem and it is this block's only job.

The engineering problem. Select the interval for the current temperature band, and when the band changes, produce a corrected debt and a rescaled gap bound so the ledger downstream is denominated consistently.

Classification: controller-side configuration selection with accounting repair. Selects from a table and computes an integer quotient. No physical modelling.

What it does not model, emphatically. No thermal model. No leakage curve. No activation energy. No retention distribution. The temperature band arrives as an input — from a sensor, a thermal management unit, or a device register — and this block neither measures it nor predicts it. §12's last misconception is about why a block claiming otherwise would be a fiction; the honest statement is that §2's contract is a table lookup, and a table lookup is all this is.

// ─────────────────────────────────────────────────────────────────────
//  retention_mode_selector
//
//  CLASSIFICATION
//    Controller-side configuration selection with accounting repair.
//    Selects an interval from a band table and recomputes a debt.
//
//  WHAT IT MODELS
//    §3's step function: one interval per temperature band, selected
//    and never interpolated.
//    §5's band-change repair: when the band changes, the debt already
//    accumulated was denominated in the OLD interval and must be
//    recomputed from elapsed time in the NEW one, and the gap bound
//    must be rescaled with it.
//
//  WHAT IT DOES NOT MODEL
//    No thermal model. No leakage curve. No activation energy. No
//    retention distribution. Chapter 2.2 owns the physics and a
//    controller observes none of it. The BAND ARRIVES AS AN INPUT
//    from a sensor or a device register; this block neither measures
//    temperature nor predicts it. §2's contract is a table lookup and
//    that is exactly what this is.
//    It also does NOT hold the ledger (Chapter 15.3's
//    refresh_credit_ledger), does not schedule (Module 17), and takes
//    no position on self-refresh configuration (§6, Module 24).
//
//  RELATIONSHIP TO EXISTING RTL
//    Chapter 15.3's refresh_credit_ledger takes an interval and
//    assumes it never changes. This block is what sits in front of it
//    when it can: it supplies the interval, and on a change it supplies
//    a CORRECTED debt for the ledger to load, plus the rescaled gap
//    bound. Without it, §5's three failures are all reachable.
//
//  GENERATION SCOPE
//    §3's bands and values are DDR4-VERIFIED for a named device, and
//    they are PARAMETERS because §3's callout is explicit that band
//    boundaries, multipliers and the measurement point are device
//    properties. A universal temperature threshold would be wrong.
//
//  CONVENTION
//    Bands are numbered 0 (coolest) upward, matching §3's table order,
//    so a higher band index means a SHORTER interval. Enforced at
//    elaboration by g_monotone.
//    Elapsed time is counted in cycles since the last service, which
//    is Chapter 15.3 §5's gap measurement, supplied as an input so
//    this block does not duplicate that counter.
//
//  SIMULTANEITY
//    band change and service on the same cycle -> the SERVICE wins for
//        the elapsed count (it resets to zero) and the band change
//        still applies to the interval. Debt after both is zero, which
//        is correct: service just occurred, so nothing is owed
//        regardless of the unit it would have been measured in.
//    band change on consecutive cycles -> each is handled; the repair
//        is a function of elapsed time and the new interval, not of
//        the previous band, so it is idempotent and safe to repeat.
//    reset -> band 0, no pending repair.
// ─────────────────────────────────────────────────────────────────────
module retention_mode_selector #(
  // Number of temperature bands. §3's verified table has three.
  parameter int BANDS = 3,
  // Interval in cycles, per band, coolest first. EDUCATIONAL sizes
  // expected in simulation -- Chapter 15.1 §7 explains why.
  // Defaults mirror §3's 4:2:1 ratio (7.8 / 3.9 / 1.95 µs).
  parameter int INTERVAL_0 = 32,
  parameter int INTERVAL_1 = 16,
  parameter int INTERVAL_2 = 8,
  // §1's postponement allowance, in commands. Chapter 15.3 §1's
  // verified value for the mode in use.
  parameter int ALLOWANCE = 8,
  parameter int BAND_W = (BANDS <= 1) ? 1 : $clog2(BANDS),
  parameter int INT_W  = $clog2(INTERVAL_0 + 1),
  // Debt width, signed, per Chapter 15.3 §6.
  parameter int DEBT_W = 2 + $clog2(ALLOWANCE + 2),
  // Gap bound reaches (ALLOWANCE+1) * INTERVAL_0 in the coolest band.
  parameter int GAP_W  = $clog2(((ALLOWANCE + 1) * INTERVAL_0) + 2)
) (
  input  logic                     clk,
  input  logic                     rst_n,

  // ── The current temperature band. AN INPUT -- see the header. This
  //    block does not measure temperature and has no thermal model.
  input  logic [BAND_W-1:0]        band,

  // ── Cycles since the last refresh service, from Chapter 15.3 §6's
  //    gap counter. Supplied rather than duplicated.
  input  logic [GAP_W-1:0]         cycles_since_service,
  input  logic                     service_accepted,

  // ── The selected interval and the rescaled gap bound, for the
  //    ledger downstream.
  output logic [INT_W-1:0]         interval_cycles,
  output logic [GAP_W-1:0]         gap_bound_cycles,

  // ── §5's repair. When the band changes, the ledger must LOAD this
  //    debt rather than carrying its own.
  output logic                     band_changed,
  output logic                     debt_reload_valid,
  output logic signed [DEBT_W-1:0] debt_reload_value,

  // ── The band moved to a SHORTER interval, so the correction is in
  //    the dangerous direction: the controller is more behind than it
  //    believed. Published because §11's debugging turns on the
  //    direction of the change.
  output logic                     band_tightened,

  // ── The band input is outside the specified table. §2's fourth
  //    reading: outside the specified range the device is not
  //    specified, and this is a system fault rather than a refresh
  //    decision. REPORTED, never silently clamped to a guess.
  output logic                     band_out_of_range
);

  // ── Elaboration guards.
  if (BANDS < 1) begin : g_bands
    initial $fatal(1, "retention_mode_selector: BANDS must be >= 1");
  end
  if (BANDS > 3) begin : g_bands_max
    // The interval table is three explicit parameters, matching §3's
    // verified three bands. Supporting more would need a packed array
    // input; refused rather than silently ignoring bands 3 and up.
    initial $fatal(1, "retention_mode_selector: BANDS > 3 needs a packed interval table");
  end
  if ((INTERVAL_0 < 1) || (INTERVAL_1 < 1) || (INTERVAL_2 < 1)) begin : g_int
    initial $fatal(1, "retention_mode_selector: intervals must be >= 1");
  end
  // §3: a higher band index is a hotter band and therefore a SHORTER
  // interval. A table that violates this would make band_tightened
  // meaningless. Enforced rather than documented.
  if ((INTERVAL_1 > INTERVAL_0) || (INTERVAL_2 > INTERVAL_1)) begin : g_monotone
    initial $fatal(1, "retention_mode_selector: intervals must not increase with band");
  end
  if (ALLOWANCE < 0) begin : g_allow
    initial $fatal(1, "retention_mode_selector: ALLOWANCE must be >= 0");
  end

  logic [BAND_W-1:0] band_q;
  logic [INT_W-1:0]  sel_interval;
  logic [INT_W-1:0]  prev_interval;

  // ── §3's step function: a select, never an interpolation.
  function automatic [INT_W-1:0] interval_of(logic [BAND_W-1:0] b);
    begin
      case (b)
        BAND_W'(0): interval_of = INT_W'(INTERVAL_0);
        BAND_W'(1): interval_of = INT_W'(INTERVAL_1);
        BAND_W'(2): interval_of = INT_W'(INTERVAL_2);
        // Out of range: hold the SHORTEST interval, which is the
        // conservative direction, and assert band_out_of_range so the
        // condition is never silent. Refreshing too often is legal
        // (Chapter 15.1 §2's MIN = N/A); refreshing too seldom is not.
        default:    interval_of = INT_W'(INTERVAL_2);
      endcase
    end
  endfunction

  always_comb begin
    sel_interval      = interval_of(band);
    prev_interval     = interval_of(band_q);
    interval_cycles   = sel_interval;
    gap_bound_cycles  = GAP_W'((ALLOWANCE + 1)) * GAP_W'(sel_interval);

    band_out_of_range = (band >= BAND_W'(BANDS));
    band_changed      = (band != band_q);
    band_tightened    = band_changed && (sel_interval < prev_interval);

    // ── §5's repair. The corrected debt is the number of NEW
    //    intervals that have elapsed since the last service. Computed
    //    with a division, which is acceptable here because this is a
    //    configuration-time event -- a band change, not a per-cycle
    //    path. Chapter 13.2 §7 made the same honest classification for
    //    its resolver.
    //    Truncating division is correct: a partial interval has not
    //    yet incremented the debt.
    debt_reload_valid = band_changed;
    debt_reload_value = band_changed
                      ? DEBT_W'($signed(32'(cycles_since_service)
                                        / 32'(sel_interval)))
                      : DEBT_W'(0);
  end

  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      band_q <= '0;
    end else begin
      band_q <= band;
    end
  end

endmodule

Interface contract. band is an input and the block has no opinion about where it comes from — §3 established the measurement point is a device property, and getting it from the wrong sensor is a system integration error this block cannot detect. debt_reload_value must be loaded by the ledger when debt_reload_valid is high; a ledger that ignores it exhibits §5's first failure.

Parameter contract. The three intervals must be non-increasing with band index, enforced at elaboration — without that, band_tightened is meaningless. BANDS is capped at 3 because the table is three explicit parameters matching §3's verified structure; supporting more would need a packed array, and refusing is better than silently ignoring bands 3 and up.

Why out-of-range holds the shortest interval. §2's fourth reading says that outside the specified range the device is not specified, so there is no correct answer. The block picks the conservative direction — refreshing more often — because Chapter 15.1 §2 verified MIN = N/A, so over-refreshing is always specification-legal while under-refreshing is not. And it asserts band_out_of_range regardless, because a conservative guess is not a substitute for reporting that the system is outside its operating conditions.

Why the division is acceptable. Chapter 13.2 §7 classified its resolver as configuration-time arithmetic for exactly this reason: a band change is a rare event, not a per-cycle path, so a divider is affordable. In a real controller this would more likely be firmware. Truncating division is the correct choice here — a partially elapsed interval has not yet incremented the debt — which is the opposite of Chapter 13.2 §3's ceiling, and the reason is that this is counting completed intervals rather than satisfying a minimum.

Corner cases. Band change and service coinciding: the service resets the elapsed count, so the reload computes zero — correct, because nothing is owed immediately after service regardless of the unit. Band change on consecutive cycles: the repair depends only on elapsed time and the new interval, so it is idempotent and repeating it is safe. BANDS == 1: no change is ever possible and the block degenerates to a constant selector. Band moving to a cooler band: band_tightened is low, the interval lengthens, and the recomputed debt falls — which is correct and is the benign direction.

Synthesis implications. A three-way mux, a comparator, a constant multiply for the gap bound, and one divider on the repair path. The divider is the only cost and it is off the critical path by construction.

Failure modes. A downstream ledger ignoring debt_reload_valid — §5's first and most likely failure, and the block cannot force the load. Rescaling the interval and not the gap bound — §5's third failure; note this block computes gap_bound_cycles from the selected interval precisely so the two cannot drift. Using a ceiling on the repair division — over-reports the debt by one, which is conservative and wrong. Reading the wrong temperature source — undetectable here, and §11's discriminator is the only way to find it.

7. The Band Change, in Cycles

This chapter's registry annotation carries a diagram and no waveform, so the trace is a solved table — which suits it, since the interesting quantity is a recomputation rather than a signal shape.

  Band 0: interval 32, gap bound (2+1)×32 = 96
  Band 1: interval 16, gap bound (2+1)×16 = 48

  cycle  event              band  elapsed  interval  debt (ledger)  correct
  ──────────────────────────────────────────────────────────────────────────
     0   REF accepted         0        0       32          0            0
    30   —                    0       30       32          0            0
    32   interval boundary    0       32       32          1            1
    40   —                    0       40       32          1            1
    44   BAND → 1             1       44       16          1  ← stale   2
    44   repair: 44/16 = 2    1       44       16          2            2   ✓
    50   —                    1       50       16          2            2
    ──────────────────────────────────────────────────────────────────────────
  gap bound was 96 under band 0; it is 48 under band 1.
  At cycle 50 the elapsed gap is 50 — already past the NEW bound of 48.

Three things this trace shows that §5's prose cannot.

At cycle 44 the ledger's debt of 1 was correct a cycle earlier and wrong now. Nothing about the controller's behaviour changed; the unit did. The repair computes 44 / 16 = 2, and a controller that carried 1 forward would believe it had twice the headroom it has.

The gap bound halved from 96 to 48, and the elapsed gap of 50 at cycle 50 is already past it. So the band change did not merely add debt — it retroactively put the controller past a bound it had not been near. A design that rescaled the interval and left the gap comparison at 96 would not notice.

The debt correction was upward by exactly one here, and that is not a general rule. It is floor(elapsed / new) − floor(elapsed / old), which depends on where in the interval the change happened. §14's second exercise works a case where it jumps by more.

8. Four Assertions Worth Writing

// ── P1. §3's step function: the interval is always one of the table
//    entries, never an interpolation or an intermediate value.
//    Catches an implementation that tries to blend bands.
property p_interval_is_a_table_entry;
  @(posedge clk) disable iff (!rst_n)
    ( (interval_cycles == INT_W'(INTERVAL_0))
   || (interval_cycles == INT_W'(INTERVAL_1))
   || (interval_cycles == INT_W'(INTERVAL_2)) );
endproperty
a_interval_is_a_table_entry: assert property (p_interval_is_a_table_entry);

// ── P2. THE property of this chapter: on a band change the repair is
//    the elapsed time measured in the NEW interval, not the old debt.
//    Catches §5's first and most likely failure -- carrying the debt
//    unchanged -- at the point where it can still be prevented.
property p_repair_is_elapsed_in_new_units;
  @(posedge clk) disable iff (!rst_n)
    debt_reload_valid |->
      (debt_reload_value ==
         DEBT_W'($signed(32'(cycles_since_service) / 32'(interval_cycles))));
endproperty
a_repair_is_elapsed_in_new_units:
  assert property (p_repair_is_elapsed_in_new_units);

// ── P3. §5's third failure: the gap bound must track the interval.
//    A design that updates one and not the other permits a stretch
//    twice as long as the new band allows, and Chapter 15.3 §3
//    established the gap is a requirement the count does not imply.
property p_gap_bound_tracks_interval;
  @(posedge clk) disable iff (!rst_n)
    (gap_bound_cycles == (GAP_W'((ALLOWANCE + 1)) * GAP_W'(interval_cycles)));
endproperty
a_gap_bound_tracks_interval: assert property (p_gap_bound_tracks_interval);

// ── P4. An out-of-range band is REPORTED and resolves conservatively.
//    §2's fourth reading: outside the table the device is not
//    specified, so the block must not guess silently. The conservative
//    direction is legal because Chapter 15.1 §2 verified MIN = N/A.
property p_out_of_range_is_conservative_and_reported;
  @(posedge clk) disable iff (!rst_n)
    band_out_of_range |-> ( (interval_cycles == INT_W'(INTERVAL_2))
                         && (interval_cycles <= INT_W'(INTERVAL_0)) );
endproperty
a_out_of_range_is_conservative_and_reported:
  assert property (p_out_of_range_is_conservative_and_reported);

// ── C1. The interesting transitions are REACHED. The tightening
//    direction is the dangerous one and is the cover people omit.
c_band_tightened: cover property (@(posedge clk) disable iff (!rst_n)
                                    band_tightened);
c_band_loosened:  cover property (@(posedge clk) disable iff (!rst_n)
                                    (band_changed && !band_tightened));
c_out_of_range:   cover property (@(posedge clk) disable iff (!rst_n)
                                    band_out_of_range);

What these prove. That the interval is selected rather than interpolated; that the band-change repair is computed in the new unit; that the gap bound tracks the interval so the two cannot drift; and that an out-of-range band is reported and resolved conservatively.

What these do not prove. Four gaps, and the first two are the ones that matter most.

Nothing proves the downstream ledger loads the repair. This block computes debt_reload_value and cannot force anything to use it. §5's first failure — carrying the debt unchanged — lives in the consumer, so the property that catches it must be written against the ledger, checking that its debt equals the reload value on the cycle after a band change. That is the single most important assertion in this chapter's material and it belongs in a different module.

Nothing proves the band input is correct. §3 established the band is defined against case temperature at a specific measurement point. A design reading ambient, or junction, or a sensor elsewhere on the board selects bands from the wrong variable — and every property here passes, because the block cannot see where its input came from. §11's first discriminator is the only way to find it.

Nothing proves the interval values match the device. They are parameters, and §3's callout is explicit that band boundaries and multipliers are device properties. A table copied from a different part passes everything.

And nothing proves the data survived — Chapter 15.1 §8's boundary, unchanged and unchangeable.

Vacuity. P2 and P3's antecedents need a band change, which a test with a static band never produces — and a static band is the natural default. C1's three covers exist for that, and the tightened one is the dangerous direction.

9. DV — Reconstructing the Band Decision

Invert the representation. The block selects from a case statement. A checker should hold the band boundaries and the interval table separately, look up the interval from the observed band, and recompute the repair by its own division — so a case-statement mis-mapping produces a disagreement.

Derive the band independently where possible. This is the chapter-specific obligation and it is harder than the equivalents in earlier chapters. §8's second limitation is that the block cannot see where its band input came from. A checker with access to the thermal instrumentation should derive the band from the measurement itself and compare — because a correct table indexed by a wrong band is confidently wrong, and nothing internal detects it.

Check the consumer, not only the producer. The failure this chapter exists to prevent is a ledger that ignores the repair. A checker must assert the downstream debt after a band change, not merely that the reload value was computed.

  REFRESH INTERVAL BAND VIOLATION
    generation        : DDR4
    device            : 16Gb, case-temperature bands   [datasheet table]
    observed band     : 1   (85°C < TC ≤ 95°C)
    required interval : 3.9 µs      →  7488 cycles @ DDR4-3200
    configured        : 7.8 µs      → 14976 cycles     ← WRONG BAND
    ─────────────────────────────────────────────────────────────────
    consequence 1     : refresh rate half of requirement
    consequence 2     : gap bound 134.8 µs used; 35.1 µs permitted
                        (allowance 8, denominated in the wrong unit)
    debt reported     : 3      debt actually owed : 7
    band source       : ambient sensor        ← measurement point is
                                                CASE temperature
    root question     : which temperature is the band selected from?

The two lines to steal are consequence 2 and band source. Reporting that the gap bound is also wrong — by a factor of two, because the allowance is denominated in the interval — pre-empts the assumption that a wrong band only affects the rate. And naming the measurement point turns the finding from “the band is wrong” into “here is why”, which §11 shows is usually the actual bug.

10. Debugging

Symptom. Corruption or refresh-deadline violations that correlate with system load or ambient conditions rather than with any access pattern.

The discriminator that defines this chapter is the measurement point. It is the first thing to check, it requires no simulation, and it is the most common cause — because “temperature” is treated as a single quantity in most system designs while the datasheet specifies case temperature at a defined point. Getting it from the wrong sensor selects the wrong row of a correct table, and every internal check passes.

The second discriminator is the timing relative to a thermal transition. Failures after a transition point at §5's accounting; failures at steady state in a hot band point at the table or the measurement point. One question about when the failures cluster separates the two.

Responsible layer. If the band is correctly derived from case temperature, the table matches the device, the repair is applied and the gap bound rescaled, then this chapter's material is exonerated and the question moves to whether the design can afford the hottest band's rate — which is Chapter 15.5.

11. Common Misconceptions

“Temperature behaviour is universal across DDR devices.” Tempting because the 85°C boundary and the doubling appear so often that they read as a property of DRAM. Why it is wrong: §3's callout — band boundaries, band count, multipliers and the measurement point are device and generation properties. The verified table belongs to one named part. Consequence: a design that hard-codes a threshold and is wrong on the next part, with no code change to blame. Replacement model: a device-specific table, read from that device's datasheet. Debugging clue: a design that worked on one part and under-refreshes on another with identical nominal speed.

“DRAM refresh doubles above 85°C.” Tempting because it is a memorable compression of a real table, and it is correct for the first step of the verified device. Why it is wrong: it omits the second step. §3 verified a third band above 95°C at 1.95 µs — four times the coolest band's rate, not twice. A design built on “doubles” is half as fast as required in the hottest band. Consequence: under-refreshing by a factor of two in exactly the condition where retention is worst. Replacement model: read all the rows. Debugging clue: corruption only at the top of the thermal range.

“The extended temperature range is a fault condition.” Tempting because it sounds like an exception and it has extra conditions attached. Why it is wrong: §4 — the datasheet says full specifications are supported there. It is a normal operating mode with different parameters. Consequence: a system that throttles or halts when it should simply refresh faster, or — worse — one that was never designed for the band it can actually reach. Replacement model: design for the worst band the system can reach. Debugging clue: thermal management intervening where a refresh-rate change was the intended response.

“A band change only changes the refresh rate.” Tempting because the table's only column is an interval. Why it is wrong: §5 — the allowance and the gap bound are denominated in the interval, so they change too, and the debt already accumulated was measured in the old unit and is stale. Consequence: a controller that updates the interval and believes it is done, carrying a debt that under-reports and a gap bound twice too generous. Replacement model: a band change invalidates the accounting, not just the parameter. Debugging clue: deadline violations clustered shortly after thermal transitions.

“Resetting the debt on a band change is the clean thing to do.” Tempting because a mode change feels like a fresh start and zero is a tidy value. Why it is wrong: §5's second failure — it discards real deficit. Service genuinely owed does not stop being owed because the unit changed. Consequence: worse than carrying the stale value, because carrying at least preserves the magnitude. Replacement model: recompute from elapsed time in the new unit. Debugging clue: debt dropping to zero at a thermal transition with no service having occurred.

“The published interval reflects typical cell retention.” Tempting because a single number suggests a representative value. Why it is wrong: §1 — it derives from the weak tail, the worst cells the device is guaranteed to contain. Almost every cell is far better. Consequence: a designer who reasons that there is “plenty of margin” because typical retention is long, and who relaxes the rate on that basis. Replacement model: the number is a worst-case guarantee, and the margin on any particular part is not contractual. Debugging clue: a proposal to slow refresh justified by measurements on a sample.

“A controller can measure retention or model leakage to set its own rate.” Tempting because the obligation originates in a physical process, so modelling it feels more principled than a table lookup. Why it is wrong: a controller has no observability into retention — no cell voltage, no per-row margin, no leakage measurement — and §7's block has no thermal model for the same reason. What it has is a band input and a table. Consequence: RTL claiming to model retention, which misleads every later reader, and a design trusting a fiction over a published guarantee. Replacement model: physics determines, the specification publishes per band, the controller selects and counts. Debugging clue: any proposed design that needs to know a cell's charge or a row's age.

12. Interview Reasoning

“Retention is a distribution. How does a controller count against one number?” It does not bridge the gap itself — the specification does, by publishing a bound derived from the weak tail of the distribution, the worst cells the device is guaranteed to contain. The controller reads that bound and counts, holding no distribution at all. Two consequences worth volunteering: almost all refresh is unnecessary for almost all cells, which is why refresh-reduction research exists and why it is hard; and a part that happens to be better than specified gives you margin that is real but not contractual.

“How does temperature affect refresh, and how precise can you be?” For the device I can cite — a 16Gb DDR4 part — the average interval is specified per case-temperature band: 7.8 µs up to 85°C, 3.9 µs from 85 to 95, and 1.95 µs from 95 to 105. So it is a step function over three bands, a four-fold rate increase across the range, and defined against case temperature specifically. The precision that matters is the caveat: band boundaries, multipliers and the measurement point are device properties, so “refresh doubles above 85°C” is a compression that also happens to omit the third band.

“What does a controller have to do when the temperature band changes?” More than change the interval, which is the answer most people give. The postponement allowance and the gap bound are both denominated in the interval, so they change with it — and the debt already accumulated was measured in the old unit and is now stale. The correct action is to recompute the debt from elapsed time in the new interval and rescale the gap bound. Carrying the debt under-reports, and resetting it to zero is worse because it discards real deficit.

“Is the extended temperature range a degraded mode?” No — the datasheet says full specifications are supported there, with additional conditions. So it is a normal operating mode with a different row of the table, not an exception path. The design consequence is that the question is not what temperature you expect but what is the worst band the system can reach, because reaching it is supported and the design has to work there. One of the additional conditions is concrete: self-refresh in the extended range requires a specific mode-register configuration, so a design that gets the interval right and leaves self-refresh at its default is still non-compliant.

“A system shows corruption that correlates with load but not with access pattern. Where do you look?” The temperature band, and specifically the measurement point — because the datasheet specifies case temperature and most systems have an ambient or junction sensor closer to hand, which can be tens of degrees off and enough to select the wrong row of a correct table. That check needs no simulation. If the band is right, the next question is whether the failures cluster shortly after thermal transitions, which points at the band-change accounting rather than the band itself.

“Why can a controller not measure retention and set its own rate?” Because it has no observability into it. There is no cell voltage available, no per-row retention margin, no leakage measurement — and no thermal model either; the band arrives as an input. The specification exists precisely so that controllers need not model physics, and a design that claimed to would be trusting a fiction over a guarantee. The honest architecture is a table lookup, which is what the contract actually is.

13. Engineering Exercises

1. Compute the rate ratio. Using §3's verified table, give the ratio of refresh commands required in the hottest band to the coolest, and the interval in cycles for each band at DDR4-3200.

Worked: the intervals are 7.8, 3.9 and 1.95 µs, so the hottest band needs four times the commands of the coolest. At DDR4-3200, tCK is 0.625 ns, so the intervals are 12,480, 6,240 and 3,120 cycles. Rounding is down, per Chapter 15.1 §13's fourth exercise, because the interval is a maximum.

2. Repair a debt across a band change. A controller's last service was at cycle 0. At cycle 100 the band changes from an interval of 32 cycles to 12 cycles. Give the debt before and after the repair, and the change.

Worked: before, floor(100 / 32) = 3. After, floor(100 / 12) = 8. The debt jumps by five, not one — §7's trace warned this is not a fixed increment. With an allowance of 8 the controller is now exactly at its limit, having been comfortably inside it a cycle earlier.

3. Find the unrescaled gap bound. Using exercise 2's figures and an allowance of 8, give the gap bound before and after the change, and state whether the elapsed gap of 100 cycles violates either.

Worked: before, (8+1) × 32 = 288 — 100 is comfortably inside. After, (8+1) × 12 = 108 — 100 is still inside, but only just, with 8 cycles of headroom where there had been 188. A controller that left the comparison at 288 would have 180 cycles of phantom headroom and would not notice until it exceeded 108.

4. Classify four temperature claims. For each, say whether it is device-specific, generation-specific or universal, and how you would check it: (a) the interval halves above 85°C; (b) retention decreases as temperature rises; (c) the band is defined on case temperature; (d) there are three bands.

Worked: (a) device-specific — verified for one part, and the claim also omits the third band. (b) universal physics, owned by Chapter 2.2, and the only one of the four that needs no device context. (c) device-specific, and the most consequential to get wrong — §10's first discriminator. (d) device-specific. Three of four need a datasheet, which is the general lesson.

5. Choose the out-of-range behaviour. §7's block holds the shortest interval and reports when the band is out of range. Argue for two alternatives — halting, and holding the last valid band — and say which you would ship.

Worked: halting is defensible for a system that must not operate out of specification, and it converts a silent risk into a loud failure; the cost is that a transient sensor glitch takes the system down. Holding the last valid band is the least disruptive and the most dangerous, because if the band went out of range by rising, the last valid band is now too slow. The shipped choice should be conservative interval plus a report, because it is the only option that is both safe for retention and visible — and the report is what makes the sensor problem findable.

6. Locate the failure in time. Two systems fail. System A's corruption is uniform across the thermal range. System B's begins within a few hundred microseconds of every thermal transition. Diagnose each.

Worked: A is a steady-state problem — a wrong table, a wrong measurement point, or a design that never handles the hot band at all. B is §5's accounting: the interval is being updated and the debt or gap bound is not being repaired, so the controller is briefly and repeatedly non-compliant immediately after each change. The timing relative to transitions is the whole discriminator.

7. Write the consumer-side assertion. §8's first limitation is that this block cannot force the ledger to load the repair. Write the property that catches it, name the module it belongs in, and say why it cannot live here.

14. Summary

Retention is physically a distribution (Chapter 2.2) and contractually a single number. The specification performs the reduction, publishing a bound derived from the weak tail — the worst cells the device is guaranteed to contain — so the controller holds one interval and never sees a distribution. Two consequences: almost all refresh is unnecessary for almost all cells, and a part that is better than specified offers margin that is real and not contractual.

Temperature is not a model a controller builds. It is a specified operating condition and a table. Verified for a 16Gb DDR4 part: the average interval is 7.8 µs for −40°C to 85°C, 3.9 µs from 85 to 95, and 1.95 µs from 95 to 105 — a step function over three case-temperature bands and a four-fold rate increase across the range. The band boundaries, the multipliers and the measurement point are device properties, so a universal threshold is never a fact — and the familiar “doubles above 85°C” compression omits the third band entirely.

The extended range is not a fault path: the datasheet states full specifications are supported there, with conditions. So the design question is not what temperature is expected but what is the worst band the system can reach. One of those conditions is concrete and verified — self-refresh in the extended range requires a specific mode-register configuration, so the temperature condition reaches beyond the interval.

And the chapter's own contribution: a band change invalidates accounting, not just a parameter. The postponement allowance and the gap bound are denominated in the interval, so both change with it, and the debt already accumulated was measured in the old unit. Carrying it under-reports; resetting it to zero discards real deficit; rescaling the interval without the gap bound permits a stretch twice as long as the new band allows. The correct action is to recompute the debt from elapsed time in the new interval, and §13's second exercise shows the correction is not a fixed increment — it jumped by five.

retention_mode_selector selects rather than interpolates, computes the repair by truncating division — correct here, because it counts completed intervals rather than satisfying a minimum — derives the gap bound from the selected interval so the two cannot drift, and resolves an out-of-range band conservatively while still reporting it, because over-refreshing is legal and operating outside the specified range is a system fault rather than a refresh decision.

Its most important limitation is honest and structural: it cannot force the downstream ledger to load the repair, so the assertion that catches the likeliest failure belongs in a different module. And it cannot see where its band input came from — which is why §10's first discriminator is the measurement point, checkable with no simulation at all, and the most common cause.

15. What Comes Next

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

Chapter 15.5 does the arithmetic, and it is more interesting than a single percentage. Using the verified figures this module has accumulated — the refresh cycle times by device density and refresh mode, and the intervals by temperature band — the unavailable fraction of a resource's time is computable directly. Three results are worth anticipating.

It grows with density. It grows sharply with temperature — and the hottest band's figure is large enough to change a thermal design decision. And the mode that exists to reduce refresh's blocking duration turns out to increase the aggregate cost, which is the opposite of what its name suggests and is the reason Chapter 15.3 §1's fine-granularity modes needed their own arithmetic rather than an intuition.