Training Question

“Walk me through write levelling.” It is asked because it has a known answer, and it is followed up because the follow-up is the actual test.

The follow-up is almost always a different training step. Read levelling, gate training, eye centring — and the candidate who recited write levelling from memory has nothing to say, while the candidate who described it as an experiment answers the next one from the same frame.

The two sentences this chapter is built on:

Training does not create margin. It finds where the margin already is — and if there is none, a successful training run reports a pass anyway.

A pass bitmap is not a physical eye. It is one classifier's answer, at the settings the search tried, on the pattern the step drove, at one voltage and one temperature.

1. Why This Question Is Asked

Training is the only part of a DDR interface whose correctness is discovered rather than designed, which makes it the cleanest test of whether a candidate can describe a procedure they cannot look up.

Row two is the reason the question exists. An interviewer who hears a memorised write-levelling narrative will ask about gate training precisely to see whether the narrative was structure or recall.

2. The Eight-Field Frame

CURRICULUM-DERIVED from 21.1, which owns these eight fields for write levelling. This chapter's contribution is using them as a template — because every training step is the same experiment with different contents, and a candidate who has the frame can answer about a step they have never implemented.

   1  CONTROLLABLE VARIABLE   what the engine sweeps
   2  STIMULUS                what is driven while it sweeps
   3  OBSERVABLE              what comes back -- usually ONE BIT
   4  PASS CRITERION          the classifier that turns it into pass/fail
   5  SEARCH DOMAIN           the range and granularity of field 1
   6  STOPPING CONDITION      when the sweep ends
   7  SELECTION POLICY        which passing setting is COMMITTED
   8  FAILURE RESULT          what happens when nothing passes

Field 7 is where the engineering is, and field 8 is where the honesty is. Fields 1 to 6 describe how the data was gathered; field 7 is the only one that makes a decision, and field 8 is the only one that can refuse to.

Two rules about the frame, both worth stating unprompted:

Field 3 is one bit in most steps, and that is the frame's hardest constraint. CURRICULUM-DERIVED from 28.1 §1: a bitmap bit is classifier(observe(device(apply(setting)))) — a composition of judgement, capture, physics and control — so a zero can come from any of four independent domains and the bitmap records only the composition. Every training-debug difficulty follows from that projection.

Field 4 is a choice, not a measurement. A lenient classifier widens every window; a strict one narrows it. So two engineers can train the same board and disagree about the margin, without either being wrong about the bitmap.

3. Write Levelling Through the Frame

Q1 (establishing). Walk me through write levelling.

CURRICULUM-DERIVED from 20.4 and 21.1:

Three sentences that make this a senior answer rather than a correct one.

The observable is the device's opinion, not the data's. Write levelling aligns the strobe to CK. CURRICULUM-DERIVED from 20.4 §1 and 21.1 §11: the write direction has two independent alignment requirements, and this step trains one of them. It says nothing about whether the strobe is correctly placed within the write data — that is 21.4's.

The boundary is the worst place to operate. It is by definition where the device's sampling became marginal, so field 7 must move away from it — and CURRICULUM-DERIVED from 21.1 §11, the offset cannot be computed by the search, because a delay code has no defined physical size. It is supplied by whoever integrated the delay resource and knows its granularity.

And boundary-plus-three is not three units of margin. 21.1 §11 owns this: it establishes that the setting is three codes from where the device's CK sampling became marginal, which is a different quantity from where the data stops being captured — and is not 20.5's timing window at all.

Field 8 deserves its own sentence, because it is the field candidates omit. CURRICULUM-DERIVED from 21.1 §12: a search that finds no transition must fail, and three situations produce that — all-zero, all-one, and a transition that exists but is not usable. Notably, all-one is a failure even though every probe passed, because the boundary lies outside the searchable range and its position is therefore unknown. A candidate who says if everything passes, commit anything has failed the question.

