CKE — Clock Enable

Chapter 6.1 established that CK defines the instant at which command inputs mean something. This chapter adds a prior question: is the device looking at all?

CKE — clock enable — answers it. When CKE is asserted the device samples its command inputs; when it is not, the device stops, and the command path effectively does not exist for it.

Two things make CKE worth a chapter rather than a table row.

It qualifies using its previous value, not its current one. That makes it a structurally different kind of signal from chip select, which qualifies the event it accompanies, and the difference has real consequences for how a controller must think about it.

And in DDR5 it does not exist as a pin. The function survives — devices still enter and leave low-power states — but it is carried by command encoding rather than by a dedicated wire. CKE is the module's first worked example of 6.1's thesis, and it makes the question concrete: if the function can be encoded, what was the pin ever buying?

1. Listening Is a State

A DRAM device with a running clock and an active command interface is spending energy continuously — receivers are biased, input buffers are active, the clock is being distributed internally. Much of that cost is incurred whether or not any command arrives.

Chapter 4.7 established the energy argument in full and built a power-state controller. This chapter is not about that trade. It is about the signalling mechanism that expresses it: how a controller tells a device to stop listening, and what "stopped listening" means precisely.

CKE deasserted means the device does not sample its command inputs. Not "ignores the commands it sees" — does not sample them. The distinction matters because it means the CA lines are free while CKE is low: the controller may drive anything on them, and no obligation from 6.1 §4 applies.

That is the same qualification idea as chip select, applied at a different granularity, and the contrast is worth holding:

The last column is the structural difference, and §2 is about why.

2. Qualification With History

The obvious design would be: sample CKE at the same instant as the command, and act on the command only if CKE is asserted. That is not how it works, and the reason is instructive.

CKE's state at the previous clock event determines whether this event's command is sampled.

Why history rather than the current value? Because "stop sampling commands" is not an instantaneous property of a device. Deasserting CKE begins a transition into a state where input receivers and internal clocking are wound down — a physical change that takes effect over time. A device cannot both be told to stop listening and be expected to correctly interpret the instruction that told it, at the same instant, using the receivers it is about to disable.

So the contract is offset by one event: CKE is evaluated at one clock event to determine behaviour at the next. That makes the signal a state declaration rather than a per-event qualifier — the controller is not gating a command, it is announcing an operating condition that will hold.

The two dashed returns are not messages the device sends. There is no acknowledgement on a DDR interface — Chapter 4.1 §4 established that the interface is a counted contract with no per-event handshake. They represent device state the controller must model, not observe, and that is precisely why a controller keeps a power-state model at all.

3. What CKE Gates, and What It Does Not

Deasserting CKE does not stop everything, and the exceptions are where the engineering is.

It does not stop refresh obligations. Chapter 2.3 established that DRAM loses its contents without refresh, and no power state changes that physics. A device in a low-power state either still has its refresh managed by the controller, or has been placed in a state where it refreshes itself — and CKE participates in selecting which. Module 15 owns refresh; the point here is that "stopped listening" never means "stopped needing refresh".

It does not by itself define which low-power state is entered. The state depends on what the device was doing when CKE was deasserted and on the command presented alongside the transition. CKE is the trigger, not the selector — a distinction that matters because a controller cannot reason about exit cost from CKE alone.

And it does not free the controller from its own obligations. The controller must still track per-bank state, and — critically — must know that some transitions require banks to be closed first. Chapter 5.2 §5's all-bank precharge exists partly for this: closing every bank before a device-wide state change, without spending a command per bank.

4. RTL — The Qualification Contract

Engineering problem

Model the qualification semantics precisely: commands are sampled based on CKE's previous value; commands presented while not listening are not seen; and re-asserting CKE does not make the device immediately usable.

The model must make the ignored case visible, because on real hardware it is invisible — a command issued to a sleeping device produces no error, no response, and no trace.

Classification

SYNTHESIZABLE RTL — an educational model of a signalling contract.

What it represents: the history-based qualification, the sampling suppression, and an exit interval as a configurable cost.

