PHY Question

“What does the PHY do, and where is the boundary with the controller?” The question looks like recall and is not, because there is no single boundary to recall.

CURRICULUM-DERIVED from 19.1 §3, which owns the ownership table and states the consequence exactly: six of its rows are implementation-dependent and one is strongly so, and an architecture diagram claiming one boundary is describing a particular product, not DDR.

So a candidate who states one split as universal has answered a question about one company's memory subsystem. And a candidate who tries to recite twenty rows runs out of time in the first four.

What survives pressure is a rule, not a table.

A function belongs to the PHY when performing it requires a physical quantity that is not knowable until after manufacture and board assembly. It belongs to the controller when it requires a decision about protocol state. When it requires both, it splits — and a question asking which one owns it has a false premise.

1. Why the Question Has No Single Answer

Three things are being graded, and the first is whether you know the question is underdetermined.

Row one has a specific failure mode worth naming: a candidate who confidently draws one boundary is not marked down for the boundary — they are marked down for not knowing it was a choice, which is what a working engineer discovers in their first week on a new project.

CURRICULUM-DERIVED from 19.1 §3's closing observation: when you join a project, the ownership table is something you read from that project's documentation. What transfers between projects is the list of functions that must be owned by somebody — and that list is what the rule in the header generates.

2. The Rule, and Where It Comes From

The rule is derived, not asserted. CURRICULUM-DERIVED from 19.1 §1, which argues it from a failing example — always_ff @(posedge dqs) elaborates and is not a DDR receiver — and from 19.1 §5, which lists what portable RTL cannot express: sub-cycle adjustable delay, a data-rate serialiser at the pin, a strobe-domain capture flop, clock multiplication and phase generation, termination and drive strength, and sensing a sampling point.

What every entry on that list has in common is the derivation:

   each one needs a quantity that DOES NOT EXIST at synthesis time

     board trace length          known after layout
     package delay               known after packaging
     process corner              known after manufacture
     temperature and voltage      known only at that moment
     the received strobe's phase  all four of the above, composed

   a synchronous RTL block is elaborated, synthesised and
   constrained BEFORE any of those numbers exist.

   -> so any function whose correctness depends on one of them
      cannot be a portable RTL block. it needs a configurable
      physical resource plus something that measures and sets it.

That is the rule, and it is why the rule works: it is not a convention about where teams draw lines. It is a statement about what information is available when.

The three zones the rule produces:

CURRICULUM-DERIVED from 19.1 §3 for every row; the zones are this chapter's reading of that table, not a replacement for it.

3. The Boundary, in Three Zones

The middle column is the answer to the interview question. CURRICULUM-DERIVED from 19.1 §3: training ownership is marked strongly implementation-dependent because firmware, the controller, or a hardware engine inside the PHY may each run the searches, and all three ship. ODT splits three ways in a single row — the controller decides when, the PHY applies it on its side, the DRAM terminates on its own die.

So the sentence to have ready: the left and right columns are fixed by what information exists at synthesis time; the middle column is a design choice, and on a new project it is the first thing I would read from the documentation. That answers the question and demonstrates the one thing the question is for.

4. Placing a Function That Is in No Table

Q1 (applying the rule). Which side owns read-data deskew across the lanes of a byte?

The value of this question is that reciting cannot help, so the rule has to carry it.

Apply the rule, out loud:

   does this need a quantity unknown until after assembly?

     lane-to-lane skew comes from trace lengths within a byte,
     package routing, and per-lane process variation.
     none of the three exists at synthesis time.

   -> the ADJUSTMENT is a per-lane physical delay: PHY side.

   does this need a decision about protocol state?

     no. it does not depend on which command was issued, on bank
     state, or on any timing parameter.

   -> the controller owns nothing here.

   but WHO FINDS the per-lane values?

     that is a search, and §2's third zone applies: training
     ownership varies. firmware, the controller, or a PHY engine.

So the complete answer has a fixed half and a varying half, and saying which is which is the answer. CURRICULUM-DERIVED from 19.1 §3, whose table marks discovering trained values as the one strongly implementation-dependent row, and 21.2 owns the read-side search.

Q2 (removing an assumption). Which side owns the decision to change data rate at runtime?

Neither cleanly, and recognising that is the point — the rule produces a split, and the split is instructive.

The fourth row is the senior observation and it is derivable rather than recalled. CURRICULUM-DERIVED from 19.5, which owns what it means for a trained value to become valid or stop being valid: a delay setting that centred a sampling point at one bit period is not correct at a different bit period, because the quantity it was trained against changed.

