The DQS Concept

Chapter 20.1 established that a strobe converts absolute arrival into a relative budget, and that the budget survives because the two signals shared a path. This chapter presses on the word shared, because it does not scale indefinitely.

A strobe is only trustworthy for the wires that genuinely shared its journey. That is a limit on how many data bits one reference can speak for — and it is why DDR groups DQ into byte lanes, each with its own strobe.

There is a second, independent fact this chapter owns, and it surprises people who have only seen the read direction:

The strobe's phase relative to the data is not the same on a read as on a write. On a read the two arrive with their transitions aligned. On a write the strobe arrives centred in the data. Those are different receivers solving different problems, and conflating them makes the whole of 20.3 incomprehensible.

1. How Far Does a Strobe's Authority Reach?

Chapter 20.1 §3 listed five reasons DQ and DQS are correlated rather than identical: different wires, different drivers, different loading, different signalling, different activity. Every one of those grows with distance.

So ask the question the other way round. Given one strobe, how many data wires can it credibly time?

  one strobe, few wires nearby          one strobe, the whole bus

    DQS ----+----+----+                  DQS ----+--------+--------+
            |    |    |                          |        |        |
           DQ0  DQ1  DQ2                        DQ0  ... DQ31 ... DQ63
    routed together, same                 routed across the device, the
    output bank, similar load             package, the module; different
                                          banks, lengths, environments
    residual skew: small                  residual skew: large, and it
    and characterisable                   varies per bit by position

The residual is not a property of the strobe. It is a property of the strobe's relationship to each particular data wire — and those relationships stop resembling one another once the wires stop sharing a neighbourhood.

2. What a Lane Is, and What It Is Not

Precision here prevents a misconception §13 catalogues.

A byte lane is a group of DQ pins together with the strobe that times them. It is an association, established by the device's pinout and preserved by the board routing and the PHY's receive organisation.

It is not the same thing as a byte of controller data. Chapter 19.2 §3 established that a controller word spans all lanes across all beats, so one lane contributes BEATS bytes to each word, not one byte. The words byte lane name the width of the pin group, not the width of anything the controller sees.

And the number of lanes is not universal. It follows from the device's data width and the generation's organisation. Chapter 19.2 §3 noted the module-level consequence — a DDR4 DIMM presents one 72-bit channel while a DDR5 DIMM presents two independent 32-bit subchannels — and the lane count follows from whichever of those a system has. An example with a specific lane count is an example, and §6's RTL takes the count as a parameter for exactly that reason.

3. Edges and Beats

Before the phase question, the simpler correspondence it rests on.

A DDR transfer moves data on both strobe edges. So within one burst, the strobe's transitions and the data's beats correspond one to one:

  EDUCATIONAL — one column is one unit interval. This shows WHICH beat
  belongs to WHICH edge. It does not show the strobe's phase relative
  to the data; that is §4, and a cycle grid cannot represent it.

   col:      0     1     2    3    4    5    6    7    8    9
   DQS:      z     0     1    0    1    0    1    0    1    0
   edge:     -     -     R    F    R    F    R    F    R    F
   DQ:       z     z     D0   D1   D2   D3   D4   D5   D6   D7

Eight beats on eight edges, alternating rising and falling. Column 1 is the preamble — the strobe is driven but no data accompanies it yet, which is Chapter 6.10 §4's point that the strobe window is wider than the data window.

The alternation is the thing to carry into 20.3. A receiver produces two kinds of capture event, one per edge polarity, and turning those two event streams back into a single ordered beat sequence is a real digital problem with a real bug — 20.3 §6's normalizer owns it, and swapping the two produces the deterministic pairwise corruption §12 describes.

4. The Phase Is Not the Same in Both Directions

Now the fact this chapter exists to establish, and the one most often assumed symmetric.

On a read, the device drives DQ and DQS with their transitions aligned. Both leave the device's output stage at the same instant, so the strobe's edges coincide with the data's edges — the boundaries between beats, not their centres.

