DQS — The Data Strobe

Chapter 6.9 built the ownership contract for the data wires and left one thing unanswered: DQ carries values, and something has to say when they are valid.

Chapter 6.1 §7 established that CK does not do this job, and why. This chapter is the answer, and its question is:

Why does data carry its own timing reference, and what does that make DQS structurally different from a clock?

Three answers, all of which distinguish it from CK: it is directional, it is not free-running, and the interval during which it toggles is wider than the interval during which data is valid. Any one of those breaks the "DQS is another clock" model; together they make it a different kind of object.

1. Why Not Just Use the Clock

The argument is Chapter 4.2 §3's and it is worth re-deriving from the signal's point of view, because the conclusion is not obvious until you do.

A receiver capturing data needs to know when to sample. The obvious source is the clock, which both sides already have.

But consider the paths. CK is generated at the controller and distributed to every device — across a board, through a connector, past several loads. The data travels from wherever it was driven to wherever it is captured, on a different set of wires, through different drivers and receivers, over a different path.

The difference between those two arrival times is skew, and the crucial property is that skew does not shrink because the transfer interval did. It is set by physical path lengths and circuit delays, and those are what they are.

So as transfer rates rise, a fixed skew consumes a growing fraction of a shrinking budget. Eventually there is nothing left. That is arithmetic, not a design deficiency.

This is Chapter 6.1 §3's principle applied to data. A differential clock carries its own voltage reference; a source-synchronous strobe carries its own timing reference. Signals that carry their own reference are robust in a way that signals depending on a distant shared reference are not — and DQS is that idea applied to the fastest-moving signals in the system.

DQS is also differential, for the same reasons CK is: the crossing point defines the instant, and disturbances common to both wires cancel.

2. A Real Strobe — Unlike RAS#

Chapter 6.4 §3 flagged this and it is worth settling explicitly, because reasoning about one by analogy with the other produces errors in both directions.

RAS# is a command bit that inherited a strobe's name. DQS is a strobe. One is timed by something; the other times something, and that is the whole distinction.

3. Ownership — the Same Discipline as DQ

DQS is driven by whichever side is driving the data. That is what source-synchronous means, and it has the direct consequence that DQS is bidirectional with the same ownership discipline Chapter 6.9 built.

   WRITE   controller / PHY drives DQ  and  drives DQS
   READ    DRAM drives DQ              and  drives DQS

Which is why dqs_oe appeared in Chapter 6.9 §4's state machine tracking dq_oe exactly. The strobe cannot have a different owner from the data it times — if it did, it would not be source-synchronous, and the skew argument of §1 would collapse.

And it means DQS has a turnaround, with all the consequences Chapter 6.9 §1 drew: the direction is committed at command time, it cannot be changed reactively, and an undriven interval must separate one owner from the next.

4. The Window Is Wider Than the Data

Here is the structural fact most likely to be missed, and it is the one §5's RTL is built around.

DQS toggles for a longer interval than data is valid. There is a preamble before the data beats and a postamble after them, during which the strobe is active and no data is being transferred.

Why a preamble exists is worth understanding rather than memorising. A receiver cannot use a strobe it has not yet seen. The strobe is not free-running — it was quiet a moment ago — so the receiver needs an interval in which the strobe is present and nothing depends on it yet. The preamble is that interval: it establishes the strobe before the strobe is relied upon.

The postamble is the same argument at the other end, giving the receiver a defined interval in which the strobe completes rather than simply stopping mid-transition.

The consequence is a rule worth stating flatly: strobe active is not data valid. A receiver that captures whenever the strobe toggles will capture during the preamble and postamble, recording whatever the data lines happened to carry — which is plausible-looking data from nowhere, the kind nothing downstream objects to.

5. RTL — The Window and Ownership Contract

Engineering problem

Express the digital contract around DQS: ownership follows the data's direction, the strobe window contains a preamble and postamble in which no data is valid, and capture is legal only in the narrower data window.

