Aligned Access

Chapters 9.1–9.2 covered the transfer sizes and their lane usage. This chapter states the alignment requirement that governs them: an AHB access of size S must be naturally aligned — its address must be a multiple of S (equivalently, the low log2(S) address bits are zero). So a word (4 bytes) must be 4-byte aligned (addr[1:0]=00), a halfword (2 bytes) must be 2-byte aligned (addr[0]=0), and a byte (1 byte) has no constraint (any address). The reason is that natural alignment keeps each access within a single bus word, mapping to a contiguous, aligned set of byte lanes — so the transfer is one clean bus transaction with simple lane handling. An unaligned access would straddle two bus words and span a non-aligned lane group, which AHB does not support. This alignment rule underlies the lane handling of chapter 9.2 and the no-unaligned rule of chapter 9.4.

1. What Is It?

The natural-alignment rule: an access of size S bytes must have an address that is a multiple of S — the low log2(S) address bits must be zero.

For the common sizes:

• Word (4 bytes): 4-byte aligned → addr[1:0] = 00 (addresses 0x00, 0x04, 0x08, …).
• Halfword (2 bytes): 2-byte aligned → addr[0] = 0 (addresses 0x00, 0x02, 0x04, …).
• Byte (1 byte): no constraint → any address (0x00, 0x01, 0x02, …).

The general statement: an access of 2^HSIZE bytes must have its low HSIZE address bits zero. So a byte (HSIZE=0) has no low bits constrained (any address); a halfword (HSIZE=1) has 1 low bit zero (addr[0]=0); a word (HSIZE=2) has 2 low bits zero (addr[1:0]=00); a doubleword (HSIZE=3) has 3 low bits zero (addr[2:0]=000); and so on. So the larger the access, the more low address bits must be zero. This is natural alignment — each access aligned to its own size. AHB requires it: an unaligned access (e.g., a word at 0x02, a halfword at 0x01) is not supported.

2. Why Does It Exist?

Natural alignment exists because it keeps each access within a single bus word, mapping to a contiguous, aligned set of byte lanes — so the transfer is one clean bus transaction with simple lane handling, rather than a complex multi-word, non-aligned access.

Consider the data bus divided into bus-width words (e.g., 4-byte words on a 32-bit bus), each aligned. An access aligned to its size falls entirely within one such bus word: an aligned word fills one whole bus word (all four lanes); an aligned halfword fills an aligned half (an aligned lane pair); an aligned byte fills one lane. So the access maps to a contiguous, aligned lane group within one bus word — clean and simple. The alignment is what guarantees this: aligning to the size ensures the access doesn't cross a bus-word boundary. So natural alignment exists to keep each access within one bus word with a clean lane group.

The reason an unaligned access would be problematic is that it would straddle two bus words: a word at 0x02, for instance, would span the bytes at 0x02–0x05, crossing the bus-word boundary at 0x04 — half in one bus word (0x00–0x03), half in the next (0x04–0x07). So it couldn't be done in one bus transaction (one bus word) — it would need two transfers, plus complex logic to recombine the halves and handle the non-aligned lane group. So unaligned access is problematic because it crosses bus-word boundaries, breaking the one-transfer, contiguous-lane model. Natural alignment avoids this by keeping each access within one bus word.

So AHB requires alignment (forbids unaligned) to keep the hardware simple: with natural alignment, every access is one bus transaction with a contiguous, aligned lane group — the lane derivation (chapter 9.2/9.5) is a simple decode, and there's no multi-transfer recombination. Supporting unaligned access would require splitting accesses, recombining data, and handling non-aligned lanes — significant complexity. So AHB makes the simplifying choice: require alignment, forbid unaligned. This keeps the bus and its components simple, at the cost that software must handle unaligned data itself (chapter 9.4). So the alignment rule exists as a simplicity choice — natural alignment for clean, single-transfer accesses.

3. Mental Model

Model alignment as parking cars in a lot with fixed-size spaces — a car (an access) must fit within marked spaces sized to it, starting at a space boundary, so it doesn't straddle two spaces and block both.

