AMBA AXI · Module 7

INCR Bursts

The AXI INCR burst (AxBURST=01) — the incrementing workhorse for memory access. How each beat's address advances by 2^AxSIZE, the per-beat address formula, length up to 256 beats, and the 4 KB-boundary constraint.

The INCR burst (AxBURST = 2'b01) is the one you'll meet most: an incrementing burst where each beat's address advances by the transfer size, so the burst sweeps a contiguous range of memory. Essentially all memory traffic — DMA to/from RAM, instruction fetch, buffer copies, structure reads — is INCR. Where FIXED reused one address, INCR walks forward; that single difference makes it the workhorse of the protocol. This chapter pins down how the address progresses, the per-beat formula, why INCR gets the long-burst extension, and the one rule that bounds it: the 4 KB boundary.

1. What an INCR Burst Is

In an INCR burst, each beat's address is the previous beat's address plus the number of bytes transferred — i.e., it increments by 2^AxSIZE every beat. The manager issues a single start address (AxADDR) and AxBURST = 2'b01; the addresses then walk forward:

beat n address = AxADDR + n × 2^AxSIZE, for n = 0 … AxLEN

So a burst with base 0x1000, AxSIZE = 2 (4 bytes/beat), and AxLEN = 3 (4 beats) touches 0x1000, 0x1004, 0x1008, 0x100C — a contiguous 16-byte span. Everything else is the standard burst machinery (AxSIZE bytes per beat, per-beat WSTRB, LAST on the final beat); the defining feature is the forward-marching address.

Figure 1 — INCR address progression. From base A, each beat advances by 2^AxSIZE (here s): A, A+s, A+2s, … A+AxLEN·s. The burst covers a contiguous range of (AxLEN+1)·2^AxSIZE bytes from one address transaction — the natural fit for memory.

2. An INCR Read on the Wire

Here a 4-beat INCR read sweeps four words from base 0x1000 (AxSIZE = 2, 4 bytes/beat). One address handshake, four data beats, each returning the word at the next address:

incr-burst — 4-beat INCR read from 0x1000, 4 bytes/beat

6 cycles

Figure 2 — incr-burst: a 4-beat INCR read (AxLEN=3, ARBURST=01) from base 0x1000, 4 bytes/beat. The address is issued once; the four R beats return the words at 0x1000, 0x1004, 0x1008, 0x100C in order, RLAST on the last. The per-beat addresses are implicit — derived by the increment, not re-sent.

3. The Workhorse — Where INCR Is Used

INCR is the default for anything that touches a contiguous memory range:

DMA to/from RAM — streaming a buffer in or out, address marching through the buffer.
Cache line fills / evictions — pulling or writing back a contiguous line (when not using WRAP, Chapter 7.4).
Instruction fetch — sequential code is a forward sweep of addresses.
Structure / array access — reading or writing a contiguous block.

If the data lives across a span of addresses rather than at one port, it's INCR. That covers the overwhelming majority of high-bandwidth traffic, which is why INCR — not FIXED or WRAP — is the type that received AXI4's long-burst extension.

Figure 3 — INCR's domain: contiguous-memory traffic. DMA buffers, cache-line fills, instruction fetch, and array/structure access all sweep a range of addresses, so they use INCR. The forward-marching address maps directly onto how memory is laid out — one transaction covers a whole block.

4. Length up to 256 — and the 4 KB Bound

INCR is the only burst type that reaches AXI4's 256-beat maximum (AxLEN up to 255); AXI3 caps it at 16, and FIXED/WRAP stay at 16 in both. Long INCR bursts are what let a DMA move a large contiguous block in one transaction.

But there is one hard limit that bites INCR specifically: a burst must not cross a 4 KB address boundary (Chapter 7.6). Because INCR's address marches forward, a long enough burst can reach a 4 KB boundary — and the manager must split the transfer at that boundary into separate bursts. (The 4 KB rule exists so that any single burst stays within one minimum-page region, so it can't span two regions that might map to different slaves.) FIXED never moves so it can't cross; WRAP wraps within its own aligned block; only INCR's forward progression makes the 4 KB rule an active design concern.

Figure 4 — INCR length and the 4 KB bound. INCR scales to 256 beats (AXI4), but its forward-marching address means a long burst can hit a 4 KB boundary — which it must not cross. The manager splits the transfer at the boundary into two bursts. This is unique to INCR among the burst types; FIXED can't move and WRAP stays within its block.

5. Common Misconceptions

Myths to unlearn