So a rate change is not a configuration write — it is a retraining event, and a candidate who says that has answered a question about the PHY without having memorised anything about rate changes.

5. Why the Controller Cannot Just Do It

Q3 (the corner case). The controller is synchronous RTL and DQS is a signal. Why can't the controller capture read data directly?

CURRICULUM-DERIVED from 19.1 §1, which owns this argument in full. The four reasons are worth being able to give in order, because each one names a real PHY structure — which is what makes the answer an architecture answer rather than a list of objections.

The fourth is the one that makes it an architecture argument rather than a timing complaint, and it is worth saying explicitly: the strobe is generated by the DRAM, so capturing on it places data in a domain the controller does not own. That is true regardless of data rate, so it cannot be fixed by running slower.

And the honesty the question is testing for: CURRICULUM-DERIVED from 19.1 §5's warning, a gearbox that reorders beats correctly proves nothing whatever about whether those beats were sampled in the right place. So “I wrote the PHY” usually means “I wrote the digital part of the PHY” — ordering, handshakes, width conversion, gate control as a logical window, and the lifecycle. Saying which half you worked on is a credibility statement, not a limitation.

6. What the PHY Believes Versus What Occurs

Q4 (the corner case that matters most). The PHY's gate is open and no data is captured. Is the gate wrong?

CURRICULUM-DERIVED from 19.4, which owns exactly this distinction: the strobe window that actually occurs, versus the window the PHY believes in. The gate is the PHY's belief; the arriving strobe is the fact.

The four possibilities, and only two of them are gate problems:

Rows three and four are the ones candidates skip, and they are the cheap checks. Row four is the sharpest distinction in the chapter: the gate asks was the strobe there, and capture asks was the data sampled in the right place — and CURRICULUM-DERIVED from 21.3, the gate's observable is presence, which differs from both a phase report and a correctness comparison.

So “the gate passed” means the strobe was found, not that the data is right. A presence observable cannot report correctness, and treating a gate pass as a data-path pass is the same error as treating a training pass as a margin measurement — 30.6 §5.

7. Controller Bug or PHY Bug?

Q5 (diagnosing). Data corruption on one byte lane. Which layer?

CURRICULUM-DERIVED from 19.1 §8, which owns the six-layer taxonomy and the rate test. The interview answer is the discriminator, not the guess.

The rate test is the single most useful discriminator, and its limits must be stated with it. CURRICULUM-DERIVED from 19.1 §8: if the interface works at a lower rate and fails at full rate, A, B and C are largely exonerated — digital ordering bugs do not care about frequency. It does not say which of D, E or F, and treating fails only at speed as proof of a signal-integrity problem skips two layers that are more likely and cheaper to check.

The one-lane detail narrows it further and is worth saying: a fault confined to one byte lane is evidence against a shared-resource cause — the clock relationship, the command path, the scheduler — because those would affect every lane. It points at per-lane structures: that lane's delay setting, that lane's trained value, that lane's routing.

And the ordering that makes this a senior answer: cheapest discriminator first. Read back the applied per-lane settings (minutes), then the rate test (an hour), then temperature, then the board. Chapter 30.10 owns the full method; what this chapter owns is that the layer question comes before any mechanism.

8. RTL Review — A Strobe Gate in the Controller's Clock Domain

The intended contract:

1. On a committed read, open a gate covering the returning strobe burst, with a guard on each side.
2. The gate's open position is CL + gate_offset, where gate_offset is an INPUT supplied by gate training — CURRICULUM-DERIVED from 21.3, which owns the search that produces it. It is not computable from protocol parameters, because it contains board flight time.
3. The gate stays open for the burst's strobe duration plus GUARD cycles either side.
4. If gate_trained is low, the gate must not open — an untrained position is unknown, and a guess is not a default.
5. Reset closes the gate.

