Unaligned Access Rules

Chapter 9.3 established the alignment requirement. This chapter focuses on the unaligned case specifically: why AHB forbids it, what happens if you issue one, and how systems handle data that is inherently unaligned. An unaligned access has an address that is not a multiple of its size (a word at 0x02, a halfword at 0x01). AHB does not support it, for three reasons: it would straddle two bus words (needing two transfers and recombination), it would span a non-aligned lane group the simple decode can't produce, and it could cross a decode or protection boundary into another region. Since basic AHB typically has no hardware check, an unaligned access is a protocol violation with incorrect behavior. Inherently-unaligned data (packed structures, network data) is handled in software — decomposed into multiple aligned accesses, or trapped and emulated. So AHB forbids unaligned access for hardware simplicity, pushing the rare unaligned case to software.

1. What Is It?

An unaligned access is one whose address is not a multiple of its size — a word at 0x02, a halfword at 0x01, etc. (the low log2(size) address bits are not zero). AHB does not support unaligned accesses. Three reasons:

1. It straddles two bus words — crosses a bus-word boundary, so it can't be done in one transaction (would need two transfers plus recombination).
2. It spans a non-aligned lane group — e.g., a halfword across lanes 1–2, which the simple size+address lane decode (chapter 9.2/9.5) can't produce.
3. It could cross a decode or protection boundary — the two halves might fall in different subordinates or protection regions — ambiguous and unsafe.

So AHB forbids unaligned access to preserve the clean access model: every access is a single transaction, within one bus word, with contiguous aligned lanes, in one region. An unaligned access breaks all three. And because basic AHB typically has no hardware alignment check, issuing an unaligned access doesn't get cleanly rejected — it produces incorrect behavior (the lane logic, assuming alignment, mishandles it). So an unaligned access is a protocol violation the master must avoid, not a feature the hardware supports.

2. Why Does It Exist? (Why the prohibition)

The prohibition exists because supporting unaligned access would impose large hardware complexity for a rare case — and AHB chooses the simplifying trade: forbid unaligned, handle it in software.

The complexity an unaligned access would require is substantial. To support a word at 0x02 (straddling 0x00–0x03 and 0x04–0x07), the hardware would need to: issue two bus transactions (one per bus word), with logic to split the access and recombine the data; handle a non-aligned lane group (the lane decode would need to produce arbitrary, non-aligned masks); and manage the case where the two halves fall in different regions (different subordinates or protection domains) — which is genuinely ambiguous (which subordinate? which permission?). So supporting unaligned access would complicate the master (split/recombine), the lane logic (non-aligned masks), and the decode/protection handling (multi-region). That's a lot of hardware. So the prohibition exists to avoid this complexity — AHB keeps the hardware simple by not supporting unaligned access.

The reason this is an acceptable trade is that unaligned access is rare: most data is naturally aligned (compilers ensure it, chapter 9.3), so the common case is always aligned. Only occasionally is data inherently unaligned (packed structures, network/file formats). So forbidding unaligned access burdens only the rare case (software handles it), while keeping the common case (aligned) fast and the hardware simple. This is the classic optimize-the-common-case trade: don't burden every access with unaligned-handling hardware for a rare case; handle the rare case in software. So the prohibition exists because the complexity isn't worth it for a rare case — software can decompose unaligned accesses when needed.

The reason there's typically no hardware check (an unaligned access just misbehaves) is also simplicity: adding alignment-check hardware to every access would cost logic, and AHB instead assumes the master honors alignment (a protocol obligation). So the master must avoid unaligned accesses, and verification (protocol checkers) flags violations — rather than the hardware checking at runtime. This is consistent with AHB's lean design: assume well-behaved masters, check in verification, don't add runtime-check hardware. So the prohibition is enforced by convention and verification, not by a runtime hardware check — keeping the hardware minimal. (A processor's load/store unit might check alignment and trap, but that's the processor, not the AHB bus itself.)

3. Mental Model

Model the unaligned prohibition as a mail system that only accepts standard-sized envelopes in standard slots — an odd-sized item that spans two slots isn't accepted; you must repackage it into standard envelopes, and the system stays simple by not handling odd sizes.