A parking lot (the address space) has marked spaces. A compact car (a byte) fits in any single small space. A larger car (a word) needs a full-size space and must park aligned to the space markings — starting at a space boundary — so it fits within one full-size space. If a large car parked straddling two spaces (unaligned), it would occupy parts of both, blocking both and making a mess — not allowed. So the rule is: park aligned to a space sized to your car, within one space. This keeps each car in its own space cleanly, just as natural alignment keeps each access within one bus word. The bigger the car (the access), the more it must align to a larger space boundary (more low address bits zero).

This captures alignment: parking spaces = bus-word boundaries; a car must fit in a space sized to it, aligned = an access of size S must be S-aligned, within one bus word; straddling two spaces = an unaligned access crossing a bus-word boundary (forbidden); bigger car needs bigger aligned space = larger access needs more low address bits zero. Park within your space, aligned — don't straddle.

Watch aligned addresses for each size:

The model's lesson: each access parks aligned within its space — the low log2(size) address bits are zero. In the waveform, the word at 0x00 (addr[1:0]=00), the halfword at 0x02 (addr[0]=0), and the byte at 0x03 (any) are all aligned for their sizes. A word at 0x02 would straddle a bus-word boundary — unaligned, not allowed.

4. Real Hardware Perspective

In hardware, natural alignment is what makes the byte-lane derivation a simple combinational decode and guarantees each access is a single bus transaction — the alignment is assumed throughout the lane and data-path logic.

Because accesses are naturally aligned, the active byte lanes form a contiguous, aligned group (chapter 9.2): an aligned word uses all lanes, an aligned halfword uses an aligned pair (0–1 or 2–3, never 1–2), an aligned byte uses one lane. So the lane-derivation logic (from HSIZE + address, chapter 9.5) only ever produces these aligned groups — a simple decode. If unaligned accesses were allowed, the lane logic would have to handle non-aligned groups (a halfword spanning lanes 1–2, or an access spanning two bus words), which is far more complex. So natural alignment keeps the lane hardware simple — it only handles aligned lane groups. The alignment is a precondition the hardware relies on.

The single-transaction guarantee is the other hardware benefit: an aligned access fits in one bus word, so it's one bus transaction (one address phase, one data phase). The data path moves the access's bytes in one transfer, on its contiguous lanes. No splitting, no recombination, no multi-transfer state. So the hardware handles every access as a single, clean transaction — because alignment guarantees it fits in one bus word. This is fundamental to the simplicity of the AHB data path: every access is one transaction. Unaligned access would break this (needing two transactions), which is why it's forbidden.