What it does not represent: any energy, voltage, current or physical wind-down; the internal circuitry CKE actually gates; which low-power state is entered; refresh behaviour in any state. EXIT_EVENTS is an educational parameter, not a JEDEC timing value — real exit intervals are per-device, per-state and per-condition, and belong to Modules 13 and 14 and the device specification. It is also not dram_power_state_ctrl from Chapter 4.7, which modelled the energy-versus-latency trade; this models the signal's qualification semantics.

Interface contract

cke is the clock enable input. cs_n, ca_in and sample_evt present commands as in 6.1. cmd_accepted with ca_out reports a sampled command; cmd_ignored reports one presented while the device was not listening. listening and exit_countdown expose the modelled device state.

State

cke_q — CKE captured at the previous sampling event, which is the qualification. An exit counter. And a powered_down flag.

Combinational behaviour

Qualification is cke_q && cke && (exit_countdown == 0) — previous value, current value, and exit complete.

Sequential behaviour

cke_q updates on sampling events only; the exit counter loads when CKE rises and counts down.

How to simulate

vlog cke_command_qualifier.sv tb_cke_command_qualifier.sv then vsim -c tb_cke_command_qualifier -do "run -all".

Expected result: commands issued while listening are accepted; commands issued during power-down or during the exit interval are reported ignored and produce no capture.