Classification

SYNTHESIZABLE RTL — a digital ownership and qualification model. Emphatically not a PHY.

What it represents: the window structure, ownership, and the qualification rule that capture belongs only to the data interval.

What it does not represent, and the list is the point: the strobe itself. No toggling, no edges, no phase, no delay elements, no centring, no gating implementation, no training, no calibration, no margin, no eye. Every one of those is a PHY function built from technology-specific delay and clocking primitives, characterised in analog simulation — Modules 19 to 21.

PREAMBLE_EVENTS and POSTAMBLE_EVENTS are educational cycle counts expressing that the intervals exist, not their durations. Real preamble and postamble behaviour is generation-specific and configurable, and is device-specification material.

Interface contract

xfer_start with xfer_is_write and xfer_beats begins a transfer. strobe_window marks the whole interval, data_valid the narrower one. strobe_oe says the controller drives the strobe. capture_req and illegal_capture make the misuse of §4 detectable.

State

The phase, a beat counter and two interval counters.

Combinational behaviour

Window and ownership derivation from the phase.

Sequential behaviour

The phase machine.

How to simulate

vlog dqs_ownership_window.sv tb_dqs_ownership_window.sv then vsim -c tb_dqs_ownership_window -do "run -all".

Expected result: strobe_window spans preamble, data and postamble while data_valid covers only the data beats, and a capture attempted in either amble is reported.

