Endianness Considerations

Chapter 9.5 gave the lane-from-address rule: a byte goes on the lane for its byte address. But which byte of a multi-byte value sits at which address is a separate question — answered by endianness. This chapter covers big- vs little-endian byte placement. Little-endian puts the least significant byte at the lowest address (and lane); big-endian puts the most significant byte at the lowest address. The crucial point: the lane-from-address rule is the same in both — endianness only decides the value→byte→address mapping, layered on the fixed lane rule. AHB supports both endiannesses, but all components must agree — a master and slave that disagree would byte-swap and corrupt every multi-byte value. Where domains of different endianness meet, an explicit byte-swap converter is required. Endianness is a system-wide convention that, with lane selection, completes the data-placement picture.

1. What Is It?

Endianness is the convention for which byte of a multi-byte value sits at which address (and hence which byte lane). For a value like 0x11223344 (MSB 0x11 … LSB 0x44) stored at a word address:

• Little-endian: the least significant byte (0x44) is at the lowest address (lane 0), the MSB (0x11) at the highest (lane 3).
• Big-endian: the most significant byte (0x11) is at the lowest address (lane 0), the LSB (0x44) at the highest (lane 3).

The key distinction: the lane-from-address rule (chapter 9.5) is unchanged — a byte at address A still goes on the lane for byte position A mod W. What endianness changes is which byte of the value is at address A. So a byte read of addr+0 returns the LSB (0x44) under little-endian or the MSB (0x11) under big-endian — same address, different byte. Endianness is thus a layer on top of lane selection: lane selection says "byte at address A → lane (A mod W)"; endianness says "byte at address A is this byte of the value." Together they place every byte of every value on its lane.

2. Why Does It Exist?

Endianness exists because a multi-byte value must be broken into bytes and placed at consecutive addresses somehow — and there are two natural orderings (LSB-first or MSB-first). Neither is inherently better, so both conventions exist, and a system must choose one.

A 32-bit value has four bytes that must occupy four consecutive byte addresses in byte-addressable memory. The value itself has an MSB and an LSB, but byte addresses don't intrinsically have a "most" or "least significant" end — so there's a choice: put the LSB at the lowest address (little-endian) or the MSB at the lowest address (big-endian). Both are coherent, self-consistent conventions; neither is fundamentally right. So endianness exists because mapping a value to consecutive byte addresses requires choosing a byte order, and history produced two. The choice is somewhat arbitrary (different processor families chose differently — x86 little-endian, some others big-endian), so both conventions persist.

The reason the lane-from-address rule is unchanged is that lane selection (chapter 9.5) is about byte addresses → lanes, which is fixed by the bus structure, while endianness is about value → byte addresses, a separate mapping. The bus always puts the byte at address A on lane (A mod W) — that's physical. Endianness only affects which byte of the value is at address A, which is a software/convention question, not a bus-structure one. So endianness sits above lane selection: it determines the value-to-address mapping, then lane selection routes each byte-address to its lane. So the lane rule doesn't change with endianness — only the value's byte placement does. This separation is why endianness and lane selection are distinct concerns.