// ---------------------------------------------------------------------
// dqs_gate_ctrl -- INTENTIONALLY DEFECTIVE, for review (§8).
//
// CLASSIFICATION: synthesisable, ILLUSTRATIVE, and CONTAINS A BUG.
//
// WHAT IT IS MEANT TO DO: the five-clause contract above -- produce a
// logical gate window around the returning read strobe, positioned by
// a TRAINED value, and refuse to open when untrained.
//
// WHY IT EXISTS HERE: §2's rule says a function needing a quantity
// unknown until after board assembly cannot be computed by
// synchronous RTL. This block is what happens when it is computed
// anyway. 19.4 owns the difference between the strobe window that
// OCCURS and the window the PHY BELIEVES IN; this is that gap,
// written down.
//
// HOW TO RUN IT: drive gate_offset to a value other than
// FLIGHT_CYCLES and observe that the gate does not move. Then hold
// gate_trained low and observe that the gate opens anyway.
// EXPECTED RESULT under clause 2: the window tracks gate_offset.
// EXPECTED TRACE: gate_open must rise at CL + gate_offset - GUARD.
//
// SYNTHESIS: one counter plus a comparator pair. No memory.
// LIMITATIONS: models the gate as a LOGICAL WINDOW in the
// controller's clock domain. The physical gate, the delay cell and
// the capture flop are outside portable RTL entirely (19.1 §5) and
// are NOT what the bug is.
// ---------------------------------------------------------------------
module dqs_gate_ctrl #(
  parameter int CL            = 22,   // ILLUSTRATIVE
  parameter int BL            = 8,    // ILLUSTRATIVE
  parameter int GUARD         = 2,    // ILLUSTRATIVE
  // ILLUSTRATIVE, and the whole problem: a compile-time constant
  // standing in for board flight time.
  parameter int FLIGHT_CYCLES = 3,
  parameter int OFS_W         = 6,
  // COUNT, not INDEX: the phase counter must REPRESENT the largest
  // position it compares against, so it needs $clog2 of that value
  // PLUS ONE. Sized to the index range it would saturate exactly in
  // the late-gate case it exists to cover.
  parameter int CNT_W         = $clog2(CL + (1 << OFS_W) + BL/2 + GUARD + 1)
)(
  input  logic              clk,
  input  logic              rst_n,

  input  logic              rd_commit,
  input  logic [OFS_W-1:0]  gate_offset,    // from 21.3's search
  input  logic              gate_trained,   // from 21.3's search

  output logic              gate_open
);
  localparam int OCC = BL / 2;            // strobe burst, in clk cycles

  initial begin
    if (GUARD < 1) $fatal(1, "dqs_gate_ctrl: GUARD must be >= 1");
    if (CL   < 1)  $fatal(1, "dqs_gate_ctrl: CL must be >= 1");
  end

  // The window this block believes in.
  localparam int OPEN_AT  = CL + FLIGHT_CYCLES - GUARD;   // <-- THE DEFECT
  localparam int CLOSE_AT = CL + FLIGHT_CYCLES + OCC + GUARD;

  logic [CNT_W-1:0] phase;
  logic             armed;

  always_ff @(posedge clk) begin
    if (!rst_n) begin
      phase <= '0;
      armed <= 1'b0;
    end else if (rd_commit) begin
      phase <= '0;
      armed <= 1'b1;
    end else if (armed) begin
      if (phase >= CLOSE_AT[CNT_W-1:0]) armed <= 1'b0;
      else                              phase <= phase + 1'b1;
    end
  end

  assign gate_open = armed
                  && (phase >= OPEN_AT[CNT_W-1:0])
                  && (phase <= CLOSE_AT[CNT_W-1:0]);
endmodule

Before reading on: which clause, and what can you tell from the port list alone?

9. The Defect — A Declared Input That Is Never Read

The violated clause is 2, and the defect needs no trace: gate_offset and gate_trained appear in the port list and appear nowhere in the body.

The window is built from FLIGHT_CYCLES, a compile-time parameter, where the contract requires the trained input. The block computes a board-dependent quantity at elaboration time — exactly what §2's rule says cannot be done, because trace length, package delay and process corner do not exist when the parameter is set.

And clause 4 falls with it. With gate_trained unread, the gate opens regardless of whether training ever ran, so an untrained interface reports a gate at a guessed position rather than refusing to open — a guess presented as a default, which is 30.6 §3's failure is a result violated at the PHY boundary.

   ILLUSTRATIVE CL = 22, BL = 8 (OCC = 4), GUARD = 2, FLIGHT_CYCLES = 3.

   this block's window        : open at 23, close at 31
   board A, true flight 3     : strobe at 25..28   -> CAPTURED
   board B, true flight 7     : strobe at 29..32   -> the tail is
                                 outside the window; short beat count
   board B at a higher rate   : flight in CYCLES grows with the clock
                                 -> worse, and in the same direction

   gate_offset = 7 is sitting on the port, correct and ignored.