// ─────────────────────────────────────────────────────────────────────────
// DQS OWNERSHIP WINDOW.
// Classification: SYNTHESIZABLE RTL -- a DIGITAL OWNERSHIP AND
// QUALIFICATION model. EMPHATICALLY NOT A PHY.
//
// WHAT THIS DOES NOT MODEL, AND CANNOT:
//   the strobe itself. No toggling, no edges, no phase relationship, no
//   delay elements, no centring, no gating implementation, no training,
//   no calibration, no margin, no eye.
//
// Every one of those is a PHY function built from technology-specific
// delay and clocking primitives and characterised in ANALOG simulation.
// Modules 19, 20 and 21 own them, and they are large modules for a reason.
//
// AND NEVER `assign dqs = clk;`. That line makes the strobe free-running
// (it is not), single-owner (it is bidirectional), amble-less (the window
// structure vanishes), and -- fundamentally -- derived from the clock,
// which recreates the exact skew problem DQS exists to solve. It does not
// model a simplified DQS; it models the thing DQS replaced.
//
// WHAT THIS DOES MODEL: ownership follows the data's direction, the strobe
// window is WIDER than the data window, and capture belongs only to the
// narrower one. PREAMBLE_EVENTS and POSTAMBLE_EVENTS express that the
// intervals EXIST, not their durations -- real behaviour is
// generation-specific and configurable.
// ─────────────────────────────────────────────────────────────────────────
module dqs_ownership_window #(
  parameter int PREAMBLE_EVENTS  = 1,
  parameter int POSTAMBLE_EVENTS = 1,
  parameter int MAX_BEATS        = 8,
  parameter int BEAT_W = (MAX_BEATS        <= 1) ? 1 : $clog2(MAX_BEATS),
  parameter int PRE_W  = (PREAMBLE_EVENTS  <= 1) ? 1 : $clog2(PREAMBLE_EVENTS + 1),
  parameter int PST_W  = (POSTAMBLE_EVENTS <= 1) ? 1 : $clog2(POSTAMBLE_EVENTS + 1)
) (
  input  logic              clk,
  input  logic              rst_n,

  input  logic              xfer_start,
  input  logic              xfer_is_write,
  input  logic [BEAT_W:0]   xfer_beats,

  // ── The whole interval in which the strobe is active.
  output logic              strobe_window,
  // ── The narrower interval in which data is valid. STROBE ACTIVE IS NOT
  //    DATA VALID -- that is the chapter's structural point, and these two
  //    outputs exist separately to make it impossible to conflate.
  output logic              data_valid,
  output logic [BEAT_W-1:0] beat_index,

  // Ownership. Follows the DATA's direction exactly: a strobe with a
  // different owner from the data it times would not be source-synchronous.
  output logic              strobe_oe,

  // 0 IDLE, 1 PREAMBLE, 2 DATA, 3 POSTAMBLE.
  output logic [1:0]        phase_out,

  input  logic              capture_req,
  // A capture attempted while the strobe is active but data is not valid.
  // On real hardware this records whatever the data lines carried --
  // plausible values from nowhere, with nothing objecting.
  output logic              illegal_capture,
  output logic              illegal_start
);

  // ── COMPILE-TIME legality.
  if (MAX_BEATS < 1) begin : g_mb
    initial $fatal(1, "dqs_ownership_window: MAX_BEATS must be >= 1");
  end
  // A zero-length preamble is rejected. A receiver cannot use a strobe it
  // has not yet seen, and the strobe is not free-running -- so an interval
  // in which the strobe is present and nothing depends on it is structural,
  // not optional. Its DURATION is out of scope; its EXISTENCE is not.
  if (PREAMBLE_EVENTS < 1) begin : g_pre
    initial $fatal(1, "dqs_ownership_window: PREAMBLE_EVENTS must be >= 1");
  end
  if (POSTAMBLE_EVENTS < 0) begin : g_pst
    initial $fatal(1, "dqs_ownership_window: POSTAMBLE_EVENTS must be >= 0");
  end

  localparam logic [1:0] P_IDLE = 2'd0;
  localparam logic [1:0] P_PRE  = 2'd1;
  localparam logic [1:0] P_DATA = 2'd2;
  localparam logic [1:0] P_POST = 2'd3;

  logic [1:0]        ph_q;
  logic [BEAT_W:0]   beats_q;
  logic [BEAT_W-1:0] index_q;
  logic [PRE_W-1:0]  pre_q;
  logic [PST_W-1:0]  pst_q;
  logic              is_write_q;

  assign phase_out  = ph_q;
  assign beat_index = index_q;

  // ── The two windows, derived from phase so they cannot disagree.
  //    strobe_window is WIDER. That relationship is the whole point and it
  //    is structural here rather than maintained.
  assign strobe_window = (ph_q == P_PRE) || (ph_q == P_DATA) || (ph_q == P_POST);
  assign data_valid    = (ph_q == P_DATA);

  // Ownership: the controller drives the strobe exactly when it drives the
  // data, across the whole strobe window including both ambles.
  assign strobe_oe = strobe_window && is_write_q;

  // Capturing while the strobe is active but data is not valid.
  assign illegal_capture = capture_req && strobe_window && !data_valid;

  logic beats_ok;
  assign beats_ok = (xfer_beats != '0) && (xfer_beats <= (BEAT_W+1)'(MAX_BEATS));
  assign illegal_start = xfer_start && ((ph_q != P_IDLE) || !beats_ok);

  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      ph_q       <= P_IDLE;
      beats_q    <= '0;
      index_q    <= '0;
      pre_q      <= '0;
      pst_q      <= '0;
      is_write_q <= 1'b0;
    end else begin
      unique case (ph_q)

        P_IDLE: begin
          if (xfer_start && beats_ok) begin
            ph_q       <= P_PRE;
            pre_q      <= PRE_W'(PREAMBLE_EVENTS);
            beats_q    <= xfer_beats;
            index_q    <= '0;
            is_write_q <= xfer_is_write;
          end
        end

        P_PRE: begin
          // The strobe is active and nothing depends on it yet. This is
          // where a receiver establishes it.
          if (pre_q <= PRE_W'(1)) ph_q <= P_DATA;
          else                    pre_q <= pre_q - PRE_W'(1);
        end

        P_DATA: begin
          if (beats_q <= (BEAT_W+1)'(1)) begin
            ph_q  <= P_POST;
            pst_q <= PST_W'(POSTAMBLE_EVENTS);
          end else begin
            beats_q <= beats_q - (BEAT_W+1)'(1);
            index_q <= index_q + BEAT_W'(1);
          end
        end

        P_POST: begin
          // A defined completion rather than the strobe simply stopping
          // mid-transition.
          if (pst_q <= PST_W'(1)) ph_q <= P_IDLE;
          else                    pst_q <= pst_q - PST_W'(1);
        end

        default: ph_q <= P_IDLE;
      endcase
    end
  end

endmodule

Cycle-by-cycle example

PREAMBLE_EVENTS = 1, POSTAMBLE_EVENTS = 1, four beats:

Cycles 1 and 6 are the chapter in two rows. strobe_window is high and data_valid is low. A receiver using strobe activity as its capture qualifier captures on both, recording whatever the data lines carried.

Waveform expectation

§6. Watch strobe_window extend beyond data_valid at both ends.

Synthesis implication

A four-state machine and three counters — negligible. What this logic produces is enables, and the PHY consumes them: the strobe's actual generation, its phase relative to the data, and the capture circuitry are built from delay and clocking primitives outside this abstraction. This block says when; the PHY realises how.

Corner cases

PREAMBLE_EVENTS == 0 does not elaborate — a receiver cannot use a strobe it has not seen, and the interval's existence is structural even though its duration is out of scope. POSTAMBLE_EVENTS == 0 is permitted, because a zero-length postamble is representable in principle and generation behaviour varies; the asymmetry is deliberate and is worth noticing. MAX_BEATS == 1 gives a single-beat transfer surrounded by ambles, where the amble overhead dominates — which is a real efficiency observation about short bursts. A start during a transfer is refused.

Debugging clues

If captured data includes plausible-looking garbage at burst boundaries, the receiver is qualifying on strobe_window rather than data_valid — the single most likely misuse. If strobe_oe is asserted during reads, is_write_q is being sampled continuously rather than captured at transfer start. If the beat index is off by the preamble length, the counter is being advanced during the preamble phase rather than only in the data phase.

Limitations

No strobe. No edges, no toggling, no phase, no delay, no gating, no training, no margin — the header lists these because the omission is the honest part. The amble parameters express existence, not duration. And this models one transfer at a time: real interfaces pipeline transfers so that one burst's postamble and the next burst's preamble interact, which is a genuine effect and Module 20's subject.

6. The Wider Window

Compare the two phase bands. The strobe window runs cycles 1 to 6; data is valid only for cycles 2 to 5. The outer band is the signal being active; the inner band is the signal being useful, and they are not the same interval.

Cycle 1 shows the hazard directly. A capture is requested during the preamble and reported illegal. On real hardware nothing would be reported — the receiver would simply capture the data lines' current state and hand it downstream as read data.

Cycles 8 and 9 begin a write, and strobe_oe asserts across the whole strobe window including the preamble. The controller drives the strobe before it drives meaningful data, which is the preamble's purpose seen from the transmitting side.

Representative educational cycles. The single-cycle ambles express that the intervals exist; real durations are generation-specific and configurable.

7. Four Assertions Worth Writing

// VERIFICATION-ONLY, inside dqs_ownership_window.

// P1 -- THE STRUCTURAL PROPERTY. Data is never valid outside the strobe
// window. The containment relationship is the chapter's claim, and this is
// the half that says the inner window is inside the outer one.
property p_data_within_strobe;
  @(posedge clk) disable iff (!rst_n)
    data_valid |-> strobe_window;
endproperty
assert property (p_data_within_strobe);

// P2 -- and the STRICT half: the strobe window genuinely extends beyond
// the data window. Without this, a design in which the two were identical
// would satisfy P1 perfectly -- and such a design has no preamble, which
// is the failure this chapter is about.
property p_strobe_strictly_wider;
  @(posedge clk) disable iff (!rst_n)
    $rose(strobe_window) |-> !data_valid;
endproperty
assert property (p_strobe_strictly_wider);

// P3 -- capture outside the data window is reported. The hazard has no
// hardware indication, so the model's only contribution is to make it
// visible.
property p_illegal_capture_reported;
  @(posedge clk) disable iff (!rst_n)
    (capture_req && strobe_window && !data_valid) |-> illegal_capture;
endproperty
assert property (p_illegal_capture_reported);

// P4 -- OWNERSHIP FOLLOWS DIRECTION. The controller drives the strobe
// exactly when it drives the data. A strobe with a different owner from
// the data it times is not source-synchronous, and the skew argument of
// Section 1 collapses.
property p_strobe_owned_on_writes_only;
  @(posedge clk) disable iff (!rst_n)
    strobe_oe |-> (strobe_window && is_write_q);
endproperty
assert property (p_strobe_owned_on_writes_only);

property p_no_strobe_drive_on_reads;
  @(posedge clk) disable iff (!rst_n)
    (strobe_window && !is_write_q) |-> !strobe_oe;
endproperty
assert property (p_no_strobe_drive_on_reads);

P1 and P2 together are the containment claim, and P2 is the one that earns its place: a design with no preamble satisfies P1 completely, because identical windows are trivially contained in each other. Whenever a property asserts that one interval contains another, ask whether the containment is meant to be strict — if it is, the strictness needs its own property.

P4 is the source-synchronous property. It is not about correctness of the strobe; it is about the strobe and the data having the same owner, which is what makes the arrangement source-synchronous at all.

What none of them prove — and it is nearly everything about a real DQS. Nothing about the strobe's phase relative to the data, which is the entire subject of Module 20. Nothing about edge placement, jitter, centring or margin. Nothing about whether training converged. No digital assertion in any simulation can establish that a strobe is correctly positioned — that is analog characterisation and measurement, and treating a green regression here as evidence about capture reliability is the category error Chapter 4.4 §7 warned about.

8. Common Misconceptions

"DQS is another copy of CK." Wrong model: a second clock distributed alongside the first. Why it is tempting: both are differential, both are timing references, and both toggle. Consequence: three separate errors. Expecting it to be free-running, so a receiver could lock to it continuously — it cannot, because it is quiet between transfers. Expecting a single owner, so reads have no strobe. And expecting no window structure, so strobe active is treated as data valid. Each of those is a real bug with a distinct symptom. Correct model: DQS is source-synchronous, directional, and gated. Driven by whichever side drives the data, over nearly the same path, active only around transfers, with a window wider than the data it qualifies. Prevention: ask who drives it and whether it is toggling right now. A clock has one answer to the first and always-yes to the second; DQS has neither.

"Strobe active means data is valid." Wrong model: the strobe's activity qualifies the data. Why it is tempting: the strobe exists to time the data, so its presence feels like a valid indication. Consequence: capture during the preamble and postamble, recording whatever the data lines carried — plausible values from nowhere, at burst boundaries, with nothing downstream objecting because the values are well-formed. Correct model: the strobe window contains the data window and is strictly wider. The preamble exists so a receiver can establish a strobe it has not yet seen; the postamble gives a defined completion. Capture belongs only to the inner interval. Prevention: keep the two qualifiers as separate signals, as §5 does. If a design has only one, the distinction has already been lost.

"You can model DQS in RTL as assign dqs = clk." Wrong model: a clock-derived strobe is a reasonable simplification. Why it is tempting: it produces a toggling signal with the right period and it simulates. Consequence: it teaches and encodes the opposite of the mechanism. The strobe becomes free-running, single-owner and amble-less — and, fundamentally, derived from the clock, so it carries the clock's skew relative to the data. It models the arrangement DQS replaced, not a simplified DQS. Correct model: model the digital contract only — ownership, enables, window structure. The strobe's generation and its phase relative to the data are PHY functions built from technology-specific primitives, characterised in analog simulation and adjusted by training. Prevention: ask whether the model's strobe would still be correct if the data path's delay changed. A real strobe tracks it; a clock-derived one does not.

"A green simulation means the capture timing is right." Wrong model: functional verification covers strobe positioning. Why it is tempting: the data comes back correct in simulation, which feels like evidence. Consequence: shipping an interface whose strobe is positioned badly, which produces the hardest fault class — works at reduced rate, marginal at full rate, no functional failure. Simulation has no representation of phase, jitter or margin, so it cannot distinguish a well-centred strobe from a barely-adequate one. Correct model: digital simulation verifies ownership, windows and qualification. Strobe positioning is verified by analog characterisation, by measurement, and by the training procedure's own reported margins — and reading those margins rather than the pass bit is Chapter 4.4 §11's discipline. Prevention: maintain the list of properties simulation cannot validate. Strobe positioning belongs on it alongside setup/hold and reset synchronisation.

9. Debugging — Corruption at Burst Boundaries

Symptom. Read data is correct in the middle of bursts and wrong at the edges — the first beat, the last beat, or both. Long bursts are proportionally better than short ones.

"Proportionally better with longer bursts" is the diagnostic gift, because it says the corrupted quantity is fixed per burst rather than proportional to length — which points directly at the boundaries, and therefore at the ambles.

Mechanism 1 — capture is qualified on strobe activity rather than data validity. Inspect: what the receive path uses as its capture enable. Expected evidence: extra captured beats at both ends, containing data-line states rather than transferred data. Discriminator: count the captured beats against the burst length. More beats than the burst means the ambles are being captured, which is §4's rule violated and the most likely cause.

Mechanism 2 — the strobe is being gated too early or too late. Inspect: when the receive path begins and stops treating the strobe as valid. Expected evidence: corruption at one end rather than both. Discriminator: which end? Head-corrupt means the strobe was trusted before it was established; tail-corrupt means gating persisted past the postamble. The asymmetry names the end, and this is Module 20's subject proper.

Mechanism 3 — the preamble is too short for the receiver. Inspect: the configured preamble against what the PHY requires to establish the strobe. Expected evidence: first-beat corruption that improves if the preamble is lengthened. Discriminator: does lengthening the preamble fix it? A direct experiment, and it distinguishes a configuration problem from a gating-logic problem.

Mechanism 4 — bus turnaround, not the strobe. Inspect: whether corruption occurs only when the boundary coincides with a direction change. Expected evidence: clean boundaries within runs of same-direction traffic, corrupt boundaries at transitions. Discriminator: does it depend on the preceding transfer's direction? Chapter 6.9 §9's territory — contention at a handoff, not an amble problem, and a completely different fix.

Mechanism 5 — not digital at all: strobe positioning. Inspect: training results and their reported margins, and whether the symptom scales with rate. Expected evidence: corruption distributed rather than boundary-localised, worsening with rate and temperature. Discriminator: is it localised at boundaries or spread through the burst? Boundary-localised points at the window logic; spread points at margin — and the two have no diagnostic steps in common.

Discrimination, cheapest first. Count captured beats against burst length — one observation, resolving mechanism 1. Then ask which end is corrupt, which splits mechanism 2 and names the direction. Then check whether boundaries are clean within same-direction runs. Then read the training margins.

The reasoning lesson. A fault whose severity is fixed per burst rather than proportional to burst length is a boundary fault, and that single ratio distinguishes it from everything distributed. It is worth computing before any other step, because boundary faults live in the window logic — which is digital, cheap to inspect and fully simulable — while distributed faults live in margin, which is analog, expensive and not simulable at all. The ratio tells you which of two entirely disjoint investigations to open, and it is available from data you already have.

10. Interview Reasoning

"Why does DDR use a data strobe instead of timing data with the clock?" Because of which skew the timing budget has to absorb. A clock distributed from the controller travels its own path to the receiver, while the data travels a different path through different drivers and receivers — so the budget must absorb the full skew between those paths, and that skew is set by physical lengths and circuit delays and does not shrink when the transfer interval does. As rates rise, a fixed skew eventually consumes the entire budget. A strobe driven by the same side as the data, over nearly the same path, leaves only the much smaller strobe-to-data skew in the budget. That is what source-synchronous means, and it is why the arrangement scales where a distributed clock does not.

"How is DQS different from CK?" Three ways, any one of which breaks the analogy. It is directional — driven by whichever side is driving the data, so it has an owner that changes and a turnaround, while CK has one owner permanently. It is not free-running — it toggles only around transfers and is otherwise not driven, so a receiver cannot lock to it continuously the way it can to a clock. And it has a window structure: there is a preamble before the data and a postamble after, during which the strobe is active and no data is valid, so strobe activity cannot be used as a data-valid indication. CK has none of those properties.

"Why does a preamble exist?" Because a receiver cannot use a strobe it has not yet seen, and the strobe is not free-running — it was quiet a moment ago. The preamble is an interval in which the strobe is present and nothing depends on it yet, so the receiving path can establish it before relying on it. The postamble is the same argument at the other end: it gives a defined completion rather than the strobe simply stopping mid-transition. The structural consequence is that the strobe window is strictly wider than the data window, and a receiver that qualifies capture on strobe activity will capture during both ambles and record whatever the data lines happened to carry.

"Why is assign dqs = clk wrong?" It gets four things wrong at once and the fourth is fatal. It makes the strobe free-running, when the real one is gated. It gives it a single owner, so reads have no strobe. It removes the preamble and postamble, so the window structure has no expression. And fundamentally it derives the strobe from the clock — meaning it travelled the clock's path and carries the clock's skew relative to the data, which undoes the entire reason DQS exists. It does not model a simplified DQS; it models the arrangement DQS replaced. The honest approach is to model the digital contract only — ownership, enables, window structure — and to say that strobe generation and its phase relative to data are PHY functions built from technology-specific primitives and characterised in analog simulation.

"Read data is corrupt at burst boundaries and fine in the middle. How do you narrow it down?" First by computing whether the corrupted quantity is fixed per burst or proportional to burst length, because a fixed amount per burst is a boundary fault and points at the window logic, while something spread through the burst points at strobe positioning and margin. Those two are entirely disjoint investigations — one is digital, cheap and fully simulable, the other is analog and not simulable at all — so the ratio tells you which to open. If it is boundary-localised, count the captured beats against the burst length: more beats than the burst means the receive path is qualifying capture on strobe activity rather than data validity and is capturing the preamble and postamble. Then ask which end is corrupt, because head-corrupt means the strobe was trusted before it was established and tail-corrupt means gating persisted past the postamble. And it is worth checking whether boundaries are clean within runs of same-direction traffic, because if corruption only appears at direction changes it is bus turnaround contention rather than anything to do with the ambles.

11. Engineering Exercise

Educational cycle counts; real amble behaviour is generation-specific and configurable.

1. A receiver uses "strobe toggling" as its capture qualifier. How many extra beats does it capture per burst, and what is in them? Preamble plus postamble worth of beats — a fixed number per burst, independent of burst length. They contain whatever the data lines carried at the time, which is well-formed and meaningless. Nothing downstream objects, because the values are not garbage.

2. Using question 1, why do short bursts suffer proportionally more? The amble overhead is fixed per burst while the useful data scales with length. A four-beat burst with two amble beats is 33% corrupt; a sixteen-beat burst with the same two is 11%. That ratio is the diagnostic of §9 and is available from data you already have.

3. §7's P1 says data is valid only within the strobe window. Why is P2 needed as well? Because identical windows satisfy P1 trivially — a set is contained in itself. P1 alone is satisfied by a design with no preamble at all, which is exactly the failure the chapter is about. P2 asserts the containment is strict.

4. §5 rejects PREAMBLE_EVENTS = 0 but permits POSTAMBLE_EVENTS = 0. Justify the asymmetry. A receiver cannot use a strobe it has not seen, so an interval before reliance is structural — without it there is no mechanism by which the receiving path could establish the strobe. A zero-length postamble is representable in principle: the strobe completing immediately after the last beat is a coherent arrangement, and generation behaviour varies. Existence is required at one end and not the other, and the code says which.

5. A colleague models DQS as a gated clock: assign dqs = clk & xfer_active. Better than assign dqs = clk? Better and still wrong. It fixes the free-running problem and adds something amble-like. It does not fix ownership — still one driver, so reads have no strobe — and it does not fix the fundamental error: the strobe is still derived from the clock, so it carries the clock's skew relative to the data. The skew argument of §1 is still undone, which is the failure that matters.

6. Which of §7's properties would still hold if the strobe were positioned badly enough to corrupt every capture? All of them. Every property here is about windows and ownership, and a badly positioned strobe violates none of them. That is the boundary: digital simulation verifies the contract and says nothing about whether the strobe is where it needs to be, which is analog characterisation and training margin. Knowing that a full pass proves nothing about capture reliability is the point of classifying the block.

12. Summary

DQS carries the data's own timing reference along nearly the same path as the data. A distributed clock and the data it would time travel different paths, and the skew between them is fixed by physical lengths — so as transfer rates rise it consumes a growing fraction of a shrinking budget until nothing remains. A source-synchronous strobe leaves only the much smaller strobe-to-data skew in the budget, which is why the arrangement scales.

It is a real strobe, unlike RAS#. RAS# is a command bit that inherited a strobe's name and is timed by CK; DQS times DQ. One is on a data port and the other, conceptually, on a clock port.

Three properties make it nothing like CK. It is directional — driven by whichever side drives the data, with the same ownership discipline and turnaround as DQ. It is not free-running — it toggles only around transfers. And it has a window structure: a preamble before the data and a postamble after, during which the strobe is active and no data is valid.

So strobe active is not data valid. The preamble exists because a receiver cannot use a strobe it has not yet seen; the postamble gives a defined completion. A receiver qualifying capture on strobe activity records whatever the data lines carried at the boundaries — well-formed, meaningless, and unobjectionable to everything downstream.

And assign dqs = clk is the most damaging line in the domain. It makes the strobe free-running, single-owner and amble-less, and — fundamentally — derives it from the clock, so it carries the clock's skew relative to the data. It does not model a simplified DQS; it models the arrangement DQS replaced.

The honest model is the digital contract only — ownership, enables, window structure — with the strobe's generation and its phase relative to the data left explicitly to the PHY, where they are built from technology-specific primitives, characterised in analog simulation, and adjusted by training.

Which means a full pass on §7's properties proves nothing about capture reliability. They verify windows and ownership; a badly positioned strobe violates none of them. That boundary is the chapter's most important content, and it is why Modules 19 to 21 exist.

13. What Comes Next

Chapter 6.11 takes a signal that modifies what a write commits.

A burst delivers a fixed number of beats, and sometimes a requester wants only part of them written. The data mask provides that — per beat, per byte — and it raises a question the interface has not faced yet: what happens when a signal's function is shared with another signal's on the same pin?

In DDR4 the answer is a mode register, and the two functions are mutually exclusive — you get one or the other, never both. And on x4 devices the pin does not exist at all, so masking is simply unavailable. Both facts have direct consequences for a controller, and neither is guessable from the signal's name.

Return to DQ for the ownership discipline DQS shares, CK / CK# for the other differential reference and the timing-domain split, or DDR1 for the generation that introduced source-synchronous timing. Modules 19 to 21 own the PHY, capture and training. The full path is on the DDR tutorials index.