The reason all components must agree is that endianness is an interpretation of the bytes — if a master writes a value little-endian (LSB at addr+0) and a slave reads it big-endian (interpreting addr+0 as the MSB), the slave reconstructs the value with its bytes reversed — a byte-swapped, corrupted value. So a consistent endianness is essential: every component must place and interpret multi-byte values the same way, or values corrupt on transfer. AHB supports both endiannesses (it doesn't mandate one), but within a system, all components must use the same one. Where two domains of different endianness must interoperate (e.g., a little-endian processor and a big-endian peripheral), an explicit byte-swap converter is needed to translate. So endianness must be consistent because it's a shared interpretation — disagreement means byte-swapped data.

3. Mental Model

Model endianness as two conventions for writing a multi-digit number into numbered boxes — left-to-right (most significant first) vs right-to-left (least significant first) — where everyone must read it the same way they wrote it, or they get the digits reversed.

You write a number like 1234 into four numbered boxes (consecutive addresses). One convention (big-endian) writes it most-significant-digit-first: box 0 gets 1, box 1 gets 2, box 2 gets 3, box 3 gets 4. The other (little-endian) writes it least-significant-digit-first: box 0 gets 4, box 1 gets 3, box 2 gets 2, box 3 gets 1. Both are valid ways to store the number; the boxes (addresses) are the same, only the digit-to-box assignment differs. But the reader must use the same convention as the writer: if you wrote MSB-first and someone reads it LSB-first, they reconstruct 4321 — the number reversed. So everyone in the system must agree on the convention. If two systems use different conventions and must exchange numbers, you need a translator that reverses the digits (a byte-swap converter).

This captures endianness: the numbered boxes = consecutive byte addresses (and lanes, fixed); MSB-first vs LSB-first = big- vs little-endian; the digit-to-box assignment = which byte of the value at each address; reader must match writer = all components must agree; translator reverses digits = byte-swap converter for mismatched domains. The boxes are fixed; the convention decides which digit goes where, and everyone must agree.

Watch the same value on the bus in each endianness:

The model's lesson: the lanes (addresses) are fixed; endianness decides which byte of the value sits on each. In the waveform, little-endian and big-endian place different bytes on each lane for the same value — so all components must agree on the convention, or they'd reconstruct the value with bytes reversed.

4. Real Hardware Perspective

In hardware, endianness determines how a master places a multi-byte value's bytes onto the data-bus lanes and how a slave interprets the lanes — and AHB's protocol signals (HADDR, HSIZE) are endianness-agnostic, so endianness is a system convention, not a per-transfer signal.

A master writing a multi-byte value drives its bytes onto the lanes per its endianness: little-endian drives the LSB on lane 0 (addr+0) up to the MSB on the top lane; big-endian the reverse. So the master's data-path wiring (which byte of the register goes to which lane) embodies its endianness. A slave reading interprets the lanes per its endianness: it takes lane 0 as the LSB (LE) or MSB (BE) of the value. So both the master's placement and the slave's interpretation are endianness-specific, baked into their data paths. The bus just carries the bytes on their lanes (per the fixed lane rule); the endianness is in how the value's bytes map to those lanes at each end.

The protocol is endianness-agnostic: AHB's signals (HADDR, HSIZE, HWDATA, HRDATA) don't encode endianness — there's no "endianness" signal. The bus carries bytes on lanes by address (chapter 9.5); endianness is purely a convention about which byte of a value is at each address, decided by the components' data-path design. So AHB supports both endiannesses without mandating one — a little-endian system and a big-endian system both use the same AHB protocol, differing only in their components' byte placement. This is why endianness is a system convention, not a protocol feature: the protocol is neutral; the components implement one endianness. (Some configurable cores have an endianness configuration, but it's about the core's data-path, not an AHB signal.)

The consistency requirement is a hardware reality: all components on the bus must place/interpret multi-byte values the same way, or values corrupt. If a master is little-endian and a slave big-endian, the slave reads the master's bytes in the wrong order — byte-swapped value. So a system is designed with one endianness throughout (all components matching). Where a different-endianness component must connect (e.g., a big-endian legacy peripheral in a little-endian system), a byte-swap converter is inserted — hardware that reverses the byte order of multi-byte values crossing the boundary. So in hardware, endianness consistency is ensured by design (matching components), with explicit byte-swap hardware at any endianness boundary. There's no automatic endianness translation in basic AHB — it's design discipline plus converters where needed.

A hardware note on byte-invariant vs word-invariant addressing (a subtlety of how endianness interacts with the bus): the AHB convention is typically byte-invariant — a given byte address always maps to the same lane regardless of access size, and endianness affects only how multi-byte values are split across addresses. This keeps the lane mapping consistent (the lane-from-address rule, chapter 9.5, is endianness-independent). So the byte-invariant view aligns with our framing: lanes by address (fixed), values to addresses by endianness (the convention). This is the cleanest way to think about it: byte addresses → lanes is fixed; values → byte addresses is endianness.

5. System Architecture Perspective

At the system level, endianness is a foundational system-wide convention — chosen once, applied everywhere — and it interacts with software, data interchange, and any cross-endianness interfaces, making it a key integration consideration.

The system-wide choice is fundamental: a system picks an endianness (driven by its processor — ARM is configurable but often little-endian, x86 little-endian, some others big-endian) and applies it consistently across all components. So endianness is decided at the architecture level and pervades the whole system: memory layout, component data paths, software data structures. This is why endianness is a basic property of an architecture — it's a system-wide convention that everything must respect. Mixing endiannesses within a system is avoided (it requires converters everywhere); instead, one endianness is chosen and used throughout.

The software interaction is significant: software must know the system's endianness when interpreting multi-byte data, especially data that crosses systems (network data, files). Network byte order is big-endian (by convention), so a little-endian system must byte-swap multi-byte values when sending/receiving network data (the familiar htonl/ntohl functions). Similarly, file formats specify an endianness, and software byte-swaps if the system's endianness differs. So endianness is a pervasive software concern for data interchange — programs must handle the conversion when their endianness differs from the data's. This is why endianness matters beyond hardware: it affects how software reads/writes external data. (Within a single-endianness system, software needn't worry — but cross-system data requires endianness awareness.)

