Interleaved Burst

Chapter 12.2 established that a burst is a permutation of its window: the starting column fixes which positions are visited, and only the order depends on the rule.

This chapter is about a different permutation of the same window.

What is an interleaved burst, how does its order differ from sequential, and — the question that matters most — which generations actually let you choose?

The last part carries a warning, and it is the chapter's real subject. A burst-order rule is only meaningful if something selects it, and the selection mechanism has a generation-specific availability that is easy to assume wrongly in either direction. This chapter states what has been verified from device documentation, and is explicit about what has not.

1. The Same Window, a Different Sequence

Everything structural from Chapter 12.2 still holds.

The order varies only the low log₂N column bits. Every bit above that field is fixed for the whole burst. The burst visits the N positions of its naturally aligned window, each exactly once, and cannot reach a row the command never named.

What changes is only which position each transfer index maps to.

   sequential:   position(i) = ( start + i )  within the window
   interleaved:  position(i) = ( start XOR i ) within the window

Both are permutations of the same N positions. Neither visits anything outside the window, neither duplicates, neither skips. The set is identical; the sequence is not.

2. The Rule, Derived

The interleaved rule computes the position by an exclusive-OR of the transfer index with the starting address, within the burst-local field.

That is the rule as described in SDRAM device material, and it is worth deriving rather than memorising, because the XOR is doing something specific.

Start from what an XOR by a constant does to a set. For any fixed s, the map i ↦ i XOR s is a bijection on the field — every value appears exactly once, because XOR is its own inverse: (i XOR s) XOR s = i. So the rule cannot duplicate or skip a position, which is the first thing you would want to know about a proposed ordering.

And it fixes the first transfer correctly. At i = 0, 0 XOR s = s — the burst begins at the starting column, exactly as sequential does.

Now what makes it interleaved. Consider the low bit. Under XOR, consecutive indices differ in bit 0, so consecutive transfers always differ in the low position bit — the order alternates between the two halves of every pair. Move to bit 1 and the same holds at pair granularity, and so on up the field. The sequence walks the window in a bit-reversed-like pattern rather than a linear one, which is where the name comes from and why it was useful to hardware that wanted particular words early.

Worked, for N = 8, generated from start XOR i and using the same starting positions as Chapter 12.2 §3 so the comparison is direct:

Check one by hand. Start 3 is 011:

   i = 0:  011 XOR 000 = 011 = 3
   i = 1:  011 XOR 001 = 010 = 2
   i = 2:  011 XOR 010 = 001 = 1
   i = 3:  011 XOR 011 = 000 = 0
   i = 4:  011 XOR 100 = 111 = 7
   i = 5:  011 XOR 101 = 110 = 6
   i = 6:  011 XOR 110 = 101 = 5
   i = 7:  011 XOR 111 = 100 = 4

Both rows contain exactly the set 0 through 7. Sequential counts up and wraps; interleaved counts down from 3 to 0, then jumps to 7 and counts down again. Same positions, entirely different traversal.

And for N = 4, where the XOR operates on two bits and the third is fixed:

3. Where the Two Rules Agree — and Why That Hides Bugs

Look at the first row of §2's table again. Starting at 0, sequential and interleaved produce identical orders.

That is not a coincidence:

   at start = 0:
     sequential:   position(i) = 0 + i  = i
     interleaved:  position(i) = 0 XOR i = i

Both reduce to the identity. And more generally, the two rules agree for any start whose burst-local bits are all zero — a block-aligned starting column.

4. Which Generations Let You Choose

This section states what device documentation verifies and what it does not. The distinction is the point.

Verified

Burst type is a selectable mode-register setting in DDR4. Vendor device documentation for DDR4 SDRAM states that accesses within a burst may be programmed to sequential or interleaved order, with the burst type selected by mode register MR0, bit A3, and that the ordering of accesses within a burst is determined by the burst length, the burst type, and the starting column address. Samsung's DDR4 device operations material describes the same arrangement.

The concept is older than DDR. In SDR SDRAM the mode register's burst-type bit selected sequential or interleaved in the same way.

So interleaved burst is not a purely historical curiosity. It is a verified, selectable DDR4 setting — which is worth stating plainly, because the opposite assumption is as common as the "universal menu" error Chapter 12.1 §3 corrects.