Why it survives — and this is the reason the defect is worth reviewing. FLIGHT_CYCLES was set from measurements on the first board, so the block passes bring-up, passes regression on that board, and passes every assertion written against that board. It is not a bug that escaped testing; it is a bug that testing on one board cannot express.

The correction, and the clause-4 refusal restored:

  // CORRECTED. The position comes from the SEARCH (21.3), not from a
  // parameter: flight time is a post-assembly quantity and §2's rule
  // says no elaboration-time constant can carry it. FLIGHT_CYCLES is
  // deleted rather than defaulted -- keeping it as a fallback
  // recreates the bug on any board where training did not run.
  logic [CNT_W-1:0] open_at, close_at;
  always_comb begin
    open_at  = CL + gate_offset - GUARD;
    close_at = CL + gate_offset + OCC + GUARD;
  end

  // Clause 4: an untrained position is UNKNOWN, and unknown is not a
  // default. The gate stays shut and the interface is not used.
  assign gate_open = armed && gate_trained
                  && (phase >= open_at) && (phase <= close_at);

The general finding, which is larger than this block: a parameter holding a physical quantity is a design smell wherever it appears. CURRICULUM-DERIVED from 19.3, which owns the decomposition of a launch offset into a part known from the configuration and a part only knowable by measurement: if a constant in the source stands for the second part, the design has decided something it cannot know. Grepping a PHY-adjacent RTL tree for parameters with units in their names is a real review technique, and it finds this class every time.

10. SVA Review — When the Defect Belongs to a Different Tool

A property offered as proof that the gate is correct:

  // Offered as "proves the gate covers the strobe".
  property p_gate_covers_strobe;
    @(posedge clk) disable iff (!rst_n)
      strobe_activity |-> gate_open;
  endproperty
  assert property (p_gate_covers_strobe)
    else $error("strobe activity outside the gate window");

Q. This passes in the board-A regression and fails in the field. What is it actually proving?

It is not proving anything. It is measuring board A.

The property's truth depends on strobe_activity, which depends on the flight time of the board the simulation was configured for. So the assertion holds because the environment and the design were given the same wrong constant — and a property whose result depends on a parameter both sides share is not an independent check.

An assertion whose outcome depends on a constant the environment and the design both take from the same source is a consistency check, not a proof. It confirms they agree; it cannot notice that they are both wrong.

This is the fourth distinct way a property passes on a defective design, and the four are worth holding together:

And the tool answer, which is the point of this section: the defect in §8 is not best caught by an assertion at all.

  // Useful, and honestly scoped: the gate must not open untrained.
  // This one DOES catch clause 4, because gate_trained is the
  // environment's signal and not a shared constant.
  property p_no_untrained_gate;
    @(posedge clk) disable iff (!rst_n)
      !gate_trained |-> !gate_open;
  endproperty
  assert property (p_no_untrained_gate)
    else $error("gate opened with no trained position");

  // The property that catches clause 2 -- note that it compares the
  // gate against the TRAINED INPUT, not against a constant, which is
  // exactly why it can fail on the defective block.
  property p_gate_tracks_offset;
    @(posedge clk) disable iff (!rst_n)
      (rd_commit && gate_trained) |->
        ##(CL) ($rose(gate_open) || gate_open);
  endproperty

  // And the covers that make the above non-vacuous: the trained value
  // must actually VARY, and it must be exercised untrained.
  cover property (@(posedge clk) disable iff (!rst_n)
                  rd_commit && gate_trained && (gate_offset != FLIGHT_CYCLES));
  cover property (@(posedge clk) disable iff (!rst_n)
                  rd_commit && !gate_trained);

The first cover is the whole verification finding. An environment that drives gate_offset to one value can never distinguish a block that uses it from a block that ignores it — so the testbench must sweep the trained input across its range. That is a stimulus requirement, not an assertion, and it is the requirement a board-tuned regression never states.

And the honest answer about p_gate_tracks_offset: it is weaker than it looks, because a gate window expressed in cycles against a ##(CL) delay cannot pin the offset exactly. The reliable check on clause 2 is not SVA at all — it is elaboration-time and lint-time: an input declared and never read, and a parameter carrying a physical unit. Naming the right tool is a legitimate verification answer, and a candidate who says lint would have caught this before simulation started is more useful than one who writes a clever property.

11. What Would You Measure?

Q. You own the controller and suspect the PHY. What do you ask for before escalating?