4. The Follow-Up — A Step You Have Not Memorised

Q2 (applying the frame cold). Now describe gate training.

This is the question the interview was for, and the correct opening is to say what you are doing: I'll use the same frame; the contents differ.

CURRICULUM-DERIVED from 21.3, which owns the step: the DQS gate must be opened over the window in which the device's read strobe actually arrives.

The two things that make this answer credible without recall.

Field 8's second case is derivable rather than remembered. If the gate reports success at every position, the gate is not selective — either it is far wider than the strobe burst, or the detector is responding to something other than the strobe. That is the all-one reasoning of §3 applied to a step whose specifics you do not know, and deriving it out loud is worth more than having memorised it.

And the honest boundary: say what you are unsure of. I would need to check whether this step depends on a previously trained value — and CURRICULUM-DERIVED from 21.5, which owns the dependency structure across the searches and the derivation of a legal order from it, that is exactly the right question: training steps are ordered because later ones consume earlier results. Naming the dependency as the thing to check is a stronger answer than asserting an order you half-remember.

What not to do: invent a specific tap count, register name or vendor sequence. §13 explains why the refusal is the strong move.

5. Two Statements, and Where They Come From

Q3 (the corner case). Training passed on every lane with a wide window. What have you established?

That the classifier said pass at the settings the search tried. Nothing about the eye.

CURRICULUM-DERIVED from 28.1 §1, which owns this boundary for the whole curriculum: the bitmap is a digital sample of a decision, taken at whatever settings the search tried, under whatever pattern the step drove, at one voltage and one temperature, through one classifier with one threshold. The eye is a continuous physical region whose height is a voltage margin and whose width is a time margin, and neither quantity appears anywhere in a bitmap.

So a wide window is not a wide eye. A weak classifier widens it; a strong pattern narrows it.

The three consequences an interviewer is listening for:

And the first statement follows from the third consequence of the frame. Training sweeps a setting and records where a classifier passed. There is no step in that loop that improves the channel. If the electrical margin is one tap wide, training finds the one-tap window and commits inside it — and reports success. CURRICULUM-DERIVED from 28.1 §5, which owns the narrow-window and one-tap signatures as failure signatures precisely because the search itself does not treat them as failures.

Training does not create margin. A successful training run on a marginal channel is a successful report of a marginal channel.

6. The Experiment Loop

The fifth message is the whole difficulty. One bit crosses back, and CURRICULUM-DERIVED from 28.1 §1 it is the composition of four independent domains — control, physics, capture and judgement. The projection is what makes training debug hard, and naming it is what separates a candidate who has debugged training from one who has read about it.

And nothing in the loop measures the eye. The third message passes through the channel; the channel's behaviour is Module 22's and is never observed directly. §5's first statement is that observation.

7. Passed, and the Interface Still Fails

Q4 (removing an assumption). Training passed on every step and every lane. The interface fails functional traffic. Where do you start?

Not by re-running training, and saying that first is the answer. Training already reported what it can report; re-running it will report the same thing.

The reframe: a pass means the classifier passed on the training pattern, at the training settings, under training conditions. Functional traffic differs in all three. So the question is which of the three changed, and each has a distinguishing observation.

The fourth row is the one that is not an electrical problem at all, and it is cheap to rule out: CURRICULUM-DERIVED from 21.1 §7's candidate-versus-committed discipline, a trained value becomes real only when it is committed, so read back what the hardware is actually using. A candidate who checks that before proposing a signal-integrity investigation has saved the expensive week.

And the fifth row is the trap in the question's wording. Training passed on every step is only reassuring if the failing requirement had a step. Chapter 20.4 §1 owns the fact that the write direction has two independent alignment requirements, so “write levelling passed” leaves one of them untrained. Ask which steps ran before accepting that everything was trained.

Chapter 28.1 owns the full method — eleven signatures, the failure-domain split, and §15's turning of a bitmap into ranked hypotheses. The interview answer is to name the method and the first discriminator, not to guess a mechanism.

