Real-System Examples

Three chapters have treated the address map as something you choose. Chapter 18.1 chose a field order, 18.2 measured what it produced, 18.3 chose a bank-selection function.

On a real machine you choose none of it. The map is set by a memory controller you did not design, programmed by firmware you did not write, and changed by the DIMM population and the settings of the machine in front of you.

So this chapter answers a different question, and it is the one that actually comes up at work:

How do you find out what mapping a real system is using — and how much should you trust the answer?

1. Four Grades of Evidence

Every claim about a real system's address map belongs in exactly one of four categories. Mixing them up is the single largest source of wrong engineering decisions in this area, because categories C and D look exactly like category A once they have been copied into a slide.

Everything in Chapters 18.1 through 18.3 is category D, and each of those chapters says so on the configuration block. That labelling was not a formality — it was practice for this chapter.

2. What the Vendors Actually Provide

The four major sources of DDR memory controllers occupy different categories, and that is the most useful single fact in this chapter.

AMD — category A and B, and unusually open. AMD has long published BIOS and Kernel Developer's Guides that document DRAM address-map and interleave configuration registers, including chip-select and channel interleaving, as public documents. For its current integrated memory controllers, AMD's own product documentation states the principle directly: the address mapping “is usually programmable in the DRAM controller and is selected at initialization time,” and — the sentence that could serve as this module's epigraph — “there is no one-size-fits-all mapping. Different mappings maximize performance of different workloads or traffic patterns.”

That is a vendor saying, in its own documentation, exactly what Chapter 18.2 demonstrated by measurement.

Arm — category B. Arm licenses memory controller IP rather than shipping one fixed platform. The CoreLink DMC-620 Technical Reference Manual is a public document, and Arm's own open-source system-control firmware exposes the controller's ADDRESS_CONTROL, DECODE_CONTROL and ADDRESS_MAP registers as fields firmware programs during initialisation. So the mechanism is documented and the map is whatever the integrator's firmware writes — which differs per SoC and per platform.

Intel — category C in practice. Intel does not publish the physical-address-to-bank-and-row translation for its memory controllers. What is known publicly about specific Intel parts comes from reverse-engineering research, not from Intel documentation.

Everything else — check before assuming. Embedded and FPGA memory controllers frequently document their mapping fully, because the integrator has to configure them.

3. The Same Four Questions, Per Source

§2 gave the landscape. Working engineers need it as a procedure, so here is the same material as the four questions worth asking about any platform — and the answers differ enough between sources that assuming one shape is the error.

AMD, integrated memory controllers and BKDG-documented families.

Arm CoreLink memory controller IP.

Intel memory controllers.

4. Recovered Mappings, and What They Are

Category C deserves precision, because the research is real, technically strong, and routinely miscited.

Published work at USENIX Security in 2016 reverse-engineered the mapping from physical addresses to DRAM channels, ranks and banks on commodity systems. The method is worth understanding because it is the same method §6 generalises: a row conflict is slower than a row hit, so timing two addresses reveals whether they share a bank; collect enough same-bank sets and the selection functions can be reconstructed by linear algebra over GF(2). Later work reached the same goal using hardware performance counters, and further work has recovered bank functions on AMD processors.

Two findings from that literature matter for this module.

The recovered functions are XORs of physical-address bits. Chapter 18.3's hashing was not a teaching device invented for convenience — XOR-based bank selection is what measurement finds in real hardware, and GF(2) linear algebra works precisely because XOR is linear over that field.

The recovered mapping is a property of a system, not of a processor model. The literature is explicit that addressing can differ with processor model, DIMM population and firmware settings. So “the mapping for processor X” is not a well-formed claim; “the mapping measured on this machine, in this configuration” is.

  RECOVERED MAPPINGS — the cited work                          CATEGORY C
    Pessl, Gruss, Maurice, Schwarz, Mangard,
    "DRAMA: Exploiting DRAM Addressing for Cross-CPU Attacks",
    USENIX Security Symposium 2016.
    Reverse-engineers physical-address to channel/rank/bank mapping;
    recovered functions are XORs of address bits, reconstructed by
    linear algebra over GF(2).

    Helm et al., "Reliable Reverse Engineering of Intel DRAM
    Addressing Using Performance Counters", IEEE 2020.

    "Reverse-Engineering Bank Addressing Functions on AMD CPUs",
    DRAMSec.

  All three are research results on specific measured hardware.
  None is a vendor specification, and none should be restated as one.

