Write Leveling

Chapter 20.2 §4 established that on a write the controller side delivers the strobe already centred in its data, which makes the device's receiver simple. That sounds like the write direction is the easy one, and for the data relationship it is.

There is a second requirement, and it is independent of the first:

The device also requires the write strobe to arrive in a defined relationship to CK. On a module wired for signal integrity rather than for equal path lengths, that relationship is different at every DRAM — so one strobe delay cannot satisfy all of them.

Write levelling is the mechanism that measures the relationship. This chapter owns what it measures, why it is needed, and how the device reports it. Chapter 21.1 owns the algorithm that uses the report — and the split matters, because the mechanism is a protocol feature while the algorithm is a search.

1. Two Requirements, Not One

A write has to satisfy two separate timing relationships, and conflating them makes write levelling look mysterious.

Requirement one — strobe to data. The strobe must sit centred in the data it times, so the device can sample on the strobe edge. Chapter 20.2 §4 established this, and the PHY satisfies it easily: it generates both signals, so it places one relative to the other by construction.

Requirement two — strobe to CK. The strobe must arrive at the device in a defined relationship to the clock the device is running on. This is not about the data at all.

  the write strobe must be simultaneously:

    centred in ITS OWN DATA          <- 20.2 §4. Easy: the PHY makes both.
        AND
    aligned to CK AT THE DEVICE      <- this chapter. Hard: the PHY does
                                        not know when CK arrives there.

The device publishes requirement two as a parameter. In the DDR4 datasheet examined for this module it appears as tDQSS — the DQS rising edge to CK rising edge relationship — specified as 0.27 CK for a 1tCK preamble and 0.50 CK for a 2tCK preamble, per the Micron 16Gb DDR4 device's timing tables. The datasheet is explicit that violating the strobe-to-clock requirements on a write burst can result in wrong data being written.

Source: Micron 16Gb: x4, x8, x16 DDR4 SDRAM datasheet, Rev. H, 8/2021 (16gb_ddr4_dram.pdf), write-strobe input timing.

2. Why the Relationship Differs Per Device

The requirement would be easy if CK arrived at every DRAM at the same moment. On a modern module it does not, and the reason is a deliberate design choice.

Fly-by topology. From DDR3 onward, module command, address and clock signals are routed in a chain that passes each DRAM in turn rather than branching to all of them equally. Module 22 owns why: fewer and shorter stubs, better signal integrity, and therefore higher achievable rates on heavily loaded signals.

The cost is skew. Because CK visits the devices in sequence, it arrives at the last device later than at the first. Meanwhile each device's DQS is routed point to point from the controller, on its own short path.

  CONCEPTUAL — NOT TO SCALE.

   controller
       |
   CK  +---> DRAM0 ---> DRAM1 ---> DRAM2 ---> DRAM3     fly-by chain:
                                                        CK arrives LATER
                                                        at each device

   DQS +----> DRAM0                                     point to point:
       +-------------> DRAM1                            each lane its own
       +---------------------> DRAM2                    short path
       +-------------------------------> DRAM3

   so CK-to-DQS at DRAM0  !=  CK-to-DQS at DRAM3
   and the difference grows along the chain

So requirement two has a different answer at every device, and since 20.2 §1 established that each byte lane has its own strobe, the controller has one delay to set per lane — which is exactly the granularity the problem has.

3. The Device Answers a Yes-or-No Question

The mechanism is simpler than its reputation, and its simplicity is the point.

In write-levelling mode, the device samples CK using the incoming DQS as the sampling event, and returns the sampled value on its DQ pins.

  the probe, once

    controller  ->  device     enter write-levelling mode
    controller  ->  device     drive a DQS edge
    device internally          sample CK at that edge
    device      ->  controller drive the sampled value on DQ

  what comes back is ONE BIT of information:

    DQ = 0   the strobe edge landed while CK was low
    DQ = 1   the strobe edge landed while CK was high

That is all the device reports. Not a phase, not an amount, not a direction — a single sample of a clock, taken at the moment the controller's strobe arrived.

Two properties of the mode worth noting, because they shape §8's interface.

Normal write behaviour is suspended. In levelling mode the device is not writing data anywhere; DQ is an output carrying the feedback rather than an input carrying data. That inversion is a mode change, not a side effect, and the controller's DQ direction control must follow it.

The probe is repeatable and non-destructive. Nothing in memory changes, so the controller may probe as often as it likes — which is what makes a search practical at all, and is why Module 21 can afford to sample a point more than once.