Not verified here

Whether DDR5 offers interleaved as a burst-type option, I could not confirm from accessible primary documentation.

What is confirmed: JESD79-5 contains sections titled "Burst Length, Type and Order" and "Burst Type and Burst Order for Optional BL32 Mode", so DDR5 has a burst type concept and the standard treats order explicitly. What the available material did not establish is which types that field offers and which register bit encodes it.

And that is the chapter's meta-lesson. Burst type is a small, old, easily-assumed property, and assumptions about it age badly in both directions: "it was removed" and "it is universal" are both wrong somewhere. The engineering habit is to ask which generation, check the mode register, and write the check against what is programmed rather than what is remembered.

5. RTL — A Reference Model for Both Rules

The engineering problem

Produce the burst position for a given transfer index under either rule, so that a checker can compare an observed order against the configured one — and can be re-pointed at the other rule when the configuration says so.

Why hardware does not need this — and verification does

A controller implements the rule it is configured for. Chapter 12.2's generator is that block for the sequential case, and it is deliberately synthesizable controller RTL.

A checker needs both. It must be able to say "the observed order matches interleaved, not sequential" — which requires generating both and comparing. That is a verification job, and building it as a reference model rather than as a configurable controller block is the honest classification given §4's unresolved generation question.

Classification

VERIFICATION-ONLY EDUCATIONAL REFERENCE MODEL. Not intended for synthesis.

What it models

The index-to-position mapping for both ordering rules, within the burst-local window, plus an agreement indicator showing where the two coincide.

What it does NOT model

The transfer count's origin (Chapter 12.1). Beat timing or data (Modules 10, 11). Which rule a device is configured for — that is an input, and discovering it is §8's subject. Mode-register decoding (Chapter 7.6). The window's row-safety guarantee — inherited structurally from the same field arithmetic Chapter 12.2 uses, and not re-derived.

Interface and parameter contract

// ─────────────────────────────────────────────────────────────────────────
// burst_order_reference_model
//
// Classification: VERIFICATION-ONLY EDUCATIONAL REFERENCE MODEL.
//   Not intended for synthesis. It drives nothing and exists so a checker
//   can compare an observed burst order against BOTH candidate rules.
//
// WHY A REFERENCE MODEL AND NOT A CONTROLLER BLOCK: presenting the choice
// as ordinary production configuration would imply that selecting either
// rule is available on whatever device is targeted. Chapter 12.3 Section 4
// verifies that burst type is a selectable MR0 setting in DDR4 and states
// that the DDR5 option set was NOT established from accessible primary
// documentation. A reference model DESCRIBES orders; it does not promise a
// feature.
//
// IS NOT Chapter 12.2's sequential_burst_address_gen, which is
// synthesizable controller RTL implementing ONE rule. This implements both
// for comparison.
//
// THE WINDOW GUARANTEE IS INHERITED, NOT RESTATED: both rules operate
// inside a WRAP_W-bit field, so neither can alter the high column bits and
// neither can reach a row the command never named (Chapter 12.2 Section 4).
//
// MODELS NO PHYSICAL OR ANALOG BEHAVIOUR.
// ─────────────────────────────────────────────────────────────────────────

// Which ordering rule a position is being computed under.
typedef enum logic [0:0] {
  BORDER_SEQUENTIAL  = 1'b0,
  BORDER_INTERLEAVED = 1'b1
} burst_order_e;