On a write, the controller side delivers DQS centred in the data. The strobe's edges sit in the middle of each data beat rather than at its boundary.

  CONCEPTUAL — NOT TO SCALE. A cycle grid cannot show sub-interval
  phase, so this is a sketch of the relationship, not a measurement.

  READ — device launches both, transitions aligned
             |<------ one beat ------>|<------ one beat ------>|
    DQ    ---+========================+========================+---
             |                        |                        |
    DQS   ---+------------------------+------------------------+---
             ^                        ^
             edges coincide with beat boundaries

  WRITE — controller delivers the strobe centred
             |<------ one beat ------>|<------ one beat ------>|
    DQ    ---+========================+========================+---
                         |                        |
    DQS   ---------------+------------------------+---------------
                         ^                        ^
                         edges sit mid-beat

Two consequences worth stating before §6.

A read receiver that samples on the raw incoming edge is wrong by construction, not by a small margin. That is 19.1 §1's always_ff @(posedge dqs) counter-example given its precise reason: the edge is at the boundary, and the boundary is where the data is changing.

The write direction's alignment problem is a different problem entirely. The controller must centre the strobe in the data and satisfy the device's requirement that the strobe arrive in a defined relationship to CK — which is a second, independent constraint, and it is 20.4's subject.

5. What Is Universal and What Is Not

§2 asserted that the lane count is not universal. That deserves to be made precise, because the parts of this chapter that generalise and the parts that do not are easy to confuse — and a design built on the wrong half is a design built on an example.

Universal — it follows from the physics.

A strobe's timing authority is bounded by the wires that shared its path. §1's argument uses nothing generation-specific; it would apply to any source-synchronous interface, memory or otherwise.

Grouping therefore exists, and the group is the unit of timing state. Whatever the group size, everything trained or measured about timing is naturally per group, which is why 19.3 §5 and 19.5 instantiate their state per lane.

The read/write phase asymmetry of §4 follows from who generates both signals, not from any particular standard's numbers.

Not universal — it depends on the device and the generation.

The number of DQ bits per strobe. A byte is the DDR family's answer, not a physical necessity.

The number of lanes per channel. It follows from the data width. Chapter 19.2 §3 recorded the module-level consequence: a DDR4 DIMM presents one 72-bit channel — 64 data bits plus 8 for ECC — while a DDR5 DIMM splits the module into two independent 32-bit subchannels, 40 bits each with ECC. Those are different lane budgets per channel, and a controller managing one is managing a different number of independent windows than a controller managing the other.

Whether a narrow device has a strobe per byte at all. On a device narrower than a byte the grouping cannot be a byte, so the association is whatever that device's pinout defines.

One consequence for the rest of the module. Chapter 20.5 §4 quantifies the skew within a lane from published figures — a per-pin window wider than the per-device one, by a margin that grows with rate. That difference is the residual §1 argued must be nonzero, measured. So this chapter's argument and that chapter's table are the same claim at two levels of precision: grouping keeps the residual small, and the datasheet says how small.

6. The Lane Binding Block

The digital fact worth making checkable: every DQ bit is captured against the strobe of the lane it belongs to, and no other.