4. The Levelling Probe, in Sequence

The Calib agent actor is deliberately vague. Chapter 19.1 §3 established that training ownership is strongly implementation-dependent: firmware, a hardware engine in the PHY, or the controller may run it, and all three ship. This chapter's interface serves any of them, which is why §8's block has a request/response shape rather than an embedded sequencer.

5. What One Probe Looks Like

EDUCATIONAL — cycle numbers show the protocol sequence only. The sub-cycle phase relationship between the strobe edge and CK is what the probe measures and is NOT representable on a cycle grid; §6 sketches it separately.

Two probes at two different delay settings, showing the report changing.

The flip between cycle 2 and cycle 6 is the entire measurement. Two probes, two bits, and the boundary is now known to lie between setting 18 and setting 22.

What the waveform cannot show is the thing being measured. The strobe edge's position within a clock phase is a sub-cycle quantity, and a cycle grid has no column for it. §6 sketches it, labelled as a sketch.

6. What the Bit Is Actually Telling You

  CONCEPTUAL — NOT TO SCALE. The horizontal axis is sub-cycle phase,
  which §5's waveform cannot represent.

   CK at the device:     ______|‾‾‾‾‾‾‾‾‾‾‾‾|______|‾‾‾‾‾‾
                               ^
                          CK rising edge

   strobe edge, delay 18:    |                     device samples CK
                             ^                     while it is LOW  -> 0

   strobe edge, delay 22:            |             device samples CK
                                     ^             while it is HIGH -> 1

   the boundary lies between 18 and 22, and AT the boundary the
   strobe edge coincides with CK's rising edge -- which is the
   relationship tDQSS is specified against (§1).

Three things this sketch makes visible that the waveform cannot.

The reported bit is a function of phase, not of time. The same delay setting produces a different answer at a different device position, because CK arrives there at a different phase.

The boundary is one point and the settings are discrete. A delay control has finite resolution, so the boundary generally falls between two achievable settings. That is not a defect; it is a quantisation, and dealing with it is part of what makes 21.1's algorithm nontrivial.

Nothing here says where the final setting should sit. Landing exactly on the boundary means sitting exactly where the device's sampling is ambiguous — which is the worst place for margin. The final choice is offset from the boundary, and by how much, in which direction, is Module 21's decision informed by 20.5's window figures.

7. Why This Is Not Read Capture Turned Around

A comparison worth making explicitly, because both chapters are about a strobe and a phase.

The feedback row is the structural difference. Chapter 20.3 §12 established that a read receiver has no way to know whether its sampling instant was good — there is no quality indication anywhere in the capture contract. Write levelling is the opposite: the device exists to answer the question.

That asymmetry is why read-side settings need a different discovery method from write-side ones (Module 21 treats them as separate chapters), and it is worth noticing that the write side is the easier problem precisely because someone can be asked.

8. The Probe Interface