A mail system (the bus) has standard slots (bus words) and accepts standard envelopes (aligned accesses) that fit one slot. An odd item that would span two slots (an unaligned access) isn't accepted — handling it would require the system to split it across slots, track both parts, and figure out if the parts go to different destinations (different regions) — a lot of complexity for an unusual item. So the system forbids odd items and stays simple. If you have an odd-sized item (inherently unaligned data), you repackage it into standard envelopes (decompose into aligned accesses) before mailing — the system only ever handles standard envelopes. The mail system optimizes for the common case (standard envelopes) and pushes the rare odd-item repackaging to the sender (software).

This captures the prohibition: standard slots/envelopes = bus words / aligned accesses; odd item spanning two slots = an unaligned access (forbidden); the complexity of handling odd items = split/recombine/multi-region; repackage into standard envelopes = software decomposing into aligned accesses; system stays simple = hardware avoids unaligned-handling complexity. Forbid the odd case, repackage in software, keep the system simple.

Watch an unaligned attempt vs the aligned decomposition:

The model's lesson: the unaligned access isn't accepted — software repackages it into aligned accesses. In the waveform, the word at 0x02 is forbidden (unaligned); software instead issues aligned accesses (e.g., halfwords at 0x02 and 0x04) and combines them. The bus only ever sees aligned accesses — the unaligned access never reaches it.

4. Real Hardware Perspective

In hardware, the prohibition means the bus and slaves are built assuming aligned accesses — there's no unaligned-handling logic — and an unaligned access would mis-drive the lane logic and possibly the decode, producing incorrect results.

The slave's lane logic assumes alignment: it derives the active lanes from HSIZE + the low address bits expecting a contiguous, aligned group (chapter 9.2/9.5). If given an unaligned access, the lane derivation would produce an incorrect or undefined lane group (it's not built to handle a halfword spanning lanes 1–2, or an access crossing the bus word). So the slave would mishandle the data — wrong lanes, wrong bytes. There's no logic to split the access across two bus words or recombine — that simply doesn't exist in basic AHB. So an unaligned access doesn't get split-and-handled; it gets mishandled by logic that assumed alignment. This is why an unaligned access produces incorrect behavior, not a clean two-transfer access.

The no-hardware-check reality means the unaligned access isn't cleanly rejected either — basic AHB typically doesn't check alignment at the bus level, so the access just proceeds and misbehaves. So there's no error response for "unaligned" (that's not a defined AHB error); the access simply does the wrong thing. The master is responsible for not issuing unaligned accesses. A processor's load/store unit may itself check alignment and trap (an alignment fault) before issuing the access — but that's the processor's doing, not the AHB bus's. So in hardware, the prohibition is enforced upstream of the bus (by the master/processor), not at the bus. The bus assumes it never sees an unaligned access.

