Mode-Register Set (MRS)

Every command in this module so far changes state. A row opens, a bank closes, the device is occupied. The state is different afterwards, and the meaning of everything else is unchanged.

MRS is different in kind. It changes how later commands are interpreted.

That makes it the only command in the module whose effect is on the decoder rather than on the array, and it introduces something Chapter 7.2 explicitly did not have: a decode-time dependency on command history. 7.2's decoder was a pure function of the sampled values. After a mode-register write, it is not.

So the chapter's question is:

What changes when a command reconfigures the interpretation of later commands — and what does that make configuration into?

The answer to the second half is the chapter's point: configuration stops being setup and becomes a correctness concern, because a command's meaning now depends on something that happened arbitrarily long ago.

1. MRS Writes Configuration

Semantically, MRS says: write this value into that mode register.

It carries two operands and no address in the usual sense. There is no bank, no row, no column — the target is a register inside the device, not a location in the array. And it moves no data on DQ; the value travels on the command/address interface alongside the command.

Its precondition is that the device be quiet. Configuration changes how the device behaves, so changing it while operations are in flight is meaningless at best. In practice this means banks idle — the same reduction Chapter 7.5 §2 introduced for refresh, and for a related reason: a device-wide change requires a device-wide quiescent state.

And its consequence is not a state transition. Nothing opens, nothing closes, nothing becomes occupied in the sense a refresh does. What changes is the rules.

2. The Operand Reuse, Again

Chapter 7.1 §5 established that an operand's meaning depends on the command carrying it, and Chapter 7.2 §3 showed A10's two meanings. MRS provides the second verified case.

Verified: in DDR4, the bank-group and bank address bits select which mode register the command targets.

   BG / BA bits with ACT, RD, WR   ->  which BANK
   BG / BA bits with MRS           ->  which MODE REGISTER

Same wires, same sampling event, entirely unrelated meanings — and again nothing distinguishes them except the command encoding present at that event.

And the anti-correlation that makes it possible is the same as ever. An MRS does not target a bank, so the bits that would name one are free. Chapter 6.6 §2 established this as the general condition for multiplexing: two functions can share wires only when they are never needed at the same event.

Which means Chapter 7.2 §2's ordered decode is not a convenience but a requirement, twice over. A decoder that extracts "bank" as a fixed field will read a mode-register number as a bank on every MRS — and will then believe the controller is operating on a bank it never touched.

3. It Changes the Decoder

Here is what makes MRS structurally unique.

A mode register can change how a later command is interpreted. Chapter 6.11 §3's case is the clearest: a mode register selects whether a pin carries the data mask or the bus-inversion flag, and verified they are mutually exclusive. So the same wire, at the same point in a later write burst, means different things depending on a command issued arbitrarily long ago.

4. RTL — Applying Configuration

Engineering problem

Accept a mode-register write, check its precondition, hold the configuration, and expose the parts of it that downstream interpretation depends on — so that the history-dependence is a real signal rather than a described idea.

Classification

SYNTHESIZABLE RTL — an educational configuration model.

What it represents: mode-register selection via the reused operand, the quiescence precondition, the stored configuration, and configuration outputs a decoder or data path would consume.

What it does not represent:

It is not a mode-register map. The two configuration fields modelled are chosen because Chapter 6.11 already established their consequence and left the mechanism open. Real mode registers hold many fields and are device-specific — the field definitions are specification material and are deliberately absent.

The register index values are educational. The mechanism — bank bits select the register — is verified; which numbered register holds which field is not modelled.

Also absent: bank state storage (Chapter 5.2 owns it, taken as input), timing, the reconfiguration settling interval a real device requires, calibration and training whose results some registers hold, and every analog property.

Interface contract

mrs_valid with mrs_index and mrs_value presents a write. bank_open_in comes from Chapter 5.2. The configuration outputs are what downstream logic consumes; mr_shadow exposes the stored values for a monitor to compare.

State

The mode-register array and the derived configuration.

Combinational behaviour

Precondition checking and configuration extraction.

Sequential behaviour

Register writes.

