AMBA AXI · Module 7

Burst Address Calculation

The exact per-beat address arithmetic for AXI bursts — the spec's Start/Aligned address and Number_Bytes variables, the FIXED/INCR/WRAP formulas, and fully worked examples for aligned, unaligned, and wrapping cases.

This chapter consolidates the arithmetic behind the three burst types into one place: given AxADDR, AxSIZE, AxLEN, and AxBURST, what address does each beat target? FIXED, INCR, and WRAP each have a precise formula, and the edge cases — unaligned starts, the wrap boundary — are where real designs go wrong. We'll define the spec's variables, give the per-type equations, and work four examples end to end (aligned INCR, unaligned INCR, WRAP, FIXED). This is the reference you'll come back to; the 4 KB rule (Chapter 7.6) and strobe behavior (Chapter 7.8) build directly on it.

1. The Variables

The AXI specification frames burst addressing with a small set of derived values:

Variable	Definition
`Start_Address`	`AxADDR` — the address the manager issued.
`Number_Bytes`	`2^AxSIZE` — bytes per beat (the transfer size).
`Burst_Length`	`AxLEN + 1` — number of beats.
`Aligned_Address`	`(INT(Start_Address / Number_Bytes)) × Number_Bytes` — `Start_Address` rounded down to a `Number_Bytes` boundary.

Aligned_Address is the key idea: it's the start address with its sub-size offset removed. For an aligned start it equals Start_Address; for an unaligned start it's the next-lower size-aligned address. The per-beat formulas are expressed in terms of these.

Figure 1 — the address-calculation inputs and derived values. From AxADDR, AxSIZE, AxLEN, AxBURST the spec derives Start_Address, Number_Bytes (2^AxSIZE), Burst_Length (AxLEN+1), and Aligned_Address (Start_Address floored to a Number_Bytes boundary). The burst type then selects which per-beat formula applies.

2. The Per-Type Formulas