The decomposition into aligned accesses is how unaligned data actually reaches the bus: software (or the processor's trap handler) breaks an unaligned access into multiple aligned accesses. For example, an unaligned word might be read as four aligned byte accesses (at the four constituent addresses), then the bytes shifted and combined; or as two aligned halfword/word accesses with masking and shifting. Each of these is aligned, so the bus handles them normally. So in hardware, what the bus sees is a sequence of aligned accesses (the decomposition), never the unaligned access itself. The recombination happens in software (or the trap handler), not on the bus. This keeps the bus hardware simple — it only ever processes aligned accesses.

A hardware note on AXI's approach: AXI (the more capable successor) supports unaligned start addresses for bursts (with byte strobes indicating valid bytes), giving more flexibility — but even AXI has alignment-related rules (e.g., not crossing 4KB boundaries) and uses byte strobes (WSTRB) for partial-lane writes. So later protocols offer more unaligned flexibility, but AHB's choice (aligned only) is the simpler one. Note also that even within AHB, sub-word aligned accesses (a byte, a halfword at an aligned address) use partial lanes (chapter 9.2) — that's aligned partial-lane use, which AHB supports; what it doesn't support is unaligned access (crossing the bus-word boundary). So the distinction is aligned-partial-lane (supported) vs unaligned (not). AHB handles partial lanes for aligned sub-word accesses but not unaligned accesses.

5. System Architecture Perspective

At the system level, the unaligned prohibition pushes unaligned-data handling to software, which is acceptable because most data is aligned — but it means software (and the processor) must detect and handle the rare unaligned cases, a real consideration for certain data formats.

The software-handles-unaligned model is the system consequence: since the bus only accepts aligned accesses, any inherently-unaligned data must be handled in software — either by the compiler/programmer explicitly using aligned accesses, or by the processor trapping unaligned accesses and emulating them. So the system has a layer (software or the processor's trap handler) that converts unaligned accesses into aligned ones. This is a real software cost for unaligned data: extra instructions (multiple aligned accesses + shifts/masks) or a trap-and-emulate penalty. So at the system level, unaligned data is slower (handled in software) — which is why aligned data is preferred and unaligned data is avoided where performance matters.

The data formats that involve unaligned data are a system concern: packed structures (where padding is disabled to save space, so fields aren't aligned), network protocols (where headers have fields at byte offsets that may not be aligned), and file formats (with arbitrary field placement). When software accesses these, it encounters unaligned data and must handle it (aligned accesses + recombination). So a system dealing with such formats needs unaligned-handling code (or a processor that traps-and-emulates). This is a known consideration in systems programming: packed/network/file data requires careful unaligned handling. So the prohibition shapes how software deals with these formats — it can't just issue an unaligned access; it must decompose.

The architectural rationale is the optimize-the-common-case trade extended system-wide: hardware (the bus, and often the processor's fast path) optimizes for aligned access (the common case), and unaligned access (the rare case) is handled by slower software or a trap. So the system as a whole is built around aligned access being fast and unaligned being slow-but-possible. This is a deliberate, widespread architectural choice (most RISC architectures, and AHB, make it): require/prefer alignment for hardware speed and simplicity, handle unaligned in software. So AHB's unaligned prohibition is one instance of this system-wide discipline. The payoff is fast, simple hardware for the common aligned case; the cost is software handling for the rare unaligned case. Understanding this connects AHB's alignment rule to the broader principle that aligned access is the fast path across the whole system stack.

6. Engineering Tradeoffs

The unaligned prohibition embodies the forbid-unaligned-for-simplicity trade.

• Forbid unaligned (simple HW) vs support it (complex HW). Forbidding unaligned access keeps the hardware simple (single-transaction, contiguous-lane, single-region) at the cost that software handles unaligned data. Supporting it would require split/recombine, non-aligned lanes, and multi-region handling — large complexity for a rare case. AHB forbids it — simplicity.
• No hardware check vs runtime check. Basic AHB assumes the master honors alignment (no runtime check) — simplest. A runtime check would add logic and an error path. AHB trusts the master (and checks in verification / at the processor). The trade is minimal hardware vs runtime detection.
• Software decomposition vs hardware support. Handling unaligned data via software decomposition (multiple aligned accesses) keeps the hardware simple at the cost of slower unaligned access. Hardware support would speed unaligned access but complicate every access. AHB chooses software decomposition for the rare case.
• Optimize common (aligned) case. The whole trade optimizes the common aligned case (fast, simple) and accepts a slow path for the rare unaligned case. This is the standard architectural choice (RISC ISAs, AHB) — common-case-fast.

The throughline: AHB forbids unaligned access — it would straddle two bus words, span a non-aligned lane group, and possibly cross a region — because supporting it would impose large hardware complexity for a rare case. Instead, the hardware optimizes the common (aligned) case, and inherently-unaligned data is handled in software (decomposed into aligned accesses) or by a processor trapping and emulating. With typically no hardware check, an unaligned access is a protocol violation the master must avoid. This is the optimize-the-common-case trade, applied system-wide.

7. Industry Example

Trace how a system handles unaligned data.

A system processes network packets (with byte-offset fields) and packed data structures on a 32-bit AHB.

• Aligned data — direct accesses. Most of the system's data is naturally aligned (compiler-managed), so the processor issues aligned word/halfword/byte accesses directly — the common, fast path. No unaligned handling needed.
• A network header field — unaligned. A network protocol header has a 32-bit field at a byte offset that isn't 4-aligned (say, at offset 0x0E in the packet buffer). The processor can't issue a single unaligned word access for it. So software reads it as aligned accesses — e.g., aligned halfword/byte reads of the constituent bytes — and shifts and combines them into the 32-bit value. The bus sees only the aligned accesses; the recombination is in software. The unaligned field is handled correctly, just with extra instructions.
• A packed structure — unaligned fields. A packed structure (padding disabled to save space) has fields at unaligned offsets. Accessing a 32-bit field that lands at an unaligned offset requires the same treatment: aligned accesses + recombination in software. So packed structures incur this unaligned-handling cost — which is the trade for their smaller size.
• Trap-and-emulate (alternative). On a processor that supports unaligned-access trapping, the program might issue what looks like an unaligned load (in the source), and the processor traps it, running a handler that decomposes it into aligned accesses and emulates the result — transparent to the program, but slower (the trap + handler overhead). So some systems handle unaligned access transparently via trap-and-emulate, at a performance cost. The bus still only sees aligned accesses (the handler's decomposition).
• No unaligned access on the bus. Throughout, the AHB bus never sees an unaligned access — every access on the bus is aligned. The unaligned network/packed data is handled by software (decomposition) or the processor (trap-and-emulate), upstream of the bus. So the bus hardware stays simple (aligned only), and the unaligned cases are absorbed by software.

The example shows the unaligned prohibition in practice: aligned data accessed directly (fast), and inherently-unaligned data (network headers, packed structures) handled in software — decomposed into aligned accesses, or trapped-and-emulated by the processor. The bus never sees an unaligned access; software/the processor converts unaligned to aligned upstream. This is the cost of AHB's aligned-only simplicity, paid by software for the rare unaligned data.

8. Common Mistakes

9. Interview Insight

The unaligned prohibition is a common interview topic — knowing why it's forbidden and how unaligned data is handled is the signal.

The answer that lands gives the reasons and the handling: "AHB doesn't support unaligned access — an access whose address isn't a multiple of its size. There are three reasons it's forbidden: it would straddle two bus words, crossing a bus-word boundary, so it couldn't be done in one transaction — it'd need two transfers and recombination; it would span a non-aligned lane group, like a halfword across lanes 1–2, which the simple size-plus-address lane decode can't produce; and it could cross a decode or protection boundary, with the two halves in different subordinates or regions. Supporting all that would be a lot of hardware for a rare case, so AHB forbids it. And basic AHB typically doesn't check alignment in hardware, so an unaligned access isn't cleanly rejected — it just misbehaves, mishandled by logic that assumed alignment. So the master must never issue one. Inherently-unaligned data — packed structures, network headers — is handled in software: decomposed into multiple aligned accesses and recombined, or the processor traps the unaligned access and emulates it. Either way, the bus only ever sees aligned accesses." The three reasons, the no-hardware-check consequence, and the software handling are the senior signals.

10. Practice Challenge

Reason from the unaligned prohibition.

1. Define unaligned. Give the definition and two examples of unaligned accesses.
2. Three reasons. State why an unaligned access is problematic.
3. Read the waveform. From Figure 2, explain what's forbidden and how software handles it.
4. No check. Explain what happens if a master issues an unaligned access on basic AHB.
5. Aligned vs unaligned sub-word. Distinguish an aligned halfword from an unaligned one.

11. Key Takeaways

• AHB does not support unaligned access (address not a multiple of the size) — for three reasons: it would straddle two bus words, span a non-aligned lane group, and possibly cross a decode/protection boundary.
• The prohibition is an optimize-the-common-case trade — supporting unaligned access would impose large hardware complexity for a rare case, so AHB forbids it.
• Basic AHB typically has no hardware alignment check — an unaligned access isn't cleanly rejected; it misbehaves. So the master must never issue one (a protocol violation).
• Inherently-unaligned data is handled in software — decomposed into multiple aligned accesses (+ shift/combine), or by a processor trapping and emulating. The bus only ever sees aligned accesses.
• Aligned sub-word accesses (byte/halfword) are supported (partial lanes within one bus word) — only unaligned access (crossing the bus-word boundary) is forbidden.
• This is a system-wide discipline — most architectures make the same trade (aligned fast path, unaligned in software); packed/network/file data requires software unaligned handling.

12. What Comes Next

You now understand why unaligned access is forbidden and how unaligned data is handled. The next chapter gives the general lane-derivation rule:

• 9.5 — Lane Selection (coming next) — the general rule for deriving the active byte lanes from the address and size (generalizing the byte/halfword/word lanes to any bus width).

To revisit the alignment rule, see Aligned Access; for the sizes and their lanes, Byte, Halfword & Word Transfers. For the decode boundary an unaligned access might cross, see Boundary Wrapping. For the broader protocol map, see the AMBA family overview.