The cross-endianness interfaces require explicit handling: when connecting components or systems of different endianness — a big-endian peripheral in a little-endian SoC, or two systems exchanging data — a byte-swap converter translates multi-byte values at the boundary. So at the system level, endianness boundaries are explicit design points where byte-swapping happens. An architect integrating a different-endianness component must insert this conversion (in hardware at the bus, or in software at the data layer). So endianness, while ideally uniform within a system, becomes an explicit interface concern at any boundary between different-endianness domains. This is a real integration consideration: identify endianness boundaries and provide conversion. So endianness is both a uniform internal convention and an explicit boundary concern — chosen system-wide, handled with converters where domains differ. Understanding endianness is essential for correct data interpretation, software portability, and system integration — a foundational convention with system-wide reach.

6. Engineering Tradeoffs

Endianness reflects the choose-a-convention-and-be-consistent design.

• Little-endian vs big-endian. Neither is fundamentally better — both are coherent conventions. Little-endian is common (x86, often ARM) and has some conveniences (the LSB at addr+0 simplifies certain casts); big-endian (network order, some architectures) is also coherent. The choice is architectural, driven by the processor.
• Protocol-agnostic vs protocol-encoded. AHB being endianness-agnostic (no endianness signal) keeps the protocol simple and supports both — at the cost that endianness is a system convention components must implement consistently. Encoding endianness per-transfer would complicate the protocol. AHB stays neutral.
• Uniform endianness vs mixed. Using one endianness system-wide avoids conversion overhead, at the cost of needing converters at any different-endianness interface. Mixing endiannesses would require pervasive conversion. Systems choose uniform endianness, converting only at external boundaries.
• Hardware vs software byte-swap. At an endianness boundary, byte-swapping can be done in hardware (a converter at the bus) or software (at the data layer, e.g., htonl). Hardware is transparent but fixed; software is flexible. Systems use whichever fits the boundary.

The throughline: endianness is the system-wide convention for which byte of a multi-byte value sits at each address — little-endian (LSB at lowest) or big-endian (MSB at lowest) — layered on the fixed lane-from-address rule. AHB is endianness-agnostic (supports both, mandates neither), so components must implement one endianness consistently, with explicit byte-swap converters at any boundary between different-endianness domains. It's a foundational architectural choice with system-wide reach — affecting memory layout, software data interpretation, and cross-system data interchange.

7. Industry Example

Trace endianness across a system and its interfaces.

A little-endian SoC (processor, memory, peripherals all little-endian) exchanges data with external systems.

• Internal accesses — all little-endian. The processor, memory, and peripherals are all little-endian: a 32-bit value 0x11223344 is stored with 0x44 at the lowest address (lane 0). Every internal access places and interprets multi-byte values little-endian, so they transfer correctly. The system is uniformly little-endian — no conversion needed internally. This is the common case: one endianness throughout.
• Network data — big-endian, needs swapping. The SoC sends/receives network packets, and network byte order is big-endian. So when the processor sends a 32-bit value over the network, it must byte-swap it (little-endian → big-endian) before transmission, and byte-swap received values back. Software uses htonl/ntohl (host-to-network / network-to-host) to do this. So the network interface is an endianness boundary, handled by software byte-swapping. The internal data is little-endian; the network data is big-endian; software converts.
• A file format — specified endianness. The SoC reads a file whose format specifies big-endian fields. Software byte-swaps the multi-byte fields when reading (and writing). Again, an endianness boundary at the data layer, handled by software conversion. The file's endianness differs from the system's, so conversion is needed.
• A legacy big-endian peripheral. Suppose the SoC must integrate a legacy big-endian peripheral. Its multi-byte registers are big-endian, while the SoC is little-endian. So a byte-swap converter is inserted at the peripheral's bus interface (or software byte-swaps accesses to it). Without this, the SoC would read the peripheral's multi-byte values byte-swapped (corrupted). So this endianness boundary needs explicit conversion hardware or software.
• The diagnosis of a mismatch. If the byte-swap were forgotten (e.g., reading network data without ntohl), the values would be byte-swapped — 0x11223344 read as 0x44332211 — plausible-looking but wrong. This is a classic, subtle bug: the access works, but the value is reversed. The fix is the missing endianness conversion. So endianness mismatches manifest as byte-swapped data, diagnosed by recognizing the reversal.