Row two is the cheapest question in the chapter and it finds §9's entire defect class in one sentence. Is this number trained or compiled in?

Row seven is the one that saves the most time and nobody asks it. §1's rule: the middle zone varies, so a function you assume the PHY owns may be yours, and a bug you escalate may come back. Reading the project's ownership table before escalating is the professional version of §2's rule.

12. Common Wrong Answers

“The PHY does serialisation and the controller does everything else.” §2, §3. Roughly true for two rows and wrong about the middle zone, which is where the real questions are.

“The controller/PHY boundary is standardised.” §1. Six rows of 19.1 §3's table are implementation-dependent and one strongly so. A diagram claiming one boundary describes a product.

“Does the controller or the PHY own ODT?” §3. False premise — the controller decides when, the PHY applies it, the DRAM terminates on its own die.

“The PHY runs training.” §3, §4. Sometimes. Firmware, the controller and a PHY-internal engine all ship, which is why this is the table's strongly dependent row.

“You can capture DDR read data with always_ff @(posedge dqs).” §5. Four independent reasons, each naming a PHY structure — and the domain argument is not fixable by slowing down.

“I wrote a DDR PHY.” §5. Usually the digital part — ordering, handshakes, width conversion, gate control, lifecycle. CURRICULUM-DERIVED from 19.1 §5: a correct gearbox proves nothing about where beats were sampled. Say which half.

“The gate passed, so the read path works.” §6. The gate's observable is presence; capture correctness is a different question and Module 20's.

“It fails only at speed, so it is signal integrity.” §7. The rate test exonerates layers A, B and C. It does not choose between D, E and F, and it skips two cheaper layers.

“A rate change is a configuration write.” §4. It invalidates every trained value, because the physical quantities were measured against the old bit period. It is a retraining event.

“Flight time is about three cycles, so I'll parameterise it.” §9. A parameter holding a post-assembly physical quantity is the defect, not a simplification — and it passes on the board it was measured on.

“If training has not run, use the default setting.” §9. An untrained position is unknown, and unknown is not a default. The gate stays shut.

“The gate assertion passes in regression, so the gate is right.” §10. The environment and the design took flight time from the same constant. That is a consistency check.

“I would write an assertion for it.” §10. For this one, lint and elaboration are the right tools — an unread input and a unit-carrying parameter. Naming the right tool is a verification answer.

“Our PHY vendor's flow does it this way, so that is how it works.” That is one implementation, and the question was about DDR. Naming a vendor narrows your answer to a product, and the interviewer's next question is what the others do — which is §1's whole subject.

13. Self-Check

1. State the placement rule in one sentence, then derive it from the fact that a synthesised block is constrained before a board exists.

2. Place these using the rule alone, and mark which zone each lands in: per-lane write deskew, refresh interval programming, data-bus turnaround, write-CRC generation, and the decision to enter a low-power state.

3. Give the four reasons the controller cannot capture read data directly, and name the PHY structure each one implies.

4. Explain why a runtime data-rate change invalidates trained values, and name the chapter that owns validity.

5. A gate is open and no data is captured. Give the four possibilities and the cheapest discriminator for each.

6. Find the defect in §8 using only the port list and the module body — no trace. Then say why it passed the first board's regression.

7. Explain why p_gate_covers_strobe is a consistency check rather than a proof, and state the stimulus requirement that would expose the defect.

8. Name the four ways a property can pass on a defective design, one per chapter from 30.4 onward, and say which of the four §8's defect belongs to.

14. Where This Goes

A PHY question is a boundary question with no universal answer. Use the rule — a function needing a post-manufacture physical quantity belongs to the PHY, a function needing a protocol-state decision belongs to the controller, and one needing both splits — and say that the middle zone is a project's choice you would read from its documentation.

Three results carry forward. A parameter holding a physical quantity is a defect, not a simplification, and it passes on the board it was measured on. An untrained value is unknown, and unknown is not a default. And an assertion whose outcome depends on a constant shared by the design and the environment is a consistency check — the fourth variety, and the reason 30.9 can treat what does this assertion actually prove as a method with a taxonomy behind it rather than a slogan.

Chapter 30.8 opens the senior tier, and the questions stop having a correct answer. “The memory subsystem is too slow — what do you do?” has no answer at all until the bottleneck is identified, and the failure mode is proposing an optimisation. The chapter's first result is that bandwidth names five different quantities — peak, usable, controller-achieved, workload-achievable and application-observed — and an engineer who has not said which one they mean has not started.