ZQ Calibration (ZQCS / ZQCL)

This module has covered commands that change row state, commands that move data, a command that performs maintenance, and a command that changes how later commands are interpreted. All of them have one thing in common: their effect is digitally observable.

A row is open or closed. Data is present or absent. Configuration holds a value you can read back. A controller can, in principle, check that any of those happened.

ZQ calibration cannot be checked. Its result is an impedance — an analog quantity established by a process inside the device, which the controller cannot compute, cannot measure from the digital side, and must simply trust was done.

So the chapter's question is:

What does a command require when its result is analog and unverifiable — and what does that mean for a controller and for verification?

And it closes an arc. Chapter 6.1 established that dedicated pins give way to encodings as generations progress. Verified: in DDR5, ZQ calibration stopped being a dedicated command and became an operand of a general-purpose one. The same economics, one level up.

1. What ZQ Calibration Requests

Semantically, the command says: calibrate your output driver and termination impedance against the external reference.

It carries no bank, no row, no column, and no data. In the all-device sense it carries almost no operand at all — which makes it the most operand-free command in the module, even more so than refresh.

And what it changes is not state in any sense this module has used. No row opens. No bank closes. No register holds a value the controller wrote. What changes is an analog property of the device's output circuitry.

Chapter 4.4 §1 established the mechanism and it is worth one sentence of recall: the die contributes adjustability and the external precision resistor contributes accuracy, and the calibration engine tunes the on-die impedance to a defined ratio against that reference. The reference's value is not the termination value — a distinction Chapter 6.7 §8 flagged as a common and consequential confusion.

2. Two Forms, Two Purposes

Verified published characteristics:

ZQ Calibration Long (ZQCL) is issued during the power-up and initialisation sequence, and after reset conditions. It requires 512 clocks to complete.

ZQ Calibration Short (ZQCS) is used to track and periodically compensate minor variations in voltage and temperature during normal operation. It requires 64 clocks, and one ZQCS can correct a minimum of 0.5 percent impedance error.

3. The Result Is Not Observable

Here is what makes this command structurally unique, and it is the chapter's central point.

Every other command in this module has a digitally checkable effect:

   ACT      -> a bank is open        checkable
   PRE      -> a bank is closed      checkable
   RD / WR  -> data moved            checkable
   REF      -> rows refreshed        not directly, but the DEVICE counts
   MRS      -> a register holds a value   checkable (readable in DDR5)

   ZQ CAL   -> an impedance is correct    NOT CHECKABLE FROM THE DIGITAL SIDE

What a controller can observe is narrow and worth being precise about. It can observe that the command was accepted, and that the device was occupied for the expected interval. Neither says anything about the impedance.

So what does a controller actually do? It issues the command at the required times, waits the required interval, and proceeds on the assumption that it worked. That is not sloppiness — there is no digital mechanism by which it could do better.

4. RTL — Issuing a Command You Cannot Check

Engineering problem

Accept a calibration request of either form, check its precondition, occupy the device for the appropriate interval, and block accesses during it.

And expose no result — because there is none to expose, and the absence is the design.

Classification

SYNTHESIZABLE RTL — an educational protocol model.

What it represents: the two calibration forms with their different durations, the precondition, device occupancy, and access blocking.

What it does not represent — and the first item is the chapter's point:

It has no result output. Not a tied-off one — none at all. There is no digital result to report, and inventing a cal_ok signal would be a fiction that invites a checker to believe the outcome had been verified. The absence is deliberate and is the most important thing about this block.

Also absent: the calibration algorithm, the impedance, the external reference resistor, the tuning engine, every analog quantity, and ODT itself — this block starts a process and does not model what the process does. Bank state is taken as an input, not stored (Chapter 5.2 owns it).

The duration parameters default to the verified published figures — 512 and 64 clocks — and are attributed as such. They are published characteristics of these commands, not Modules 13/14 timing parameters, and they are parameters here because they are device- and generation-specific.

Interface contract

zq_req with zq_long selects the form. bank_open_in comes from Chapter 5.2. Acceptance, refusal reason, occupancy and access blocking come out. Nothing about the result comes out.