How to simulate

vlog mrs_config_apply.sv tb_mrs_config_apply.sv then vsim -c tb_mrs_config_apply -do "run -all".

Expected output

An MRS with banks idle is accepted and the configuration outputs change. An MRS with a bank open is refused and configuration is unchanged. A write to the reserved index is accepted on the interface and has no effect — matching the verified DDR4 behaviour that access to MR7 is ignored.

// ─────────────────────────────────────────────────────────────────────────
// MODE-REGISTER SET AND CONFIGURATION APPLY.
// Classification: SYNTHESIZABLE RTL -- an educational configuration model.
//
// MRS IS STRUCTURALLY UNIQUE IN THIS MODULE: every other command changes
// STATE; this one changes how later commands are INTERPRETED. That makes
// decode history-dependent -- Chapter 7.2's decoder is a pure function of
// the sampled values, and a REAL decoder must take configuration as an
// extra input, where configuration is a function of command history.
//
// VERIFIED (JEDEC / DDR4 material): the bank-group and bank address bits
// SELECT WHICH MODE REGISTER is written -- the same bits that name a bank
// on ACT, RD and WR. Chapter 7.1 Section 5's operand reuse, second case.
// Also verified: DDR4 IGNORES ACCESS TO MR7, and bit settings there may
// take no effect -- modelled below as a reserved index.
//
// THIS IS NOT A MODE-REGISTER MAP. The two configuration fields modelled
// are chosen because Chapter 6.11 already established their consequence
// (a pin carrying either the data mask or the bus-inversion flag,
// mutually exclusive) and explicitly left the mechanism open. Real mode
// registers hold many device-specific fields; those definitions are
// specification material and are deliberately absent. The register INDEX
// VALUES here are educational -- the selection MECHANISM is verified.
//
// ALSO NOT MODELLED: bank state storage (Chapter 5.2 owns it; taken as
// input), timing, the settling interval a real device needs after
// reconfiguration, calibration and training results some registers hold,
// and every analog property.
// ─────────────────────────────────────────────────────────────────────────
module mrs_config_apply #(
  parameter int NUM_MR    = 8,
  parameter int MR_W      = 14,
  parameter int NUM_BANKS = 16,
  // Educational: the index treated as reserved, modelling DDR4's ignored
  // MR7. Which index is reserved is device-specific.
  parameter int RESERVED_MR = 7,
  parameter int MR_IDX_W = (NUM_MR    <= 1) ? 1 : $clog2(NUM_MR),
  parameter int BANK_W   = (NUM_BANKS <= 1) ? 1 : $clog2(NUM_BANKS)
) (
  input  logic                   clk,
  input  logic                   rst_n,

  input  logic                   mrs_valid,
  // Carried on the bank-group and bank address bits. VERIFIED mechanism.
  input  logic [MR_IDX_W-1:0]    mrs_index,
  input  logic [MR_W-1:0]        mrs_value,

  // Bank state from Chapter 5.2's table. A device-wide configuration
  // change requires a device-wide quiescent state, so the precondition is
  // a reduction -- the same shape Chapter 7.5 introduced for refresh.
  input  logic [NUM_BANKS-1:0]   bank_open_in,

  output logic                   mrs_accepted,
  // 0 none, 1 banks not idle, 2 invalid index, 3 reserved index written.
  output logic [1:0]             mrs_reject_reason,
  output logic                   mrs_rejected,
  // The write was accepted on the interface and had NO EFFECT. Distinct
  // from a rejection: the device did not refuse it, it ignored it.
  output logic                   mrs_ignored,

  // ── CONFIGURATION OUTPUTS. These are what makes the history-dependence
  //    real: downstream decode and data-path logic consume these, so their
  //    behaviour depends on a command issued arbitrarily long ago.
  //
  //    cfg_dm_pin_function is exactly the PIN_FUNC that Chapter 6.11's
  //    write_mask_apply took as a PARAMETER, and whose runtime
  //    configurability that chapter listed as a stated limitation. This is
  //    where it becomes a signal.
  output logic [1:0]             cfg_dm_pin_function,
  output logic [1:0]             cfg_burst_mode,

  // The stored registers, for a monitor to compare against its own
  // reconstruction -- Chapter 7.4's independence argument applies here too.
  output logic [MR_W-1:0]        mr_shadow [NUM_MR]
);

  // ── COMPILE-TIME legality.
  if (NUM_MR < 1) begin : g_nmr
    initial $fatal(1, "mrs_config_apply: NUM_MR must be >= 1");
  end
  if (MR_W < 4) begin : g_mrw
    initial $fatal(1, "mrs_config_apply: MR_W must be >= 4 for the modelled fields");
  end
  if (NUM_BANKS < 1) begin : g_nb
    initial $fatal(1, "mrs_config_apply: NUM_BANKS must be >= 1");
  end
  if ((RESERVED_MR < 0) || (RESERVED_MR >= NUM_MR)) begin : g_res
    initial $fatal(1, "mrs_config_apply: RESERVED_MR must be within NUM_MR");
  end

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

  // ── Educational field positions within a register. Not a device's map.
  localparam int DM_FUNC_LSB = 0;
  localparam int BURST_LSB   = 2;
  // Educational: which register holds the modelled fields.
  localparam int MR_CFG_IDX  = 1;

  logic [MR_W-1:0] mr_q [NUM_MR];

  always_comb begin
    for (int i = 0; i < NUM_MR; i++) mr_shadow[i] = mr_q[i];
  end

  // ── Index range check, Chapter 5.1's generate pattern rather than a
  //    width cast that truncates for power-of-two counts.
  logic idx_bad;
  if (NUM_MR >= (1 << MR_IDX_W)) begin : g_idx_full
    assign idx_bad = 1'b0;
  end else begin : g_idx_chk
    assign idx_bad = ({1'b0, mrs_index} >= (MR_IDX_W+1)'(NUM_MR));
  end

  logic is_reserved, all_idle;
  assign is_reserved = (mrs_index == MR_IDX_W'(RESERVED_MR));
  assign all_idle    = (bank_open_in == '0);

  always_comb begin
    mrs_accepted      = 1'b0;
    mrs_ignored       = 1'b0;
    mrs_reject_reason = RJ_NONE;

    if (mrs_valid) begin
      if (idx_bad) begin
        mrs_reject_reason = RJ_BAD_IDX;
      end else if (!all_idle) begin
        // Chapter 7.1's question three. A device-wide configuration change
        // while operations are in flight is meaningless, so the state
        // forbids it even though the encoding is fine.
        mrs_reject_reason = RJ_NOT_IDLE;
      end else if (is_reserved) begin
        // VERIFIED DDR4 behaviour: access to MR7 is ignored. Note this is
        // ACCEPTED on the interface and has NO EFFECT -- which is a third
        // outcome distinct from accepted-and-applied and from rejected.
        // A controller that cannot distinguish them will believe it wrote
        // configuration that does not exist.
        mrs_accepted = 1'b1;
        mrs_ignored  = 1'b1;
      end else begin
        mrs_accepted = 1'b1;
      end
    end
  end

  assign mrs_rejected = mrs_valid && !mrs_accepted;

  // ── The configuration a decoder and data path consume. Derived from the
  //    stored register, so it persists until changed -- which IS the
  //    history-dependence.
  assign cfg_dm_pin_function = mr_q[MR_CFG_IDX][DM_FUNC_LSB +: 2];
  assign cfg_burst_mode      = mr_q[MR_CFG_IDX][BURST_LSB   +: 2];

  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      // Reset to zeros. NOTE: a real device's reset configuration is
      // specification-defined and is NOT necessarily all zeros -- and
      // Chapter 6.8 Section 3 established that a released reset is not a
      // configured device. This model's zeros are a stand-in, and a
      // controller must write configuration explicitly rather than
      // assuming a reset value.
      for (int i = 0; i < NUM_MR; i++) mr_q[i] <= '0;
    end else if (mrs_accepted && !mrs_ignored) begin
      mr_q[mrs_index] <= mrs_value;
    end
  end

endmodule

Cycle-by-cycle example

NUM_MR = 8, RESERVED_MR = 7, four banks:

Cycle 0 is the history-dependence being created. cfg_dm_pin_function changes, and from now on Chapter 6.11's write-mask logic behaves differently — for every subsequent write, until something changes it again.

Cycle 2 is the third outcome. The command was accepted and had no effect — verified DDR4 behaviour for MR7. That is neither acceptance-with-effect nor rejection, and a controller that models only two outcomes will believe it wrote configuration that does not exist.

Cycle 1 is the precondition. One bank open, and the configuration change is refused. A device-wide change needs a device-wide quiescent state — the same reduction shape as refresh.

Waveform expectation

§6. Watch a configuration output change at one command and stay changed indefinitely.

Synthesis implication

NUM_MR × MR_W flip-flops plus a small decode — for eight 14-bit registers, about 112 flops. Negligible. In a real device the registers fan out widely, because their bits gate behaviour across the command decoder, the data path and the analog configuration — which is why a mode-register change typically requires a settling interval this model does not represent.

Corner cases

NUM_MR == 1 makes MR_IDX_W == 1 through the guard and the range check materialises — Chapter 5.1 §5's degenerate case. An out-of-range index is rejected, not masked. The reserved index is accepted and ignored, which is the verified behaviour and is deliberately a distinct third outcome. Reset loads zeros, and the comment says why that is a stand-in rather than a claim — a real device's reset configuration is specification-defined and Chapter 6.8 §3 established that a released reset is not a configured device.

Debugging clues

If configuration appears not to take effect, check whether the target index is reserved — the write was accepted and ignored, and mrs_ignored is the only thing that distinguishes it from success. If configuration changes are refused during operation, check bank state at the command rather than at the symptom; the precondition is a reduction over all banks. If a monitor's configuration model diverges from the device's, check whether it is tracking ignored writes as effective — the most likely single cause, because the interface gives no hint.

Limitations

Not a mode-register map, as the header states at length. No reconfiguration settling interval — a real device needs time after a change and this model applies it instantly. No bank state storage. No timing. And no modelling of the fact that some mode registers hold calibration or training results rather than controller-written configuration, which is the case DDR5's readable form in §5 exists for.

5. DDR5 Makes It Readable, Which Is New in Kind

Verified: DDR5 accesses mode registers with MRW and MRR commands — mode-register write and mode-register read — and the read is used for functions including retrieving training and configuration results stored in the mode register, and post-package repair operations.

The readable form is genuinely new in kind, and it is worth saying why.

Every command in this module so far has been write-only into the device. A controller tells the device to do things and gets back data (from a read) or, as Chapter 6.12 §1 established, an error indication on the one output a DRAM drives. There has been no mechanism for asking the device about itself.

A mode-register read is that mechanism, and it matters because of what Chapter 4.4 §3 established: from DDR3 onward, interface timing is measured rather than designed. Training produces results — and those results are device-side state. Being able to read them back turns an opaque procedure into an inspectable one.

Which connects directly to a debugging lesson this curriculum has repeated. Chapter 4.4 §11 argued that reading a training procedure's reported margins rather than its pass bit is the highest-yield diagnostic available, and Chapter 6.12 §9 that a device with one output wire has almost no way to report anything. A readable mode register widens that channel considerably — the device can now be asked what it concluded.

6. Configuration Persisting, in Cycles

cfg_dm_func is the signal to watch, and what matters about it is how long it stays changed. It changes at cycle 1 and holds until cycle 8. Between those cycles, every write burst's mask lines are interpreted according to a command issued at cycle 0 — which is the history-dependence, made visible as a signal that outlives the command that set it.

Cycle 4 is the outcome most likely to be missed. mrs_accepted and mrs_ignored are both high, and cfg_dm_func does not move. The device did not refuse the command — it took it and did nothing. A controller tracking only accept/reject will record a successful configuration write that never happened.

Cycle 2 is the precondition. bank_open is 2 — one bank open — and the change is refused.

Representative educational cycles. The register index values and field positions are educational; the selection mechanism and the ignored-register behaviour are verified.

7. Four Assertions Worth Writing

// VERIFICATION-ONLY, inside mrs_config_apply.

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

// P2 -- THE THIRD-OUTCOME PROPERTY. An ignored write is accepted and
// changes nothing. Verified DDR4 behaviour for MR7, and the outcome a
// controller modelling only accept/reject cannot represent -- it will
// believe it wrote configuration that does not exist.
property p_ignored_changes_nothing;
  @(posedge clk) disable iff (!rst_n)
    mrs_ignored |-> (mr_shadow[RESERVED_MR] == '0);
endproperty
assert property (p_ignored_changes_nothing);

property p_ignored_implies_accepted;
  @(posedge clk) disable iff (!rst_n)
    mrs_ignored |-> mrs_accepted;
endproperty
assert property (p_ignored_implies_accepted);

// P3 -- configuration persists until explicitly changed. This is what
// makes decode history-dependent, and asserting it guards against a
// design that reset configuration on some unrelated event -- which would
// silently change the meaning of later commands.
property p_config_stable_unless_written;
  @(posedge clk) disable iff (!rst_n)
    !(mrs_accepted && !mrs_ignored && (mrs_index == MR_IDX_W'(MR_CFG_IDX)))
      |=> (cfg_dm_pin_function == $past(cfg_dm_pin_function));
endproperty
assert property (p_config_stable_unless_written);

// P4 -- a rejected write changes nothing. Report, never partially apply:
// a half-applied configuration is worse than a refused one, because the
// controller's model and the device's diverge on a subset of fields.
property p_reject_changes_nothing;
  @(posedge clk) disable iff (!rst_n)
    mrs_rejected |=> (cfg_dm_pin_function == $past(cfg_dm_pin_function));
endproperty
assert property (p_reject_changes_nothing);

// P5 -- the liveness companion. P1 to P4 all forbid; a design that never
// applied any configuration would satisfy every one of them.
property p_accepted_write_applies;
  @(posedge clk) disable iff (!rst_n)
    (mrs_accepted && !mrs_ignored)
      |=> (mr_shadow[$past(mrs_index)] == $past(mrs_value));
endproperty
assert property (p_accepted_write_applies);

P3 is the property specific to this chapter, and what it protects is subtle: configuration must persist. A design that cleared configuration on some unrelated event — a refresh, an idle period, a partial reset — would silently change the meaning of later commands, and every affected command afterwards would be misinterpreted with no error anywhere. Persistence is the whole mechanism, so it needs asserting.

P2 exists because there are three outcomes, not two. Accepted-and-applied, accepted-and-ignored, and rejected. A verification model with two states cannot express the middle one, and the interface gives no hint — which makes it exactly the kind of thing to pin down with a property.

What none of them prove. Nothing about whether the configuration written is correct for the system — a perfectly applied wrong value is the fault §8 is about, and no assertion here can see it. Nothing about the settling interval a real device needs after reconfiguration. Nothing about registers holding training results rather than controller-written values. And nothing about whether downstream logic actually honours the configuration, which is a system-level property spanning this block and every consumer.

8. Debugging — Behaviour Changed and No Recent Command Explains It

Symptom. A system worked and now misbehaves. The misbehaviour concerns data masking, burst behaviour, termination, or timing. The command stream immediately before the failure looks entirely normal.

"No recent command explains it" is the diagnostic signature of configuration, because configuration is the only thing in this module whose effect outlives its command arbitrarily.

Mechanism 1 — a mode-register write changed the meaning of later commands. Inspect: the command stream for any MRS since the last reset, not just recent ones. Expected evidence: a configuration change whose affected behaviour matches the symptom. Discriminator: search the whole trace, not a window. This is first because it is the only mechanism whose cause can be arbitrarily distant from its effect, and because the instinct — look at recent commands — is guaranteed to miss it.

Mechanism 2 — a write was accepted and ignored. Inspect: whether the target index is reserved. Expected evidence: a configuration the controller believes it wrote and the device does not have. Discriminator: compare the controller's intended configuration against a read-back, where the generation supports it — which is exactly what DDR5's mode-register read makes possible. Without read-back, compare against the device's specification for ignored registers.

Mechanism 3 — the write was refused and the controller did not check. Inspect: bank state at the MRS. Expected evidence: a configuration write issued with banks open, refused, and the controller proceeding as though it succeeded. Discriminator: check bank state at the configuration command, not at the failure. Chapter 5.2 §10's lesson again: the first disagreement, not the first symptom.

Mechanism 4 — configuration was never written at all. Inspect: whether initialisation completed and wrote configuration. Expected evidence: the device operating on reset defaults. Discriminator: did initialisation run to completion? Chapter 6.8 §3 established that a released reset is not a configured device, and §4's reset comment notes that a real device's reset configuration is specification-defined and must not be assumed.

Mechanism 5 — not configuration: the behaviour change has a state cause. Inspect: whether an auto-precharge or all-bank precharge changed bank state invisibly. Expected evidence: the symptom correlating with access patterns rather than persisting uniformly. Discriminator: is the misbehaviour persistent or pattern-dependent? Configuration faults are persistent — they affect every affected command identically. State faults are pattern-dependent. That single distinction separates this whole chapter's causes from Chapter 7.4's.

Discrimination, cheapest first. Ask whether the misbehaviour is persistent or pattern-dependent — one observation, and it separates configuration causes from state causes entirely. Then search the whole trace for MRS commands. Then compare intended configuration against read-back or against the specification's ignored registers. Then check bank state at each MRS.

The reasoning lesson. Configuration is the only thing in this module whose cause can be arbitrarily distant from its effect, and that breaks the debugging habit everything else rewards. Every other fault in Module 7 is found by looking at the failing command or the one before it; a configuration fault may have been set thousands of commands earlier and will produce identical misbehaviour on every affected command since. So the first question is not "what happened just now" but "is this persistent or pattern-dependent" — because persistent misbehaviour means you should stop looking at the recent past and start looking at the whole history.

9. Common Misconceptions

"MRS is just initialisation." Wrong model: mode registers are written once at startup and then fixed. Why it is tempting: most of them are, and initialisation is where the bulk of configuration happens. Consequence: no provision for configuration changing during operation, and a state model that treats configuration as a constant. Real systems reconfigure at runtime — termination settings, feature enables, and Chapter 6.11 §3's pin function are all live decisions — and a controller or monitor that assumes constancy will misinterpret every command after the first change. Correct model: MRS is issued whenever configuration must change, subject to the quiescence precondition. Configuration is live state, not setup. Prevention: ask whether anything would ever want to change this during operation. For termination and pin function, the answer is yes.

"A mode-register write either succeeds or is rejected." Wrong model: two outcomes. Why it is tempting: it is how essentially every other command behaves, and it is how most interfaces work. Consequence: a controller that believes it wrote configuration the device does not have. Verified: DDR4 ignores access to MR7, and bit settings there may take no effect — so a write can be accepted on the interface and have no effect, with nothing distinguishing it from success. Correct model: three outcomes — accepted and applied, accepted and ignored, rejected. The middle one is invisible on the interface, which is why read-back (where available) matters. Prevention: check which registers the device documents as reserved or ignored, and do not write them expecting effect.

"The bank bits on an MRS name a bank." Wrong model: operand fields have fixed meanings. Why it is tempting: those bits name a bank on every access command, and they are called bank bits. Consequence: a decoder or monitor that reads a mode-register number as a bank, and therefore believes the controller operated on a bank it never touched — corrupting its state model with no error. Chapter 7.2 §3's A10 case, in a second location. Correct model: verified — on an MRS the bank-group and bank bits select which mode register is written. Operand meaning is a property of the command-operand pair. Prevention: extract operands after decoding the operation. Chapter 7.2 §2's ordered decode, and this is its second justification.

"A decoder is a pure function of the sampled values." Wrong model: given the same interface values, decode always gives the same result. Why it is tempting: Chapter 7.2 §4's decoder genuinely is, and it is a desirable property — it makes the decoder trivially testable. Consequence: a decoder or monitor that cannot correctly interpret commands whose meaning depends on configuration, and — practically — a debugging technique that silently breaks. Replaying a window of a trace gives different results from replaying it from the start, because the configuration established earlier is missing. Correct model: a real decoder takes configuration as an additional input, and configuration is a function of command history. Chapter 7.2's block is a pure function precisely because it does not model configuration, and §4 is where the dependency enters. Prevention: when replaying a trace, capture the configuration state at the start of the window — or replay from a known reset.

10. Interview Reasoning

"How is a mode-register command different from every other DDR command?" Every other command changes state — a row opens, a bank closes, the device becomes occupied — and the meaning of later commands is unchanged. A mode-register command changes how later commands are interpreted. That makes it the only command whose effect is on the decoder rather than on the array, and it introduces a decode-time dependency on command history: a decoder that was a pure function of the sampled values now needs configuration as an extra input, and configuration is a function of everything that came before. The practical consequence is that configuration becomes a correctness concern rather than setup, because a wrong value does not fail immediately — it changes the meaning of every affected command from then on.

"What do the bank bits mean on an MRS command?" They select which mode register is being written — not a bank. That is the same operand-reuse pattern as A10, which is an auto-precharge flag on a read or write and a scope selector on a precharge: the meaning belongs to the command-operand pair, not to the wire. The enabling condition is the same anti-correlation that makes multi-function pins possible — an MRS does not target a bank, so the bits that would name one are free. And the consequence is that ordered decode is a requirement rather than a convenience: a decoder extracting "bank" as a fixed field will read a mode-register number as a bank on every MRS and believe the controller operated on a bank it never touched.

"Can a mode-register write be accepted and have no effect?" Yes, and it is worth knowing because it is a third outcome most models do not have. DDR4 ignores access to MR7, and bit settings there may take no effect — so the device neither refuses the command nor acts on it. Nothing on the interface distinguishes that from success, which means a controller tracking only accept and reject will believe it wrote configuration the device does not have. That is one of the concrete reasons DDR5's mode-register read matters: it lets the controller ask the device what it actually holds rather than assuming its writes landed.

"Why is DDR5's mode-register read new in kind rather than just convenient?" Because every command up to that point is write-only into the device. A controller tells the device to do things and gets back data from a read, or an error indication on the single output a DRAM drives — there is no mechanism for asking the device about itself. A mode-register read is that mechanism, and it matters most because from DDR3 onward interface timing is measured rather than designed: training produces results, and those results are device-side state. Being able to read them back turns an opaque procedure into an inspectable one, which connects directly to the debugging principle that reading a training procedure's reported margins rather than its pass bit is the highest-yield diagnostic available.

"A system's behaviour changed and the recent command stream looks normal. How do you approach it?" First by asking whether the misbehaviour is persistent or pattern-dependent, because that separates configuration causes from state causes entirely — configuration faults affect every affected command identically, while state faults correlate with access patterns. If it is persistent, the important move is to stop looking at the recent past: configuration is the only thing in this module whose cause can be arbitrarily distant from its effect, so I would search the whole trace since reset for mode-register commands rather than a window. Then compare the controller's intended configuration against a read-back where the generation supports it, because a write to a reserved register is accepted and ignored with nothing on the interface to say so. And check bank state at each mode-register command, since the precondition requires banks idle and a refused write that the controller did not check produces exactly this.

11. Engineering Exercise

Verified mechanism and verified ignored-register behaviour; educational register indices and field positions.

1. A controller issues MRS while one bank is open. What happens, and why is the precondition a reduction rather than a lookup? It is refused. The precondition is a reduction because configuration is device-wide — it changes how the device behaves generally, so it needs a device-wide quiescent state. That is the same shape as refresh's precondition and for a related reason.

2. A controller writes the reserved register index and checks only accept/reject. What does it conclude, and what is true? It concludes the write succeeded — because the command was accepted. What is true is that it had no effect (verified DDR4 behaviour for MR7). The controller's configuration model now disagrees with the device's, and nothing on the interface said so.

3. A monitor is attached to a running system and must interpret a write burst's mask lines. What does it need, and can it get it? It needs the mode-register configuration that selects whether the shared pin carries the data mask or the inversion flag. It cannot get it from observation alone — the configuration was written before it attached. It must declare uncertainty, exactly as Chapter 7.4's monitor does about rows — or, on DDR5, read it back.

4. Why is Chapter 7.2's decoder a pure function while a real one cannot be? Because 7.2's decoder does not model configuration. A real decoder must take configuration as an input, and configuration depends on command history — so the same sampled values can mean different things at different times. 7.2's purity is a consequence of its scope, not a claim about real decoders, and §4 is where the dependency enters.

5. A debugging technique that works for every other Module 7 fault fails for configuration faults. Name it and say why. Replaying or inspecting a window of a command trace. Every other fault's cause is at or near the failing command. A configuration fault's cause may be thousands of commands earlier, and replaying from the middle loses the configuration established before the window — so the replay produces different results from reality. Capture configuration at the window start, or replay from a known reset.

6. §7's P3 asserts that configuration persists unless written. Construct a bug it catches that P1, P2, P4 and P5 would all miss. A design that clears configuration on a refresh — or on an idle period, or a partial reset. Every write still behaves correctly, every precondition still holds, every rejection still changes nothing — so P1, P2, P4 and P5 all pass. What breaks is that commands after the clearing event are misinterpreted, with no error anywhere, which is exactly the persistent misbehaviour §8 is about.

12. Summary

MRS is the only command in this module whose effect is on interpretation rather than on state. Every other command opens a row, closes a bank, or occupies the device. This one changes the rules.

It writes a value into a register inside the device. No bank, no row, no column, no data on DQ. Its precondition is device-wide quiescence — a reduction over bank state, the same shape as refresh's, because a device-wide change needs a device-wide quiet state.

Verified: the bank-group and bank bits select which mode register — the same bits that name a bank on an access command. Chapter 7.1 §5's operand reuse, second case, and the second justification for ordered decode: a decoder extracting "bank" as a fixed field will read a register number as a bank on every MRS.

And it makes decode history-dependent. Chapter 7.2's decoder is a pure function of the sampled values; a real decoder takes configuration as an extra input, and configuration is a function of command history. Three consequences: replaying a trace window silently breaks unless configuration is captured; a monitor must reconstruct configuration and declare uncertainty about it; and configuration becomes a correctness concern rather than setup.

There are three outcomes, not two. Accepted and applied, accepted and ignored — verified for DDR4's MR7 — and rejected. The middle one is invisible on the interface, so a controller modelling two will believe it wrote configuration that does not exist.

Verified: DDR5 adds a mode-register read alongside the write, used among other things to retrieve training and configuration results stored in the registers. That is new in kind: every command before it was write-only into the device, with the only return paths being read data and ALERT#. A readable register lets the controller ask the device what it concluded — which is exactly what Chapter 4.4 §11's "read the margins, not the pass bit" needs.

And the debugging lesson is a break from the rest of the module. Configuration is the only thing whose cause can be arbitrarily distant from its effect, so the first question is persistent or pattern-dependent — persistent means stop looking at the recent past and search the whole history.

13. What Comes Next

Chapter 7.7 closes the module with a command unlike any so far.

ZQ calibration moves no data, targets no bank, and changes no configuration the controller chose. It starts a long-running process inside the device — one whose result is an analog quantity the controller cannot compute, cannot verify from the digital side, and must simply trust was established.

And it completes an arc this module and Module 6 have been building. 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 command. Pins became encodings; now dedicated commands become operands — the same economics, one level up, and 7.7 is where that becomes a stated rule rather than an observation.

Return to DM for the pin function this chapter's configuration selects, Read for the ordered decode this chapter's operand reuse justifies again, Refresh for the quiescence precondition shape, or RESET# for why a released reset is not a configured device. The full path is on the DDR tutorials index.