AMBA AHB · Module 18

Address / Data Misalignment

Diagnosing data captured or driven in the wrong phase or cycle — a pipeline off-by-one where data pairs with the wrong address (data at the wrong address, a read returning the previous/next transfer's data, a write to the neighbor's location), with no hang. Because the address is in the address phase and the data is one cycle later in the data phase, the design must register the address context and pair it with the data; misalignment is that pairing slipped. The causes are the capture not gated by HREADY, a write committing in the wrong phase, a read muxed with the current (not registered) select, or an extra/missing pipeline register. Diagnose by lining up each address phase with its data phase; it hides in zero-wait same-slave traffic and surfaces with waits/slave-switching.

The stuck HREADY (18.1) hung the bus; the wrong HTRANS (18.2) broke the burst structure. This chapter covers a bug that strikes at AHB's defining feature — the pipeline: address/data misalignment, where the data of a transfer is captured or driven in the wrong phase or cycle, so it pairs with the wrong address. Because AHB is pipelined, the address is in the address phase and the data is one cycle later in the data phase — so the design must register the address-phase context and pair it with the data-phase data (the capture-then-act discipline of Module 16). Misalignment is an off-by-one in that pairing. The symptom is quiet (no hang): data lands at the wrong address, a read returns the previous or next transfer's data, or a write commits to the neighbor's location. The common root causes are exactly the Module-16 disciplines gone wrong: the address-phase capture not gated by HREADY (16.7 — a wait state shifts the pairing), a write committing in the address phase instead of the data phase (16.8 — before the data arrives), a read muxed with the current address-phase select instead of the registered data-phase select (16.5 — the wrong-slave-data bug), or an extra/missing pipeline register (a cycle added/removed). To diagnose, line up each address phase with its data phase (one cycle later) and check the data pairs with the right address — the off-by-one usually appears only with wait states or slave-switching transfers (zero-wait same-slave hides it). This chapter builds the diagnosis.

1. What Is It?

Address/data misalignment is a pipeline off-by-one where data pairs with the wrong address; debugging it means lining up the phases and finding the cycle slip. Its parts:

The pipeline pairing — the address is in the address phase, the data one cycle later in the data phase; the design registers the address and pairs it with the data.
The off-by-one — misalignment is that pairing slipped by a cycle: data pairs with the wrong address.
The symptom — quiet (no hang): data at the wrong address, a read returning the previous/next transfer's data, a write to the neighbor's location.
The causes — capture not HREADY-gated (16.7), commit in the wrong phase (16.8), read mux wrong select (16.5), or an extra/missing pipeline register.

Figure 1 — diagnosing address/data misalignment. Symptom: data lands at the wrong address, a read returns the previous/next transfer's data, a write commits to the neighbor's location (no hang). The root: AHB is pipelined (addr in the address phase, data one cycle later in the data phase), so the design must register the address context and pair it with the data; misalignment is that pairing off-by-one. Common root causes → fix: capture not HREADY-gated (a wait state shifts the pairing — 16.7 → gate capture on HREADY); commit in the wrong phase (write commits in the address phase before the data — 16.8 → commit in the data phase); read mux wrong select (current address-phase select vs registered data-phase — 16.5 → use the registered select); extra/missing register stage (a cycle added/removed → align the pipeline depth). Diagnosis: line up each address phase with its data phase (+1 cycle) and check the data pairs with the right address. It usually appears only with wait states or slave-switching (zero-wait same-slave hides it).

So address/data misalignment is the pipeline bug — a cycle slip in the address-to-data pairing that AHB's pipelining requires. The root is AHB's defining structure: the address and data of a transfer are one cycle apart (address phase, then data phase), so correct operation requires the design to register the address-phase context and pair it with the data-phase data exactly one cycle later — the capture-then-act discipline (Module 16). Misalignment is that pairing slipping — the data paired with the wrong (off-by-one) address. The symptom is quiet: no hang (the bus runs), just wrong data at wrong addresses — a read returning the neighbor's data, a write landing next door. The causes are precisely the Module-16 disciplines violated: the un-gated capture (16.7), the wrong-phase commit (16.8), the wrong mux select (16.5), or a pipeline-depth error. And the diagnostic key is to line up the phases — draw the address phase → data phase pairing (across the one-cycle gap) and check each data lands on its own address. So address/data misalignment is the pipeline-pairing off-by-one, debugged by phase alignment. So it's the bug at AHB's core feature.

