Source-Synchronous Interfaces

Chapter 6.10 §1 already settled why DDR sends a strobe with its data: a clock distributed from the controller travels a different path from the data, the skew between those paths is fixed by physics, and a fixed skew eats a growing fraction of a shrinking transfer interval until nothing is left. That argument is complete and this chapter does not repeat it.

This module begins where that conclusion stops being reassuring.

Sending a reference with the data does not remove timing uncertainty. It replaces an unanswerable question — when exactly does this data arrive? — with a bounded one: how far apart do these two signals arrive?

The second question has an answer. It is published in device datasheets, it is a budget rather than a guarantee, and spending it badly is what the remaining four chapters of this module are about.

1. Two Disciplines, Two Budget Equations

Source-synchronous is not a DDR invention and framing it as one obscures what it does. It is one of two general ways to make a receiver agree with a transmitter about when.

System-synchronous. Both sides interpret data relative to a reference they each receive independently. The transmitter launches on its copy of the clock; the receiver samples on its copy. Neither knows how the other's copy arrived.

Source-synchronous. The transmitter sends a timing reference alongside the data, over a matched path, from the same place at the same time. The receiver uses that reference and never needs to know about anyone else's copy.

The difference shows up as which terms survive into the timing budget:

  SYSTEM-SYNCHRONOUS — what the receiver must absorb

     transmitter launch uncertainty
   + transmitter clock arrival vs receiver clock arrival   <-- the killer
   + data path flight time
   + data path variation
   + receiver sampling requirement
   ------------------------------------------------------
     all of it, against one transfer interval

  SOURCE-SYNCHRONOUS — what the receiver must absorb

     transmitter's own data-to-strobe skew
   + the DIFFERENCE between data and strobe path flight
   + receiver sampling requirement
   ------------------------------------------------------
     a residual, against the same interval

The second list is shorter and — more importantly — its terms are structurally different. The removed term was a comparison between two independently-distributed references. What replaced it is a comparison between two signals that were launched together and travelled together.

2. Why CK Cannot Locate a Returning Read

Apply the general argument to the specific case that motivates this module, because the read direction is where it bites hardest.

The controller knows precisely when it issued a READ. Chapter 17.1's commit point recorded the cycle. So why does it not simply count CL cycles (14.9) and sample?

Because the interval between issuing the command and the data appearing at the receiver's pins is the sum of a list, and the controller knows only the first item:

Seven of eight terms are unknown to the controller, and CL — the one thing it does know — is a cycle count the device promises to honour internally, not a measurement of how long the round trip physically takes.

3. Correlated, Not Identical

The claim that must not be overstated, because overstating it is the single most common misconception about source-synchronous links.

DQ and DQS do not experience identical delay. They experience correlated delay. The difference is what remains in the budget, and it is nonzero for concrete, enumerable reasons:

Different wires. Routed together is not routed identically. Trace lengths differ by whatever the layout tolerance is; vias, layer changes and neighbouring geometry differ.

Different drivers. DQ and DQS leave the device through separate output stages. Two instances of the same circuit on the same die do not have identical delay — that is process variation at the smallest scale.

Different loading. The strobe and the data pins see different capacitive environments, and on a multi-device bus, different fan-out.

Different signalling. Chapter 6.10 established that DQS is differential while DQ is single-ended. Those are not the same receiver problem, and they do not have the same delay through an input stage.

Different activity. A strobe toggles every transfer; a data line's transitions depend on the data. Pattern-dependent effects therefore hit them differently — which is Module 22's subject and named here only to complete the list.

  the residual, conceptually

    launched together  ---->  ||  ----> arrive not-quite-together
                              ||
                        matched-ish paths
                              ||
                              vv
                    residual DQ-to-DQS skew
                              ||
                              vv
                 published as a device parameter
                    (20.5 gives the real figures)

That residual has a name in the datasheet. Chapter 20.5 shows it published as a DQS-to-DQ skew parameter in unit intervals, alongside a hold-time parameter, and the two together define how much of a bit period the receiver can actually rely on. The number is small. It is not zero. And at high rates a small fraction of a shrinking interval is still a real constraint — which is precisely the arithmetic 6.10 §1 used against the distributed clock, now applied one level down.

