CAS-Latency Question

CL is the most quoted number in memory and the least informative, and the interview exploits that precisely. Nobody useful asks what CL stands for. What they ask is a comparison, a budget, or a trace — and each one fails for a different reason.

The single sentence this chapter is built on: CL is a cycle count, a latency, and one term — and the three common errors are treating it as a time, as a throughput cost, and as the budget.

1. Three Questions That Sound Like One

All three are phrased as tell me about CAS latency. They are not the same question and they fail differently.

And there is a fourth, asked less often and worth more: we raised CL; why did bandwidth not drop? That one separates people who know the number from people who know what kind of quantity it is.

2. The Conversion the Question Requires

CURRICULUM-DERIVED from 10.2 §3, which owns the unit discipline: CL is a count of clock cycles, so it becomes a time only against a clock period, and the data rate is twice the clock rate, so a latency in cycles and a burst in beats are not in the same unit.

   the three quantities, and the two conversions between them

     CL          cycles           a protocol offset
     t_CK        ns / cycle       a property of the OPERATING POINT
     CL * t_CK   ns               the time the question means

   and the factor of two that trips the second term:

     transfers per clock cycle = 2
     a burst of BL beats occupies BL/2 CLOCK CYCLES

So a CL quoted without its operating point is not a fact about anything — and that is the first sentence of a correct answer to question one, before any arithmetic.

3. Working the Questions

Q1 (establishing). What does CL relate?

Two protocol events — the read command's sampling event and the first beat of its return — counted in clock cycles under one configuration. Chapter 10.2 §11 owns the complete answer and this chapter does not restate it.

What matters here is how long you spend on it. This is a fifteen-second answer, and a candidate who spends two minutes on it has used the interview's time on the only part that was free. Answer it in one sentence and ask which of §1's three questions they actually want.

Q2 (applying). Part A: CL 16 at a 2400 MT/s data rate. Part B: CL 22 at 3200 MT/s. Which part has lower read latency?

DERIVED, all figures ILLUSTRATIVE, from §2's conversions:

   part A   2400 MT/s -> 1200 MHz clock -> t_CK = 0.833 ns
            CL = 16 cycles
            CL * t_CK = 16 * 0.833 = 13.33 ns

   part B   3200 MT/s -> 1600 MHz clock -> t_CK = 0.625 ns
            CL = 22 cycles
            CL * t_CK = 22 * 0.625 = 13.75 ns

   so part A's column latency is LOWER, by 0.42 ns -- about 3%.
   and part B's data rate is HIGHER by 3200/2400 = 33%.

The correct answer is that A wins the question as asked and B is usually the better part, and both halves have to be said.

Why the second half is the real answer. The 3% latency penalty buys 33% more bandwidth. Under load, bandwidth converts into latency — a faster channel drains the controller's queues sooner, and §4 shows the queueing term dominating everything else. So the part with the worse headline latency delivers better observed latency in exactly the conditions that matter.

This is the shape of a correct "it depends". The dependency is whether the system is loaded; the branches are lightly loaded, A is marginally faster and loaded, B is faster because queueing dominates; and the distinguishing observation is the controller's queue occupancy — not an opinion, a counter. A candidate who says "it depends on the workload" and stops has said nothing.

And the trap to name unprompted: 16 and 22 are not comparable numbers. Comparing CL across speed grades compares nothing — 10.2 §4 owns why the cycle count grew while the physical interval did not.

Q3 (the corner case). We reconfigured the part from CL 22 to CL 26. Why did sustained bandwidth barely change?

Because CL is a delay, not an occupancy — and this is the distinction the rest of the chapter is built on.

CURRICULUM-DERIVED from 10.2 §11, which states that nothing is busy for CL cycles: the interval is an offset between two events, not the duration of an operation that excludes other work.

   DERIVED from a stated model. ILLUSTRATIVE BL = 8, so a burst
   occupies BL/2 = 4 clock cycles on the data bus (§2).

   a pipeline DELAY shifts every return later by the same amount:

     CL=22   RD@0  RD@4  RD@8   -> data at 22, 26, 30
     CL=26   RD@0  RD@4  RD@8   -> data at 26, 30, 34

   the SPACING between returns is 4 cycles in both cases.
   the bus carries the same 4 cycles of data per command either way.

   sustained bandwidth is set by the SPACING, not by the OFFSET.
   the offset is paid ONCE, at the start of a stream.