Numbering beats N = 1 … Burst_Length (the spec's 1-based convention):

Beat 1 (all types): Address_1 = Start_Address — the very first beat always uses the issued address (which may be unaligned).

FIXED: every beat uses the same address.

Address_N = Start_Address (for all N)

INCR: after the first beat, addresses step by Number_Bytes from the aligned address.

Address_N = Aligned_Address + (N − 1) × Number_Bytes (for N ≥ 2)

WRAP: like INCR, but the address wraps at the upper edge of an aligned block.

Wrap_Boundary = (INT(Start_Address / (Number_Bytes × Burst_Length))) × (Number_Bytes × Burst_Length)

Use the INCR formula; whenever Address_N reaches Wrap_Boundary + (Number_Bytes × Burst_Length), set it back to Wrap_Boundary and continue.

The subtlety: for INCR/WRAP the first beat is Start_Address (possibly unaligned), but beat 2 onward uses Aligned_Address — so an unaligned start produces a partial first beat and aligned beats thereafter.

3. Worked Examples

Four examples on a bus wide enough that Number_Bytes is the transfer size (not lane-limited). Number_Bytes = 4 (AxSIZE = 2), Burst_Length = 4 (AxLEN = 3) throughout except FIXED.

#	Type	Start	Per-beat addresses	Note
1	INCR (aligned)	`0x00`	`0x00, 0x04, 0x08, 0x0C`	clean increment
2	INCR (unaligned)	`0x02`	`0x02, 0x04, 0x08, 0x0C`	beat 1 partial; beats 2+ aligned
3	WRAP	`0x08`	`0x08, 0x0C, 0x00, 0x04`	wraps at 16-byte block top
4	FIXED	`0x40`	`0x40, 0x40, 0x40, 0x40`	same address each beat

Example 2 (unaligned INCR), step by step: Aligned_Address = INT(0x02 / 4) × 4 = 0x00. Beat 1 = Start_Address = 0x02 (transfers only bytes 2–3, a partial beat). Beat 2 = 0x00 + 1×4 = 0x04. Beat 3 = 0x00 + 2×4 = 0x08. Beat 4 = 0x00 + 3×4 = 0x0C. So 0x02, 0x04, 0x08, 0x0C.

Example 3 (WRAP), step by step: block size = 4 × 4 = 16, Wrap_Boundary = INT(0x08 / 16) × 16 = 0x00. Beat 1 = 0x08, beat 2 = 0x0C. Beat 3 would be 0x10 = Wrap_Boundary + 16 → wrap to 0x00. Beat 4 = 0x04. So 0x08, 0x0C, 0x00, 0x04.

address-progression — unaligned INCR read from 0x02, 4 bytes/beat

6 cycles

Figure 2 — address-progression: an unaligned INCR read (Example 2), base 0x02, 4 bytes/beat. Beat 0 targets the issued address 0x02 (a partial beat transferring bytes 2–3); beats 1–3 use the aligned progression 0x04, 0x08, 0x0C. The first-beat-at-Start, rest-at-Aligned rule is what produces the partial leading beat.

Figure 3 — the four worked examples side by side. Aligned INCR steps cleanly; unaligned INCR starts at the issued 0x02 then snaps to the aligned progression; WRAP starts at 0x08 and wraps at the 16-byte block top back to 0x00; FIXED holds 0x40 every beat. Same inputs (4 bytes/beat, 4 beats) — the burst type alone changes the address sequence.

4. Choosing the Formula

The whole calculation reduces to: derive the variables, branch on AxBURST, apply the formula:

Figure 4 — the address-calculation decision flow. Compute Number_Bytes, Burst_Length, Aligned_Address; beat 1 is always Start_Address; then branch on AxBURST — FIXED holds the address, INCR steps from Aligned_Address, WRAP steps and wraps at the block boundary. Every per-beat address in AXI comes from this one procedure.

5. Common Misconceptions

Myths to unlearn

"Every beat (including the first) uses Aligned_Address." No — beat 1 uses Start_Address (possibly unaligned, hence a partial first beat); only beats 2+ use Aligned_Address. Flattening the first beat to the aligned address loses the unaligned offset.
"Increment is by 1, or by AxLEN." It's by Number_Bytes = 2^AxSIZE per beat (for INCR/WRAP). Using anything else gives the wrong stride.
"Aligned_Address rounds up." It rounds down — INT(Start / Number_Bytes) × Number_Bytes floors to the size boundary.
"WRAP wraps at a 4 KB (or arbitrary) boundary." It wraps at the Number_Bytes × Burst_Length block boundary, aligned to that block — not 4 KB and not the size boundary.
"FIXED needs the aligned-address math." FIXED just holds Start_Address — no progression, though the active byte lanes are still those the address/size select.
"Unaligned starts apply to WRAP too." No — WRAP requires a size-aligned start; only INCR (and the degenerate FIXED) tolerate unaligned AxADDR.

6. Debugging Insight

🔍 Debugging insight — reconstruct the expected addresses and compare beat-by-beat

Almost every burst-addressing bug is found the same way: recompute the expected per-beat addresses from the formula and compare to where data actually landed.

Wrong stride (gaps or overlaps)? The increment isn't Number_Bytes — recompute Aligned_Address + (N−1)·2^AxSIZE. Too-big a step (e.g., stepping by the bus width instead of 2^AxSIZE on a narrow burst) leaves gaps; too-small overlaps.
First beat misplaced on an unaligned start? The implementation used Aligned_Address for beat 1 instead of Start_Address — the leading partial beat is at the wrong address. Beat 1 must be the issued (possibly unaligned) address.
WRAP wraps at the wrong point (or not at all)? The block size Number_Bytes × Burst_Length or its alignment is miscomputed — recompute Wrap_Boundary and check the wrap happens at Wrap_Boundary + block_size.
Data off by a sub-word offset throughout? Aligned_Address computed with the wrong Number_Bytes (wrong AxSIZE) shifts the whole progression.
FIXED beats marching forward? FIXED logic is incrementing when it must hold Start_Address.

The single most powerful tool here is a reference function implementing the exact spec formula; diff its output against the observed beat addresses and the failing beat localizes the bug (stride, first-beat, or wrap).

7. Verification Insight

✅ Verification insight — a golden address model is the centerpiece

The high-value asset is a golden per-beat address model implementing the spec equations exactly — Start_Address for beat 1, Aligned_Address + (N−1)·Number_Bytes for INCR, the wrap variant for WRAP, hold for FIXED. Every monitored burst's beat addresses are checked against it, and a byte-accurate scoreboard confirms data lands where the model says. This one check catches stride errors, first-beat (unaligned) errors, and wrap-boundary errors uniformly.

Coverage must exercise the arithmetic edges, not just happy paths: aligned and unaligned starts (every sub-size offset), narrow transfers (where Number_Bytes < bus width changes lane usage as the address steps), all WRAP lengths 16 with the start at every offset in the block (so the wrap occurs at each position, including base = INCR-like and top = immediate wrap), and AxSIZE from 1 byte to full width. The most productive directed tests are the unaligned-INCR leading beat and the WRAP wrap point, since those are where the Start vs Aligned distinction and the block math bite. Because the 4 KB rule and strobe progression are computed from these addresses, getting this model right is a prerequisite for Chapters 7.6 and 7.8.

8. Interview Questions

9. Summary

Burst addressing reduces to one procedure. Derive Number_Bytes = 2^AxSIZE, Burst_Length = AxLEN+1, and Aligned_Address = INT(Start/Number_Bytes) × Number_Bytes. Beat 1 is always Start_Address (possibly unaligned → partial). Then branch on AxBURST: FIXED holds Start_Address; INCR uses Aligned_Address + (N−1)·Number_Bytes; WRAP does the same but wraps at Wrap_Boundary + Number_Bytes×Burst_Length back to the block-aligned Wrap_Boundary. The four canonical results — aligned INCR 0x00,04,08,0C; unaligned INCR 0x02,04,08,0C; WRAP-from-0x08 0x08,0C,00,04; FIXED 0x40×4 — capture every case.

The recurring subtleties are the Start vs Aligned split (the partial first beat) and the wrap-boundary math; both are where implementations and verification environments slip. The discipline for both debug and verification is identical: build a golden per-beat address model from these equations and diff it against observed beat addresses, beat by beat. Everything downstream — the 4 KB boundary rule and strobe progression — is computed from these addresses. Next: the 4 KB boundary rule, the one placement constraint a burst's address range must never violate.

10. What Comes Next

You've got the exact addressing arithmetic; next, the constraint it must respect:

7.6 — The 4KB Boundary Rule (coming next) — why no burst may cross a 4 KB boundary, and how masters split transfers to obey it.
7.7 — Narrow & Unaligned Transfers (coming soon) — the partial-beat and lane behavior the unaligned cases here imply.

Previous: 7.4 — WRAP Bursts. Related: 7.1 — Burst Length, Size & Beats for the underlying quantities. 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.