5. Why "The Mapping" Is Often a Category Error

Even with perfect documentation, on many systems there is no single map to state, because the map is a function of configuration decided after the silicon was designed.

  inputs that can change the effective map on one machine

    memory controller generation and stepping
    number of channels populated
    channel interleaving mode
    number of ranks per channel
    DIMM capacity and internal organisation (row/column/bank counts)
    firmware / BIOS interleaving and hashing settings
    memory holes and reserved regions
    ECC configuration
    address remapping above the controller

Change the DIMM population and the device geometry changes — Chapter 5.3 established that the bank-group organisation itself is device-width dependent, so the number of bits in the bank-group field can change, and every field above it shifts.

One change, worked through. Take Chapter 18.1 §1's configuration and swap the DIMM for one built from devices with half the bank groups — two instead of four, which Chapter 5.3 established is exactly what a change of device width can do.

  EDUCATIONAL CONFIGURATION — CATEGORY D, from Chapter 18.1 §1.
  Not a JEDEC-mandated map and not any vendor's. The point it makes
  about field shifting is general; the widths are not.

  before: bg 2 bits, bank 2 bits, column 4, offset 6, row 8   (22 bits)
  after : bg 1 bit,  bank 2 bits, column 4, offset 6, row 8   (21 bits)

  Policy R, before          Policy R, after
    column  PA[9:6]           column  PA[9:6]      unchanged
    bank    PA[11:10]         bank    PA[11:10]    unchanged
    bg      PA[13:12]         bg      PA[12]       NARROWED
    row     PA[21:14]         row     PA[20:13]    SHIFTED DOWN ONE BIT

Every row bit moved. An address that decoded to row 41 now decodes to a different row, and any tool, model, monitor or test that hardcoded row = PA[21:14] is now silently wrong — not crashing, just describing a different location than the one being accessed.

Nothing about the processor changed. Nothing about the controller's design changed. A DIMM was swapped, and the map moved.

This is why §2's answer is a mechanism rather than a table, and why the practical skill is reading a configuration rather than memorising a map.

6. Discovering a Mapping You Were Not Given

When documentation runs out, the map can still be determined — by hypothesis and test rather than by assumption. The procedure follows directly from 18.1 and 18.2.

  1. HYPOTHESISE   propose a candidate selection function, e.g.
                   bank = PA[9:6] ^ PA[13:10]

  2. PREDICT       for a set of probe addresses, compute the bank each
                   one should land in under the hypothesis

  3. OBSERVE       determine the actual grouping — by controller
                   telemetry where available, or by the same-bank
                   timing signal §4 describes

  4. COMPARE       does the observed grouping partition the probes the
                   same way the hypothesis does?

  5. REFINE        a mismatch identifies a source bit that is wrong,
                   missing, or extra

Step 4 is subtler than it looks, and getting it wrong wastes a lot of time. The observation usually yields which addresses share a bank — a partition of the probe set. It does not yield the bank index. A hypothesis that predicts the right grouping with every index permuted is correct: the labels are arbitrary, and only the grouping is observable.

So the comparison must be on the partition, not on the numbers. §7's block is built around exactly that distinction, because a checker that compares indices directly will reject correct hypotheses and send the investigation chasing a bug that does not exist.

7. The Hypothesis Checker