So raising CL costs latency and costs essentially no bandwidth on a long stream, and the quantity that would have changed bandwidth is column spacing — 14.6's tCCD, which is the occupancy rule.

The follow-up that checks whether you actually understand it: when would raising CL hurt throughput? When the access pattern cannot keep enough reads in flight to cover the longer pipeline — a dependent chain, or a requester with too few outstanding transactions. Then the delay stops being hidden and starts being serialised, and the governing quantity is outstanding-transaction capacity rather than any DRAM parameter. Chapter 12.4 owns the measures that distinguish these — slot utilisation falls while command efficiency does not.

Q4 (removing an assumption). You measured the command-to-first-beat offset at the controller as 31 cycles. CL is configured to 22. Is this a bug?

Not necessarily, and answering "yes" is the trap. The measured offset is not CL, and three named terms account for the difference.

CURRICULUM-DERIVED from 10.5 §1, which owns the three timing domains, and 10.2 §9, which owns the one-cycle-late mechanisms:

So the first response is a question: where was that measured, and against which event? A command-to-beat offset measured at the controller is CL plus additive plus PHY, and it is supposed to exceed CL.

And the discriminator that settles it in one observation: does the offset change after retraining? If it does, the difference belongs to the measured part of the launch offset rather than the configured part — 19.3 owns that decomposition and 10.2 §11 owns the discriminator — and it is not a controller bug at all. If it is stable and exactly equal to the configured additive latency, the controller is scheduling against the wrong term, which is the most common real cause.

What not to do, and say so unprompted: do not tune the pipeline depth until the test passes. That compensates for an unmodelled term and breaks at the next speed grade.

Q5 (diagnosing). Isolated reads return correct data. Back-to-back reads return wrong data. Where do you start?

With the observation that the symptom is diagnostic before any evidence is gathered: something in the read path has a single-transaction assumption.

Chapter 10.5 §9 owns this investigation — its five candidate mechanisms and the discriminators that separate them — and a candidate should name the method rather than guess a mechanism. The one fact that splits the space fastest is whether the first read of each pair is correct: if it is, the second acceptance disturbed the first's record; if both are wrong, the association itself is broken.

What this chapter adds is the sixth mechanism, and it is the one §7 implements: the controller's data-bus reservation may model CL as a delay and forget the occupancy, so two returns are permitted to overlap on the bus. That mechanism is invisible in isolated traffic for the same reason as the other five, and §8 shows why it can stay invisible even under back-to-back traffic.

4. Where CL Actually Sits

Q. A CPU load missed all caches and took 140 ns. How much of that was CL?

DERIVED from a stated model, every term ILLUSTRATIVE, composed under 29.1 and 29.3, which own latency composition across an SoC. ILLUSTRATIVE t_CK 0.625 ns, CL 22, a row conflict, BL 8.

So CL is about a tenth of it, and the queueing term is nearly three times larger. DERIVED: 13.75 / 135.75 = 10.1%; 40.00 / 135.75 = 29.5%.

Two results follow, and the second is the senior one.

First, optimising CL is the wrong lever. Removing 4 cycles of CL removes 2.5 ns — under 2% of the load. Removing the row conflict removes 17.5 ns, and halving the queueing term removes 20 ns.

Second, the shares are load-dependent, so the table is an argument for measuring rather than a result to memorise. Drop the queueing term to an unloaded 5 ns and the total becomes 100.75 ns, in which CL is 13.6% — DERIVED. The two conditions rank the levers differently, which is exactly why 30.8 insists the bottleneck is identified before anything is optimised.

The honest qualification a strong candidate adds: these terms do not simply sum in a pipelined system — they overlap across concurrent requests, so this is a single-request critical path, not a throughput model. Saying that unprompted is worth more than the arithmetic.

5. Q6 — And the Write Side?

“You have described CL. What about CWL?” The expected answer is the same thing for writes, and it is wrong in the way that matters most.

