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.

Continue learning

Standards & specifications

Governing standard: Arm AMBA AXI Protocol Specification (IHI 0022)(opens Arm in a new tab)
Defines the AXI channels, handshake and ordering rules. RTL structure, interconnect topology and verification strategy are design choices this specification does not mandate.

This page also covers RTL structure, verification approach and debugging technique. Those are engineering practice built on the standard, not requirements the standard itself imposes.

Where this fits

Part of the AMBA AXI curriculum.