// ─────────────────────────────────────────────────────────────────────
// mapping_hypothesis_check
//
// CLASSIFICATION
//   Synthesizable educational RTL. Sequential. One responsibility:
//   decide whether a hypothesised bank-selection function PARTITIONS a
//   set of probe addresses the same way an observed system does.
//
//   It is a DISCOVERY instrument. It does not map anything and it is
//   not part of a controller datapath.
//
// WHAT IT DOES NOT MODEL
//   - No address mapping. The hypothesis is evaluated outside and
//     presented as hyp_group; Chapter 8.6 owns real decode.
//   - No timing side channel, no measurement apparatus, no attack.
//     obs_group is an INPUT, whatever produced it (§4, §6).
//   - No bank state, no commands, no scheduling, no performance.
//   - It does NOT compare bank indices. Observation yields which
//     addresses share a bank, never what the bank is called, so index
//     equality is the wrong test (§6) and this block avoids it.
// ─────────────────────────────────────────────────────────────────────
module mapping_hypothesis_check #(
  // Number of distinct group labels either side may use.
  parameter int NUM_GROUPS = 16,
  parameter int GRP_W = (NUM_GROUPS <= 1) ? 1 : $clog2(NUM_GROUPS),
  parameter int CNT_W = 16
) (
  input  logic               clk,
  input  logic               rst_n,

  // ── One probe result per cycle: the group the hypothesis predicts,
  //    and the group the system was observed to use.
  input  logic               probe_valid,
  input  logic [GRP_W-1:0]   hyp_group,
  input  logic [GRP_W-1:0]   obs_group,

  input  logic               trial_restart,

  // ── The verdict. A hypothesis is CONSISTENT while a bijection
  //    between its labels and the observed labels still exists: every
  //    hypothesis group maps to exactly one observed group and vice
  //    versa. Permuted labels are therefore accepted, as §6 requires.
  output logic               consistent,
  output logic               conflict_seen,

  // ── Which probe broke it, for the report.
  output logic [CNT_W-1:0]   probe_index,
  output logic [CNT_W-1:0]   first_conflict_probe,
  output logic [GRP_W-1:0]   conflict_hyp_group,
  output logic [GRP_W-1:0]   conflict_obs_group,

  // ── Coverage: a hypothesis only survives a trial that exercised it.
  //    A trial touching two groups proves almost nothing, and without
  //    this the verdict is meaningless.
  output logic [NUM_GROUPS-1:0] hyp_groups_seen,
  output logic [NUM_GROUPS-1:0] obs_groups_seen
);

  if (NUM_GROUPS < 1) $fatal(1, "mapping_hypothesis_check: NUM_GROUPS must be >= 1");
  if (CNT_W      < 2) $fatal(1, "mapping_hypothesis_check: CNT_W must be >= 2");

  // ── The partial bijection, learned as probes arrive. fwd maps a
  //    hypothesis label to the observed label first seen with it; rev
  //    is the inverse. BOTH directions are needed: fwd alone accepts a
  //    hypothesis that merges two real groups into one, which is the
  //    most common way a too-narrow source set passes a weak check.
  logic [NUM_GROUPS-1:0]              fwd_bound;
  logic [NUM_GROUPS-1:0][GRP_W-1:0]   fwd_map;
  logic [NUM_GROUPS-1:0]              rev_bound;
  logic [NUM_GROUPS-1:0][GRP_W-1:0]   rev_map;

  logic hyp_ok, obs_ok, violates;
  assign hyp_ok = (int'(hyp_group) < NUM_GROUPS);
  assign obs_ok = (int'(obs_group) < NUM_GROUPS);

  // ── A probe violates the bijection if either direction is already
  //    bound to a different partner.
  always_comb begin
    violates = 1'b0;
    if (probe_valid && hyp_ok && obs_ok) begin
      if (fwd_bound[hyp_group] && (fwd_map[hyp_group] != obs_group)) violates = 1'b1;
      if (rev_bound[obs_group] && (rev_map[obs_group] != hyp_group)) violates = 1'b1;
    end
  end

  assign consistent = !conflict_seen;

  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      fwd_bound            <= '0;
      rev_bound            <= '0;
      conflict_seen        <= 1'b0;
      probe_index          <= '0;
      first_conflict_probe <= '0;
      conflict_hyp_group   <= '0;
      conflict_obs_group   <= '0;
      hyp_groups_seen      <= '0;
      obs_groups_seen      <= '0;
      for (int g = 0; g < NUM_GROUPS; g++) begin
        fwd_map[g] <= '0;
        rev_map[g] <= '0;
      end
    end else if (trial_restart) begin
      // A new trial tests a NEW hypothesis, so the learned bijection
      // must be discarded entirely -- unlike Chapter 18.2's profile,
      // where the modelled device state deliberately survives.
      fwd_bound       <= '0;
      rev_bound       <= '0;
      conflict_seen   <= 1'b0;
      probe_index     <= '0;
      hyp_groups_seen <= '0;
      obs_groups_seen <= '0;
    end else if (probe_valid && hyp_ok && obs_ok) begin
      if (!(&probe_index)) probe_index <= probe_index + CNT_W'(1);
      hyp_groups_seen[hyp_group] <= 1'b1;
      obs_groups_seen[obs_group] <= 1'b1;

      if (violates) begin
        // Latch the FIRST conflict only. Later probes will usually
        // also conflict once the hypothesis is known wrong, and the
        // first one is the one that localises the bad source bit.
        if (!conflict_seen) begin
          conflict_seen        <= 1'b1;
          first_conflict_probe <= probe_index;
          conflict_hyp_group   <= hyp_group;
          conflict_obs_group   <= obs_group;
        end
      end else begin
        fwd_bound[hyp_group] <= 1'b1;
        fwd_map[hyp_group]   <= obs_group;
        rev_bound[obs_group] <= 1'b1;
        rev_map[obs_group]   <= hyp_group;
      end
    end
  end

endmodule

Why both map directions. Suppose the real system uses four banks and the hypothesis uses a source set too narrow to distinguish two of them, so it labels two genuinely different banks identically. The forward direction never complains — hypothesis group 0 consistently maps to observed group 0 for one of them. The reverse direction catches it: observed group 1 is now also claimed by hypothesis group 0, which is already bound to observed group 0. A merged group is the signature of a missing source bit, and it is the most common wrong hypothesis.

Synthesis. 2 × NUM_GROUPS × (1 + GRP_W) flops plus comparators — 160 flops for sixteen groups. It is an instrument and would live in a testbench or a debug block, not a datapath.

8. What the Assertions Prove

// ── P1. Consistency is exactly the absence of a recorded conflict.
//    A definitional anchor: it fails the day someone adds a heuristic
//    that lets a hypothesis "mostly" pass.
property p_consistent_iff_no_conflict;
  @(posedge clk) disable iff (!rst_n)
    consistent == !conflict_seen;
endproperty
a_consistent_iff_no_conflict: assert property (p_consistent_iff_no_conflict);

// ── P2. A conflict is permanent within a trial. Catches a checker
//    that lets a later agreeing probe clear an earlier contradiction.
property p_conflict_sticky;
  @(posedge clk) disable iff (!rst_n)
    (conflict_seen && !trial_restart) |=> conflict_seen;
endproperty
a_conflict_sticky: assert property (p_conflict_sticky);

// ── P3. THE property that makes the instrument correct: a CONSISTENT
//    permutation of group labels must never be reported as a conflict.
//    §6 -- observation yields a partition, not indices, so a checker
//    that demanded index equality would reject correct hypotheses.
property p_permutation_accepted;
  @(posedge clk) disable iff (!rst_n)
    (probe_valid && hyp_ok && obs_ok
     && !fwd_bound[hyp_group] && !rev_bound[obs_group])
      |=> !$rose(conflict_seen);
endproperty
a_permutation_accepted: assert property (p_permutation_accepted);

// ── P4. A merged group is detected. If two distinct observed groups
//    are both claimed by one hypothesis group, the hypothesis is
//    missing a source bit and must be rejected.
property p_merge_detected;
  @(posedge clk) disable iff (!rst_n)
    (probe_valid && hyp_ok && obs_ok
     && fwd_bound[hyp_group] && fwd_map[hyp_group] != obs_group)
      |=> conflict_seen;
endproperty
a_merge_detected: assert property (p_merge_detected);

// ── Covers. A verdict from an unexercised trial is worthless, and
//    these are what distinguish "survived" from "was never tested".
c_all_hyp_groups: cover property (@(posedge clk) disable iff (!rst_n)
                    &hyp_groups_seen);
c_merge_rejected: cover property (@(posedge clk) disable iff (!rst_n)
                    $rose(conflict_seen));
c_permuted_pass:  cover property (@(posedge clk) disable iff (!rst_n)
                    consistent && (&hyp_groups_seen)
                    && (hyp_groups_seen != obs_groups_seen));

What they prove. That the instrument implements a bijection test rather than an equality test, that a contradiction is not forgotten, and that a merged group is rejected.

What they do not prove — and the gap is the whole point of this chapter. Nothing here establishes that a surviving hypothesis is the system's actual mapping. A hypothesis that survives a trial is one that has not yet been contradicted by the probes that were run. Run probes that vary only bits the true function ignores, and every hypothesis agreeing on those bits survives equally.

Consistency is not confirmation. It is failure to refute — which is why c_all_hyp_groups exists, and why §9's report leads with coverage rather than with the verdict. A hypothesis that survived a trial reaching two of sixteen groups has been tested almost not at all, and reporting it as "consistent" without that qualification is how a category-C result gets promoted to category A.

9. DV — Reporting a Trial Honestly

The reference model is a dictionary of dictionaries — hypothesis label to observed label and back — replaying the probe stream independently. The representation differs from the RTL's bound-mask-plus-array, so an indexing error cannot be mirrored.

The report format matters more than usual here, because its readers will quote it:

  MAPPING HYPOTHESIS TRIAL
    hypothesis     : bank = PA[9:6] ^ PA[13:10]
    evidence class : D (proposed) — becomes C if it survives on real
                     hardware, and never becomes A or B
    probes run     : 256
    hyp groups hit : 16 of 16          <- coverage FIRST
    obs groups hit : 16 of 16
    address bits varied by the probe set : [17:6]
    bits NOT varied                      : [21:18], [5:0]

    verdict        : CONSISTENT — not contradicted by these probes
    caveat         : bits [21:18] were never varied. Any hypothesis
                     that agrees with this one on [17:6] and differs
                     only above bit 17 is equally consistent with this
                     trial and was not distinguished.
    next probe set : vary [21:18] with [17:6] held constant

  ---------------------------------------------------------------
  MAPPING HYPOTHESIS TRIAL  (refuted)
    hypothesis     : bank = PA[9:6]
    probes run     : 41
    first conflict : probe 12
      hyp group    : 0x3
      obs group    : 0xB   (0x3 was already bound to 0x7)
    diagnosis      : hypothesis group 0x3 claims two distinct observed
                     groups -> MERGED GROUP -> a source bit is missing.
    localisation   : probes 5 and 12 share PA[9:6] and differ in
                     PA[13:10]; they were observed in different groups.
                     PA[13:10] influences bank selection and the
                     hypothesis ignores it.
    refined guess  : bank = PA[9:6] ^ PA[13:10]

The refuted trial is the more useful of the two, and that is worth noticing. A refutation names the bit; a survival names only what has not yet been ruled out.

Directed probe sets worth running: a single-bit walk over the full address width, which is 18.1 §11's test applied to a system rather than an RTL block, and the most efficient way to find which bits influence selection at all; pairs differing in exactly one candidate source bit; a sweep holding all candidate sources constant, which must place every probe in one group if the hypothesis is complete; and a repeat of the whole trial after a reboot, which is the only way to observe the configuration dependence of §5.

10. Corner Cases

Contrast the trial_restart row with Chapter 18.2 §11's: there the modelled device state deliberately survives a restart, here the learned bijection must be discarded. The two instruments restart oppositely for the same underlying reason — each keeps what belongs to the system under test and clears what belongs to the trial.

11. Debugging

Symptom: the documented mapping does not match observed behaviour. Before doubting the documentation, check whether it was category B — a mechanism — rather than category A. If the map is programmable, the document describes registers and the firmware supplies the answer, so read the configuration rather than the architecture manual.

Symptom: a mapping that worked on one machine fails on another. §5. Compare DIMM population, channel count and interleaving settings first. A different DIMM capacity changes the device geometry and shifts every field above the row.

Symptom: a published mapping does not reproduce. Check the paper's hardware. Category C results are specific to the machines measured, and the literature says so. Not a contradiction — a scope mismatch.

Symptom: the hypothesis checker says consistent but predictions are wrong in production. §8. Read the coverage line: the trial probably never varied the bits that matter. Re-run with a probe set that sweeps the untested range.

Symptom: every hypothesis is rejected immediately. Suspect the observation rather than the hypotheses. If the observed grouping is noisy — measurement error, or a system doing other work — no hypothesis can survive. Establish a control first: probes that must share a bank should be observed to do so.

12. Misconceptions

“JEDEC defines the physical-address map.” It defines device behaviour given a row, bank and column. The transformation is controller and platform policy, which §2 shows a vendor stating outright. Clue: an expectation that a map is portable across platforms.

“A processor has a mapping.” §5 — it has a configurable mechanism, and the map is a property of a configured machine. Clue: a claim indexed by part number alone.

“Reverse-engineered mappings are vendor contracts.” §4 — nothing obliges a vendor to preserve them. Clue: a recovered function hardcoded in shipping software.

“If it is in a published paper it applies to my machine.” It applies to the hardware measured. Clue: a citation with no hardware configuration attached.

“A textbook diagram shows what real processors do.” Textbook diagrams — including every one in 18.1 to 18.3 — are category D. Clue: a bit diagram with no source and no configuration.

“Vendors keep mappings secret.” Some publish extensively; some do not; some license IP whose map the integrator chooses. Assuming uniform secrecy means not looking. Clue: reverse-engineering a mapping that is documented.

“A surviving hypothesis is the mapping.” §8 — consistency is failure to refute, bounded by the probes run. Clue: a verdict quoted without its coverage line.

“Matching bank indices proves the hypothesis.” §6 — observation yields a partition; labels are arbitrary. An index-equality check rejects correct hypotheses. Clue: a checker that fails on a relabelling.

“Knowing the mapping lets me fix performance.” It lets you explain behaviour and choose access patterns. On most systems you cannot change the map, and 18.3 §5 showed that even choosing it does not defeat every stride. Clue: a plan that depends on remapping a platform you do not control.

13. Interview Reasoning

“What address mapping does a modern x86 processor use?” The honest answer is the strong one: it depends on the vendor, the part, the DIMM population and the firmware, and for some vendors it is not publicly documented at all. Then the useful follow-up: how would you find out for a specific machine?

“You find a bank-selection function in a paper. Can you design against it?” Not as a contract. Name the category, the scope, and what it legitimately supports — explaining a measured result on that hardware, or designing an experiment.

“How would you determine the mapping of a system you have?” Documentation first, then configuration registers, then hypothesis-and-test. A walking-bit probe set to find which bits influence selection, then candidate functions, then refinement.

“Your checker says the hypothesis is consistent. Are you done?” No — check the coverage. Consistency bounded by a probe set that never varied the relevant bits means nothing.

“Why compare partitions rather than bank numbers?” Because measurement reveals which addresses share a bank, not what the bank is called. A relabelling is the same mapping.

“The vendor documents registers, not a map. Is that useless?” The opposite — it is the more accurate artifact, because the map is a property of the configuration. §2's callout is the answer.

14. Exercises

1. Classify each as A, B, C or D: a BKDG register table describing interleave fields; a bit diagram in a conference tutorial; a measured bank function in a peer-reviewed paper; Chapter 18.1 §1's Policy R.

2. A hypothesis predicts groups [0,1,2,3] for four probes; observation gives [2,3,0,1]. Consistent or not? Justify from §6.

3. A hypothesis predicts [0,0,1,1]; observation gives [0,1,2,3]. Which probe first violates the bijection, and in which direction — forward or reverse?

4. Design a probe set of eight addresses that distinguishes bank = PA[9:6] from bank = PA[9:6] ^ PA[13:10]. Give the addresses and the predicted groupings under each.

5. A trial reports CONSISTENT with hyp_groups_seen showing 2 of 16. What can be concluded, and what probe set would you run next?

6. §7's checker maintains both fwd_map and rev_map. Give a hypothesis and probe stream that the forward direction accepts and the reverse rejects.

7. A colleague hardcodes a recovered mapping into a memory allocator. List three configuration changes that would silently invalidate it.

8. You are told a platform's mapping is "documented". What two questions establish whether that is category A or category B?

15. Module 18, Complete

Four chapters, one argument.

The map is policy. Chapter 18.1 showed two lossless orders over one device disagreeing about every resource a workload touches, and reduced the whole question to: what changes on the next access?

The policy has measurable consequences. 18.2 ran fixed streams through both orders and found perfect mirror symmetry — and found that in every pair, the high row-hit rate belonged to the single-bank result. Hit rate drives nothing by itself; the class distribution and the bank spread must be read together.

The consequences can be pathological. 18.3 showed a power-of-two stride collapsing sixteen banks to one under both orders, with every command legal, the scheduler correct and the mapping lossless — a fault located in an interaction rather than a component. Hashing redistributes it, is exactly reversible when it only reads retained bits, and is defeated by a larger stride, because a bounded source set always has one.

And on a real machine you mostly do not choose. This chapter separated what is documented from what is configured from what has been measured, and gave the method for the case where all three run out.

The one sentence the module was built to earn:

Address mapping changes no DDR timing rule. It changes which resources a workload presents to those rules — and that is enough to make a correct controller look broken.

Module 19 turns to the DDR PHY, where the decoded command and address finally become signals on a bus, and a different set of physical constraints takes over.