// ─────────────────────────────────────────────────────────────────────
// write_level_feedback_if
//
// CLASSIFICATION
//   Synthesizable educational RTL. Sequential. One responsibility:
//   issue ONE write-levelling probe at a caller-supplied delay
//   setting, and report the one bit the device returns.
//
//   IT IS AN INTERFACE, NOT AN ALGORITHM. It has no loop, no sweep,
//   no boundary detection and no notion of a "good" setting.
//
// WHAT IT DOES NOT MODEL
//   - NO SEARCH. Chapter 21.1 owns the write-levelling algorithm:
//     which delay to try next, how many samples per point, how to
//     handle a noisy boundary, and where relative to the boundary the
//     final value should sit (§3, §6). A block that looped here would
//     make that chapter redundant and would teach the search badly.
//   - NO DELAY ELEMENT. delay_setting is passed OUT to the strobe path
//     and applied by technology-specific hardware (Chapter 19.1 §5).
//     Nothing here delays anything.
//   - NO SUB-CYCLE TIMING. The phase relationship this probe measures
//     is not representable in portable RTL; the block only handles the
//     PROTOCOL around the measurement.
//   - No mode-register programming. Entering and leaving levelling
//     mode is a command sequence the controller issues (Module 7);
//     wl_mode_active is an input reporting that it has happened.
//   - No read capture (Chapter 20.3), no data path, no gate.
// ─────────────────────────────────────────────────────────────────────
module write_level_feedback_if #(
  parameter int DELAY_W = 6,
  // Cycles from driving the strobe edge to the device's feedback being
  // stable at the PHY. A device-and-board property supplied by the
  // caller, not a constant this block could know.
  parameter int FEEDBACK_LATENCY = 2,
  parameter int LAT_W = (FEEDBACK_LATENCY <= 1) ? 1 : $clog2(FEEDBACK_LATENCY + 1)
) (
  input  logic                clk,
  input  logic                rst_n,

  // ── From the calibration agent -- firmware, a hardware engine, or
  //    the controller. Chapter 19.1 §3: which of those it is varies by
  //    implementation, so this interface serves any of them.
  input  logic                probe_req,
  input  logic [DELAY_W-1:0]  delay_setting,

  // ── From the controller: the device has been placed in levelling
  //    mode and its DQ pins are outputs carrying feedback (§3).
  input  logic                wl_mode_active,

  // ── To the strobe path. The setting is forwarded for technology-
  //    specific hardware to apply; this block does not delay anything.
  output logic [DELAY_W-1:0]  strobe_delay,
  output logic                drive_strobe_edge,

  // ── From the receive path: the device's returned sample. One bit.
  input  logic                dq_feedback_valid,
  input  logic                dq_feedback,

  // ── To the agent. ONE probe, ONE bit.
  output logic                probe_done,
  output logic                probe_result,
  output logic                busy,

  output logic                err_probe_outside_mode,
  output logic                err_feedback_without_probe
);

  if (DELAY_W          < 1) $fatal(1, "write_level_feedback_if: DELAY_W must be >= 1");
  if (FEEDBACK_LATENCY < 1) $fatal(1, "write_level_feedback_if: FEEDBACK_LATENCY must be >= 1");

  typedef enum logic [1:0] {
    W_IDLE  = 2'd0,
    W_DRIVE = 2'd1,  // strobe edge driven this cycle
    W_WAIT  = 2'd2   // waiting for the device's feedback
  } wl_state_e;

  wl_state_e        state;
  logic [LAT_W-1:0] wait_cnt;
  logic [DELAY_W-1:0] held_setting;

  assign busy              = (state != W_IDLE);
  assign strobe_delay      = held_setting;
  assign drive_strobe_edge = (state == W_DRIVE);

  // ── A probe outside levelling mode drives a strobe edge at a device
  //    that is not expecting one and will not answer. Reported: the
  //    agent would otherwise wait for feedback that never comes.
  assign err_probe_outside_mode = probe_req && !wl_mode_active;

  // ── Feedback with no probe outstanding. Either the device answered
  //    something nobody asked, or the latency parameter is wrong and
  //    the answer arrived after this block stopped listening.
  assign err_feedback_without_probe =
      dq_feedback_valid && (state != W_WAIT);

  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      state        <= W_IDLE;
      wait_cnt     <= '0;
      held_setting <= '0;
      probe_done   <= 1'b0;
      probe_result <= 1'b0;
    end else begin
      // probe_done is a one-cycle pulse; clear it every cycle unless
      // re-asserted below, so the agent cannot mistake a stale result
      // for a fresh one.
      probe_done <= 1'b0;

      unique case (state)

        W_IDLE:
          if (probe_req && wl_mode_active) begin
            // The setting is latched at the request and does NOT track
            // delay_setting afterwards. A setting that changed mid-probe
            // would make the returned bit describe a phase that was
            // never actually applied -- §10's corner case.
            held_setting <= delay_setting;
            state        <= W_DRIVE;
          end

        W_DRIVE: begin
          state    <= W_WAIT;
          wait_cnt <= '0;
        end

        W_WAIT: begin
          if (dq_feedback_valid) begin
            // Take the device's answer the moment it is valid. The
            // counter below is a TIMEOUT, not the expected arrival.
            probe_result <= dq_feedback;
            probe_done   <= 1'b1;
            state        <= W_IDLE;
          end else if (wait_cnt >= LAT_W'(FEEDBACK_LATENCY)) begin
            // No answer within the stated latency. Returning to idle
            // WITHOUT probe_done means the agent sees no result rather
            // than a fabricated one -- the honest failure (§10).
            state <= W_IDLE;
          end else begin
            wait_cnt <= wait_cnt + LAT_W'(1);
          end
        end

        default: state <= W_IDLE;
      endcase
    end
  end

endmodule

Simulating it. Assert wl_mode_active, pulse probe_req with a setting, and observe drive_strobe_edge for one cycle followed by busy until the feedback arrives; probe_done then pulses for one cycle with probe_result carrying the device's bit. Sweep the setting from the testbench and watch the result flip — which reproduces §5's two probes, and makes the point that the sweep lives outside this block.

Synthesis. Two state bits, a small wait counter, and a DELAY_W-wide holding register. Instantiated per lane, because §2 established the skew is per device position and 20.2 §1 established the lane is the unit of strobe authority.

What is unrealistic about it. FEEDBACK_LATENCY stands in for a real round trip through the device and the board, and the block treats it as a fixed cycle count. A real implementation's timeout has to accommodate whatever that round trip actually is across PVT — which is not a constant, and is why the block takes the answer when it arrives rather than at a predicted cycle, using the count only as a bound.

9. What the Assertions Prove

// ── P1. A probe drives exactly one strobe edge. More than one and the
//    device samples CK more than once per request, so the returned bit
//    may describe a different edge than the agent thinks it asked about.
property p_one_edge_per_probe;
  @(posedge clk) disable iff (!rst_n)
    drive_strobe_edge |=> !drive_strobe_edge;
endproperty
a_one_edge_per_probe: assert property (p_one_edge_per_probe);

// ── P2. The applied setting is immutable for the duration of a probe.
//    If it moved mid-probe the returned bit would describe a phase that
//    was never applied, which silently corrupts a search that trusts it.
property p_setting_stable_during_probe;
  @(posedge clk) disable iff (!rst_n)
    busy |=> (busy -> $stable(strobe_delay));
endproperty
a_setting_stable_during_probe: assert property (p_setting_stable_during_probe);

// ── P3. A result is reported only in response to a probe. Catches a
//    fabricated answer -- which is the worst possible failure here,
//    because a search cannot distinguish a wrong bit from a right one.
property p_result_only_after_probe;
  @(posedge clk) disable iff (!rst_n)
    probe_done |-> $past(state == W_WAIT, 1);
endproperty
a_result_only_after_probe: assert property (p_result_only_after_probe);

// ── P4. probe_done is a single-cycle pulse. A held result lets an
//    agent read the same answer twice and believe it probed twice.
property p_done_is_a_pulse;
  @(posedge clk) disable iff (!rst_n)
    probe_done |=> !probe_done;
endproperty
a_done_is_a_pulse: assert property (p_done_is_a_pulse);

// ── P5. No probe is accepted outside levelling mode. Driving a strobe
//    edge at a device in normal mode is not a measurement; it is a
//    stray strobe on a live interface.
property p_no_probe_outside_mode;
  @(posedge clk) disable iff (!rst_n)
    $rose(busy) |-> wl_mode_active;
endproperty
a_no_probe_outside_mode: assert property (p_no_probe_outside_mode);

// ── P6. A probe always terminates -- with a result, or without one on
//    timeout, but never hanging. An agent blocked forever on a probe
//    stalls the whole bring-up sequence (Chapter 19.5).
property p_probe_terminates;
  @(posedge clk) disable iff (!rst_n)
    $rose(busy) |-> ##[1:FEEDBACK_LATENCY+2] !busy;
endproperty
a_probe_terminates: assert property (p_probe_terminates);

// ── Covers.
c_result_zero:    cover property (@(posedge clk) disable iff (!rst_n)
                    probe_done && !probe_result);
c_result_one:     cover property (@(posedge clk) disable iff (!rst_n)
                    probe_done && probe_result);
c_timeout:        cover property (@(posedge clk) disable iff (!rst_n)
                    $fell(busy) && !probe_done);
c_probe_outside:  cover property (@(posedge clk) disable iff (!rst_n)
                    err_probe_outside_mode);

What they prove. That the probe protocol is sound: one edge per request, an immutable setting, a result only in response to a request, a single-cycle report, no probing outside the mode, and guaranteed termination.

What they do not prove — and the limitation is total. Nothing here says the returned bit is correct. The device sampled its clock and reported what it saw; if the strobe delay was applied wrongly by the delay hardware, or the feedback path mis-samples, or the latency assumption is wrong and a stale value is read, every property above still passes. The bit is an input and this block trusts it completely.

Nor does anything here say the bit is useful. A probe at a setting far from the boundary returns a perfectly valid bit that locates nothing. Turning valid bits into a good setting is the algorithm, and the algorithm is Chapter 21.1's — which is the boundary this chapter has maintained throughout.

c_result_zero and c_result_one together are the covers that matter. A test that only ever probes one side of the boundary exercises the protocol but never demonstrates that the interface can report both answers — and an interface that can only ever return one bit value would satisfy every property while being useless.

10. Corner Cases

The timeout row is the one with a design decision behind it. Returning to idle without probe_done means the agent observes no result — it can retry, or report a failure, or move on. Asserting probe_done with a default value would be far worse, because a search has no way to distinguish a fabricated bit from a measured one, and a single wrong bit can place the boundary in entirely the wrong place. Silence is a usable answer; a guess is not.

11. DV — Model the Device, Not the Block

The interesting checker here models the device, because the device is what the block is talking to.

Build a behavioural device model that holds a notional boundary setting B, and for a probe at setting D returns D >= B. That model has no relationship to the RTL's state machine, so it exercises the protocol without duplicating it. Then check three things:

Protocol conformance — one edge per probe, a result for every probe that was answered, no result for one that was not.

Bit fidelity — the reported bit equals what the device model returned, every time. A block that inverted, held or delayed a bit would fail here and nowhere else.

Monotonicity across probes — sweeping D from the testbench must produce a report that changes at most once, from 0 to 1. That is a property of the device model and the interface together, and it is the closest a simulation can come to checking that the measurement means anything.

  WRITE-LEVELLING PROBE FIDELITY MISMATCH
    lane                 : 2
    device model boundary : B = 20  (model returns 1 for D >= 20)

    probe sequence and results
      D = 16   model 0   reported 0   ok
      D = 18   model 0   reported 0   ok
      D = 20   model 1   reported 0   <-- MISMATCH
      D = 22   model 1   reported 1   ok

    first mismatch : D = 20, the boundary setting itself
    pattern        : the reported boundary is one setting LATE

    diagnosis : the feedback is being sampled one cycle early, so the
                probe at D = 20 read the previous probe's value.
                FEEDBACK_LATENCY is understated for this path.
    why it is dangerous : the protocol is sound, every assertion
                passes, and the boundary is simply reported in the
                wrong place. A search using these bits converges
                confidently on a setting one step off.
    discriminator : increase FEEDBACK_LATENCY by one and re-run. If
                the mismatch moves to a different D, the latency is
                wrong; if it stays at D = 20, the delay hardware is
                not applying the setting the block forwarded.
    NOT indicated : anything about whether setting 20 has good margin.
                The boundary is a phase, not a quality (§6).

The why it is dangerous block is the reason bit fidelity is checked separately from protocol conformance. A sound protocol carrying a wrong bit is worse than a broken protocol, because nothing complains and the error propagates into a confident wrong answer.

Directed cases worth running: a probe at every setting from 0 to maximum against a fixed model boundary, confirming exactly one transition; a probe outside levelling mode; feedback withheld entirely, which must time out silently; feedback on the last permitted cycle and one cycle later; probe_req held high; probe_req during busy; FEEDBACK_LATENCY = 1; and a reset landing in each state.

12. Debugging

Symptom: writes fail on some device positions and not others, on a fully populated module. §2. This is the fly-by signature, and it is what write levelling exists to fix. Check whether levelling ran at all and whether it produced a different setting per lane — a single global setting is the design error, not a tuning problem.

Symptom: levelling reports the same bit at every setting. The probe is not reaching the device or the feedback is not reaching the PHY. err_probe_outside_mode and err_feedback_without_probe distinguish the two ends. A report that never changes locates no boundary, and a search fed by it will either fail to converge or converge on an endpoint.

Symptom: levelling converges but writes still fail. Separate the two claims. The boundary may be correct and the final setting wrong — which is Chapter 21.1's offset decision, not this interface's. Or the boundary may be correct and the margin around it too small, which is 20.5's question.

Symptom: levelling results differ between runs on the same hardware. A noisy boundary, which is expected near the transition and is why Module 21 samples a point more than once. If the whole sweep differs, suspect the feedback latency rather than the device.

Symptom: writes fail after a temperature change, having worked at bring-up. Not this chapter's mechanism failing — the mechanism measured correctly at the time. The relationship moved, which is Chapter 19.5 §4's periodic-recalibration argument applied to the write side.

Symptom: err_feedback_without_probe asserts during normal operation. The device is driving DQ when the PHY expects to. Almost always a mode-exit problem: levelling mode was not properly left, so the device still thinks DQ is an output (§3).

13. Misconceptions

“Write levelling aligns the strobe to the data.” §1 — that requirement is satisfied by construction, because the PHY generates both. Levelling aligns the strobe to CK. Clue: a design that treats levelling as unnecessary because the strobe is already centred.

“One strobe delay works for the whole interface.” §2 — fly-by gives each device position a different CK arrival. Clue: a single global write-strobe setting on a populated module.

“The controller can calculate the CK-to-DQS skew.” §2's callout — it depends on module routing, device position, board and temperature, and the controller has no probe at the device's pins. Clue: a design with a computed write-strobe delay and no levelling step.

“The device reports how far off the strobe is.” It reports one bit — before or after (§3). It is a detector, not a meter. Clue: an expectation of a phase value in the feedback.

“Landing exactly on the reported boundary is the goal.” §6 — the boundary is where the device's sampling is ambiguous, which is the worst place for margin. The final setting is offset from it. Clue: a levelling result placed at the transition.

“Write levelling and read capture are the same problem mirrored.” §7 — on a read nobody can be asked whether the sampling instant was good; on a write the device answers. Different structure, different discovery method. Clue: a single training approach applied to both directions.

“Levelling once at bring-up is enough.” The relationship moves with temperature and voltage (19.5 §4). Clue: an interface that degrades under sustained load.

“A timeout should report a default result.” §10 — a search cannot distinguish a fabricated bit from a measured one, and one wrong bit misplaces the boundary. Clue: a probe interface that always asserts done.

“This chapter explains how write levelling works.” It explains what it measures and how the device answers. The search that turns answers into a setting is 21.1's, and a diagram of the probe is not an understanding of the algorithm. Clue: an answer about levelling that describes one probe rather than a search.

14. Interview Reasoning

“Why does DDR need write levelling?” Because fly-by routing makes CK arrive at a different phase at each device, while the device requires the write strobe in a defined relationship to CK. The strong answer names both requirements of §1 and says which one levelling addresses.

“What does the device actually report?” One bit — the value of CK sampled at the arriving strobe edge. Then the consequence: it is a boundary detector, so the information is where the answer changes.

“Why can't the controller just compute the delay?” It depends on module routing, device position, board and temperature, none of which is knowable at design time, and the controller has no probe at the device's pins.

“Where should the final setting sit relative to the reported boundary?” Offset from it, because the boundary is where sampling is ambiguous. How far is a margin decision informed by the window parameters — and volunteering that it is not a levelling question is the discriminating part.

“Write levelling converged and writes still fail. What do you separate?” Boundary correct versus final setting correct versus margin sufficient. Three different owners: this interface, 21.1's algorithm, 20.5's budget.

“Why is the write side easier to train than the read side?” Because there is someone to ask. §7 — the device answers a direct question about the write strobe's phase; nothing answers the equivalent question on a read.

15. Exercises

1. State the two alignment requirements a write must satisfy, say which side satisfies each, and explain why satisfying one does nothing for the other.

2. On a four-device fly-by chain, rank the devices by how much strobe delay their lanes are likely to need, and justify the ordering from §2's sketch.

3. A probe at setting 12 returns 0 and a probe at setting 13 returns 1. What is known about the boundary? What is not known that a search still needs?

4. §8's block latches delay_setting at the request. Construct the sequence where not latching it produces a bit that describes a phase never applied.

5. The timeout path deliberately omits probe_done. Describe what a search observes, and contrast it with what a search would observe if a default bit were reported instead.

6. All six properties in §9 pass while the reported bit is inverted. Give the resulting sweep output for a device whose true boundary is 20, and say which DV check catches it.

7. Explain why probe_done must be a pulse rather than a level, in terms of what an agent could otherwise conclude.

8. A colleague adds a sweep loop inside write_level_feedback_if. Name two things that become impossible to change without modifying the block, and say which chapter's material has been absorbed.

16. Where This Goes

The write direction's second requirement is now explained: the strobe must meet CK at the device, fly-by makes that per-position, and the device answers a one-bit question that locates the boundary.

What this chapter deliberately has not said is how far from the boundary the final setting should sit, and that question cannot be answered without knowing how much margin exists to spend. The same gap sits at the end of 20.3: it established that a read sample should be near the centre of the data rather than at its transitions, without saying how wide the usable region actually is.

Chapter 20.5 closes both. It supplies the published window parameters — what the device guarantees about the region a receiver can rely on, how that region is specified per device and per pin, and what the arithmetic of subtracting the residual skew of 20.1 §3 actually leaves. That is what turns “offset from the boundary” and “sample near the centre” from advice into a budget with numbers in it.

Module 21 then owns every search that spends that budget.