The alignment is the master's responsibility: the master must issue aligned addresses for its access sizes. Processors naturally generate aligned addresses for aligned data (a word load from a word-aligned address), and the compiler/software ensures data is aligned. So the master drives aligned HADDR for its HSIZE, and the bus/slave assume this. There's typically no hardware check for alignment in basic AHB (it's a protocol assumption) — though a protocol checker (verification) would flag an unaligned access as a violation. So in hardware, alignment is assumed and the master must honor it; the slave's lane logic is built assuming aligned accesses. An unaligned access would violate the assumption and cause incorrect lane handling.

A hardware note on doubleword and wider: the rule scales — a doubleword (8 bytes) must be 8-byte aligned (addr[2:0]=000), a 16-byte access 16-byte aligned, etc. So on wider buses with wider accesses, the alignment requirement grows correspondingly (more low bits zero). The principle is the same: align to the size, stay within one bus word. So the alignment rule applies uniformly across all HSIZE values, scaling the number of zero low bits with the size. The wider the access, the stricter the alignment.

5. System Architecture Perspective

At the system level, natural alignment is a contract between software and hardware — software ensures data is aligned to its access size, and the hardware relies on it for simple, single-transaction accesses — making alignment a foundational system convention (and the reason compilers align data).

The software-hardware contract is the key framing: the hardware (AHB) requires aligned accesses, so software (compilers, drivers) must ensure data is laid out and accessed aligned. Compilers align data structures (a 32-bit field at a 4-byte-aligned offset, etc.) precisely so accesses are naturally aligned. So alignment is a contract: hardware requires it, software provides it. This is why data structures have alignment/padding — the compiler aligns each field to its size so accesses are aligned. So at the system level, alignment shapes data layout (padding, structure packing) to honor the hardware's requirement. The contract is pervasive: it affects how all data is laid out in memory.

The consequence for unaligned data is that software must handle it explicitly (chapter 9.4): if software needs to access data that isn't naturally aligned (e.g., a misaligned field in a packed structure, or unaligned network data), it can't issue a single unaligned AHB access — it must use multiple aligned accesses and recombine (or the processor traps and emulates). So unaligned data is a software burden, not a hardware feature. This is a deliberate trade: the hardware stays simple (aligned only), and software handles the (rarer) unaligned cases. So at the system level, the alignment requirement pushes unaligned handling to software — which is acceptable because most data is aligned (the compiler ensures it), and unaligned access is the exception.

The architectural payoff is hardware simplicity and uniformity: because every access is aligned, every component (master, interconnect, slave, memory) handles only single-transaction, contiguous-lane accesses — simpler, faster, more uniform than supporting unaligned access. So the alignment requirement is a system-wide simplification that benefits all components. This is the same trade many architectures make (most RISC ISAs require or prefer alignment): require alignment for hardware simplicity, handle the rare unaligned cases in software. So AHB's alignment requirement aligns (so to speak) with the broader system architecture — aligned data, aligned access, simple hardware, software handling exceptions. It's a foundational convention that keeps the whole data path simple, and it's why alignment matters far beyond the bus (it shapes data structures, ISAs, and compilers). The bus's alignment requirement is one instance of the system-wide alignment discipline.

6. Engineering Tradeoffs

Natural alignment embodies the require-alignment-for-simplicity choice.

• Require alignment vs support unaligned. Requiring natural alignment keeps the hardware simple (single-transaction, contiguous-lane accesses) at the cost that software must handle unaligned data. Supporting unaligned access would burden the hardware (splitting, recombination, non-aligned lanes). AHB requires alignment — hardware simplicity, software handles exceptions.
• Align-to-size vs a fixed alignment. Requiring each access to align to its own size (word to 4, halfword to 2) is exactly what keeps it within one bus word. A fixed alignment (e.g., always 4) would be simpler to state but waste flexibility for sub-word accesses. Align-to-size is the precise rule.
• Master ensures alignment vs hardware checks. Basic AHB assumes the master issues aligned addresses (no hardware alignment check) — simple, trusting. A hardware check would add logic. Verification (protocol checkers) flags violations instead. AHB trusts the master, checks in verification.
• Software burden vs hardware burden. Pushing unaligned handling to software (the rare case) keeps the common case (aligned) fast and simple. Putting it in hardware would slow/complicate every access. AHB puts the burden on software — optimize the common aligned case.

The throughline: AHB requires natural alignment — an access of size S must be S-aligned (low log2(S) address bits zero) — because it keeps each access within one bus word, mapping to a contiguous aligned lane group, so the transfer is a single clean transaction with simple lane handling. The cost is that software must handle unaligned data (via multiple aligned accesses), accepted because most data is aligned (compilers ensure it) and the hardware simplification is large. Alignment is a software-hardware contract and a foundational system convention.

7. Industry Example

Trace alignment across a system's accesses.

A processor with a compiler-managed memory layout accesses aligned data on a 32-bit bus.

• Aligned word accesses. The processor loads 32-bit integers and instructions from word-aligned addresses (the compiler placed them at 4-byte-aligned offsets). Each is a word access at addr[1:0]=00 — aligned, within one bus word, one transaction, all four lanes. The common case, naturally aligned by the compiler.
• Aligned halfword accesses. The processor accesses 16-bit values at 2-byte-aligned addresses (addr[0]=0). Each halfword fits within one bus word (an aligned lane pair) — one transaction. The compiler aligned the 16-bit fields to 2 bytes.
• Byte accesses (any address). The processor accesses single bytes at any address — no alignment constraint. A byte fits in one lane regardless. Characters, flags, byte-wide registers.
• The compiler's role. The compiler lays out data structures with alignment and padding: a struct with a byte, a halfword, and a word has the halfword at a 2-aligned offset and the word at a 4-aligned offset (with padding as needed). So every field access is naturally aligned. This is why structs have padding — to align each field to its size for aligned access. The compiler honors the hardware's alignment contract.
• Unaligned data — software handles it. Suppose the processor needs a 32-bit value from a misaligned address (e.g., unaligned network data, or a packed structure). It cannot issue a single unaligned word access. Instead, software accesses it as multiple aligned accesses (e.g., aligned bytes or halfwords) and recombines — or, on some processors, the hardware traps the unaligned access and software emulates it (chapter 9.4). So the unaligned case is handled in software, not by a single AHB access. This is the rare exception; most data is aligned.
• No unaligned AHB accesses. Throughout, the processor issues only aligned AHB accesses — the bus never sees an unaligned access. The compiler's alignment and software's handling of unaligned data ensure this. The hardware stays simple (aligned only), relying on the contract.

The example shows alignment as the software-hardware contract: the compiler aligns data (padding structs, aligning fields) so accesses are naturally aligned, the processor issues only aligned AHB accesses, and the rare unaligned data is handled in software (multiple aligned accesses or trap-and-emulate). The hardware never sees an unaligned access — the contract keeps it simple.

8. Common Mistakes

9. Interview Insight

Alignment is a foundational interview check — the size-aligned rule and the why (one bus word, contiguous lanes) are the signals.

The answer that lands states the rule and the why: "AHB requires natural alignment — an access of size S must be aligned to S, meaning its address is a multiple of S, so the low log2(S) address bits are zero. A word must be 4-byte aligned, so the low two address bits are zero; a halfword must be 2-byte aligned, so the low bit is zero; a byte has no constraint. The reason is that natural alignment keeps each access within a single bus word, so it maps to a contiguous, aligned set of byte lanes — one clean bus transaction with simple lane handling. An unaligned access would straddle two bus words and span a non-aligned lane group, needing two transfers and complex logic — so AHB forbids it. The master must issue aligned addresses; if software has unaligned data, it handles it with multiple aligned accesses. It's a software-hardware contract — compilers align data so accesses are aligned." The size-aligned rule, the one-bus-word/contiguous-lanes rationale, and the software-hardware contract are the senior signals.

10. Practice Challenge

Reason from the alignment rule.

1. State the rule. Give the alignment requirement for word, halfword, byte, and doubleword.
2. Check addresses. Which are valid: a word at 0x08, a word at 0x06, a halfword at 0x03, a byte at 0x05?
3. Explain the why. Why does alignment keep an access within one bus word, and why does that matter?
4. Unaligned handling. Explain how software accesses unaligned data without an unaligned AHB access.
5. Data layout. Explain why compilers pad data structures.

11. Key Takeaways

• An AHB access of size S must be naturally aligned — its address a multiple of S, so the low log2(S) address bits are zero.
• Per size: word → 4-aligned (addr[1:0]=00); halfword → 2-aligned (addr[0]=0); byte → any address; doubleword → 8-aligned (addr[2:0]=000). The larger the access, the more low bits must be zero.
• Alignment keeps each access within one bus word, mapping to a contiguous, aligned lane group — one clean bus transaction with simple lane handling.
• An unaligned access would straddle two bus words and span a non-aligned lane group (needing two transfers and recombination) — so AHB forbids it.
• The master must issue aligned addresses (basic AHB doesn't check in hardware; verification flags violations). Unaligned data is handled in software (multiple aligned accesses).
• Alignment is a software-hardware contract — compilers align/pad data so accesses are naturally aligned, keeping the hardware simple. It shapes data layout system-wide.

12. What Comes Next

You now understand the alignment requirement. The next chapters cover the no-unaligned rule and the lane derivation:

• 9.4 — Unaligned Access Rules (coming next) — why AHB forbids unaligned access and the consequences.
• 9.5 — Lane Selection (coming soon) — the general rule for deriving the active byte lanes from address and size.

To revisit the sizes and their lanes, see Byte, Halfword & Word Transfers; for the HSIZE encoding, HSIZE Encoding. For the HADDR signal, see HADDR & HWRITE. For the broader protocol map, see the AMBA family overview.