Misalignment = a pipeline OFF-BY-ONE: data captured/driven in the wrong phase/cycle pairs with the wrong address. Diagnose by lining up each address phase with its data phase (+1 cycle); causes are the capture/commit/mux disciplines gone wrong; it hides in zero-wait same-slave traffic

Address/data misalignment in one frame: a pipeline off-by-one — the data of a transfer is captured or driven in the wrong phase or cycle, so it pairs with the wrong address. AHB is pipelined: the address is in the address phase, the data one cycle later in the data phase — so the design must register the address-phase context and pair it with the data-phase data (the capture-then-act discipline — Module 16). Misalignment is that pairing slipped by a cycle. The symptom is quiet (no hang): data at the wrong address, a read returning the previous/next transfer's data, a write committing to the neighbor's location. The common causes — all Module-16 disciplines gone wrong: (a) the address-phase capture not gated by HREADY (16.7 — a wait state shifts the pairing, since the master moves the address during the wait); (b) a write committing in the address phase instead of the data phase (16.8 — committing before the data arrives, pairing it with the address-phase address); (c) a read muxed with the current address-phase select instead of the registered data-phase select (16.5 — returning the next slave's data); (d) an extra or missing pipeline register (adding/removing a cycle). The diagnostic: line up each address phase with its data phase (one cycle later) and check the data pairs with the right address — draw the diagonal across the one-cycle gap. The off-by-one usually appears only with wait states or slave-switching transfers — zero-wait same-slave traffic hides it (the address doesn't change, so the slip is invisible). The fix is the capture/commit/mux disciplines (gate capture on HREADY, commit in the data phase, use the registered select, align the pipeline depth).

2. Why Does It Exist?

Address/data misalignment exists because AHB's pipelining makes correct address-data pairing a timing discipline (register the address, pair one cycle later) — and any slip in that discipline causes a cycle off-by-one; it's quiet (no hang) and hides in simple traffic, so it's insidious and must be debugged by phase alignment.

The pipelining makes pairing a discipline is the root: AHB separates the address (address phase) from the data (data phase) by one cycle. So pairing them correctly is not automatic — it requires the design to register the address-phase context and act on it one cycle later (16.7). This capture-then-act is a timing discipline, and any deviation (a missing register, a wrong-cycle action, an un-gated capture) slips the pairing. So misalignment exists because the pipeline makes pairing a discipline that can be violated. So it's a pipeline-discipline bug. So pipelining creates the risk.

The it's quiet and hides drives the insidiousness: misalignment doesn't hang — the bus runs normally; it just pairs data with the wrong address. And it hides in simple traffic: in zero-wait, same-slave transfers, the address doesn't change (or changes predictably), so a one-cycle slip might coincidentally pair the right data with the right address (or the difference is invisible). It only surfaces when the pairing matters — wait states (which stretch the pipeline, exposing the un-gated capture) or slave-switching (where the address differs between consecutive transfers, exposing the wrong-select mux). So misalignment is insidious — quiet and condition-dependent. So it must be deliberately exposed and carefully debugged. So it's hidden. So the insidiousness demands care.

The debug requires phase alignment is the method's basis: because the bug is a pipeline off-by-one, the diagnosis must examine the pipeline pairing — line up each address phase with its data phase (one cycle later) and check the data pairs with the right address. This phase-alignment reading is the only way to see the cycle slip. So the debug method exists because the bug is a phase-pairing error. So it's phase-alignment debug. So address/data misalignment exists because: AHB's pipelining makes correct address-data pairing a timing discipline (register + pair one cycle later — violable — the why); the bug is quiet (no hang) and hides in simple traffic, surfacing only with waits/slave-switching (insidious — the consequence); and debugging it requires phase alignment (lining up the address and data phases to see the off-by-one — the method). So address/data misalignment is the pipeline off-by-one — caused by violating the capture-then-act discipline, hidden in simple traffic, and debugged by lining up the phases. So this chapter teaches the phase-alignment diagnosis. So align the phases to find the slip.

3. Mental Model

Model debugging misalignment as finding why a coat-check is handing back the wrong coats — the tickets and coats are one step out of sync. You hand in your coat (the address) and get a ticket; later you return the ticket and collect your coat (the data, one step later). If the attendant's numbering slips by one — they tag your coat with the next person's number — then everyone gets the neighbor's coat. To find it, you line up each coat with the ticket it was given and check they match across the one-step delay. The mix-up only shows when consecutive coats differ — if everyone checked in identical coats, you'd never notice the off-by-one.