// ─────────────────────────────────────────────────────────────────────────
// CKE COMMAND QUALIFIER.
// Classification: SYNTHESIZABLE RTL -- educational model of a SIGNALLING
// CONTRACT.
//
// GENERATION SCOPE: DDR4 AND EARLIER. DDR5 has no dedicated CKE pin;
// power-down entry and exit are triggered by CS_n plus CA-bus command
// encoding. See Section 6.
//
// The point of the model is to make the IGNORED case visible. On real
// hardware, a command issued to a device that is not sampling produces no
// error, no response and no trace -- it simply does not happen, and the
// controller finds out later when state does not match its model.
//
// WHAT THIS DOES NOT MODEL: energy, voltage, current, the physical
// wind-down, which internal circuitry CKE gates, WHICH low-power state is
// entered, or refresh behaviour in any state. EXIT_EVENTS is an
// EDUCATIONAL parameter -- real exit intervals are per-device, per-state
// and per-condition (Modules 13/14 and the device specification).
//
// This is NOT dram_power_state_ctrl (Chapter 4.7), which modelled the
// ENERGY-VERSUS-LATENCY TRADE. This models the SIGNAL'S SEMANTICS.
// ─────────────────────────────────────────────────────────────────────────
module cke_command_qualifier #(
  parameter int CA_W = 24,
  // Sampling events after CKE is reasserted before commands are accepted.
  // EDUCATIONAL. Not a timing parameter.
  parameter int EXIT_EVENTS = 2,
  parameter int CNT_W = (EXIT_EVENTS <= 1) ? 1 : $clog2(EXIT_EVENTS + 1)
) (
  input  logic            clk,
  input  logic            rst_n,

  // Active high: asserted means "sample your command inputs".
  input  logic            cke,

  input  logic            cs_n,
  input  logic [CA_W-1:0] ca_in,
  input  logic            sample_evt,

  output logic            cmd_accepted,
  output logic [CA_W-1:0] ca_out,
  // A command was presented while the device was not sampling. On real
  // hardware there is NO such indication -- this output exists so the
  // failure is observable in simulation.
  output logic            cmd_ignored,

  output logic            listening,
  output logic            powered_down,
  output logic [CNT_W-1:0] exit_countdown
);

  // ── COMPILE-TIME legality.
  if (CA_W < 1) begin : g_ca
    initial $fatal(1, "cke_command_qualifier: CA_W must be >= 1");
  end
  if (EXIT_EVENTS < 0) begin : g_exit
    initial $fatal(1, "cke_command_qualifier: EXIT_EVENTS must be >= 0");
  end

  // ── CKE as captured at the PREVIOUS sampling event. This register IS the
  //    qualification semantics of Section 2: a device cannot be told to
  //    stop listening and simultaneously be expected to interpret the
  //    instruction using receivers it is about to disable, so the decision
  //    is offset by one event.
  logic cke_q;

  // ── The device is usable when it was listening at the previous event, is
  //    still being told to listen now, and any exit interval has elapsed.
  //    All three terms are load-bearing: dropping cke_q would make it a
  //    per-event qualifier like chip select, and dropping the countdown
  //    would model a device that wakes instantly.
  assign listening    = cke_q && cke && (exit_countdown == '0);
  assign powered_down = !cke_q;

  logic cmd_present;
  assign cmd_present = sample_evt && !cs_n;

  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      // Reset leaves the device NOT listening. A device coming out of
      // reset has not been told to sample anything yet, and Chapter 6.8
      // covers why assuming otherwise is a real integration bug.
      cke_q          <= 1'b0;
      ca_out         <= '0;
      cmd_accepted   <= 1'b0;
      cmd_ignored    <= 1'b0;
      exit_countdown <= '0;
    end else begin
      cmd_accepted <= 1'b0;
      cmd_ignored  <= 1'b0;

      if (sample_evt) begin
        // ── Capture CKE for the NEXT event's qualification. Evaluated only
        //    at sampling events, because CKE is defined relative to the
        //    clock's command-rate events -- not to arbitrary cycles.
        cke_q <= cke;

        // A rising CKE starts the exit interval. Detected against the
        // registered value so a single glitchy cycle cannot restart it
        // repeatedly.
        if (cke && !cke_q) begin
          exit_countdown <= CNT_W'(EXIT_EVENTS);
        end else if (exit_countdown != '0) begin
          exit_countdown <= exit_countdown - CNT_W'(1);
        end

        if (cmd_present) begin
          if (listening) begin
            ca_out       <= ca_in;
            cmd_accepted <= 1'b1;
          end else begin
            // REPORT, NEVER REPAIR -- and note this report has no hardware
            // counterpart. The whole hazard is that real silicon is silent
            // here.
            cmd_ignored <= 1'b1;
          end
        end
      end
    end
  end

endmodule

Cycle-by-cycle example

EXIT_EVENTS = 2:

Event 2 is the silent failure. The controller issued a well-formed command and the device did not see it. No error exists on real hardware — the controller discovers the problem later, when its bank-state model disagrees with the device, which Chapter 5.2 §4 showed can surface as wrong data with nothing reported.

Event 4 is the subtler one. CKE is asserted, cke_q is asserted, and the command is still ignored because the exit interval has not elapsed. A controller that models CKE as a simple gate gets this case wrong and will issue commands into a device that is awake but not yet usable.

Waveform expectation

§5. Watch that cmd_ignored asserts in two distinct situations — genuinely powered down, and awake-but-exiting — because conflating them is the most common modelling error.

Synthesis implication

One flip-flop for cke_q, a small counter, and a handful of gates. Trivial. A real controller contains the policy side of this — deciding when to deassert CKE and tracking when the device becomes usable again — while the device side is inside the DRAM and not RTL at all.

Corner cases

EXIT_EVENTS == 0 models a device usable immediately on reassertion, which is unrealistic and permitted so the parameter's effect is isolable — comparing 0 against 2 on identical stimulus is the most informative test of this block. CNT_W is guarded so EXIT_EVENTS of 0 or 1 yields a 1-bit counter rather than a zero-width field. CKE toggling between sampling events is not observed at all, which is deliberate: the signal is defined relative to command-rate events. Reset leaves the device not listening, which is correct and is the case an integration most often gets wrong.

Debugging clues

If commands are accepted immediately after CKE rises, the exit countdown is missing or is being decremented on every cycle rather than on sampling events. If commands are accepted while CKE is low, the qualification is using cke alone rather than cke_q && cke — which turns a state declaration into a per-event gate and loses the whole semantics. If cmd_ignored never fires in a system that is losing commands, check that the model is being driven with the attempted commands rather than with commands the controller already suppressed.

Limitations

No energy or physical behaviour. No distinction between low-power states. No refresh. No interaction with bank state — a real transition may require banks closed first, and this model neither checks nor enforces that. EXIT_EVENTS is a cycle count, not a duration. And the whole block is DDR4-and-earlier semantics; §6 explains why it does not describe DDR5.

5. Ignored Commands, in Cycles

cke_q lagging cke by one event is the whole of §2. At cycle 1 the controller has already deasserted CKE and the registered copy is still high; at cycle 2 it follows. The device's behaviour is governed by the lagging trace, not the leading one.

Two ignored commands, two different reasons. Cycle 2's 3C is lost because the device is genuinely not sampling. Cycle 5's 7E is lost even though CKE is high and cke_q is high — the exit interval has not elapsed. A controller model that treats CKE as a simple gate handles the first case and silently fails the second, and the second is the one that appears in real bring-up, because it only manifests when the controller is aggressive about power states.

Neither ignored command produces anything on real hardware. cmd_ignored is an observability output this model invents; silicon is silent.

Representative cycles. The two-event exit interval is chosen for legibility and corresponds to no specification value.

6. What DDR5 Did Instead

DDR5 removed the dedicated CKE pin. Power-down entry and exit are triggered by CS_n in combination with command encoding on the CA bus.

The reasoning is 6.1's thesis, and it is worth working through rather than accepting.

A pin is justified when its function cannot be expressed in the command stream. CKE's function can be: "enter a low-power state" and "leave it" are operations, and an interface that already carries operations can carry two more. So what was the pin buying?

Chiefly, it was buying availability when the command path is not usable — and that turns out to be a weaker argument than it appears. A device still has a clock and still has chip select; it does not need a dedicated wire to be told to wake, only a signalling path that works in the low-power state. Chapter 4.6 §3 noted that DDR5's design repeatedly converts a dedicated mechanism into an encoded one, and this is that pattern applied to power control.

What the change costs. The command path must remain minimally alive in low-power states so the exit encoding can be received — the device must keep monitoring chip select and enough of the CA bus to recognise the exit. So "not listening" becomes narrower in DDR5: a device is not sampling general commands but is still watching for a specific one.

What it buys. A pin, on every device, on every rank, on every module — and Chapter 3.2 §4 established pins are among the most expensive resources in the system. It also removes a signal from the set that must be routed to every device, which Chapter 4.4 §2 identified as the hardest signals on the board.

7. Two Assertions Worth Writing

// VERIFICATION-ONLY, inside cke_command_qualifier.

// P1 -- THE HISTORY PROPERTY, and the chapter's architectural claim.
// Acceptance requires CKE to have been asserted at the PREVIOUS sampling
// event, not merely now. A design that dropped cke_q would turn a state
// declaration into a per-event gate, and would pass every count- or
// value-based check while having the wrong semantics.
property p_requires_previous_cke;
  @(posedge clk) disable iff (!rst_n)
    cmd_accepted |-> $past(cke_q);
endproperty
assert property (p_requires_previous_cke);

// P2 -- a presented command is either accepted or reported ignored, never
// silently dropped by the MODEL. The hardware is silent; the model must
// not be, or it reproduces the hazard instead of exposing it.
property p_presented_is_resolved;
  @(posedge clk) disable iff (!rst_n)
    (sample_evt && !cs_n) |=> (cmd_accepted ^ cmd_ignored);
endproperty
assert property (p_presented_is_resolved);

// P3 -- nothing is accepted during the exit interval. Separated from P1
// deliberately: a device can satisfy P1 completely and still be unusable,
// which is exactly the case real controllers get wrong.
property p_nothing_during_exit;
  @(posedge clk) disable iff (!rst_n)
    (exit_countdown != '0) |-> !cmd_accepted;
endproperty
assert property (p_nothing_during_exit);

// P4 -- reset leaves the device not listening. An integration that assumes
// otherwise issues its first commands into a device that never agreed to
// receive them.
property p_reset_not_listening;
  @(posedge clk)
    !rst_n |=> !listening;
endproperty
assert property (p_reset_not_listening);

P1 is the property that distinguishes this signal from chip select, and it is the one worth writing because the wrong implementation is natural. Gating a command on the current value of an enable is what most engineers write first, and it produces a design that works in every test where CKE is stable — which is most tests. The bug only appears at the transition, which is exactly where power-management code lives.

P3 exists because P1 is not sufficient. A device whose cke_q is asserted is permitted to be sampled and may still be unusable. Separating "allowed" from "ready" is the useful distinction, and a controller that conflates them issues commands into an exit interval.

What none of them prove. Nothing about energy — whether the power state saved anything is Chapter 4.7's question and is not observable here. Nothing about which low-power state was entered. Nothing about refresh continuing to be satisfied, which is a real obligation this model does not represent. And nothing about DDR5, whose mechanism is different in kind.

8. Common Misconceptions

"CKE is just an enable — gate the command on it and you are done." Wrong model: CKE qualifies the command it accompanies, like chip select. Why it is tempting: it is what the name suggests, and it is how nearly every other enable signal in digital design works. Consequence: a controller that issues commands during the exit interval, and one whose behaviour at the entry transition depends on which edge happened to be sampled first. The failure appears only at transitions, so it survives testing that keeps CKE stable — and power-management code is precisely the code that does not. Correct model: CKE is a state declaration qualified by its previous value. It announces an operating condition that will hold, and re-asserting it does not make the device immediately usable. Prevention: ask whether the signal changes what the receiver does or what the receiver is. The second kind needs lead time.

"A command sent to a device in power-down is an error the hardware will report." Wrong model: illegal operations produce error indications. Why it is tempting: well-designed interfaces usually do report protocol violations, and DDR4 does report some things — CA parity errors, for instance. Consequence: no handling for a class of failure that produces wrong state with no signal. The controller's bank model silently diverges from the device, and the symptom surfaces much later as wrong data or a refused command. Correct model: a device that is not sampling does not see the command at all. There is nothing to report because nothing happened. The controller's own model is the only thing that can detect the divergence. Prevention: ask what the device would do if it never received the command. If the answer is "nothing, silently", the controller must not rely on the device to notice.

"DDR5 has CKE, it just works differently." Wrong model: the signal exists in some form in every generation. Why it is tempting: the function genuinely does survive, and generation-to-generation continuity is usually the safe assumption. Consequence: a controller design or a pin-out that assumes a wire that is not there, and — more insidiously — reasoning that carries CKE's one-event-lead semantics into a DDR5 design where power transitions are command-encoded and follow command timing rules instead. Correct model: DDR5 has no dedicated CKE pin. Power-down entry and exit are triggered by CS_n plus CA-bus command encoding. The capability survived; the signalling did not. Prevention: check the generation's signal list, not the previous generation's. "If DDR4 has it, DDR5 must" fails concretely here and again at ODT.

"Power-down means the device stops needing refresh." Wrong model: a low-power state suspends all obligations. Why it is tempting: "powered down" sounds total, and the device genuinely stops responding to commands. Consequence: data loss. Chapter 2.3 established that DRAM cells lose charge continuously and that retention worsens with temperature; no power state changes that physics. Correct model: refresh obligations continue in every state. Either the controller continues managing them, or the device has been placed in a state where it refreshes itself — and CKE participates in selecting which, but never in suspending the requirement. Prevention: ask what is maintaining the cells. There is always an answer, and "nothing" is never it.

9. Debugging — A Command Appears to Have Been Issued and Had No Effect

Symptom. A controller's state model says a device should have a row open, or should be in a particular configuration, and the device behaves as though the command never arrived. No errors anywhere. It is intermittent and correlates with periods of low activity.

"Correlates with low activity" is the diagnostic gift here, because it points immediately at power management: the mechanism that engages precisely when nothing is happening.

Mechanism 1 — the command was issued during the exit interval. Inspect: the controller's model of when the device becomes usable after CKE is reasserted, against when it actually issued. Expected evidence: commands issued a small, fixed number of events after a CKE rise. Discriminator: is there a consistent offset between CKE rising and the lost command? This is §4's event-4 case and it is the most common, because it requires the controller to model a delay rather than a level — and a controller that treats CKE as a gate has no delay to model.

Mechanism 2 — the command was issued while genuinely powered down. Inspect: CKE state at the sampling event of the lost command. Expected evidence: CKE low, or cke_q low. Discriminator: was CKE actually asserted? Distinguished from mechanism 1 by the CKE trace alone, and cheaper to check.

Mechanism 3 — the transition was illegal for the device's state. Inspect: whether banks were open when the power transition was requested. Expected evidence: a transition requested with banks active. Discriminator: check bank state at the transition, not at the failure. Some transitions require banks closed first, and this model does not enforce it. The symptom appears at a later command while the cause was at the transition — the same "find the first disagreement, not the first symptom" lesson Chapter 5.2 §10 drew.

Mechanism 4 — refresh was not maintained across the state. Inspect: whether data is wrong rather than a command being lost. Expected evidence: corrupted contents rather than unexpected device state, correlated with how long the device was idle and worsening when hot. Discriminator: is a command missing, or is data wrong? These are entirely different faults with the same trigger, and Chapter 2.3 §4's temperature dependence is the confirming signature.

Mechanism 5 — not CKE at all: DDR5, where there is no CKE. Inspect: the generation. Expected evidence: a controller or a mental model built around a pin the device does not have. Discriminator: check the device's signal list. On DDR5 the whole of mechanisms 1 to 3 must be re-expressed in terms of CS_n and command encoding, and an investigation framed around a CKE pin will not converge because it is looking for a wire that is not there.

Discrimination, cheapest first. Read CKE at the lost command's sampling event — one trace lookup, and it separates mechanism 2 immediately. Then measure the offset from the last CKE rise, which resolves mechanism 1. Then ask whether the failure is a missing command or wrong data, which splits mechanism 4 off entirely. Then check bank state at the transition rather than at the failure.

The reasoning lesson. A fault that correlates with idleness rather than with load inverts the usual search. Most memory problems get worse under stress, so the instinct is to reproduce by hammering — and hammering a power-management bug makes it disappear, because an always-busy device never enters a low-power state. When a symptom correlates with quiet, the reproduction strategy has to invert too: introduce idle gaps deliberately, and vary their length, because the bug lives in the transition and not in the traffic.

10. Interview Reasoning

"What does CKE do, and how is it different from chip select?" CKE determines whether a device samples its command inputs at all, while chip select determines whether a particular command event applies to a particular rank. The structural difference is timing: chip select qualifies using its current value, because deciding whether to act on a command does not change the receiving machinery. CKE qualifies using its previous value, because deasserting it begins winding down the input receivers and internal clocking — a device cannot be told to stop listening and simultaneously be expected to interpret that instruction using the receivers it is about to disable. So CKE is a state declaration with one event of lead time, not a per-event gate.

"What happens if you issue a command to a device whose CKE is deasserted?" Nothing, silently. The device is not sampling its command inputs, so it does not see the command — there is no error, no response, and no trace anywhere on the interface. The controller finds out later, when its own model of the device's state disagrees with reality, and that can surface as a refused command or as data read from a row the controller did not think was open. That is why the controller's state model is the only thing capable of detecting the divergence, and why this class of fault is harder than one the hardware reports.

"Does DDR5 have a CKE pin?" No. DDR5 removed the dedicated CKE pin; power-down entry and exit are triggered by CS_n combined with command encoding on the CA bus. The capability survived and the signalling did not, which matters practically because a controller written against a CKE pin does not port, and the one-event-lead semantics do not carry over — DDR5's transitions follow command timing rules instead. It is also not an isolated change: DDR5 removed the dedicated ODT pin by the same mechanism, which tells you the principle being applied is that control functions whose state changes infrequently relative to the command rate can afford to occupy a command slot.

"Why can CKE's function be encoded when DQS's cannot?" Because of how often each is needed. A power transition happens occasionally — once per idle period — so spending a command slot on it costs essentially nothing. DQS is needed on every data transfer and carries timing information that must accompany the data physically, so there is no command slot frequent enough and no encoding that could deliver a timing reference. The general rule the DDR5 changes reveal is that control functions with low state-change rates relative to the command rate are candidates for encoding, and per-transfer functions never are.

"A controller loses commands intermittently, correlated with idle periods. How do you approach it?" The correlation with idleness rather than load is the strongest clue, because it points at power management — the mechanism that only engages when nothing is happening. It also inverts the reproduction strategy: hammering the interface makes the bug disappear, so you have to introduce idle gaps deliberately and vary their length. Then read CKE at the lost command's sampling event, which immediately separates "issued while genuinely asleep" from something else. Then measure the offset between the last CKE rise and the lost command, because a consistent small offset means commands are being issued during the exit interval — the device is awake but not yet usable, and a controller that models CKE as a simple gate has no delay to represent that. It is also worth checking whether the failure is a missing command or actually wrong data, because unmaintained refresh across a low-power state produces corruption with the same trigger and a completely different fix.

11. Engineering Exercise

Educational cycle counts throughout; no specification values are implied.

1. A controller deasserts CKE and, at the very next sampling event, issues a command. Using §2's semantics, is the command seen? Yes. cke_q still holds the previous value, which was asserted. The device is still sampling at that event. The lead-time offset works in both directions, and a controller that assumes deassertion is immediate will be surprised by a command that did take effect.

2. Same controller reasserts CKE and issues a command at the next event. Is it seen? No — twice over. cke_q is still deasserted at that event, and even once it follows, the exit interval has not elapsed. Asymmetry is the point: entering is lazy and leaving is expensive, which is exactly Chapter 4.7 §11's finding that the benefit scales with idle duration while the exit cost is fixed.

3. §4's model has three terms in listening. Remove cke_q and describe the resulting bug. CKE becomes a per-event gate like chip select. Commands are accepted or rejected based on the current value with no lead time. The design works in every test that holds CKE stable and fails only at transitions — which is where power-management code exclusively lives, and why this bug reaches production.

4. Remove the exit_countdown term instead. What breaks, and when is it noticed? The device appears usable the moment cke_q follows CKE high. Commands issued in that interval are lost on real hardware and accepted by the model. It is noticed late, because it only manifests when the controller is aggressive enough to issue immediately after a wake — so a conservative controller can ship with this bug latent and a later optimisation exposes it.

5. A DDR5 design is being reviewed and the controller has a cke_o output. What is wrong, and what should be there instead? There is no CKE pin to drive. Power-down entry and exit must be issued as commands — CS_n plus CA encoding — which means they go through the command scheduler and obey command timing rules, rather than being a signal the controller asserts asynchronously to its command stream. The architectural consequence is larger than the pin count: power transitions become scheduled events competing for command bandwidth.

6. Why did DDR5 remove CKE and ODT but not RESET# or CK? Because a signal that establishes the conditions under which encoding is possible cannot itself be encoded. CKE and ODT are control functions invoked occasionally, and a device that is receiving commands can be told to change them. CK is required for any command to be sampled, and RESET# must work when the device's state is unknown and no command path can be trusted — Chapter 6.8 develops this. The surviving dedicated signals are exactly the ones the command path depends on.

12. Summary

CKE determines whether a device samples its command inputs at all. When it is deasserted the device is not ignoring commands — it is not seeing them, which means the CA lines carry no obligation during that period.

It qualifies using its previous value, not its current one, and that is the structural difference from chip select. Deasserting CKE begins winding down input receivers and internal clocking, so a device cannot be told to stop listening and simultaneously be expected to interpret that instruction using the receivers it is about to disable. The general principle: a signal that changes what a receiver is needs lead time; a signal that changes what a receiver does does not.

Re-asserting CKE does not make the device usable. An exit interval follows, and "allowed to be sampled" and "ready" are different states — a controller that conflates them issues commands into the gap. Entering is lazy and leaving is expensive, which is the asymmetry Chapter 4.7 priced.

Commands issued while not listening produce nothing at all. No error, no response, no trace — §4's cmd_ignored is an observability output the model invents, and silicon is silent. The controller's own state model is the only thing that can detect the divergence, and it may not do so until much later.

CKE never suspends refresh. Either the controller keeps managing it or the device has been placed in a state where it refreshes itself; there is no state in which the cells stop losing charge.

And in DDR5 the pin is gone. Entry and exit are triggered by CS_n plus CA-bus command encoding — the capability survived, the signalling did not. DDR5 removed the dedicated ODT pin the same way, which reveals the principle: control functions whose state changes infrequently relative to the command rate can afford a command slot, and per-transfer functions never can. That is why DQS and DQ will never be encodable.

13. What Comes Next

Chapter 6.3 takes the other qualification signal — the per-event one.

Chip select answers a different question: a command bus reaches every rank on a channel, so every rank sees every command. Something must decide which of them acts, and that decision is made fresh for each command rather than declared as a state.

That makes CS# the signal that turns a broadcast into an instruction, and it is also the signal DDR5 leaned on when it took CKE's and ODT's jobs away — so understanding what chip select was already doing explains why it was the natural place to put more.

Return to CK / CK# for the sampling events CKE qualifies, LPDDR Evolution for the energy-versus-latency trade this signal expresses, or The Refresh Requirement for the obligation no power state suspends. The full path is on the DDR tutorials index.