CURRICULUM-DERIVED from 11.2, which owns the distinction and states it exactly: a read latency is a promise the device makes and a controller can mispredict. A write latency is a requirement the controller must meet. The device commits to sampling at a defined offset, and the controller must have data there.

A promise can be mispredicted. A deadline can only be missed.

What follows from the asymmetry, and each point is derivable rather than remembered:

Row two is the answer to the question. A mispredicted read latency is a controller bug that loses data the controller already had. A missed write deadline writes something into the array — and the device has no way to report that it sampled nothing meaningful. So the write side has a failure mode with no error signal, which is why 11.2 builds a pipeline whose job is to meet an offset rather than to predict one.

Row four is the one that separates levels. 30.3 §5 established that for a minimum separation the safe direction is the stricter one. A deadline has no stricter direction — early is as wrong as late, because the device samples at one offset and not over a window. Recognising that the asymmetry argument from the timing chapter does not transfer is the sign the model is understood rather than pattern-matched.

And the follow-up that ties the two together: what happens at the direction change?

A read's data is still arriving while a write's data must start being driven, and the bus is shared. DERIVED, ILLUSTRATIVE, from §2's conversions:

   a read committed at cycle 0, CL = 22, BL = 8 -> OCC = 4
     its beats occupy cycles 22..25

   a write whose data must be present at CWL after its command
   cannot be allowed to drive before cycle 26, and the bus needs
   time to change direction on top of that.

   so the controller's obligation is:
     command spacing such that  read occupancy  and
     write data delivery  DO NOT OVERLAP  --  and the
     turnaround penalty is the cost of the change itself.

Chapter 30.5 §7 owns the scheduling consequence — batching to amortise turnaround, and the second starvation problem it creates. What this chapter owns is why the two numbers cannot simply be compared: one is an offset the device produces and the other is an offset the controller must hit.

And the last thing worth volunteering: tWR is a third quantity again, and it is neither. CURRICULUM-DERIVED from 11.4, which owns an obligation belonging to the device — the recovery the array needs after a write before a precharge. Three write-side numbers, three different owners of the obligation, and a candidate who keeps them apart has answered the question the interviewer was building toward.

6. One Read, Three Domains

Two messages carry the whole chapter. The fifth is where CL starts, and it is a single hop out of nine. The seventh is the occupancy — a separate quantity from the delay, and the one §7's RTL gets wrong.

And the eighth is Q4's answer in one line: the PHY term is added below the controller boundary, so the offset the controller measures is supposed to exceed CL.

7. RTL Review — A Read Data-Bus Reservation

The intended contract:

1. A committed RD causes the device to drive the data bus beginning CL cycles later.
2. That read's burst occupies the data bus for OCC = BL/2 consecutive clock cycles — CURRICULUM-DERIVED from 10.2 §3's factor of two and 12.1.
3. bus_busy must be high on every cycle of that occupancy window.
4. can_issue must be low whenever committing a RD this cycle would cause its occupancy window to overlap an already-reserved window.
5. Reset clears every reservation.