8. Passes Cold, Fails Hot

Q5 (diagnosing). It trains and runs at room temperature and fails after an hour under load. Is this a training bug?

Probably not a search bug, and the reasoning is a distinction the curriculum already owns.

CURRICULUM-DERIVED from 19.5 and 21.5, which own the one-time versus continuous split and the retraining question of which steps repeat and which run once: some calibrations are performed once at bring-up and some must track drift. A parameter that drifts with temperature and is trained only once will be correct at boot and wrong later, with no defect anywhere in the search.

So the three hypotheses, with their discriminators:

Row one is the first check because it is a configuration question, not an electrical one. Row three is the row candidates never offer, and it inverts the conclusion — the mechanism that exists to prevent drift failure can be the mechanism causing the failure, and the fix is then the interval rather than the margin.

And the honest framing to give unprompted: training is a boot-time measurement, so anything that changes after boot is outside what training can guarantee unless a retraining policy exists. That sentence answers the question before any evidence arrives, which is what makes it a senior answer.

9. RTL Review — Committing a Window

The intended contract:

1. Scan a pass bitmap of NTAPS bits and identify its contiguous runs of passing taps.
2. Select the widest run. Ties go to the lower-indexed run.
3. A run narrower than MIN_WIDTH is not eligible at all.
4. Commit the selected run's midpoint; on an even-length run, the lower of the two central taps.
5. If no run is eligible, do not commit — assert no_window and leave the committed value at its reset default. CURRICULUM-DERIVED from 21.1 §12: failure is a result.