A coat-check (the pipeline) where checking in and collecting happen one step apart (the address phase, then the data phase). You hand in your coat and get a numbered ticket (the address phase — the address/context, registered as the ticket). Later, you return the ticket and collect your coat (the data phase — the data, paired with the registered context, one step later). The correct operation: your coat is tagged with your number, and your ticket retrieves your coat — the pairing holds across the one-step delay. Now, misalignment is when the attendant's numbering slips by one — they tag your coat with the next person's number (an off-by-one in the pairing). The result: everyone gets the neighbor's coat — quietly (no crash; the coat-check runs fine), just wrong coats returned. To find the slip, you line up each coat with the ticket it was given and check they match — tracing the one-step delay between check-in and collection. And here's the insidious part: the mix-up only shows when consecutive coats differ — if everyone checked in identical black coats (zero-wait same-slave — the address doesn't change), you'd never notice the off-by-one (you'd get a black coat, seemingly fine). It only surfaces when coats differ (slave-switching) or when there's a delay that shifts the numbering (a wait). The fix: ensure the coat is tagged with its own ticket's number and collected with the matching ticket across the exact one-step delay (the capture-then-act discipline).

This captures misalignment debug: the coat-check = the pipeline; checking in / collecting one step apart = the address phase then data phase; the numbered ticket = the registered address context; your coat tagged with your number = data paired with its own address; the numbering slipping by one = the off-by-one pairing; everyone getting the neighbor's coat = data at the wrong address; quiet, no crash = no hang; lining up each coat with its ticket across the delay = lining up each address phase with its data phase; identical black coats hiding the mix-up = zero-wait same-slave hiding the bug; differing coats / a delay surfacing it = slave-switching / wait states surfacing it. Line up each coat with its ticket across the one-step delay, and watch for the off-by-one — visible only when coats differ.

Watch a misaligned read on the waveform — returning the previous transfer's data:

A misaligned read (off-by-one pairing)

3 cycles

Figure 2 — a misaligned read returning the previous transfer's data (an off-by-one). Two reads to different slaves. Cycle 0: address phase for A (slave X). Cycle 1: A's data phase — the master should sample slave X's data (DX); but also cycle 1 is B's address phase (slave Y). A buggy read mux uses the CURRENT address-phase select (Y) instead of the registered (X), so it returns slave Y's data — except Y's data isn't ready yet, so the master samples the WRONG/stale value. Cycle 2: B's data phase. The 'expected HRDATA' row shows DX in cycle 1 (A's data); the 'actual (buggy)' shows the wrong value (mis-selected). The 'check' fires in cycle 1. Lining up A's address phase (cycle 0) with its data phase (cycle 1) reveals the data didn't pair with A — the off-by-one. This only shows because the transfers switch slaves; two reads to the same slave would hide it.

The model's lesson: line up each coat with its ticket across the one-step delay, and watch for the off-by-one. In the waveform, lining up A's address phase (cycle 0) with its data phase (cycle 1) reveals the returned data didn't pair with A — the buggy mux used the current select (Y) instead of the registered (X). The slip is visible only because the transfers switch slaves.

4. Real Hardware Perspective

In debug, you read the waveform by phase alignment (draw the address-phase → data-phase pairing), find the cycle where the data pairs with the wrong address, identify which discipline slipped (capture/commit/mux/pipeline), and confirm by checking whether waits or slave-switching are present.

The phase-alignment reading: on the waveform, annotate each address phase (with its address) and its data phase (one cycle later). Draw the pairing — the diagonal from each address phase to its data phase. Then check: does each data (write data committed, or read data returned) pair with its own address? A mismatch — data paired with the wrong (off-by-one) address — is the misalignment. So in debug, read by phase alignment. So it's the alignment read. So that's the core technique.

Figure 3 — lining up address and data phases to spot misalignment. A write sequence: cycle 0 address phase A, cycle 1 data phase data-of-A (should commit to A) and address phase B, cycle 2 data phase data-of-B (commits to B). Correct pairing: data-of-A with A, data-of-B with B — each data one cycle after its address (the diagonal). A misaligned design pairs them wrong — e.g. committing data-of-A to B because it used the current address phase B instead of the captured A (an off-by-one). To catch this, draw the diagonal pairing across the one-cycle gap and verify each data lands on its own address. When wait states stretch the data phase, the pairing must still hold across the stall — where a non-gated capture breaks it.

The identify the slipped discipline: with the misalignment located (which transfer's data went to the wrong address), identify which discipline slipped: (a) if a wait state is present and the pairing shifts across it → the capture isn't HREADY-gated (16.7 — the capture sampled the next address during the wait); (b) if a write commits a cycle early (in the address phase) → the commit is in the wrong phase (16.8); (c) if a read returns the next slave's data on slave-switching → the read mux uses the wrong (current) select (16.5); (d) if everything is shifted by a constant cycle → an extra/missing pipeline register. So in debug, the pattern of the slip points to the discipline. So it's discipline identification. So that localizes it.

The confirm via the conditions: because misalignment hides in zero-wait same-slave traffic and surfaces with waits/slave-switching, confirm the diagnosis by checking the conditions: is the bug present with waits (capture issue) or slave-switching (mux issue) but absent in zero-wait same-slave? This confirms it's a pipeline-pairing off-by-one (not some other bug). And the fix is the corresponding discipline (gate the capture, commit in the data phase, use the registered select, align the pipeline depth — Module 16). A scoreboard (17.4) catches misalignment (the data doesn't match the expected address); an assertion on the capture/mux timing helps too. So in debug, address/data misalignment is a phase-alignment read (draw the address→data pairing → find the off-by-one → identify the slipped discipline → confirm via waits/slave-switching → fix). So in debug, line up the phases and find the slip. So that's the method.

5. System Architecture Perspective

At the system level, address/data misalignment is a silent data-corruption bug at AHB's defining feature (the pipeline) — making it insidious (no hang, hides in simple traffic) and high-consequence (corrupts data); it's exactly the bug the Module-16 disciplines prevent and the Module-17 scoreboard catches.

The silent corruption at the core feature: AHB's pipelining is its defining feature (the source of its efficiency) — and misalignment is the bug at that feature. It's silent (no hang — the bus runs) and corrupts data (data at wrong addresses). So it's insidious: the system appears to work but quietly corrupts. So at the system level, misalignment is a silent corruption at the core of the protocol. So it's dangerous. So the core feature carries the risk.

The prevented by discipline, caught by the scoreboard: misalignment is exactly what the Module-16 disciplines prevent (the HREADY-gated capture, the data-phase commit, the registered mux select — all about correct pipeline pairing) and what the Module-17 scoreboard catches (the data not matching the expected address). So the whole RTL-and-verification methodology is, in part, about preventing/catching this bug. So at the system level, misalignment is the negative of the disciplines — get them right (prevent) and check them (catch). So it's the discipline's purpose. So the methodology targets it.

The surfaced by the right stimulus: because misalignment hides in simple traffic, surfacing it requires the right stimulus — wait states (17.7) and slave-switching (the cross-product traffic — 17.6) — exactly the targeted tests. So finding misalignment depends on the adversarial stimulus. So at the system level, address/data misalignment is a silent data-corruption bug at AHB's defining pipeline feature (insidious — no hang, hides in simple traffic; high-consequence — corrupts data), prevented by the Module-16 pipeline disciplines and caught by the Module-17 scoreboard, and surfaced by the targeted stimulus (waits + slave-switching). So misalignment is the bug that ties together the whole AHB story — the pipeline (the protocol's core), the RTL disciplines (that pair correctly), the verification (that checks the pairing), and the targeted stimulus (that exposes the slip) — making its prevention, detection, and debug a through-line of mastering AHB. So get the pipeline pairing right, check it, and stress it. So misalignment is the pipeline made-or-broken.

6. Engineering Tradeoffs

Debugging address/data misalignment embodies the phase-alignment, discipline-identification, condition-confirmation approach.

Phase-alignment reading vs value-by-value. Lining up the address and data phases (the diagonal pairing) reveals the off-by-one; reading values in isolation misses the cycle slip. Read by phase alignment.
Identify the discipline vs guess. Matching the slip pattern to the discipline (capture/commit/mux/pipeline) localizes the fix; guessing is slow. Match the pattern.
Confirm via conditions vs assume. Checking that the bug appears with waits/slave-switching but hides in zero-wait same-slave confirms it's a pipeline-pairing off-by-one; assuming risks misdiagnosis. Confirm via the conditions.
Fix the discipline vs patch the symptom. Fixing the discipline (gate capture, commit in data phase, registered select) is correct; patching (e.g. adding an ad-hoc delay) risks re-misaligning elsewhere. Fix the discipline.

The throughline: address/data misalignment is a pipeline off-by-one — the data captured or driven in the wrong phase or cycle pairs with the wrong address. AHB is pipelined (address in the address phase, data one cycle later in the data phase), so the design must register the address context and pair it with the data — misalignment is that pairing slipped. The symptom is quiet (no hang): data at the wrong address, a read returning the previous/next transfer's data, a write to the neighbor. The causes are the Module-16 disciplines gone wrong: capture not HREADY-gated (16.7), commit in the wrong phase (16.8), read mux wrong select (16.5), or an extra/missing register. Diagnose by lining up each address phase with its data phase (one cycle later) and checking the data pairs with the right address. It hides in zero-wait same-slave traffic and surfaces with waits/slave-switching. It's a silent corruption at AHB's core feature — prevented by the RTL disciplines, caught by the scoreboard, surfaced by the targeted stimulus.

Misalignment is QUIET (no hang) and HIDES in zero-wait same-slave traffic — it surfaces only with wait states or slave-switching. So debug by lining up each address phase with its data phase (the off-by-one is invisible value-by-value), and reproduce with the RIGHT stimulus (waits + slave-switching) — don't conclude 'no bug' from zero-wait tests passing

Two traps make misalignment hard to catch and debug: (1) Concluding "no bug" from simple traffic. Misalignment hides in zero-wait, same-slave traffic — and this is exactly the default traffic in a naive test. In zero-wait transfers, the pipeline isn't stretched, so an un-gated capture (16.7) happens to sample the right address (the address didn't change during a — nonexistent — wait). In same-slave transfers, the address doesn't switch between consecutive transfers, so a wrong-select read mux (16.5) happens to select the same (correct) slave. So a zero-wait same-slave test passes even with a misalignment bug present — giving false confidence. Don't conclude "no misalignment bug" from such a test. To expose it, you need the right stimulus: wait states (17.7 — stretch the pipeline, exposing the un-gated capture) and slave-switching (consecutive transfers to different slaves — exposing the wrong-select mux), ideally combined (the cross-product — 17.6). This is why wait-state and burst/slave-switching testing are essential — they're what surface misalignment. (2) Debugging value-by-value instead of by phase alignment. The off-by-one is invisible if you read HRDATA/HWDATA values in isolation — a value looks plausible (it's real data, just for the wrong transfer). The only way to see the slip is to line up the phases: draw each address phase → data phase pairing (across the one-cycle gap) and check the data pairs with its own address. The misalignment appears as a data paired with the wrong (off-by-one) address — visible only in the phase-aligned view. So don't debug value-by-value (you'll see plausible data and miss the slip); line up the phases. The unifying discipline: misalignment is quiet and condition-dependent, so reproduce it with the right stimulus (waits + slave-switching) and debug it by phase alignment (the off-by-one is invisible otherwise). The tell of a missed misalignment: a design that passes zero-wait same-slave tests but corrupts data under realistic (waited, multi-slave) traffic — and the tell of a mis-debug: staring at plausible-looking data values without lining up the phases. (See Address / Control Capture, HRDATA Muxing, and Wait-State Testing.)