// ---------------------------------------------------------------------
// read_bus_reservation -- INTENTIONALLY DEFECTIVE, for review (§7).
//
// CLASSIFICATION: synthesisable, ILLUSTRATIVE, and CONTAINS A BUG.
//
// WHAT IT IS MEANT TO DO: the five-clause contract above -- reserve
// the data-bus cycles a committed read will occupy, and refuse to
// admit a read whose window would overlap one already reserved.
//
// WHY IT EXISTS HERE: §3 Q3 establishes that CL is a DELAY and the
// burst is an OCCUPANCY, and 10.2 §11 states that nothing is "busy"
// for CL cycles. This block is what happens when that distinction is
// understood for the delay and forgotten for the occupancy.
//
// HOW TO RUN IT: commit reads separated by fewer than OCC cycles.
// EXPECTED RESULT under clauses 3 and 4: the second read is refused,
// or -- if forced -- bus_busy is high across BOTH full windows with
// no gap.
// EXPECTED TRACE: with CL=22, OCC=4, reads committed at 0 and 1,
// bus_busy must be high for 22..25 and 23..26, i.e. 22..26 with the
// overlap REPORTED, not silently permitted.
//
// SYNTHESIS: one shift register, DEPTH = CL + OCC bits. No memory.
// LIMITATIONS: models the READ direction only. Read-to-write
// turnaround (11.x) and the bus handover it needs are out of scope
// and are NOT what the bug is.
// ---------------------------------------------------------------------
module read_bus_reservation #(
  parameter int CL  = 22,      // ILLUSTRATIVE
  parameter int BL  = 8        // ILLUSTRATIVE
)(
  input  logic clk,
  input  logic rst_n,

  input  logic rd_commit,      // a READ committed THIS cycle
  output logic bus_busy,       // the data bus carries beats this cycle
  output logic can_issue       // committing a READ now would not overlap
);
  // OCC is the burst's data-bus occupancy in CLOCK cycles. Two
  // transfers per clock cycle, so BL beats span BL/2 cycles -- the
  // factor of two that 10.2 §3 owns.
  localparam int OCC   = BL / 2;
  localparam int DEPTH = CL + OCC;

  initial begin
    if (BL < 2 || (BL % 2) != 0)
      $fatal(1, "read_bus_reservation: BL must be even and >= 2 (got %0d)", BL);
    if (CL < 1) $fatal(1, "read_bus_reservation: CL must be >= 1");
  end

  // resv[i] == 1 means "the data bus is reserved i cycles from now".
  logic [DEPTH-1:0] resv;

  always_ff @(posedge clk) begin
    if (!rst_n) begin
      resv <= '0;                       // clause 5
    end else begin
      logic [DEPTH-1:0] nxt;
      nxt = resv >> 1;                  // one cycle closer
      if (rd_commit)
        nxt[CL] = 1'b1;                 // <-- THE DEFECT
      resv <= nxt;
    end
  end

  assign bus_busy  = resv[0];
  assign can_issue = !resv[CL];         // <-- AND ITS CONSEQUENCE
endmodule

Before reading on: which clause, what trace — and why does ordinary traffic never expose it?

8. The Defect, and Why It Survives

The violated clauses are 3 and 4, and the defect is a single reserved slot where a window was required.

nxt[CL] = 1'b1 reserves one cycle — the arrival cycle — when clause 2 says the burst occupies OCC. The delay was modelled and the occupancy was not. can_issue then inherits the error: testing resv[CL] asks is the arrival cycle free, not is the whole window free.

The trace:

   ILLUSTRATIVE CL = 22, BL = 8, so OCC = 4.

   RD committed at cycle 0   -> occupies 22, 23, 24, 25
   RD committed at cycle 1   -> occupies 23, 24, 25, 26

   contract clause 4 : the second read OVERLAPS and must be refused
   this code, at cycle 1 :
       resv[22] refers to cycle 23, which it never reserved
       -> can_issue is HIGH, the read is admitted
       -> two bursts drive the bus on cycles 23, 24, 25

   and clause 3 fails independently:
       bus_busy is high on 22, 23, 25, 26 only in the first read's
       own terms -- one cycle per read, never the window.

Now the harder question, and the one an interviewer is actually asking: why does this never fail in practice?

Because a second guard shadows it. CURRICULUM-DERIVED from 14.6: two column commands are separated by a minimum column spacing, and that spacing exists precisely so that one burst's beats finish before the next begins. With ILLUSTRATIVE BL 8, the shorter spacing is 4 clock cycles — equal to OCC — so a controller that respects tCCD can never present the colliding case at all.

Which produces the senior observation this section exists for:

A guard that is always shadowed by another guard is not a working guard. It is an untested one.

And the three ways the shadow lifts:

So the fix is two lines, and the finding is larger than the fix.

      // CORRECTED. Reserve the WINDOW, not the arrival cycle: the
      // burst occupies OCC consecutive clock cycles starting at CL.
      // Clause 3 then holds on every cycle of it.
      if (rd_commit)
        nxt[CL +: OCC] = {OCC{1'b1}};
      ...
  // CORRECTED. Overlap means ANY cycle of the prospective window is
  // already reserved -- clause 4 is about the window, not the arrival.
  assign can_issue = ~(|resv[CL +: OCC]);

And the review comment worth more than either line: this guard was never exercised, because tCCD made the case unreachable. Cover it explicitly, or the corrected version is as untested as the defective one — §8.

9. SVA Review — Proving the Offset Versus Proving No Collision

A property offered as proof that the reservation logic is correct:

  // Offered as "proves the data arrives CL cycles after the command".
  property p_data_arrives_after_cl;
    @(posedge clk) disable iff (!rst_n)
      rd_commit |-> ##CL bus_busy;
  endproperty
  assert property (p_data_arrives_after_cl)
    else $error("no bus activity CL cycles after a read commit");

Q. This property passes on the defective code in §7. What does it actually prove, and what does the prose claim?

It proves the delay and says nothing about the occupancy. ##CL bus_busy checks one cycle — the arrival cycle — which is exactly the one cycle the defective code reserves correctly. The property and the bug have the same blind spot, which is not a coincidence: both were written from the same incomplete model.

This is the general pattern, and it is 30.9's subject in miniature: a property written from the same mental model as the design cannot detect that the model is wrong. It is not weak verification of a correct idea; it is correct verification of the wrong idea.

What actually covers the contract:

  // Clause 3 -- the WINDOW, not the arrival cycle. The consecutive
  // repetition is the whole point: [*OCC] is what "occupancy" means
  // in a property, and its absence above is what the bug shares.
  property p_occupancy_window;
    @(posedge clk) disable iff (!rst_n)
      rd_commit |-> ##CL bus_busy[*OCC];
  endproperty
  assert property (p_occupancy_window)
    else $error("data bus not held for the full burst occupancy");

  // Clause 4 -- overlap must be REFUSED, not silently permitted.
  property p_no_overlapping_admission;
    @(posedge clk) disable iff (!rst_n)
      (rd_commit && $past(rd_commit, 1)) |-> $past(can_issue, 1);
  endproperty
  assert property (p_no_overlapping_admission)
    else $error("a read was admitted whose window overlaps another");

  // And the cover WITHOUT WHICH BOTH ASSERTIONS ARE VACUOUS HERE.
  // §7: tCCD shadows this guard, so an environment that respects
  // column spacing never reaches the case. If this cover stays at
  // zero, the guard is untested and the assertions above proved
  // nothing about it.
  cover property (@(posedge clk) disable iff (!rst_n)
                  rd_commit ##[1:OCC-1] rd_commit);

  // The antecedent of the clause-4 property, published separately --
  // because a zero here and a zero above have different causes.
  cover property (@(posedge clk) disable iff (!rst_n)
                  rd_commit ##1 rd_commit);

The cover is the load-bearing item. CURRICULUM-DERIVED from §7's shadow argument: in an environment that respects tCCD, p_no_overlapping_admission cannot fail, so a green result means the case never occurred. Reporting that property as passing, without its cover, is reporting a vacuous proof as evidence.

Follow-up an interviewer should ask: so should the environment violate tCCD to reach it? Not in the system-level environment — that would inject an illegal stimulus and invalidate everything else. At the block level, yes: this module's contract is about windows, not about column spacing, so its unit environment should present overlapping commits and check the refusal. Naming that boundary is the answer; saying "add a cover" is not.

10. What Would You Measure?

Q. You are told memory latency is too high. What do you instrument, and in what order?

Row one is first for a reason. §4 showed the queueing term dominating under load and shrinking to a tenth of itself when unloaded. Until you know which regime you are in, every other measurement is being interpreted against the wrong budget — and the ordering, not the list, is what the question is testing.

Row four is the one candidates miss. High slot utilisation with poor observed latency means the delay is being hidden and the channel is the limit; low slot utilisation with poor latency means the delay is being serialised, and the fix is at the requester, not in the memory. Two opposite conclusions from one counter.

11. Common Wrong Answers

“CL 16 is faster than CL 22.” §2, §3 Q2. Cycle counts at different clock periods are not comparable; convert first, and the gap is about 3% rather than 27%.

“Lower CL is better.” §3 Q2. Only at a fixed operating point and a fixed metric. A 3% column-latency penalty that buys 33% bandwidth is usually the better part under load.

“CL is memory latency.” §4. About a tenth of a loaded read, and less than the queueing term by a factor of three.

“Raising CL reduces bandwidth.” §3 Q3. CL is a delay; sustained bandwidth is set by the occupancy and the spacing. The exception is a requester with too few outstanding transactions to cover the pipeline — say the exception too.

“The controller sees an offset larger than CL, so the PHY is broken.” §3 Q4. It is supposed to exceed CL — additive latency plus the PHY's return contribution. Establish the domain before declaring a bug.

“I'll increase the pipeline depth until the data lines up.” §3 Q4. That compensates for an unmodelled term and breaks at the next speed grade.

“##CL bus_busy proves the read data timing.” §9. It proves one cycle — the same one cycle the defective design reserves. A property built from the design's own model cannot falsify that model.

“The overlap assertion passes, so overlaps are handled.” §9. tCCD makes the case unreachable, so it passed vacuously. Without its cover at a non-zero count, a green result is not evidence.

“CWL is the same thing for writes.” §5. CL is a promise the device makes; CWL is a deadline the controller must meet — 11.2. A promise can be mispredicted; a deadline can only be missed.

“For writes, err on the late side to be safe.” §5. A deadline is two-sided: the device samples at one offset, so early is as wrong as late. 30.3 §5's asymmetry argument does not transfer.

“A missed write deadline shows up as an error.” §5. It writes something into the array and the device has no way to report that it sampled nothing meaningful.

“tWR is part of CWL.” §5. It is a third quantity — an obligation belonging to the device after the write completes — 11.4.

“CL cycles is how long the device is busy.” §3 Q3, and 10.2 §11 owns the correction: it is an offset between two events, not a duration during which anything is occupied.

“The numbers in that budget are the real ones.” §4. Every term there is ILLUSTRATIVE, and the point of the table is that the shares move with load — the unloaded case reranks the levers.

“CL for DDR5-6400 is …” Do not. Latency settings are per-device, per-speed-bin and per-mode-register configuration, and a remembered value is more likely wrong than useful. “Symbolically CL; the value comes from the part's datasheet and the configured operating point” is the stronger answer — and it is stronger precisely because §3 Q2 shows the arithmetic matters and the constant does not.

12. Self-Check

1. Convert CL 20 at a 3200 MT/s data rate to nanoseconds, showing both steps. Then state the one fact about the part you still do not know that keeps this from being a latency claim.

2. Using §4's model, recompute CL's share if the access were a row hit rather than a conflict. State which term disappears and by how much the share moves.

3. Explain in two sentences why raising CL costs latency but not sustained bandwidth, naming the quantity that would cost bandwidth.

4. Give the access pattern under which the answer to question 3 reverses, and the counter that would show it.

5. State the promise-versus-deadline distinction in one sentence, then give the failure mode a missed write deadline produces and say why no error signal reports it.

6. Explain why 30.3 §5's "when unsure, take the longer reading" is correct for tRCD and wrong for CWL.

7. Find the defect in §7 without reading §8. Then answer the harder question: name the rule that hides it, and one configuration change that lifts the shadow.

8. Explain why ##CL bus_busy passes on the defective design, and write the property that does not.

9. A colleague reports that p_no_overlapping_admission passes in the system-level regression. State what you would ask for before accepting that as evidence, and why the block-level environment may legitimately do something the system-level one must not.

13. Where This Goes

CL is a cycle count, a latency, and one term. Convert before comparing, because cycle counts at different clock periods are not comparable; measure before budgeting, because CL is about a tenth of a loaded read and the queueing term is three times larger; and separate delay from occupancy, because the first sets latency and only the second sets bandwidth.

Three results carry forward. A correct "it depends" names the dependency, both branches and the counter that distinguishes them — §3 Q2 is the template. A guard that another rule always shadows is untested, not working. And a property written from the design's own mental model cannot detect that the model is wrong — the pattern 30.9 turns into a method.

Chapter 30.5 opens the block that has been named in every chapter so far and never designed. You will be asked to whiteboard a memory-controller scheduler, and the failure mode is not missing a feature — it is collapsing four distinct things into one. A request is not a candidate, a candidate is not a grant, and a grant is not a committed command, and the interview is won by answering which requests are legal before which one should issue.