"INCR increments by 1 (or by a fixed 4) each beat." It increments by 2^AxSIZE — the bytes per beat. With 8-byte beats it steps by 8, with 4-byte beats by 4. It's the transfer size, not a constant.
"An INCR burst can be any length up to 256, anywhere." It can be up to 256 beats (AXI4) — but it must not cross a 4 KB boundary, so the placement and length together are constrained; long bursts near a boundary must be split.
"INCR and FIXED are interchangeable for a FIFO." No — INCR to a FIFO scatters the words across ascending addresses (Chapter 7.2). FIFOs need FIXED; ranges need INCR.
"The per-beat addresses are sent on the bus." They aren't — only the base AxADDR is transferred; each beat's address is derived by the increment. The data channel carries no address.
"INCR must start aligned." The start address can be unaligned; the first beat may be partial and subsequent beats align to the size (Chapters 7.7–7.8). The increment still applies from the (aligned) progression.

6. Debugging Insight

🔍 Debugging insight — INCR bugs are address-arithmetic and boundary errors

INCR problems are usually wrong stepping or a boundary violation:

Data lands at the wrong stride (every other word, or overlapping)? The increment is wrong — it must be 2^AxSIZE per beat. A master computing the step from AxLEN or a hardcoded constant instead of 2^AxSIZE smears the data: too-large a step leaves gaps, too-small overlaps/overwrites.
A long transfer corrupts data or gets a DECERR partway? Suspect a 4 KB-boundary crossing — the burst marched past a 4 KB boundary it should have split at, so the tail beats hit a different region/slave (possibly unmapped → DECERR). Check the base+length against the nearest 4 KB boundary.
A 256-beat burst rejected on an AXI3 path? The length limit — AXI3 caps INCR at 16; the long AXI4 burst must be split when bridged down.
FIFO/port data scattered across addresses? Wrong type — INCR was used where FIXED was needed (Chapter 7.2).
First/last beat data misplaced on an unaligned start? The unaligned-start handling (partial first beat) is wrong — the progression and strobes for the edge beats need care (Chapters 7.7–7.8).

Triage: reconstruct the expected per-beat addresses with AxADDR + n·2^AxSIZE, compare to where data actually landed, and check whether any beat crosses a 4 KB boundary. A stride mismatch points at the increment; a tail-only failure points at the boundary.

7. Verification Insight

✅ Verification insight — per-beat address progression, length, and the 4 KB rule

INCR's verification centers on address arithmetic. Assert that beat n's effective address equals AxADDR + n·2^AxSIZE for the whole burst — a reference model that recomputes the progression catches any stride or off-by-one error, and a byte-accurate scoreboard then confirms each beat's data lands at the right address. Length: enforce the per-version limit (≤256 AXI4 / ≤16 AXI3) and exercise the maximum. The 4 KB rule is the highest-value INCR check: assert no burst's address range crosses a 4 KB boundary, and add directed tests that place a burst's tail right at a 4 KB boundary to confirm the DUT (or the splitter under test) handles it — this is a classic source of silent corruption (covered fully in Chapter 7.6).

Coverage should sweep aligned and unaligned start addresses (partial first beat), narrow and full-width beats, length 1 through the maximum, and bursts positioned just inside and just crossing a 4 KB boundary (the latter as a negative test that must be flagged or split). Because INCR is the workhorse, the bulk of memory-traffic functional coverage rides on getting its address progression and boundary handling right; FIXED and WRAP are comparatively special-purpose.

8. Interview Questions

9. Summary

The INCR burst (AxBURST = 2'b01) is AXI's workhorse: each beat's address advances by 2^AxSIZE, so beat n targets AxADDR + n·2^AxSIZE and the burst sweeps a contiguous memory range. That maps directly onto how memory is laid out, which is why essentially all high-bandwidth traffic — DMA to/from RAM, cache-line fills, instruction fetch, array/structure access — is INCR, and why INCR is the only type that gets AXI4's 256-beat extension (AXI3 and the other types stay at 16). Only the base address rides the bus; the per-beat addresses are derived arithmetic.

The defining constraint, unique among burst types, is the 4 KB boundary: because INCR's address marches forward, a burst can reach a 4 KB boundary it must not cross, so masters split transfers there. Its bugs are address-arithmetic (wrong stride if you don't step by 2^AxSIZE), boundary crossings (tail-of-transfer corruption), and unaligned-edge handling. Debug and verify by reconstructing AxADDR + n·2^AxSIZE and checking the 4 KB boundary. Next: the third type, WRAP — where the address increments but wraps within an aligned block, the natural fit for cache-line fills.

10. What Comes Next

You've got the incrementing workhorse; next, the wrapping variant:

7.4 — WRAP Bursts (coming next) — bursts whose address increments then wraps within an aligned block, the natural fit for critical-word-first cache-line fills.
7.5 — Burst Address Calculation (coming soon) — worked per-beat address derivations for every burst type.

Previous: 7.2 — FIXED Bursts. Related: 7.6 — The 4KB Boundary Rule for the constraint INCR must respect, and 7.1 — Burst Length, Size & Beats for the underlying arithmetic. For the broader protocol catalog, see the AMBA family overview doc.