4. The Budget, as a Structure

The bottom row is the honest part of the drawing. Two problems survive the change of discipline, and each is owned by a different chapter: the receiver must still be listening (19.4), and it must still choose a phase within the window it is listening to (20.3).

5. What This Chapter's RTL Can and Cannot Be

A boundary worth setting before any code, because this module is where fake hardware is easiest to write.

What cannot be modelled in portable RTL: flight time, driver delay, process variation, pad behaviour, sampling aperture, metastability. Chapter 19.1 §5 listed these and nothing has changed — they are physical quantities, not logic functions, and no amount of SystemVerilog represents them.

What can be modelled honestly: the structure of the budget. Which terms exist, which discipline removes which, how they accumulate, and whether what remains fits. That is bookkeeping over abstract quantities, and bookkeeping is exactly what RTL does.

So §6's block carries abstract units — not picoseconds, not UI — and its purpose is to make the §1 and §2 argument executable rather than rhetorical. A reader can change which terms are present and watch the residual change. That teaches the reframe; it predicts nothing about silicon, and its header says so.

6. The Budget Block

// ─────────────────────────────────────────────────────────────────────
// arrival_uncertainty_budget
//
// CLASSIFICATION
//   Synthesizable educational RTL. Purely combinational. One
//   responsibility: accumulate the uncertainty terms of §1 and §2
//   under a selected transfer discipline, and report whether the
//   residual fits inside a declared transfer interval.
//
//   IT IS A BOOKKEEPING MODEL IN ABSTRACT UNITS.
//
// WHAT IT DOES NOT MODEL
//   - No physical time. Every input is in ARBITRARY UNITS chosen by
//     the caller. There are no picoseconds, no UI and no nanoseconds
//     here, and a result from this block predicts nothing about any
//     real device. Chapter 20.5 is where verified figures live.
//   - No flight time, driver delay, process variation, pad behaviour,
//     sampling aperture or metastability -- none of these is a logic
//     function (Chapter 19.1 §5), and this block only ever receives
//     somebody else's number for them.
//   - No gate. Whether the receiver is listening at all is Chapter
//     19.4's problem and is independent of this budget (§2).
//   - No sampling phase. WHERE inside the surviving window to sample
//     is Chapter 20.3's subject; this block only says how wide it is.
//   - No training. Chapter 21 owns finding settings.
// ─────────────────────────────────────────────────────────────────────
module arrival_uncertainty_budget #(
  // Width of every budget quantity, in the caller's abstract units.
  parameter int Q_W = 12,
  // 0 = SYSTEM_SYNC  : the reference reaches each side independently
  // 1 = SOURCE_SYNC  : the reference travels with the data
  parameter int DISCIPLINE = 1
) (
  // ── The transfer interval the budget must fit inside.
  input  logic [Q_W-1:0] interval,

  // ── Terms present under BOTH disciplines.
  input  logic [Q_W-1:0] tx_launch_uncertainty,
  input  logic [Q_W-1:0] rx_sampling_requirement,

  // ── Terms present only under SYSTEM_SYNC. These are the ones a
  //    source-synchronous reference makes irrelevant (§1) -- not by
  //    shrinking them, but by removing them from the comparison.
  input  logic [Q_W-1:0] reference_distribution_skew,
  input  logic [Q_W-1:0] data_path_flight,
  input  logic [Q_W-1:0] data_path_variation,

  // ── The term that REPLACES them under SOURCE_SYNC. §3: the two
  //    paths are correlated, not identical, so this is nonzero.
  input  logic [Q_W-1:0] residual_data_to_strobe_skew,

  // ── Results.
  output logic [Q_W:0]   consumed,
  output logic [Q_W:0]   remaining,
  output logic           fits,
  output logic           source_sync_selected,

  // ── Observability: how much this discipline removed, so the §1
  //    comparison is a readable output rather than a claim.
  output logic [Q_W:0]   terms_excluded
);

  if (Q_W < 1) $fatal(1, "arrival_uncertainty_budget: Q_W must be >= 1");
  if (DISCIPLINE != 0 && DISCIPLINE != 1)
    $fatal(1, "arrival_uncertainty_budget: DISCIPLINE must be 0 or 1");

  assign source_sync_selected = (DISCIPLINE == 1);

  // ── Common terms. Both disciplines pay these: the transmitter's own
  //    launch uncertainty and the receiver's sampling requirement are
  //    properties of the endpoints, not of the reference scheme.
  logic [Q_W:0] common;
  assign common = {1'b0, tx_launch_uncertainty}
                + {1'b0, rx_sampling_requirement};

  // ── The discipline-specific terms, computed BOTH ways so that
  //    terms_excluded can report the difference. Summed one bit wider
  //    than a single term; the caller is responsible for keeping the
  //    total inside Q_W+1, which the overflow flag below checks.
  logic [Q_W:0] sys_specific;
  logic [Q_W:0] src_specific;
  assign sys_specific = {1'b0, reference_distribution_skew}
                      + {1'b0, data_path_flight}
                      + {1'b0, data_path_variation};
  assign src_specific = {1'b0, residual_data_to_strobe_skew};

  assign consumed = (DISCIPLINE == 1) ? (common + src_specific)
                                      : (common + sys_specific);

  // ── What choosing source-synchronous removed. Saturated at zero
  //    rather than wrapping: a negative exclusion would mean the
  //    source-synchronous residual exceeded the system-synchronous
  //    terms, which is possible in principle and must not appear as a
  //    huge positive number.
  assign terms_excluded = (sys_specific > src_specific)
                            ? (sys_specific - src_specific)
                            : '0;

  assign fits      = (consumed <= {1'b0, interval});
  assign remaining = fits ? ({1'b0, interval} - consumed) : '0;

endmodule

Simulating it. Instantiate it twice with the same inputs and DISCIPLINE set to 0 and 1. With any nonzero reference_distribution_skew, the source-synchronous instance reports a smaller consumed and a nonzero terms_excluded — which is §1's table, executed. Then shrink interval step by step: the system-synchronous instance stops fitting first, and the gap between the two failure points is the headroom the discipline bought.

Synthesis. Three adders and two comparators of width Q_W+1. It would synthesise, and there is no reason to: it is a teaching model and a checker input, not a datapath. terms_excluded exists purely so the comparison is an observable output rather than something a reader has to trust.

What is unrealistic about it. Everything physical. Real budgets do not add worst cases linearly — some terms are statistical and combine as distributions rather than sums, which is why a datasheet publishes a characterised window (20.5) rather than a list of terms for the reader to add. Linear worst-case addition is pessimistic, and this block is pessimistic on purpose, because a model that is pessimistic in a known direction is more useful than one that is optimistic in an unknown one.

7. The Two Disciplines, Side by Side

EDUCATIONAL — arbitrary units throughout. These are not picoseconds, not UI, and not any device's figures. §6's header states why.

Q_W = 12. The same five inputs, evaluated under both disciplines.

  input term                        units
  ───────────────────────────────   ─────
  interval                            100
  tx_launch_uncertainty                 10
  rx_sampling_requirement               15
  reference_distribution_skew           45   <-- system-sync only
  data_path_flight                      20   <-- system-sync only
  data_path_variation                   12   <-- system-sync only
  residual_data_to_strobe_skew           8   <-- source-sync only

  DISCIPLINE = 0  (SYSTEM_SYNC)
    common        = 10 + 15                    =  25
    sys_specific  = 45 + 20 + 12               =  77
    consumed                                   = 102
    fits          = 102 <= 100                 =  NO
    remaining                                  =   0

  DISCIPLINE = 1  (SOURCE_SYNC)
    common        = 10 + 15                    =  25
    src_specific  = 8                          =   8
    consumed                                   =  33
    fits          = 33 <= 100                  = YES
    remaining                                  =  67
    terms_excluded= 77 - 8                     =  69

Two readings, and the second is the one this module needs.

The obvious one: the same link fails under one discipline and passes under the other, with no change to any physical property. Only the reference scheme changed.

The one that matters: the source-synchronous case still consumed 33 units of a 100-unit interval — a third of the budget, gone, with a perfectly matched strobe. Twenty-five of those are endpoint properties no reference scheme can remove, and eight are the residual of §3.

Now shrink the interval, which is what rising transfer rates do:

  interval   system-sync fits?   source-sync fits?   source-sync remaining
  ────────   ─────────────────   ─────────────────   ─────────────────────
      100           no                 yes                    67
       60           no                 yes                    27
       40           no                 yes                     7
       33           no                 yes                     0
       30           no                 NO                      0

Source-synchronous transfer does not make the problem go away; it moves the cliff. At an interval of 30 abstract units this link fails under either discipline, and the reason is the same arithmetic 6.10 §1 used: a fixed cost against a shrinking interval eventually wins.

That is why Module 21's training and Module 22's signal integrity exist. Once the reference scheme has given you everything it can, the remaining margin has to be found by measurement and protected by the channel — and the numbers that say how much margin there is are 20.5's.

8. What the Assertions Prove

arrival_uncertainty_budget is combinational and has no clock, so these belong in a testbench or a bind unit sampled on the environment's clock — the arrangement Chapter 16.2 §10 established for combinational blocks.

// ── P1. The accounting balances: consumed is exactly the terms the
//    selected discipline includes, and no others. Definitional against
//    the RTL, and a regression anchor -- it fails the day a term is
//    added to one branch and not the other.
property p_consumed_matches_discipline;
  @(posedge clk) disable iff (!rst_n)
    consumed == (source_sync_selected
                   ? (tx_launch_uncertainty + rx_sampling_requirement
                      + residual_data_to_strobe_skew)
                   : (tx_launch_uncertainty + rx_sampling_requirement
                      + reference_distribution_skew
                      + data_path_flight + data_path_variation));
endproperty
a_consumed_matches_discipline: assert property (p_consumed_matches_discipline);

// ── P2. The endpoint terms are never excluded. §7's second reading as
//    a property: no reference discipline can remove the transmitter's
//    own launch uncertainty or the receiver's sampling requirement,
//    and a model that let it would teach the opposite of the lesson.
property p_endpoint_terms_always_paid;
  @(posedge clk) disable iff (!rst_n)
    consumed >= (tx_launch_uncertainty + rx_sampling_requirement);
endproperty
a_endpoint_terms_always_paid: assert property (p_endpoint_terms_always_paid);

// ── P3. fits and remaining agree. Catches a remaining that reports
//    headroom on a budget that did not fit -- which would read as a
//    passing link.
property p_fits_agrees_with_remaining;
  @(posedge clk) disable iff (!rst_n)
    (!fits |-> remaining == '0)
    && (fits |-> remaining == ({1'b0, interval} - consumed));
endproperty
a_fits_agrees_with_remaining: assert property (p_fits_agrees_with_remaining);

// ── P4. terms_excluded saturates rather than wrapping. A residual
//    larger than the terms it replaced is legitimate in principle,
//    and must report as zero exclusion, not as a huge saving.
property p_exclusion_saturates;
  @(posedge clk) disable iff (!rst_n)
    (residual_data_to_strobe_skew
       >= (reference_distribution_skew + data_path_flight
           + data_path_variation))
      |-> terms_excluded == '0;
endproperty
a_exclusion_saturates: assert property (p_exclusion_saturates);

// ── Covers. The interesting configurations, without which P1 and P4
//    are checking an empty space.
c_sys_fails_src_fits: cover property (@(posedge clk) disable iff (!rst_n)
                        !fits && source_sync_selected == 1'b0);
c_both_fail:          cover property (@(posedge clk) disable iff (!rst_n)
                        !fits && source_sync_selected);
c_no_exclusion:       cover property (@(posedge clk) disable iff (!rst_n)
                        terms_excluded == '0);

What they prove. That the bookkeeping is internally consistent and that the model cannot be made to claim a discipline removes an endpoint cost.

What they do not prove — and this is categorical. Nothing here says any input value is right. The block adds whatever numbers it is handed, and a budget assembled from wrong terms balances just as well as one assembled from right ones. No digital assertion can establish a physical timing quantity, and every remaining chapter of this module repeats that boundary because it is the thing most easily forgotten when the RTL passes.

Nor do these properties say anything about whether linear worst-case addition is the right combination rule. §6 stated that it is pessimistic; establishing how pessimistic is a statistical question about real distributions, which is not an RTL question at all.

c_both_fail is the cover that matters. If a test suite never drives the interval low enough for the source-synchronous case to fail, the model has only ever been exercised in the regime where the answer is comfortable — and §7's cliff, which is the chapter's real conclusion, has never been reached.

9. Corner Cases

The maximum-terms row is the one with a genuine limitation behind it. Five terms of width Q_W can sum past Q_W+1 bits, and this block widens by only one. It is the caller's responsibility to keep the total representable, which is a real constraint and is stated rather than papered over with an arbitrary extra bit — a model whose width rule is explicit is easier to use correctly than one whose margin is mysterious.

10. DV — Checking a Reframe, Not a Datapath

There is no data transformation here, so the independent model is not a datapath model. It is a term-set comparison.

Build the reference as an explicit set of named terms per discipline — a dictionary from term name to value, filtered by which discipline includes it — and sum that. The RTL adds a fixed expression; the checker sums a filtered collection. Those are different enough that a term dropped from the RTL's expression cannot be dropped from the checker's set by the same slip.

Then check the property the RTL cannot state: that the two term sets share exactly the endpoint terms and differ in nothing else. That is §1's table as an executable claim.

  BUDGET TERM-SET MISMATCH
    discipline under test : SOURCE_SYNC
    interval              : 100

    reference term set    : tx_launch_uncertainty        10
                            rx_sampling_requirement      15
                            residual_data_to_strobe_skew  8
                            ----------------------------------
                            expected consumed            33

    observed consumed     : 53
    difference            : 20

    diagnosis : 20 is exactly data_path_flight, which belongs to the
                SYSTEM_SYNC set only. The source-synchronous branch is
                charging a term the discipline removes.
    why it matters : the model now reports that source-synchronous
                transfer saves less than it does, which is the wrong
                direction for a teaching model -- a reader would
                conclude the discipline is weaker than it is.
    caught by : P1 (consumed matches discipline)
    NOT caught by : P2 or P3, both of which remain satisfied -- the
                total is still at least the endpoint terms and
                remaining still agrees with fits.

The last two lines are the reason the checker tracks a set rather than a total. A wrong total that is still internally consistent passes every property about consistency, and only an independent enumeration of which terms should be present catches it.

Directed cases worth running: both disciplines with identical inputs, which must differ by exactly terms_excluded; every term individually set to zero, to confirm each is actually wired into the right branch; interval swept down through both cliff points of §7; residual set above the system terms, which must saturate; and Q_W = 1.

11. Debugging

Symptom: a link closes in analysis and fails in hardware. Ask first which discipline the analysis assumed. A budget built as if the reference were distributed will be pessimistic for a source-synchronous link and will not explain a failure; a budget built as if the strobe were perfectly matched omits §3's residual and is optimistic, which does. The direction of the error tells you which mistake was made.

Symptom: the budget says there is margin and errors occur at rate. Suspect a missing term rather than a wrong one. §2's table has eight entries and the residual of §3 has five contributors; a budget with four terms in it is not a budget. This is the most common failure of the analysis rather than of the hardware.

Symptom: analysis and measurement disagree by a consistent factor. Likely the combination rule, not the terms. §6 adds worst cases linearly and says so; a real characterised window (20.5) is not that sum, and expecting them to agree numerically is a category error rather than a bug in either.

Symptom: the link works on one board and not another. Nothing in this chapter distinguishes them, and that is the finding. Board-to-board variation lands in terms this chapter names but does not quantify — which routes to Module 21 if the settings differ, and Module 22 if the channel does.

12. Misconceptions

“Source-synchronous means zero skew.” §3 — correlated, not identical, for five enumerable reasons. Consequence: a budget with the residual omitted, which is optimistic and closes when it should not. Clue: an analysis with no DQ-to-DQS term in it at all.

“DQ and DQS have identical propagation.” Different wires, drivers, loading, signalling and activity. Clue: an expectation that matched routing makes a parameter unnecessary.

“The strobe removes timing uncertainty.” It changes the variable from absolute to relative (§1). Clue: a design that skips the gate on the grounds that DQS will tell it when data arrives — 19.4 §3 shows why that fails.

“CK can locate returning read data if you count CL correctly.” §2 — seven of eight terms are unknown to the controller, and CL is a cycle count rather than a flight time. Clue: a receiver with no trained arrival term.

“Source-synchronous transfer scales indefinitely.” §7's table — the cliff moves, it does not disappear. Clue: surprise that a strobe-based interface needs training and equalisation at higher rates.

“A strobe means the receiver does not need a sampling phase.” It needs one relative to the strobe instead of relative to a clock, which is 20.3's whole subject. Clue: always_ff @(posedge dqs) — 19.1 §1's counter-example.

“The endpoint terms can be designed away.” P2 — transmitter launch uncertainty and receiver sampling requirement are properties of the endpoints. Improving the reference scheme does not touch them. Clue: a budget where the reference scheme is expected to absorb the receiver's own requirement.

“An RTL budget model validates a timing analysis.” §8 — it checks arithmetic consistency, not physical correctness. Clue: sign-off from a simulation of the budget.

13. Interview Reasoning

“What does source-synchronous mean?” The transmitter sends a timing reference alongside the data over a matched path. The strong answer continues to the consequence: it converts absolute arrival into relative arrival.

“Why does DDR send a strobe rather than relying on CK?” Cite the scaling argument, then the eight-term table of §2 — the controller knows one of the terms.

“Does a strobe eliminate skew?” No. It eliminates one skew and leaves another, and the residual is published as a device parameter. Saying "no" and naming what remains is the discriminating answer.

“Why are DQ and DQS not identically delayed if they are routed together?” Different wires, different drivers, different loading, different signalling, different activity. Naming three is enough; naming the categories shows the reasoning transfers.

“Your source-synchronous link fails at a higher rate. Has the discipline stopped working?” No — the fixed costs are the same and the interval shrank. §7's table. Then where the remaining margin comes from: training and the channel.

“What can an RTL timing-budget model tell you?” Whether the accounting is consistent and which terms each discipline includes. Not whether any term is physically right, which is measurement.

14. Exercises

1. With §7's inputs, compute consumed under both disciplines by hand and confirm the terms_excluded figure.

2. At what interval does the source-synchronous case stop fitting, given §7's terms? Show the arithmetic.

3. Set residual_data_to_strobe_skew to 80 with §7's other terms. Which discipline now consumes less, what does terms_excluded read, and which property covers the result?

4. List the five contributors to the residual from §3 and classify each as layout, silicon, or signalling.

5. §2's table has eight terms. Which one does the controller genuinely know, and why is knowing it insufficient?

6. Explain why P2 could not be written as an equality rather than an inequality.

7. A colleague adds reference_distribution_skew to the source-synchronous branch "for safety margin". Describe what the model now teaches and why that is worse than an explicit margin term.

8. §6 adds worst cases linearly. Explain why a datasheet publishes a characterised window instead, and what that means for comparing the two numbers.

15. Where This Goes

The reframe is established: a strobe converts an absolute question into a relative one, and the relative answer is a budget that is small, nonzero, and publishable.

Four things follow, one per remaining chapter. Chapter 20.2 asks why the strobe is organised per byte lane rather than one per device — which turns out to be the same matched-path argument applied to how many wires one reference can credibly speak for. 20.3 opens the box Module 19 left closed and asks where inside the window to sample, given that on a read the strobe arrives aligned to the data's transitions rather than to its centre. 20.4 turns the problem around for writes, where the alignment the device requires is against CK rather than against the data. And 20.5 supplies the figures this chapter deliberately withheld — the published parameters that say how much of a bit period a receiver can actually rely on.