State

The occupancy countdown and a record of which form is running.

Combinational behaviour

The precondition check and access blocking.

Sequential behaviour

The countdown.

How to simulate

vlog zq_cal_ctrl.sv tb_zq_cal_ctrl.sv then vsim -c tb_zq_cal_ctrl -do "run -all".

Expected output

A long calibration with banks idle is accepted and occupies the device for ZQCL_EVENTS; a short one for ZQCS_EVENTS. Accesses during occupancy are blocked. No output reports whether the impedance is correct, because none can.

// ─────────────────────────────────────────────────────────────────────────
// ZQ CALIBRATION CONTROL.
// Classification: SYNTHESIZABLE RTL -- an educational PROTOCOL model.
//
// THIS BLOCK HAS NO RESULT OUTPUT, AND THAT IS THE POINT.
//
// Every other command in Module 7 has a digitally observable effect: a
// bank's state, data that moved, a register value. ZQ calibration produces
// an IMPEDANCE -- an analog property the controller cannot compute, cannot
// measure from the digital side, and must trust was established.
//
// Inventing a `cal_ok` signal would be a FICTION, and a damaging one: it
// would invite a checker to believe the outcome had been verified when no
// digital simulation can establish it. The absence of a result output is
// deliberate.
//
// WHAT DIGITAL VERIFICATION CAN ESTABLISH: that the command was issued at
// the required points, that its precondition was met, that the device was
// left alone for the required interval, and that the SHORT form is issued
// PERIODICALLY. All real and worth checking.
// WHAT IT CANNOT: that the impedance is correct. That is analog and
// mixed-signal simulation, characterisation and measurement (Module 22).
//
// VERIFIED PUBLISHED FIGURES used as the duration defaults:
//   ZQCL -- issued during power-up/initialisation and after reset;
//           requires 512 clocks.
//   ZQCS -- tracks and periodically compensates minor voltage and
//           temperature variation during normal operation; requires 64
//           clocks, and one ZQCS corrects a minimum of 0.5% impedance
//           error.
// These are published CHARACTERISTICS OF THESE COMMANDS, not Modules
// 13/14 timing parameters. They are parameters here because they are
// device- and generation-specific.
//
// ALSO NOT MODELLED: the calibration algorithm, the impedance, the
// external reference resistor, the tuning engine, every analog quantity,
// and ODT itself (Chapter 6.7). Bank state is an input, not stored
// (Chapter 5.2 owns it).
//
// GENERATION: ZQCL/ZQCS are dedicated commands in DDR3 and DDR4. DDR5
// folds ZQ calibration under a Multi-Purpose Command with operands
// selecting the task -- see Section 5.
// ─────────────────────────────────────────────────────────────────────────
module zq_cal_ctrl #(
  parameter int ZQCL_EVENTS = 512,
  parameter int ZQCS_EVENTS = 64,
  parameter int NUM_BANKS   = 16,
  parameter int OCC_W = (ZQCL_EVENTS <= 1) ? 1 : $clog2(ZQCL_EVENTS + 1)
) (
  input  logic                   clk,
  input  logic                   rst_n,

  input  logic                   zq_req,
  // 1 = long form (initialisation / after reset).
  // 0 = short form (periodic drift compensation).
  input  logic                   zq_long,

  // Bank state from Chapter 5.2's table. Calibration changes a
  // device-wide analog property, so like MRS and refresh it needs a
  // device-wide quiescent state.
  input  logic [NUM_BANKS-1:0]   bank_open_in,

  // An access the controller would like to issue, so occupancy can be
  // shown to block it.
  input  logic                   access_req,

  output logic                   zq_accepted,
  // 0 none, 1 banks not idle, 2 calibration already in progress.
  output logic [1:0]             zq_reject_reason,
  output logic                   zq_rejected,

  output logic                   device_busy,
  output logic [OCC_W-1:0]       busy_countdown,
  // The occupancy interval elapsed. NOTE THE NAME: the process FINISHED.
  // It does not say the process SUCCEEDED, because nothing digital can.
  output logic                   cal_interval_done,
  output logic                   access_blocked

  // ── DELIBERATELY ABSENT: any output describing the resulting impedance,
  //    its accuracy, or whether calibration "worked". See the header.
);

  // ── COMPILE-TIME legality.
  if (NUM_BANKS < 1) begin : g_nb
    initial $fatal(1, "zq_cal_ctrl: NUM_BANKS must be >= 1");
  end
  if (ZQCS_EVENTS < 1 || ZQCL_EVENTS < 1) begin : g_ev
    initial $fatal(1, "zq_cal_ctrl: calibration durations must be >= 1");
  end
  // The long form searches for a value from a cold start; the short form
  // nudges an existing one. A long form no longer than a short one would
  // invert that relationship, so it is rejected rather than simulated --
  // every conclusion from such a run would be about a device that cannot
  // exist.
  if (ZQCL_EVENTS < ZQCS_EVENTS) begin : g_order
    initial $fatal(1, "zq_cal_ctrl: ZQCL_EVENTS must be >= ZQCS_EVENTS");
  end

  localparam logic [1:0] RJ_NONE     = 2'd0;
  localparam logic [1:0] RJ_NOT_IDLE = 2'd1;
  localparam logic [1:0] RJ_BUSY     = 2'd2;

  logic all_idle;
  assign all_idle = (bank_open_in == '0);

  always_comb begin
    zq_accepted      = 1'b0;
    zq_reject_reason = RJ_NONE;

    if (zq_req) begin
      if (device_busy) begin
        // A calibration while one is running. Reported rather than
        // absorbed: the controller has lost track of occupancy, and that
        // is worth knowing before the next command depends on the same
        // wrong belief.
        zq_reject_reason = RJ_BUSY;
      end else if (!all_idle) begin
        // Chapter 7.1's question three: the encoding is fine, the
        // semantics are fine, and the state forbids it.
        zq_reject_reason = RJ_NOT_IDLE;
      end else begin
        zq_accepted = 1'b1;
      end
    end
  end

  assign zq_rejected    = zq_req && !zq_accepted;
  assign device_busy    = (busy_countdown != '0);
  assign access_blocked = access_req && device_busy;

  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      busy_countdown    <= '0;
      cal_interval_done <= 1'b0;
    end else begin
      cal_interval_done <= 1'b0;

      if (zq_accepted) begin
        busy_countdown <= zq_long ? OCC_W'(ZQCL_EVENTS)
                                  : OCC_W'(ZQCS_EVENTS);
      end else if (busy_countdown != '0) begin
        busy_countdown <= busy_countdown - OCC_W'(1);
        if (busy_countdown == OCC_W'(1)) begin
          // The INTERVAL elapsed. Deliberately not called `cal_done` or
          // `cal_ok`: the only claim this signal makes is that time
          // passed, which is the only claim available.
          cal_interval_done <= 1'b1;
        end
      end
    end
  end

endmodule

Cycle-by-cycle example

Scaled-down educational durations — ZQCL_EVENTS = 6, ZQCS_EVENTS = 2 — so a trace fits. The real published figures are 512 and 64 clocks, and the ratio here preserves the relationship rather than the magnitudes:

Cycle 7 is the honest one. cal_interval_done asserts, and that is the strongest claim the block can make: the interval elapsed. It does not say the impedance is right, because nothing digital can.

Cycle 3 is a refusal worth having. A calibration requested while one is running means the controller has lost track of occupancy — and a controller that then assumes the second one ran will believe calibration is fresher than it is.

Waveform expectation

§6. Watch the two forms produce different occupancy lengths, and no result signal anywhere.

Synthesis implication

One counter wide enough for the long duration, a comparison tree over the bank vector, and a few gates. With the real 512-clock figure the counter is 10 bits. Negligible — and note that the expensive part of calibration is entirely inside the device's analog circuitry, which is why this block is so small relative to what it starts.

Corner cases

ZQCL_EVENTS < ZQCS_EVENTS does not elaborate, because it inverts the search-versus-nudge relationship §2 established and every conclusion from such a run would concern a device that cannot exist. A request while busy is refused with its own reason rather than queued. Banks not idle refuses. OCC_W is sized from the long duration so both forms fit one counter. Reset clears occupancy — which is correct and has a real consequence: a reset during calibration abandons it, and Chapter 6.8 §3 established that a released reset is not a configured device, so a fresh ZQCL is required.

Debugging clues

If short calibrations occupy the device for the long duration, the zq_long selection is inverted or the countdown loads unconditionally from ZQCL_EVENTS. If accesses are not blocked during calibration, device_busy is being derived from zq_accepted rather than from the countdown — making occupancy one cycle regardless of the parameter. If a controller believes calibration is current when it is not, check whether refused calibrations are being detected: zq_rejected is the only signal that distinguishes "ran" from "was refused", and nothing about the impedance will tell you.

Limitations

No result, by design — the header says why at length. No algorithm, no impedance, no reference resistor, no analog quantity. No periodic scheduling: this block accepts a request and does not decide when one is due, which is a controller policy question and — like refresh scheduling — belongs to Module 17. No multi-rank serialisation. No ODT interaction. And the durations are device- and generation-specific, which is why they are parameters.

5. DDR5 Stopped Making It a Command

Verified: in DDR3 and DDR4, ZQ calibration is invoked by dedicated commands. DDR5 folds it under a Multi-Purpose Command, where the controller issues the general command with operands that select the calibration task.

This is the module's closing argument, and it is worth setting out carefully because it completes a pattern that began two modules ago.

Chapter 6.1 opened Module 6 with a thesis: as rates rise, dedicated control pins are progressively replaced by encoding on a shared bus, because encoding is cheaper than pins. Module 6 then watched it happen three times — CKE, ODT, and the RAS#/CAS#/WE# trio.

Module 6 also derived the criterion. Chapter 6.8 §1 turned it into a test: a function that must work when the command path does not needs a wire; everything else becomes an encoding. And Chapter 6.2 §6 added the frequency condition: functions whose state changes infrequently relative to the command rate can afford a command slot.

ZQ calibration extends the pattern one level further. It never needed a pin. But it did have a dedicated command — an entry in the command space, consuming an encoding — and DDR5 took that away too:

   Module 6:   dedicated PIN        ->  encoding on a shared bus
   Module 7:   dedicated COMMAND    ->  operand of a general command

6. Occupancy Without a Result

The most important thing about this trace is a signal that is not in it. There is no cal_ok, no impedance_valid, no result of any kind. interval_done at cycle 7 says only that the time elapsed — which is the strongest claim available.

Cycle 0's refusal and cycle 3's refusal have different reasons and the same consequence: calibration did not happen. A controller that does not check zq_rejected will believe its impedance is freshly calibrated when it is not — and, per §3, nothing about the impedance will ever tell it otherwise. The only evidence is the refusal it ignored.

The two occupancy phases show the form difference. Six events and two — preserving the published 8:1 ratio rather than the magnitudes, since the verified figures of 512 and 64 clocks do not fit a ten-cycle trace.

Representative, scaled educational cycles. The real durations are in §2 and are device- and generation-specific.

7. Three Assertions Worth Writing

// VERIFICATION-ONLY, inside zq_cal_ctrl.
//
// NOTE WHAT IS ABSENT FROM THIS LIST: any property about the resulting
// impedance. There is nothing to assert -- the result is analog and no
// digital simulation represents it. These properties verify the PROTOCOL
// AROUND the command, which is real and worth verifying, and they must not
// be mistaken for coverage of the outcome.

// P1 -- THE PRECONDITION. Calibration is never accepted while any bank is
// open. A reduction over state, like refresh's and MRS's: a device-wide
// change needs a device-wide quiescent state.
property p_cal_needs_all_idle;
  @(posedge clk) disable iff (!rst_n)
    zq_accepted |-> (bank_open_in == '0);
endproperty
assert property (p_cal_needs_all_idle);

// P2 -- the two forms occupy the device for their own durations. The
// distinction is not cosmetic: a short form running for the long duration
// would stall traffic eightfold longer than necessary, and a long form
// running for the short duration would leave the impedance unestablished
// with nothing reporting it.
property p_long_form_duration;
  @(posedge clk) disable iff (!rst_n)
    (zq_accepted && zq_long) |=> (busy_countdown == OCC_W'(ZQCL_EVENTS));
endproperty
assert property (p_long_form_duration);

property p_short_form_duration;
  @(posedge clk) disable iff (!rst_n)
    (zq_accepted && !zq_long) |=> (busy_countdown == OCC_W'(ZQCS_EVENTS));
endproperty
assert property (p_short_form_duration);

// P3 -- OCCUPANCY IS RESPECTED. The device must be left alone for the
// whole interval. This is the property that actually matters for
// correctness of the outcome, indirectly: a calibration interrupted by
// traffic may not establish a valid impedance, and nothing would report it.
property p_busy_blocks_access;
  @(posedge clk) disable iff (!rst_n)
    (access_req && device_busy) |-> access_blocked;
endproperty
assert property (p_busy_blocks_access);

property p_no_cal_while_busy;
  @(posedge clk) disable iff (!rst_n)
    device_busy |-> !zq_accepted;
endproperty
assert property (p_no_cal_while_busy);

// P4 -- completion reports only that the interval elapsed. Asserted
// against the countdown rather than against any notion of success,
// because success is not representable here.
property p_done_means_interval_elapsed;
  @(posedge clk) disable iff (!rst_n)
    cal_interval_done |-> ($past(busy_countdown) == OCC_W'(1));
endproperty
assert property (p_done_means_interval_elapsed);

P3 is the property that matters most, and for an indirect reason worth spelling out. None of these assertions can check the impedance — but a calibration interrupted by traffic may fail to establish a valid one, and nothing would report that. So enforcing occupancy is the closest digital verification gets to protecting the outcome. It is a protocol property standing in for an analog one, and recognising when that is the best available is a real skill.

And the absence is deliberate. There is no p_calibration_succeeded, because such a property cannot exist. A property list that is complete about the protocol and silent about the outcome is the honest shape here — and a reviewer should notice the silence and ask where the outcome is verified, rather than assuming it is covered.

What none of them prove. Nothing about the impedance — not its value, not its accuracy, not whether the external reference is the right one, and Chapter 6.7 §8 noted a wrong reference resistor is a particularly nasty fault because everything still works. Nothing about whether calibration is being issued often enough, which is a scheduling property spanning many commands. And nothing about whether ODT subsequently uses the calibrated value correctly.

8. Debugging — Marginal Signalling and Calibration Looks Fine

Symptom. An interface is functional and electrically marginal — clean at reduced rate, occasional errors at full rate, no functional failure. Calibration commands appear in the trace at the expected points.

"Calibration appears in the trace" is precisely the trap this chapter is about, because a command appearing is not evidence that it worked — and §3 established that no digital evidence of success exists.

Mechanism 1 — the calibration was refused and nobody checked. Inspect: whether each calibration command was accepted, given bank state and occupancy at the time. Expected evidence: commands issued with banks open, or while a previous calibration was still running. Discriminator: check acceptance, not issuance. This is first because it is a trace comparison costing nothing, and because it is the one failure mode that is digitally visible — the refusal. A controller that does not check zq_rejected has thrown away the only evidence available.

Mechanism 2 — the periodic short calibration is not being issued. Inspect: the interval between short calibrations over a long run. Expected evidence: an initial long calibration and no periodic ones, or a periodic schedule that stopped. Discriminator: does marginality worsen over time or with temperature? Verified: the short form exists to track voltage and temperature variation, so an interface calibrated once at power-up and never since will drift — and Chapter 4.4 §11's third mechanism is the same failure for training.

Mechanism 3 — calibration was interrupted. Inspect: whether accesses or other commands occurred during the occupancy interval. Expected evidence: traffic inside the window. Discriminator: check the interval, not just the command. §7's P3 — and the consequence is a possibly-invalid impedance with nothing reporting it, which is why enforcing occupancy is worth asserting.

Mechanism 4 — the external reference is wrong. Inspect: the reference resistor's value and tolerance against the device's requirement. Expected evidence: calibration completing normally and the realised impedance being wrong. Discriminator: measure, because nothing digital will tell you. Chapter 6.7 §8 flagged this: a wrong reference resistor mis-terminates the bus with no functional symptom, and Chapter 4.4 §8 noted the reference's value is not the termination value, which is where the confusion starts.

Mechanism 5 — not calibration: the ODT policy is wrong. Inspect: whether the accessed rank terminates during reads. Expected evidence: a driver terminating its own output. Discriminator: Chapter 6.7 §9's first mechanism — and it produces an identical symptom from a completely different cause. Calibration establishes what the termination is; ODT decides whether to apply it, and either can be wrong.

Discrimination, cheapest first. Check that each calibration was accepted rather than merely issued — the only digitally visible failure. Then check the periodic schedule over a long run. Then check for traffic inside occupancy intervals. Then read the ODT policy. Only then measure the reference and the impedance.

The reasoning lesson, and it is the module's closing one. A command appearing in a trace is evidence that it was issued, and nothing more. For every other command in this module, "did it work" has a digital answer — a bank is open, data moved, a register holds a value. For this one it does not, which means the diagnostic order inverts: you exhaust everything observable about the protocol first, because that is all you can get cheaply, and only then commission the analog measurement that can actually answer the question. Teams that skip to measurement waste the cheap evidence; teams that trust the trace never commission the measurement. Both failures come from not asking what the command's result is measured in.

9. Common Misconceptions

"Calibration is a one-time initialisation step." Wrong model: calibrate at power-up and you are done. Why it is tempting: the long form genuinely is an initialisation activity, and most configuration is one-time. Consequence: an interface that drifts. Verified: the short form exists to track minor variations in voltage and temperature during normal operation — so those variations are real and ongoing. An interface calibrated once becomes marginal as conditions move, which appears as intermittent failures correlated with temperature and load. Correct model: the long form establishes; the short form maintains. Chapter 4.4 §3's general property: calibrated and trained values are state that must be maintained, not settings that are configured. Prevention: ask what the value tracks. If it tracks temperature, it needs re-establishing as temperature moves.

"ZQCS is just a faster, less accurate ZQCL." Wrong model: the two differ in thoroughness along one axis. Why it is tempting: one is shorter and the names suggest short and long versions of one thing. Consequence: believing a short calibration could substitute for a long one at initialisation — which it cannot, because there is no value for it to adjust from. It also obscures why the durations differ by roughly eightfold rather than being a tunable trade. Correct model: ZQCL searches for a value from a cold start; ZQCS nudges an existing one. The verified minimum correction of 0.5 percent is the giveaway — a mechanism for small adjustments, not for establishing a value. Prevention: ask what the command starts from. From nothing, or from nearly right?

"If the calibration command was issued, calibration happened." Wrong model: issuance implies execution. Why it is tempting: it is true for most commands in most interfaces, and the command is the visible thing in a trace. Consequence: the failure §8's first mechanism describes. A calibration can be refused — banks not idle, or one already running — and a controller that does not check will believe its impedance is fresh. The refusal is the only digital evidence available, and ignoring it discards it entirely. Correct model: a command in a trace was issued. Whether it was accepted is a separate fact, and whether it succeeded is not digitally observable at all. Prevention: check acceptance. It is the only thing you can check.

"A green simulation covers calibration." Wrong model: functional verification establishes that calibration works. Why it is tempting: the regression exercises the command, the protocol checks pass, and nothing fails. Consequence: the analog verification never gets commissioned, because the team believes it is covered. The gap surfaces on silicon as marginality with no functional failure — the hardest class in the whole curriculum. Correct model: digital verification establishes the protocol: issued at the right points, precondition met, device left alone, issued periodically. The outcome is an impedance and is established by analog and mixed-signal simulation, characterisation and measurement (Module 22). Prevention: ask what the result is measured in. Cycles, bits or state — digital verification reaches it. Ohms, volts or picoseconds — it does not, and something else must.

10. Interview Reasoning

"What makes ZQ calibration different from every other DDR command?" Its result is not digitally observable. Every other command in the command set produces an effect you can check: a bank is open or closed, data moved, a register holds a value you can read back. ZQ calibration produces an impedance — an analog property of the device's output circuitry that the controller cannot compute, cannot measure from the digital side, and must simply trust was established. What the controller can observe is that the command was accepted and that the device was occupied for the expected interval, and neither says anything about the impedance. That is not a shortcoming of the controller; there is no digital mechanism by which it could do better.

"How do ZQCL and ZQCS differ, and why?" Not just in duration — in what they do. The long form is issued during power-up and initialisation and after reset, and it establishes the impedance from a cold start, where the die's value is whatever the process happened to give it. It has to search, which is why it takes 512 clocks. The short form tracks and compensates minor variations in voltage and temperature during normal operation; it is nudging a value that is already close, takes 64 clocks, and corrects a minimum of half a percent of impedance error. So the short form could not establish a value at all from nothing — it is not a less thorough long form, it is a different operation. The practical consequence is that the short form must be issued repeatedly and forever, because the conditions it tracks never stop drifting.

"How would you verify ZQ calibration?" By verifying the protocol around it rigorously and being explicit that the outcome is verified elsewhere. Digitally you can establish that the command is issued at the required points in initialisation, that its precondition was met — banks idle — that the device was left alone for the whole occupancy interval, and that the short form is issued periodically thereafter. The occupancy property matters most, indirectly: a calibration interrupted by traffic may fail to establish a valid impedance and nothing would report it, so enforcing occupancy is the closest digital verification gets to protecting the outcome. What you cannot write is a property asserting that calibration succeeded, because the result is in ohms and simulation has no representation of it. The general rule is to ask what a command's result is measured in — cycles, bits or state can be verified digitally; ohms, volts or picoseconds cannot.

"DDR5 removed ZQCL and ZQCS as dedicated commands. What replaced them and what does that tell you?" They were folded under a Multi-Purpose Command, where the controller issues the general command with operands selecting the calibration task. What it tells you is that the encoding-consolidation pattern that ran through the signals also runs through the commands. Module 6's thesis was that dedicated pins give way to encodings on a shared bus because encoding is cheaper than pins; this is the same economics one level up — a dedicated command occupies an encoding slot, which is also scarce, and a general command with operands trades one slot for many operations. The enabling condition is the same anti-correlation: these operations are never needed simultaneously, so they can share a slot. And the frequency criterion holds too — calibration happens at initialisation and then periodically, which is rare relative to the command rate, and a function needed occasionally can afford to be an operand while one needed every transfer cannot. That is why DQ and DQS will never be encoded away.

"An interface is electrically marginal and the trace shows calibration commands at the right points. Where do you look?" The first thing to recognise is that a command appearing in a trace means it was issued and nothing more. So I would check whether each calibration was actually accepted rather than refused — banks may not have been idle, or a previous calibration may still have been running — because the refusal is the only digitally visible failure mode and a controller that does not check it has discarded the only evidence available. Then check whether the periodic short calibration is happening at all over a long run, because the short form exists to track voltage and temperature drift and an interface calibrated once at power-up will become marginal as conditions move. Then check for traffic inside the occupancy interval, since an interrupted calibration may not establish a valid impedance with nothing reporting it. It is also worth checking the ODT policy, because calibration establishes what the termination is while ODT decides whether to apply it, and either being wrong produces an identical symptom. Measuring the reference resistor and the realised impedance comes last, because it is the expensive step — but it is also the only one that can actually answer the question.

11. Engineering Exercise

Verified published durations quoted in §2; scaled educational values in §6's trace.

1. A controller issues ZQCS once at initialisation and never again. What eventually happens, and what is the symptom? The impedance drifts as voltage and temperature move, because verified the short form exists to track exactly those variations. The symptom is marginality that worsens with temperature and time — clean at reduced rate, intermittent at full rate, no functional failure. It is also the wrong form for initialisation: there was no established value for it to adjust.

2. Could ZQCS substitute for ZQCL at power-up? No. The short form nudges an existing value; at power-up there is none — the impedance is whatever the process gave it. The published 0.5% minimum correction is the evidence: a mechanism for small adjustments cannot search a range.

3. §4's block has no result output. Argue for that rather than a cal_ok signal. A cal_ok would be a fiction, because no digital logic in the device or the controller can evaluate whether an impedance is correct. Worse, it would invite a checker to believe the outcome was verified — and a team that believes its regression covers calibration will not commission the analog work that actually does. The absence is the honest design.

4. A calibration is issued while a bank is open. What does the controller learn, and what does it learn if it ignores the refusal? It learns the calibration did not happen — zq_rejected. If it ignores the refusal it learns nothing at all, and will believe its impedance is freshly calibrated. Nothing about the impedance will ever correct that belief, which makes the refusal the only evidence in existence.

5. Using §5's rule, predict whether a hypothetical new DDR control function — one needed once per power-up — would get a pin, a command, or an operand. An operand. It is needed once per power-up, which is maximally infrequent relative to the command rate, and there is no reason it must work when the command path is unusable — initialisation already has RESET# and CK for that. Frequency and independence both point to an operand, and the rule predicts rather than merely describes.

6. §7 has no property asserting calibration succeeded. Is the property list incomplete? No — it is correctly shaped. The list is complete about the protocol and silent about the outcome, because the outcome is analog and unrepresentable. A reviewer should notice the silence and ask where the outcome is verified — the answer being analog and mixed-signal simulation, characterisation and measurement. Adding a fictional success property would make the list look complete and be worse.

12. Summary

ZQ calibration is the only command in this module whose result is not digitally observable. Every other command produces a checkable effect — a bank's state, data, a register value. This one produces an impedance, an analog property the controller cannot compute, cannot measure from the digital side, and must trust was established.

What a controller can observe is narrow: that the command was accepted, and that the device was occupied for the expected interval. Neither says anything about the impedance — and the refusal is therefore the only evidence of failure that exists.

Two forms with two purposes. Verified: the long form is issued at power-up, initialisation and after reset, requires 512 clocks, and establishes the value from a cold start. The short form tracks and compensates minor voltage and temperature variation during operation, requires 64 clocks, and corrects a minimum of 0.5 percent impedance error — it nudges a value that is already close. A search and a nudge are different operations, which is why the short form cannot substitute at initialisation.

And it must be maintained forever, because the conditions it tracks never stop drifting — Chapter 4.4 §3's general property that calibrated values are state to be maintained, not settings to be configured.

For verification the boundary is sharp. Digital verification establishes the protocol: issued at the right points, precondition met, device left alone for the whole interval, issued periodically. It cannot establish the outcome, and §7's property list is deliberately silent about it rather than fictional. The general rule: ask what the result is measured in. Cycles, bits or state are reachable; ohms, volts and picoseconds are not.

And DDR5 completes the module's arc. Verified: ZQ calibration stopped being a dedicated command and became an operand of a Multi-Purpose Command.

   Module 6:   dedicated PIN      ->  encoding on a shared bus
   Module 7:   dedicated COMMAND  ->  operand of a general command

Same economics, same anti-correlation condition, one level up. Which gives the complete rule: frequency and independence decide representation. A function needed at every event keeps a pin; one needed when the command path is unusable keeps a pin; one needed often keeps a command; one needed occasionally becomes an operand — and eventually will, in whichever generation next needs the slot.

13. What Comes Next

Module 7 established what a command is: a sampled encoding, qualified for a target, carrying operands whose meaning depends on the command, interpreted against device state — and it kept four questions apart throughout. Encoding and semantics and state legality are this module's; timing legality is not.

Module 8 — DDR Addressing takes the operands this module deliberately kept symbolic. Every chapter here carried a bank, a row or a column without saying how a physical address becomes those fields — and Chapter 7.2 §3 and Chapter 7.6 §2 both showed that which bits carry which field is decided per command. Module 8 owns the addressing system properly.

After that the deferrals resolve in order: Module 9 makes activate and precharge physically concrete, Modules 10 to 12 cover read, write and burst mechanics, and Modules 13 and 14 finally supply the fourth question — the timing legality this module has consistently declined to invent.

Return to Activate for the command model and the four questions, DDR3 for why calibration exists at all, ODT for the signal that applies the calibrated value, or CK / CK# for the thesis this chapter completes. The full path is on the DDR tutorials index.