// ─────────────────────────────────────────────────────────────────────
// lane_strobe_binding
//
// CLASSIFICATION
//   Synthesizable educational RTL. Purely combinational. One
//   responsibility: express and check the ASSOCIATION between DQ bits
//   and the strobe that times them, so that a broken binding is a
//   detected condition rather than an invisible one (§2).
//
//   It models an ASSOCIATION, not a capture. Nothing here samples
//   anything.
//
// WHAT IT DOES NOT MODEL
//   - NO CAPTURE. It does not sample DQ, does not shift a strobe, and
//     has no notion of a sampling phase. Chapter 20.3 owns capture.
//   - No sub-interval timing, no skew, no setup or hold. Those are
//     physical quantities (Chapter 19.1 §5); this block only knows
//     which strobe is SUPPOSED to time which bits.
//   - No strobe generation or ownership. Chapter 6.10 owns both, with
//     dqs_ownership_window.
//   - No gate. Whether a strobe should be admitted at all is Chapter
//     19.4's problem.
//   - No training. Per-lane settings are Module 21's to discover.
// ─────────────────────────────────────────────────────────────────────
module lane_strobe_binding #(
  parameter int NUM_LANES = 4,
  parameter int LANE_W    = 8,
  parameter int BUS_W     = NUM_LANES * LANE_W,
  // Index over lanes. Guarded: $clog2(1) is 0 and a zero-width index
  // is not a legal declaration.
  parameter int LN_W = (NUM_LANES <= 1) ? 1 : $clog2(NUM_LANES)
) (
  // ── The bus as the device presents it, and one strobe-active flag
  //    per lane. The flags come from Chapter 19.4's gate: a lane's
  //    strobe is "active" when that lane's gate is admitting it.
  input  logic [BUS_W-1:0]        dq_bus,
  input  logic [NUM_LANES-1:0]    lane_strobe_active,

  // ── Which lane each capture event claims to belong to. A capture
  //    path reports its own lane identity; this block checks the
  //    claim rather than trusting it.
  input  logic                    event_valid,
  input  logic [LN_W-1:0]         event_lane,

  // ── The DQ slice that lane owns. Published so a consumer takes the
  //    bits from the binding rather than slicing the bus itself --
  //    one place to be wrong instead of many.
  output logic [LANE_W-1:0]       lane_dq,

  // ── The binding, as data: bit i of the bus belongs to this lane.
  output logic [BUS_W-1:0]        lane_bit_mask,

  // ── Design errors. None should ever assert.
  output logic                    err_lane_out_of_range,
  output logic                    err_event_without_strobe,
  output logic                    err_no_lane_active
);

  if (NUM_LANES < 1) $fatal(1, "lane_strobe_binding: NUM_LANES must be >= 1");
  if (LANE_W    < 1) $fatal(1, "lane_strobe_binding: LANE_W must be >= 1");

  logic in_range;
  assign in_range = (int'(event_lane) < NUM_LANES);

  assign err_lane_out_of_range = event_valid && !in_range;

  // ── THE CHECK OF §2. A capture event claiming lane L is only
  //    legitimate if lane L's own strobe is the one that is active.
  //    An event arriving for a lane whose strobe is not active means
  //    the bits are being timed by somebody else's reference -- the
  //    failure that leaves every other lane looking perfect.
  assign err_event_without_strobe =
      event_valid && in_range && !lane_strobe_active[event_lane];

  // ── No lane active at all while an event is claimed. Distinguished
  //    from the above because the diagnosis differs: this is a gate
  //    problem (Chapter 19.4), that one is a binding problem.
  assign err_no_lane_active = event_valid && (lane_strobe_active == '0);

  // ── The slice. A variable part-select, so the lane-to-bit mapping
  //    exists in exactly one place.
  assign lane_dq = dq_bus[event_lane * LANE_W +: LANE_W];

  // ── The same mapping published as a mask, by comparison rather than
  //    by a shift: an out-of-range index yields an all-zero mask
  //    rather than an aliased one, failing safe and visibly.
  always_comb begin
    lane_bit_mask = '0;
    if (event_valid && in_range) begin
      for (int b = 0; b < BUS_W; b++)
        if ((b / LANE_W) == int'(event_lane)) lane_bit_mask[b] = 1'b1;
    end
  end

endmodule

Simulating it. Drive lane_strobe_active with a single bit set and event_lane matching it: lane_dq presents that lane's eight bits and no error asserts. Now hold event_lane at 1 while only lane 0's strobe is active — err_event_without_strobe asserts, and that single signal is the difference between a diagnosable fault and a week of measuring lanes that are working.

Synthesis. A NUM_LANES-to-one multiplexer of width LANE_W, a comparator, and a BUS_W-wide mask built from a comparison tree. For the defaults that is a 4:1 8-bit mux and 32 comparisons — negligible, and instantiated once per receive path.

What is unrealistic about it. It checks the binding as declared in RTL. A binding broken by a board routing error or a device pinout misunderstanding is invisible here, because this block only sees the signals it was handed and the lane identities they claim. Detecting a physical mis-binding requires driving known per-lane patterns and observing where they emerge — which is a bring-up activity, and §10's debugging section treats it as such.

7. What the Assertions Prove

These are combinational; the block has no clock. They belong in a testbench or a bind unit sampled on the environment's clock, as Chapter 16.2 §10 established.

// ── P1. THE binding property of §2: a capture event for a lane
//    requires that lane's own strobe to be the active one. If this
//    fails, DQ bits are being timed against a reference that did not
//    share their path, and every parameter in 20.5 stops applying.
property p_event_requires_own_strobe;
  @(posedge clk) disable iff (!rst_n)
    (event_valid && int'(event_lane) < NUM_LANES)
      |-> lane_strobe_active[event_lane];
endproperty
a_event_requires_own_strobe: assert property (p_event_requires_own_strobe);

// ── P2. The published slice matches the published mask. Two
//    representations of one mapping, deliberately: the slice is what a
//    consumer uses and the mask is what a checker reads, and a
//    disagreement means the lane-to-bit mapping is ambiguous.
property p_slice_matches_mask;
  @(posedge clk) disable iff (!rst_n)
    (event_valid && int'(event_lane) < NUM_LANES)
      |-> ($countones(lane_bit_mask) == LANE_W);
endproperty
a_slice_matches_mask: assert property (p_slice_matches_mask);

// ── P3. Lane masks never overlap. A bit belongs to exactly one lane,
//    which is what makes "the strobe that timed it" a well-defined
//    phrase at all.
property p_mask_within_one_lane;
  @(posedge clk) disable iff (!rst_n)
    (event_valid && int'(event_lane) < NUM_LANES)
      |-> ((lane_bit_mask >> (event_lane * LANE_W)) & ((1 << LANE_W) - 1))
          == ((1 << LANE_W) - 1);
endproperty
a_mask_within_one_lane: assert property (p_mask_within_one_lane);

// ── P4. An out-of-range lane fails safe: no bits claimed, error
//    raised. Catches an aliased index silently selecting a valid lane.
property p_out_of_range_fails_safe;
  @(posedge clk) disable iff (!rst_n)
    err_lane_out_of_range |-> (lane_bit_mask == '0);
endproperty
a_out_of_range_fails_safe: assert property (p_out_of_range_fails_safe);

// ── Covers. P1 fires only on a real event, and the error paths are
//    what a happy-path test never reaches.
c_each_lane_used:   cover property (@(posedge clk) disable iff (!rst_n)
                      event_valid && event_lane == LN_W'(NUM_LANES-1));
c_binding_violated: cover property (@(posedge clk) disable iff (!rst_n)
                      err_event_without_strobe);
c_multi_lane_active:cover property (@(posedge clk) disable iff (!rst_n)
                      $countones(lane_strobe_active) > 1);

What they prove. That the lane-to-bit mapping is a partition, that it is consistently published, that an event is only honoured for a lane whose own strobe is active, and that a bad index fails safe.

What they do not prove — and the gap is the physical one. Nothing here establishes that lane 1's wires actually reach lane 1's receiver. The block checks a declared association; a board that routes lane 1's DQ to lane 2's pins satisfies every property above while delivering exactly the failure §2 describes. A digital assertion cannot verify a physical binding, and the only thing that can is driving distinguishable per-lane patterns through real hardware.

Nor do they say anything about the phase the strobe is used at. That is 20.3's, and this block has no representation of it.

c_binding_violated is the cover that matters most. A test suite that never drives a mismatched event has never exercised P1, and P1 is the only reason the block exists.

8. Corner Cases

The multi-lane row deserves emphasis because it is the one most likely to be coded wrong. A read burst arrives on every lane at once, so lane_strobe_active normally has many bits set; the block's job is not to enforce exclusivity but to check that each event names a lane that is among them. A design that asserted one-hot activity would reject normal operation.

9. DV — Driving Distinguishable Patterns

The independent model must not reuse the block's part-select, and the interesting test is not a random one.

Build the reference as an explicit lane-to-bit dictionary — lane index to the list of bus bit positions it owns — constructed from the parameters by integer division, and compare against lane_bit_mask. Different representation, same claim.

Then the test that matters: drive each lane with a distinguishable pattern rather than random data. If every lane carries a value derived from its own index, a mis-binding is immediately readable in the output rather than being one wrong value among many.

  LANE BINDING MISMATCH
    NUM_LANES = 4, LANE_W = 8
    stimulus : each lane driven with its own index repeated
               lane 0 -> 0x00   lane 1 -> 0x11
               lane 2 -> 0x22   lane 3 -> 0x33

    event_lane                : 2
    lane_strobe_active        : 0b0100   (lane 2 active — correct)
    expected lane_dq          : 0x22
    observed lane_dq          : 0x11

    diagnosis : the slice is one lane low. The mask and the slice
                disagree, so P2 fires; and because the pattern is
                index-derived, the observed value NAMES the wrong
                lane directly -- 0x11 is lane 1's pattern.
    discriminator : with random data both a one-lane offset and a
                bit-reversal inside the lane look like "wrong bits".
                With index-derived patterns the first is readable at a
                glance and the second is not, so run BOTH: index
                patterns to find lane errors, then a walking one
                within a lane to find bit errors.
    NOT indicated : anything physical. A routing mis-binding produces
                the same observed value and no property fires, because
                the RTL's declared association is self-consistent.

The discriminator line is the point of using structured stimulus. Random data makes every wrong answer look the same; index-derived data makes the wrong answer say which lane it came from.

Directed cases worth running: NUM_LANES = 1 and LANE_W = 1; an event for each lane in turn with only that lane active; an event for each lane with all lanes active; a mismatched event, which must raise the error; an out-of-range lane; and a walking-one pattern within a single lane, which finds bit-order errors that lane-level patterns cannot.

10. Debugging

Symptom: one lane produces wrong data and every other lane is correct. Not a controller problem and not a gearbox problem — 19.2 §14 established that a gearbox slices uniformly, so a slicing error affects all lanes identically. That leaves per-lane state, per-lane physics, or the binding itself. Check err_event_without_strobe first: it costs one signal read and it distinguishes a binding fault from a timing fault before any measurement.

Symptom: the binding checks pass and one lane is still wrong. Then the association is correct as declared and the fault is physical or per-lane timing. §7 is explicit that no digital property can see a routing error. Drive index-derived per-lane patterns through real hardware and observe where each emerges — if lane 2's pattern appears at lane 1, the binding is broken below the RTL.

Symptom: every lane is wrong in the same way. Not a binding problem. A uniform fault points at something shared — the gearbox (19.2), the assembly order (20.3), or a common timing reference.

Symptom: beats arrive in pairs that are swapped. Not this chapter. §3's edge alternation means a rise/fall ordering error produces exactly that signature, and it is 20.3 §6's normalizer.

Symptom: reads fail and err_no_lane_active is asserted. A gate problem, not a binding problem — no strobe is being admitted at all. Chapter 19.4 §12 owns that diagnosis, and the two error signals exist separately so the distinction costs nothing.

11. Misconceptions

“DQS is just a clock.” It is not free-running, it is undriven between bursts (6.10), its owner changes with data direction, and — this chapter's addition — its authority extends only to its own lane. A clock has none of those four properties. Clue: a receive design with one timing reference for the whole bus.

“One strobe could time the whole bus.” §1 — the published parameter would have to cover the worst relationship anywhere on the bus, penalising every bit. Clue: a skew budget with no per-group scoping.

“A byte lane is a byte of controller data.” §2 — a lane contributes BEATS bytes to each controller word (19.2 §3). Clue: a lane-to-byte mapping derived without reference to the beat count.

“Every DDR interface has the same number of lanes.” It follows from device width and generation organisation. Clue: a hardcoded lane count with no configuration named.

“Read and write use the same DQ-to-DQS phase.” §4 — read is edge-aligned, write is centre-aligned. Consequence: a read receiver that samples on the raw edge samples at the beat boundary. Clue: a receive path with no strobe shift in it.

“The device centres its read strobe.” It does not, and §4 explains why: accurate sub-interval delay is expensive and PVT-sensitive, and a commodity die avoids it. Clue: an expectation that a read needs no PHY-side phase adjustment.

“Sampling on a DQS edge automatically gives good margin.” On a read it gives the worst margin, because the edge is where the data is changing. Clue: always_ff @(posedge dqs) presented as a receiver.

“If both strobes are toggling, the lanes are bound correctly.” §2's callout — both can be perfect while the association between them and the data is crossed. Clue: a one-lane failure investigated as a timing problem before the binding is checked.

12. Interview Reasoning

“Why does DDR use one strobe per byte rather than one per bus?” Because the strobe's usable skew parameter only covers wires that shared its path, so a single strobe would have to be specified for the worst relationship on the bus. The strong answer names the trade against pin count.

“What is a byte lane?” A group of DQ pins plus the strobe that times them — an association, not a data width. The follow-up worth volunteering: that is why trained timing settings are per lane.

“Is the DQ-to-DQS phase the same on reads and writes?” No — edge-aligned on a read, centre-aligned on a write. Then why: the side that generates both signals can place the strobe where it likes; the device declines the expense on reads and pushes it to the controller.

“What does a read receiver have to do that a write receiver does not?” Shift the strobe before using it, because it arrives at the beat boundary rather than the centre.

“One lane is producing wrong data. What do you check first?” The binding, before any timing. It is one signal read and it eliminates a whole class. Then per-lane settings, then physical routing with index-derived patterns.

“Can an assertion prove the lanes are wired correctly?” No — it can prove the declared association is self-consistent. A routing error satisfies every digital property. Knowing that boundary is the answer.

13. Exercises

1. With NUM_LANES = 4 and LANE_W = 8, which bus bits does lane 2 own? Give the lane_bit_mask value in hex.

2. §3's waveform shows eight beats on eight edges. Which beats arrive on falling edges, and how many strobe transitions occur in total including the preamble?

3. Explain why a single strobe for a 64-bit bus would force a larger published skew parameter, referring to which relationship the parameter must cover.

4. A read receiver samples directly on the incoming DQS rising edge. Using §4's sketch, say where in the beat it is sampling and why that is the worst available choice.

5. Construct a stimulus where err_event_without_strobe asserts while every strobe on the interface is toggling correctly. What is the physical situation it corresponds to?

6. lane_bit_mask is built by comparison rather than by ((1 << LANE_W) - 1) << (event_lane * LANE_W). Give a NUM_LANES and event_lane where the shift version silently selects real bits and the comparison version does not.

7. Design the per-lane stimulus pattern that makes a one-lane offset readable at a glance, and explain why random data does not.

8. Explain why §7's properties all pass on a board that swaps lane 1's and lane 2's DQ traces, and name the only thing that detects it.

14. Where This Goes

Two facts are now in place. The strobe's authority is per lane, which is why every timing setting in this module and the next is per lane. And on a read the strobe arrives edge-aligned with the data, which means a receiver cannot use it as it stands.

Chapter 20.3 opens the box Module 19 left closed and deals with that second fact directly: the strobe must be shifted before it can sample, the two edge polarities must be turned back into one ordered beat sequence, and the arriving burst cannot be told to wait while the digital side catches up. 20.4 turns to the write direction, where the alignment that matters is not against the data at all. 20.5 supplies the published figures — the real parameters that say how much of a beat a receiver can rely on, and what eats the rest.