module burst_order_reference_model #(
  parameter int COL_W = 10,
  // Transfers in this burst, from Chapter 12.1's contract.
  parameter int BURST_TRANSFERS = 8,
  parameter int WRAP_W = (BURST_TRANSFERS <= 1) ? 1 : $clog2(BURST_TRANSFERS),
  parameter int IDX_W  = WRAP_W
) (
  input  logic [COL_W-1:0] start_col,
  input  logic [IDX_W-1:0] xfer_index,
  // An INPUT, not a parameter: a checker must be able to evaluate both
  // rules against one observation to determine which the device used.
  input  burst_order_e     order_rule,

  output logic [COL_W-1:0] xfer_col,

  // Both candidate positions, exposed so a checker can report WHICH rule
  // an observation matches rather than only whether it matched one.
  output logic [COL_W-1:0] col_if_sequential,
  output logic [COL_W-1:0] col_if_interleaved,

  // The two rules coincide for this (start, index). Section 3: they agree
  // for every index when the starting local bits are zero, which is why a
  // burst-type disagreement survives a block-aligned regression.
  output logic             rules_agree,

  output logic             is_last
);

  if (COL_W < 1) begin : g_cw
    initial $fatal(1, "burst_order_reference_model: COL_W must be >= 1");
  end
  if (BURST_TRANSFERS < 1) begin : g_bt
    initial $fatal(1, "burst_order_reference_model: BURST_TRANSFERS must be >= 1");
  end
  // Same power-of-two requirement, same reason as Chapter 12.2: both rules
  // operate on a FIELD, and a field of WRAP_W bits holds exactly 2**WRAP_W
  // values. A burst of any other length would revisit or skip positions
  // under either rule, and neither outcome is repairable at runtime.
  if (BURST_TRANSFERS != (1 << WRAP_W)) begin : g_pow
    initial $fatal(1, "burst_order_reference_model: BURST_TRANSFERS must be a power of two");
  end
  if (WRAP_W > COL_W) begin : g_fit
    initial $fatal(1, "burst_order_reference_model: burst window wider than COL_W");
  end

  logic [WRAP_W-1:0] start_local;
  logic [WRAP_W-1:0] local_seq;
  logic [WRAP_W-1:0] local_int;
  logic [WRAP_W-1:0] local_sel;

  assign start_local = start_col[WRAP_W-1:0];

  // ── The two rules. Both computed in a WRAP_W-bit field, so in both
  //    cases the carry (for the addition) simply does not exist and the
  //    XOR cannot widen. The window guarantee is structural for both.
  assign local_seq = start_local + xfer_index;
  assign local_int = start_local ^ xfer_index;

  assign local_sel = (order_rule == BORDER_INTERLEAVED) ? local_int : local_seq;

  // ── Reassembly, with the high bits taken unchanged from the command.
  if (WRAP_W == COL_W) begin : g_all_local
    assign xfer_col           = local_sel;
    assign col_if_sequential  = local_seq;
    assign col_if_interleaved = local_int;
  end else begin : g_with_high
    assign xfer_col           = {start_col[COL_W-1:WRAP_W], local_sel};
    assign col_if_sequential  = {start_col[COL_W-1:WRAP_W], local_seq};
    assign col_if_interleaved = {start_col[COL_W-1:WRAP_W], local_int};
  end

  assign rules_agree = (local_seq == local_int);

  assign is_last = (xfer_index == IDX_W'(BURST_TRANSFERS - 1));

endmodule

State, combinational and sequential behaviour

None, none, and none. Two narrow operations, a select, and a concatenation — a pure function of (start_col, xfer_index, order_rule), for the same random-access reason Chapter 12.2 §5 argued.

Bit-level derivation

At WRAP_W = 3, start_local = 3 (011):

Two rows agree and six differ. Index 0 always agrees — both rules start at the starting column. Index 4 agrees here by arithmetic coincidence (011 + 100 = 111 and 011 ^ 100 = 111, because the addition happened to produce no carries), which is worth noticing: agreement at a single index proves nothing about the rule.

How to simulate, and expected output

Sweep xfer_index for both rules and check against §2's tables. Then:

Block-aligned start — start_local = 0. rules_agree must be high at every index, and both orders must be identical. This is §3's hiding place, and the test exists to make it visible rather than to pass.

Start with all local bits set — start_local = 7 at WRAP_W = 3. Sequential gives 7 0 1 2 3 4 5 6; interleaved gives 7 6 5 4 3 2 1 0. Maximum divergence, and the best directed case for a rule-identification check.

Verify both outputs are permutations of the window for every starting column under both rules. That is §7's P1 and it is cheap to check exhaustively at small WRAP_W.

BURST_TRANSFERS = 4 and 16 to confirm the field width tracks the contract.

Non-power-of-two must not elaborate.

Expected waveform

§6, which places the two orders side by side for one starting column.

Synthesis implications

None claimed — it is verification-only. It would elaborate; synthesising it would be meaningless because nothing consumes its outputs and a controller implements one rule, not both. Declaring it non-synthesisable is a classification rather than a limitation, the same distinction Chapter 7.4 and Chapter 9.2 drew.

Corner cases

BURST_TRANSFERS == 1 gives a single transfer where both rules trivially agree. start_local == 0 makes rules_agree high everywhere — correct, and the case §3 is about. WRAP_W == COL_W removes the high-bit concatenation. Non-power-of-two does not elaborate, for the reason in the guard.

Failure modes and debugging clues

rules_agree high across an entire run means every access was block-aligned — so the regression has not distinguished the rules at all, which is a coverage finding rather than a design one. An observed order matching col_if_interleaved while the configuration says sequential is §9's case, and the two exposed outputs are what make that statement possible.

Extension ideas

Accumulating which rule each observed burst matched, and reporting the counts, turns this into a rule-identification monitor — genuinely useful during bring-up when the programmed burst type is uncertain, and §8's recommendation.

Limitations

Two rules only. Power-of-two burst lengths. It does not know which rule the device uses — that is the input, and the block's value is precisely that it makes the question answerable. And it produces positions, not data.

6. The Two Orders, Side by Side

Read the two order rows as sets and then as sequences. As sets they are identical — both contain exactly 0,1,2,3,4,5,6,7. As sequences they share only two entries in the same place.

Index 0 agrees because both rules begin at the starting column, which is a property of both rules and not a coincidence.

Index 4 agrees by accident — 3 + 4 and 3 XOR 4 both give 7, because that particular addition produced no carry. That is worth seeing precisely because it is meaningless: a checker that sampled only index 4 would conclude the rules matched.

And col high is constant under both rules, which is Chapter 12.2 §4's guarantee holding regardless of the ordering — both operate inside the same field, so neither can leave the window.

EDUCATIONAL. One transfer per cycle is a drawing convenience; no spacing corresponds to any timing parameter.

7. Four Assertions Worth Writing

// P1 -- THE RULE-INDEPENDENT PROPERTY. Whatever the rule, a burst visits
// every window position exactly once. Written as a bijection check across
// a sweep, this is the cheapest and most valuable burst-order check
// because it holds before you know which rule is configured.
//
// Expressed here per-index as its necessary condition: the generated
// position is inside the window and the mapping is invertible.
property p_position_is_in_window;
  @(posedge clk)
    (WRAP_W < COL_W)
      |-> (xfer_col[COL_W-1:WRAP_W] == start_col[COL_W-1:WRAP_W]);
endproperty
assert property (p_position_is_in_window);

// P2 -- both rules begin at the starting column. This is what makes the
// starting column meaningful under either rule, and it is the anchor a
// rule-identification check needs: if transfer zero is wrong, the fault is
// not the ordering rule.
property p_both_rules_start_at_start;
  @(posedge clk)
    (xfer_index == '0)
      |-> (col_if_sequential == start_col)
          && (col_if_interleaved == start_col);
endproperty
assert property (p_both_rules_start_at_start);

// P3 -- the interleaved rule is its own inverse. XOR by a constant is an
// involution, so applying the rule to its own output recovers the index.
// This proves the mapping cannot duplicate or skip a position WITHOUT
// sweeping every index, which a bijection check would require.
property p_interleaved_is_an_involution;
  @(posedge clk)
    ((col_if_interleaved[WRAP_W-1:0] ^ start_col[WRAP_W-1:0])
      == WRAP_W'(xfer_index));
endproperty
assert property (p_interleaved_is_an_involution);

// P4 -- the rules agree exactly when the addition produces no carries.
// Stated so that rules_agree is trustworthy: a checker uses it to know
// when an observation CANNOT distinguish the rules, and an over-reporting
// agree signal would make it discard usable evidence.
property p_agreement_is_reported_exactly;
  @(posedge clk)
    rules_agree == (col_if_sequential == col_if_interleaved);
endproperty
assert property (p_agreement_is_reported_exactly);

What these prove. P1 is the rule-independent guarantee and the one worth having first — it holds under both rules and catches a position that left its window. P2 anchors both sequences. P3 is the elegant one: because XOR is an involution, one algebraic property proves the interleaved mapping is a bijection without enumerating it — which is a stronger statement than a sweep and cheaper to check. P4 makes the agreement indicator trustworthy, which matters because a checker uses it to decide when evidence is inconclusive.

What these do not prove. Nothing here says which rule the device is using — order_rule is an input, and determining the configured type is §8's subject and ultimately a mode-register question. Nothing says the device supports either rule: §4 establishes that availability is generation-specific and partly unverified, and no property in a reference model can settle it. Nothing says the right data appeared at these positions — the model holds no data. Nothing about timing, and nothing physical.

8. DV — Checking an Order You Did Not Configure

The verification problem this chapter creates is unusual and genuinely useful: you may not know which rule is in force, and you can find out by observing.

The structure is a two-hypothesis check:

   for each burst:
     generate the expected order under BOTH rules
     compare the observed sequence against each
     record which rule it matched — or that it matched neither

Three outcomes, and each is informative:

Matched exactly one rule. You have identified the configured burst type from observation. Accumulate this across bursts: a run where every burst matches the same rule is strong evidence, and a run where bursts match different rules means something is changing the configuration mid-run.

Matched both. Every starting column in the sample was block-aligned, so the observations could not distinguish the rules — §3. This is a coverage result, not a pass, and rules_agree is what makes it reportable rather than silently indistinguishable.

Matched neither. The positions are wrong in a way no ordering rule explains — a window-size error, a wrong starting column, or a generator fault. Chapter 12.2 §9's mechanisms, and the permutation check localises it.

Two requirements that follow:

Derive the expected rule from the programmed mode register, and check the observation against it independently. The same argument as everywhere in this curriculum: a monitor configured from the design's own parameter agrees with it by construction. Here the stakes are higher because §3's alignment effect means the disagreement passes most traffic.

Make unaligned starting columns a directed coverage goal. Random address streams are heavily block-aligned in practice — cache lines start at boundaries. A regression that never issues a burst starting mid-window has never tested the ordering rule at all, and rules_agree being permanently high is the signal that this has happened.

9. Debugging — Right Positions, Wrong Sequence

Symptom. Data is wrong, but in a recoverable-looking way: all the expected bytes are present and they are in the wrong places within the transferred block. Block-aligned accesses are fine. Unaligned ones are scrambled.

Two observations diagnose this almost completely, and both are cheap.

First: are the positions a permutation of the window? If yes, the window size and the starting column are correct and the address generator is producing a valid order. Nothing is arithmetically broken.

Second: do block-aligned accesses work? If yes, you are looking at §3's agreement case — the two rules coincide there and diverge elsewhere.

Together those two facts point at a burst-type disagreement and away from everything else.

Candidate mechanisms.

1. The controller or the monitor is applying one rule while the device is configured for the other.
2. The mode-register burst-type setting is not what the design assumes — programmed differently, or never programmed. Chapter 7.6.
3. The design targets a generation whose burst-type availability differs from the one assumed. §4.
4. The positions are not a permutation and the resemblance to a rule mismatch is coincidental — a window-size or starting-column fault. Chapter 12.2 §9.
5. The order is right and the data association is off by one — Module 10 or 11.

Evidence to collect. The observed sequence for a failing unaligned burst, in full. The expected sequence under both rules — which is what the §5 model exists to produce. The programmed mode-register burst-type value, read back rather than assumed. And whether rules_agree was ever low during the passing tests.

Discriminator.

• Does the observed sequence match the other rule exactly? Mechanism 1 or 2, and you now know which rule the device is actually using. That single comparison converts a data-corruption mystery into a one-bit configuration question.
• Read back the mode register. If it differs from the design's assumption, mechanism 2 and everything downstream was computed from a fiction.
• If the register matches the assumption and the device still uses the other rule, mechanism 3 — the generation's behaviour is not what was assumed, and §4's caution applies.
• If the observed sequence matches neither rule, mechanism 4: check the permutation property first, because a non-permutation rules out both ordering rules immediately.
• If the sequence matches the configured rule and the data is still wrong, mechanism 5 — ordering is exonerated and the fault is association.

Responsible layer. Mechanisms 1 to 3 are configuration and the controller's model. Mechanism 4 is Chapter 12.2's generator. Mechanism 5 is the transaction modules'. None is a device fault — the device produces its configured order, and every failure here is a disagreement about what that order is.

Fix. Read the burst type from the programmed register, single-source it, and add unaligned starting columns to the regression — because the bug is invisible without them and will return the moment the check is removed.

10. Common Misconceptions

"Interleaved burst is a purely historical concept with no modern relevance."

Why it is tempting: it is rarely discussed in modern controller material, and sequential is the common default.

Concrete failure: an engineer assumes the mode-register burst-type bit is vestigial, never checks it, and is confounded when a device configured for interleaved produces scrambled unaligned accesses.

Correct model: burst type is a verified, selectable MR0 setting in DDR4. §4.

Prevention: check the programmed register rather than assuming a default.

"Interleaved burst is a normal option on every DDR generation."

Why it is tempting: it is the opposite over-correction, and the concept does span many generations.

Concrete failure: a controller offering a burst-type selection its target generation may not expose, or a monitor that assumes both rules are always candidates.

Correct model: availability is generation-specific. Verified for DDR4; not established here for DDR5. §4, and the resolution is the device's documentation.

Prevention: scope the claim to a generation, or decline to make it — which is what §4 does.

"Sequential and interleaved visit different columns."

Why it is tempting: different orders feel like they should reach different places.

Concrete failure: a checker that compares the set of visited positions to detect a rule mismatch. It never fires, because both rules produce the same set — so the check appears to pass and the real disagreement is missed.

Correct model: same window, same positions, different sequence. §1.

Prevention: check set and sequence separately. Chapter 12.2 §8.

"If it works, the burst type must be configured correctly."

Why it is tempting: passing tests feel like evidence.

Concrete failure: the entire regression uses block-aligned starting columns, where both rules produce identical orders. The wrong burst type passes everything and fails in the field on unaligned traffic.

Correct model: §3 — the rules agree for every block-aligned start. Passing proves nothing unless unaligned starts were exercised.

Prevention: report rules_agree; if it is permanently high, the regression has not tested the rule.

"The XOR could duplicate or skip a position."

Why it is tempting: XOR feels less orderly than addition, so it seems less obviously safe.

Concrete failure: an engineer adds a defensive duplicate-detection mechanism that cannot fire, and reasons about a hazard that does not exist.

Correct model: XOR by a constant is an involution, hence a bijection on the field — every position appears exactly once, provably. §2 and P3.

Prevention: the involution property, which proves it in one line without enumeration.

"Burst order is chosen per access like a burst length can be."

Why it is tempting: Chapter 12.1 §3 established that DDR4 allows a burst length choice per command on an address bit, so per-command order selection sounds plausible.

Concrete failure: a controller model that varies the order per command, producing sequences the device never generates.

Correct model: the verified DDR4 arrangement selects burst type in the mode register — a configuration setting — while the per-command bit selects burst length. §4. Two different mechanisms with two different scopes.

Prevention: separate the two in the model, exactly as the device separates them.

11. Interview Reasoning

"What is an interleaved burst?"

A different permutation of the same burst window. The position for transfer i is the XOR of the starting column with i, taken within the burst-local field — so it visits exactly the positions a sequential burst would, in a different sequence. The XOR is doing something specific: because XOR by a constant is an involution, the mapping is provably a bijection, so it cannot duplicate or skip a position; and because consecutive indices differ in the low bit, consecutive transfers always alternate between the halves of each pair, which is what makes the traversal "interleaved" rather than linear.

"Where is interleaved burst actually available?"

Verified: it is a selectable mode-register setting in DDR4 — MR0 bit A3 chooses sequential or interleaved, and the burst order is determined by burst length, burst type and the starting column. The concept is older, going back to SDR SDRAM's mode register. What I would not assert without checking is DDR5: the standard has a burst-type concept and treats order explicitly, but which options the field offers is something I would read from the device documentation rather than assume. Both over-corrections are common — treating it as vestigial, and treating it as universal — and the habit that avoids both is to check the programmed register for the generation in front of you.

"Why do sequential and interleaved agree for some accesses?"

Because for a block-aligned starting column — local bits all zero — both rules reduce to the identity: 0 + i and 0 XOR i are both i. And most real traffic is block-aligned, since cache lines start at natural boundaries. That makes a burst-type disagreement one of the best-hidden bugs in this area: it passes essentially any regression built from aligned accesses and then corrupts unaligned ones in the field. It is the same hiding place as a full-width-adder bug in the sequential generator, which is also correct exactly when the start is aligned.

"How would you determine which burst order a device is using, from observation?"

Generate the expected sequence under both rules and compare each against the observed one. Three outcomes and all are informative: matching exactly one identifies the configured type from observation; matching both means every sampled start was block-aligned, so the evidence is inconclusive — a coverage result rather than a pass; and matching neither means the positions are not a valid order at all, which points at a window-size or starting-column fault rather than the rule. Accumulating the result across bursts is what turns it from a guess into evidence.

"A burst delivers all the right bytes in the wrong places, and only for unaligned accesses. Where do you look?"

At the burst type, almost immediately. Two cheap observations get there: are the visited positions a permutation of the window — if yes, the window and the starting column are right and nothing is arithmetically broken; and do block-aligned accesses pass — if yes, that is the signature of two rules that coincide when aligned and diverge otherwise. Then compare the observed sequence against the other rule; if it matches exactly, a data-corruption mystery has become a one-bit configuration question, and the fix is to read the burst type from the programmed register rather than assume it.

12. Engineering Exercise

COL_W = 10, BURST_TRANSFERS = 8, so WRAP_W = 3.

1. Generate the interleaved order for local starts 1, 4 and 7. Show the XOR for one of them.

2. For each of those starts, give the sequential order and say at which indices the two rules agree.

3. Prove, without enumerating, that the interleaved rule cannot visit a position twice.

4. A regression reports rules_agree high on every transfer of every burst. What does that tell you, and is it a pass?

5. An observed burst from local start 5 is 5 4 7 6 1 0 3 2. Which rule is the device using? What would sequential have produced?

6. A colleague proposes selecting burst order per command, by analogy with DDR4's per-command burst-length bit. Why is that wrong?

13. Summary

An interleaved burst visits the same window as a sequential one, in a different sequence. Position i is the XOR of the starting column with i, within the burst-local field — so the set is identical and only the traversal differs.

The XOR is provably safe. Because XOR by a constant is an involution, the mapping is a bijection: no position is duplicated and none is skipped, and that is one algebraic line rather than an enumeration.

The two rules agree for block-aligned starts — and for some other starts besides. Both reduce to the identity when the local start bits are zero. Since most real traffic is block-aligned, a burst-type disagreement passes almost any regression and corrupts unaligned accesses in the field.

Burst type is a verified, selectable DDR4 mode-register setting. It is not a vestigial curiosity — and it is also not something to assume is universally available. Which options a generation offers comes from that generation's documentation, and this chapter declines to assert the DDR5 option set rather than guess it.

Which makes the real lesson a habit rather than a fact. A small, old, easily-assumed property, where both over-corrections are wrong somewhere. Ask which generation, read the programmed register, and write the check against what is configured rather than what is remembered.

And check set and sequence separately. The permutation check is rule-independent and cheap; the sequence check is what identifies the rule. Neither substitutes for the other.

14. What Comes Next

Three chapters have established what a burst is: how many transfers, which positions, in what order.

Chapter 12.4 — Data-Transfer Efficiency asks what it is all for — and finds that the question has more than one answer.

Bursting exists to amortise command cost, and it does. But a burst also transfers a fixed amount whether the requester wanted all of it or not, so the same arrangement that makes the command interface efficient can make the data interface wasteful. Those are different efficiencies, they trade against each other, and collapsing them into a single percentage is how architectural arguments go wrong.

That chapter separates the measures, builds the instrumentation to count them, and is careful about a specific temptation: a busy bus and a useful bus are not the same thing.

Return to Sequential Burst for the window, the rule this one is compared against, and the row-boundary guarantee both inherit, Burst Length for the contract being ordered, Mode-Register Set for where a burst-type setting lives and why configuration is a correctness concern, and SDR SDRAM for the generation where this selection first appeared.