7. Industry Example

Debug an address/data misalignment that passed unit tests but corrupts data in the system.

A design passed its unit tests but, in the full system, reads return wrong data — intermittently, with no hang.

The symptom. No hang. The CPU occasionally reads the wrong value — a value that looks plausible (it's real data) but is for a different address. The scoreboard (in a system regression) flags data mismatches.
Reproduce with the right stimulus. The unit tests were zero-wait, same-slave — which hid the bug. You reproduce it with realistic traffic: wait states and slave-switching (consecutive reads to different slaves). Now the wrong reads appear consistently.
Phase-alignment read. On the waveform, you line up each address phase with its data phase (one cycle later). You find: a read to slave X (address phase) is followed (next cycle) by a read to slave Y; in X's data phase, the master samples — but gets Y's (not-yet-ready) data instead of X's. The data didn't pair with X's address — an off-by-one.
Identify the discipline. The slip appears on slave-switching reads → the read mux is using the current address-phase select (Y) instead of the registered data-phase select (X) — the wrong-mux-select bug (16.5). (Confirmed: same-slave reads are fine — the select happens to match.)
The fix. Correct the interconnect's read mux to use the registered (data-phase) select, so X's data phase returns X's data. (The Module-16 discipline restored.)
Add the check. You add the scoreboard (17.4) to the unit environment and the slave-switching + wait stimulus (17.6/17.7) — so the bug would be caught in unit verification next time (it escaped because the unit tests lacked the surfacing stimulus).

The example shows the insidious nature and the method: the bug hid in zero-wait same-slave unit tests, surfaced under realistic (waited, slave-switching) traffic, and was found by phase-alignment reading (lining up X's address phase with its data phase to see the off-by-one) → identified as the wrong-mux-select discipline (16.5) → fixed → and the test gap (missing surfacing stimulus) closed. This is how you debug a silent pipeline-pairing bug. This is misalignment found.

8. Common Mistakes

Address/data-misalignment debugging misconceptions

"Zero-wait same-slave tests passed, so there's no misalignment." No — misalignment hides there (the pipeline isn't stretched, the address doesn't switch). Reproduce with waits + slave-switching.
"Read the data values to find the bug." No — the off-by-one is invisible value-by-value (the data looks plausible). Line up the phases (address → data, one cycle later) to see the slip.
"It's a random/intermittent data bug." It's deterministic given the conditions (waits/slave-switching). It seems intermittent because it depends on the traffic pattern. Reproduce the conditions.
"The bus is fine (no hang)." Misalignment doesn't hang — it's a silent corruption. No hang ≠ no bug. Check the data pairing.
"Patch it with an ad-hoc delay." No — fix the discipline (gate capture on HREADY, commit in the data phase, use the registered select). An ad-hoc delay risks re-misaligning elsewhere.
"It's one specific cause." It's one of the capture/commit/mux/pipeline disciplines — match the slip pattern (does it appear on waits? slave-switching? always shifted?) to the specific cause.

9. Interview Insight

Address/data misalignment is a high-signal debug interview topic — the pipeline-off-by-one insight, the phase-alignment method, and the hides-in-simple-traffic awareness are the signals.

Figure 4 — a strong answer in one card: misalignment is a pipeline off-by-one (addr in the address phase, data +1 cycle in the data phase → data pairs with the wrong addr); diagnose by lining up each address phase with its data phase and checking the pairing; causes are capture not HREADY-gated (16.7), commit in the wrong phase (16.8), read mux wrong select (16.5), or an extra/missing register; it shows up mainly with wait states / slave-switching (zero-wait same-slave hides it). The senior point: misalignment is a pipeline off-by-one — align the data-phase action with the captured address-phase context, gated by HREADY.

The answer that lands gives the off-by-one insight and the phase-alignment method: "Address/data misalignment is a pipeline off-by-one. Because AHB is pipelined, the address is in the address phase and the data is one cycle later in the data phase, so the design has to register the address-phase context and pair it with the data-phase data — the capture-then-act discipline. Misalignment is when that pairing slips by a cycle, so the data ends up paired with the wrong address. The symptom is quiet — no hang. You see data landing at the wrong address, a read returning the previous or next transfer's data, or a write going to the neighbor's location. The way I debug it is by phase alignment: I line up each address phase with its data phase, one cycle later, and check that the data pairs with its own address. The off-by-one is invisible if you just read the data values, because they look plausible — they're real data, just for the wrong transfer. You only see the slip when you line up the phases and draw the diagonal pairing. The causes are exactly the slave-RTL disciplines gone wrong: the address capture not gated by HREADY, so a wait state shifts the pairing; a write committing in the address phase instead of the data phase; a read multiplexed with the current address-phase select instead of the registered data-phase select, returning the next slave's data; or an extra or missing pipeline register. So I match the pattern of the slip to the cause. The crucial thing is that this bug hides in simple traffic — zero-wait, same-slave transfers — because the pipeline isn't stretched and the address doesn't switch, so the slip is invisible or coincidentally correct. It only surfaces with wait states or slave-switching transfers. So a design can pass naive unit tests and corrupt data in the system. To catch it, you need the right stimulus — waits and slave-switching — which is exactly why wait-state and multi-slave testing matter, and the scoreboard catches the data-not-matching-the-address." The pipeline-off-by-one insight, the phase-alignment method, and the hides-in-simple-traffic awareness are the senior signals.

🔍 The discriminator: misalignment is a pipeline OFF-BY-ONE (data paired with the wrong address) — debug by LINING UP each address phase with its data phase (invisible value-by-value); it HIDES in zero-wait same-slave traffic and surfaces with waits/slave-switching; the causes are the capture/commit/mux disciplines gone wrong

The discriminator on address/data misalignment is whether you frame it as a pipeline off-by-one and debug it by phase alignment — plus the hides-in-simple-traffic awareness. A weak answer says "the data is wrong, I'd check the data path." A solid answer recognizes it's a pipeline (address-vs-data) issue. But the senior answer nails the off-by-one framing: AHB's pipelining makes address-data pairing a timing discipline (register the address, pair one cycle later — capture-then-act), and misalignment is that pairing slipped by a cycle — data paired with the wrong address. The method is the signal: line up each address phase with its data phase (the diagonal pairing across the one-cycle gap) and check the data pairs with its own address — because the off-by-one is invisible value-by-value (the data looks plausible — real data for the wrong transfer). The standout insight is the hiding: misalignment hides in zero-wait same-slave traffic (the pipeline isn't stretched; the address doesn't switch — the slip is invisible or coincidentally correct) and surfaces only with wait states (exposing the un-gated capture — 16.7) or slave-switching (exposing the wrong-select mux — 16.5) — so a design can pass naive unit tests and corrupt data in the system. This connects the whole AHB story: the causes are the Module-16 disciplines gone wrong (capture/commit/mux), it's prevented by getting them right, caught by the scoreboard (17.4), and surfaced by the targeted stimulus (waits + slave-switching — 17.6/17.7). The framing that impresses: misalignment is a silent corruption at AHB's defining feature (the pipeline) — no hang ≠ no bug — and finding it requires the right stimulus and phase-alignment reading. A candidate who frames it as a pipeline off-by-one, debugs by lining up the phases, and knows it hides in simple traffic (needing waits/slave-switching to surface) demonstrates deep AHB pipeline mastery — connecting the protocol, the RTL disciplines, and the verification.

10. Practice Challenge

Build and reason from debugging address/data misalignment.

The off-by-one. Explain why misalignment is a pipeline off-by-one (address phase vs data phase, the capture-then-act pairing).
Phase alignment. Describe how to diagnose by lining up each address phase with its data phase and checking the pairing.
Read the waveform. From Figure 2, explain how lining up A's address phase with its data phase reveals the misaligned read.
The hiding. Explain why misalignment hides in zero-wait same-slave traffic and surfaces with waits/slave-switching.
The connections. Explain how the causes (16.7/16.8/16.5), the scoreboard (17.4), and the stimulus (17.6/17.7) connect.

11. Key Takeaways

Address/data misalignment is a pipeline off-by-one — data captured or driven in the wrong phase/cycle pairs with the wrong address. AHB's pipelining (address phase, then data phase) makes correct pairing a timing discipline; misalignment is that pairing slipped.
The symptom is quiet — no hang: data at the wrong address, a read returning the previous/next transfer's data, a write to the neighbor. No hang ≠ no bug.
Diagnose by phase alignment — line up each address phase with its data phase (one cycle later) and check the data pairs with its own address. The off-by-one is invisible value-by-value.
The causes are the Module-16 disciplines gone wrong — capture not HREADY-gated (16.7), commit in the wrong phase (16.8), read mux wrong select (16.5), or an extra/missing pipeline register. Match the slip pattern to the cause.
It hides in zero-wait same-slave traffic and surfaces with wait states (exposing the capture bug) or slave-switching (exposing the mux bug) — so naive unit tests pass while the system corrupts data. Reproduce with the right stimulus.
It ties the AHB story together — prevented by the RTL pipeline disciplines, caught by the scoreboard (17.4), surfaced by the targeted stimulus (17.6/17.7). A silent corruption at AHB's defining feature.

12. What Comes Next

You now can debug a pipeline misalignment. The next chapters cover the remaining failure modes:

Incorrect HSEL (next) — diagnose a transfer hitting the wrong (or no) slave.
Wrong HRDATA Timing, Bad HRESP, Burst Wrap Error, and the rest — diagnose the other failures, building to a general waveform-debug methodology.

To revisit the disciplines this debugs, see Address / Control Capture, HRDATA Muxing, and Write FSM; for the pipeline itself, see Pipelined Operation; for the stimulus that surfaces it, see Wait-State Testing.