// ---------------------------------------------------------------------
// window_commit -- INTENTIONALLY DEFECTIVE, for review (§9).
//
// CLASSIFICATION: synthesisable, ILLUSTRATIVE, and CONTAINS A BUG.
//
// WHAT IT IS MEANT TO DO: the five-clause contract above -- pick the
// WIDEST eligible run of passing taps and commit its midpoint, or
// refuse to commit.
//
// WHY IT EXISTS HERE: 21.1 §12 names the hazard without implementing
// it -- "the algorithm above stops at the first one and would take a
// spurious flip as the boundary; a production implementation
// continues the sweep". This block is that hazard in the window form,
// and 28.1 §6's disjoint-window signature is what feeds it.
//
// HOW TO RUN IT: present a bitmap with a narrow-but-eligible run at a
// LOW tap index and a much wider run above it.
// EXPECTED RESULT under clause 2: the WIDER run is committed.
// EXPECTED TRACE: commit_tap must land in the widest run's midpoint,
// not in the first run that happens to clear MIN_WIDTH.
//
// SYNTHESIS: one pass over NTAPS in a combinational loop. No memory.
// LIMITATIONS: one dimension only. Two-axis centring over sampling
// position and reference level is 21.4's and is NOT what the bug is.
// A wrapped bitmap (a run crossing the domain edge) is out of scope.
// ---------------------------------------------------------------------
module window_commit #(
  parameter int NTAPS     = 64,
  parameter int MIN_WIDTH = 3,          // ILLUSTRATIVE
  // COUNT, not INDEX: run lengths reach NTAPS, so the width register
  // needs $clog2(NTAPS+1) bits. Sized with $clog2(NTAPS) it saturates
  // on an all-passing bitmap -- the case 21.1 §12 calls a FAILURE, so
  // the counter would overflow inside the very signature it must report.
  parameter int W_W      = $clog2(NTAPS + 1),
  parameter int T_W      = $clog2(NTAPS)
)(
  input  logic [NTAPS-1:0]  bitmap,
  output logic [T_W-1:0]    commit_tap,
  output logic [W_W-1:0]    commit_width,
  output logic              no_window
);
  initial begin
    if (MIN_WIDTH < 1)      $fatal(1, "window_commit: MIN_WIDTH must be >= 1");
    if (MIN_WIDTH > NTAPS)  $fatal(1, "window_commit: MIN_WIDTH exceeds NTAPS");
  end

  always_comb begin
    logic [W_W-1:0] run_len;
    logic [T_W-1:0] run_start;
    logic           done;

    commit_tap   = '0;                  // clause 5: safe default
    commit_width = '0;
    no_window    = 1'b1;
    run_len      = '0;
    run_start    = '0;
    done         = 1'b0;

    for (int t = 0; t < NTAPS; t++) begin
      if (bitmap[t]) begin
        if (run_len == 0) run_start = t[T_W-1:0];
        run_len = run_len + 1'b1;
      end

      // A run ends at a failing tap or at the top of the domain.
      if (!bitmap[t] || (t == NTAPS - 1)) begin
        if (!done && run_len >= MIN_WIDTH[W_W-1:0]) begin   // <-- THE DEFECT
          commit_width = run_len;
          commit_tap   = run_start + (run_len - 1'b1) / 2;  // clause 4
          no_window    = 1'b0;
          done         = 1'b1;
        end
        run_len = '0;
      end
    end
  end
endmodule

Before reading on: which clause, what bitmap, and why does a narrow run exist at a low tap index in the first place?

10. The Defect — First Eligible, Not Widest

The violated clause is 2, and the defect is the !done term: the block commits the first run that clears MIN_WIDTH and then stops looking.

MIN_WIDTH is what makes it survive review. The guard is real, it is correctly applied, and it rejects genuine noise of one or two taps — so the code looks careful, and a reviewer who sees a width floor tends to stop checking the selection.

The bitmap that exposes it:

   ILLUSTRATIVE NTAPS = 24, MIN_WIDTH = 3.
   tap:      0         1         2
             0123456789012345678901234
   bitmap:   0001110000000111111111000
                ^^^                     run A: taps 3-5,   width 3
                            ^^^^^^^^^   run B: taps 13-21, width 9

   contract clause 2 : commit run B, midpoint tap 17
   this code         : run A clears MIN_WIDTH first, done = 1
                       -> commit_tap = 4, commit_width = 3

   committed 4 taps from a failing tap, with a 9-tap window unused.

Now the question the review is for: why does run A exist at all?

Because a fragmented bitmap is a documented signature, not a hypothetical. CURRICULUM-DERIVED from 28.1 §6, which owns the disjoint-windows signature, and 28.1 §7, the unstable bitmap. A narrow low-index island is exactly what an aliased response, a marginal classifier or a noisy single probe produces — and 21.1 §5 owns why one probe per setting is untrustworthy near a boundary. So the input that breaks this block is the input the system is known to produce.

And the consequence is the worst available combination. The block reports a pass, with commit_width = 3 — a number that, if anyone looks at it, is the evidence. So the failure mode is silent at the interface and visible only in a field nobody reads, which is why §12's first instrument is that field.

The correction, and the invariant it restores:

        // CORRECTED. Clause 2: track the widest eligible run across
        // the WHOLE sweep and commit that one. Removing `done` is the
        // fix; keeping `>` rather than `>=` is what makes ties go to
        // the lower-indexed run, as the clause requires.
        if (run_len >= MIN_WIDTH[W_W-1:0] && run_len > commit_width) begin
          commit_width = run_len;
          commit_tap   = run_start + (run_len - 1'b1) / 2;
          no_window    = 1'b0;
        end

And the review comment that outlives the fix: commit_width is now an output worth exporting, not a debug leftover. CURRICULUM-DERIVED from 21.1 §11, which makes the same argument about the uncertain band: it is not a margin, but it is a repeatable number that changes when the channel changes — and a system that records it can tell a narrow window from a wide one across boots and boards. A committed value alone cannot.

11. SVA Review — A Local Invariant Versus a Best Choice

A property offered as proof that the selector is correct:

  // Offered as "proves we commit inside a passing window".
  property p_commit_is_passing;
    @(posedge clk) disable iff (!rst_n)
      !no_window |-> bitmap[commit_tap];
  endproperty
  assert property (p_commit_is_passing)
    else $error("committed a failing tap");

Q. This passes on the defective block. Why, and what would catch it?

Because the committed tap is passing. Tap 4 is inside run A. The property checks membership in a window; the contract requires membership in the widest window — and no amount of strengthening the membership check reaches that.

This is a different failure from the previous two chapters' and the distinction is the lesson. 30.4 §8's property was too narrow in time; 30.5 §11's never named the contract's key signal. This one names everything it needs and still cannot express the obligation, because the obligation is a comparison against an alternative that was never computed.

A property can check a local invariant. It cannot check that a choice was the best available, because "best" requires the alternatives — and computing the alternatives is a reference model, not an assertion.

So the verification answer is a model, and these are the properties worth having alongside it:

  // Local invariants -- genuinely useful, and honestly scoped.
  property p_width_at_least_min;
    @(posedge clk) disable iff (!rst_n)
      !no_window |-> (commit_width >= MIN_WIDTH);
  endproperty
  assert property (p_width_at_least_min)
    else $error("committed a run narrower than MIN_WIDTH");

  // Clause 5 -- an invariant, not an implication: there is no cycle on
  // which committing with no window is acceptable.
  property p_refusal_is_safe;
    @(posedge clk) disable iff (!rst_n)
      no_window |-> (commit_width == '0);
  endproperty
  assert property (p_refusal_is_safe)
    else $error("reported no window but published a width");

  // The obligation that needs the MODEL. An independent scan computes
  // the widest eligible run; the check is equality against it. This is
  // 21.1 §16's "model the device, not the engine" applied to the
  // selector: the model recomputes the ANSWER, not the algorithm.
  //   assert (commit_width == ref_widest_eligible(bitmap));
  //   assert (commit_tap   == ref_midpoint_of_widest(bitmap));

  // And the covers the model needs to have been exercised at all --
  // §10's input is the one that matters, and a directed bitmap is the
  // only way to reach it reliably.
  cover property (@(posedge clk) disable iff (!rst_n)
                  !no_window && (num_eligible_runs > 1));
  cover property (@(posedge clk) disable iff (!rst_n)
                  !no_window && (commit_width == MIN_WIDTH));
  cover property (@(posedge clk) disable iff (!rst_n) no_window);

The first cover is the one that finds the bug, because a bitmap with a single run cannot distinguish first from widest. CURRICULUM-DERIVED from 21.1 §16's discipline — model the device, not the engine — and the same discipline applied here says the reference model must recompute the answer independently, not re-implement the selector's loop. A model that walks the bitmap the same way inherits the same bug.

Follow-up an interviewer should ask: is random stimulus enough? No, and saying so is the point. A random bitmap rarely produces a narrow low-index island beside a wide high-index one, so the first cover stays near zero under random traffic. The bitmaps that matter are the eleven signatures 28.1 catalogues, and they are directed tests — which is why the training-step testbench is a signature library rather than a constraint set.

12. What Would You Measure?

Q. What should a training run record, beyond the committed values?

Row one is the answer to the question, and row two is the answer to the follow-up. A pass/fail result per step is almost worthless; a width per step turns §5's statement into a measurement, and a full bitmap is what makes the eleven signatures usable at all.

Row seven is the senior addition, because it turns §8's drift question from a hypothesis into an experiment that does not disturb the system: measure the window again later and compare, rather than retraining and losing the evidence.

13. Common Wrong Answers

“Training optimises the interface timing.” §5. It finds where the margin already is. Nothing in the loop improves the channel.

“A wide passing window means good margin.” §5, and 28.1 §1 owns the correction: it means this classifier passed on this pattern at this moment. A weak classifier widens it.

“The window is 12 taps, so we have 12 taps of margin.” §5. A tap has no defined physical size — 21.1 §11. Taps are not picoseconds.

“Commit at the boundary.” §3. The boundary is by definition where the device's sampling became marginal — the worst available setting.

“Boundary plus three gives three units of margin.” §3. It gives three codes from where CK sampling became marginal, which is a different quantity from where data capture fails.

“Every probe passed, so commit the middle of the range.” §3. All-one is a failure: the boundary lies outside the searchable domain and its position is unknown — 21.1 §12.

“Write levelling passed, so the write path is trained.” §3, §7. The write direction has two independent alignment requirements and this step trains one — 20.4 §1.

“It trained, so the settings are in the hardware.” §7. Candidate is not committed — 21.1 §7. Read the applied register back.

“Training passed and it still fails, so re-run training.” §7. It will report the same thing. Ask which of pattern, settings and conditions changed.

“It fails after an hour, so the training search has a bug.” §8. Training is a boot-time measurement; anything that changes afterwards is outside what it guarantees unless a retraining policy exists.

“Continuous calibration can only help.” §8. It can be the disturbance — and the discriminator is whether the failure rate correlates with the calibration interval.

“One probe per setting is enough.” §5. Near a boundary it is not — 21.1 §5 — and a single-probe bitmap cannot distinguish a narrow window from a noisy one.

“The selector commits inside a passing window, so it is correct.” §11. Inside a window. The contract said the widest, and membership cannot express that.

“Random bitmaps will find selector bugs.” §11. They rarely produce a narrow island beside a wide window. The signatures are directed tests.

“The write-levelling sequence is: set MR…, then…” Do not recite register names or tap counts from memory. They are device- and PHY-specific, a remembered one is more likely wrong than useful, and the frame in §2 is what the question is testing. Saying the controllable variable is the strobe delay and the observable is the device's own CK sample; the specific register depends on the device and PHY is the stronger answer.

14. Self-Check

1. Write the eight fields from memory. Then state which one makes the decision and which one can refuse to.

2. Fill all eight for read levelling, using only the frame and 21.2's scope line. Mark each field you are inferring rather than recalling, and name the one dependency you would need to check.

3. Explain in two sentences why an all-passing sweep is a failure, and give the gate-training analogue of the same argument.

4. State the three consequences of “a pass bitmap is not an eye” and, for each, the measurement that would establish the real quantity instead.

5. Find the defect in §9 without reading §10. Construct a bitmap that exposes it, and say why that bitmap is a documented signature rather than a contrived input.

6. Explain why p_commit_is_passing passes on the defective block, and why no strengthening of it reaches the contract.

7. Give the general rule §11 derives, and contrast it with the rules 30.4 §8 and 30.5 §11 derived. All three concern a property that passes on a defective design; say what is different about each.

8. Training passes, the system runs for an hour, and fails. Give three hypotheses and, for each, one observation that would distinguish it — without retraining.

15. Where This Goes

A training question is an experiment question. Describe the eight fields rather than a narrative, because the follow-up is a step you did not prepare; training finds margin and never creates it, so a pass on a marginal channel is a successful report of marginality; a bitmap is one classifier's answer on one pattern at one moment, and its width is not picoseconds; and failure is a result, so all-passing is a failure too.

Three results carry forward. A width is worth recording and a pass is almost worthless. Candidate is not committed, so read the register back before investigating the channel. And a property can check a local invariant but not that a choice was the best available — the third distinct way a property passes on a defective design, and the reason 30.9 treats the question what does this assertion actually prove as a method rather than a habit.

Chapter 30.7 takes the layer this chapter kept reaching into and never opened. Training is a search the PHY runs; the PHY is the block that made the search necessary — and the question what does the PHY do fails in a specific way, because the honest answer is that the split between controller and PHY is not the same in any two implementations, and a candidate who states one boundary as universal has answered a question about one product.