The example shows endianness as a uniform internal convention (the SoC is all little-endian, transferring values correctly) with explicit conversion at boundaries (network data via htonl/ntohl, files, a legacy big-endian peripheral via a byte-swap converter). The subtle mismatch bug (forgetting a swap → byte-swapped values) shows why endianness consistency and explicit boundary conversion matter. Endianness is uniform within, converted at the edges.

8. Common Mistakes

9. Interview Insight

Endianness is a common interview topic — the LSB/MSB-at-lowest-address distinction, the unchanged lane rule, and the consistency requirement are the signals.

The answer that lands distinguishes endianness from lane selection: "Endianness is the convention for which byte of a multi-byte value sits at the lowest address. Little-endian puts the least significant byte at the lowest address; big-endian puts the most significant byte there. The important thing is that the lane-from-address rule — a byte at address A goes on the lane for byte position A mod W — is the same in both endiannesses. Endianness doesn't change the lanes; it only changes which byte of the value is at each address, and hence which byte lands on each lane. So a byte read of addr+0 gives the LSB under little-endian or the MSB under big-endian — same address, different byte. AHB itself is endianness-agnostic — there's no endianness signal; it supports both, and the system chooses one. The critical requirement is that all components share the same endianness, because endianness is an interpretation of the bytes — if a master and slave disagree, multi-byte values are byte-swapped and corrupted, silently. So where different-endianness domains meet — like a little-endian system and big-endian network data — you need a byte-swap converter, which is what htonl/ntohl do in software." The LSB/MSB distinction, the unchanged lane rule, the agnostic protocol, and the consistency requirement are the senior signals.

10. Practice Challenge

Reason from endianness.

1. Place a value. Show where the bytes of 0x0A0B0C0D go (addresses and lanes) in little-endian and big-endian.
2. The unchanged rule. Explain why endianness doesn't change the lane-from-address rule.
3. A mismatch. Describe what happens if a little-endian master writes to a big-endian slave.
4. Network data. Explain why a little-endian system byte-swaps network data and how.
5. Boundaries. Explain how a different-endianness peripheral is integrated.

11. Key Takeaways

• Endianness decides which byte of a multi-byte value sits at the lowest address — little-endian: LSB at lowest; big-endian: MSB at lowest.
• The lane-from-address rule (chapter 9.5) is unchanged — endianness is a separate layer that decides the value→byte→address mapping, on top of the fixed address→lane rule.
• AHB is endianness-agnostic — no endianness signal; it supports both, and the system chooses one (driven by the processor). Endianness is in the components' data paths.
• All components must share one endianness — a mismatch silently byte-swaps every multi-byte value (plausible-looking but wrong, no error).
• Cross-endianness boundaries need a byte-swap converter — in hardware at the bus, or software at the data layer (htonl/ntohl for big-endian network data).
• Endianness is a foundational system-wide convention — affecting memory layout, software data interpretation, and cross-system data interchange (network, files).

12. What Comes Next

You now understand endianness on the data bus. The next chapters cover the downstream use of size/lane info and narrow transfers:

• 9.7 — Write Strobes in Bridges (coming next) — how size/lane info becomes write strobes downstream.
• 9.8 — Narrow Transfers (coming soon) — sub-bus-width transfers and their lane behavior.

To revisit the lane rule endianness builds on, see Lane Selection and Byte, Halfword & Word Transfers. For the write data placed on the lanes, see HWDATA & HRDATA. For the broader protocol map, see the AMBA family overview.