Control / Data Alignment

This chapter resolves one of the most common waveform-reading confusions in AHB: which control governs which data? Building on the one-cycle lead (5.2), the answer is precise — the control signals driven in the address phase (HWRITE, HSIZE, HBURST, HPROT) describe the access whose data moves in the following data phase. So the control on cycle N governs the data on cycle N+1. They are one cycle apart, which means on a waveform the control for a data beat sits one column to its left. Reading them in the same column — the natural but wrong instinct — mis-associates control with data. We make the alignment exact and build the diagonal-read habit that prevents the mistake.

1. What Is It?

The control/data alignment rule: the address-phase control governs the data phase one cycle later. The signals that describe an access — HADDR, HWRITE, HSIZE, HBURST, HPROT — are all driven in the access's address phase (cycle N). The data they govern moves in the access's data phase (cycle N+1). So:

• The direction (HWRITE) of the data in cycle N+1 was set in cycle N.
• The size (HSIZE) of the data beat in cycle N+1 was set in cycle N.
• The address (HADDR) the data in cycle N+1 goes to/from was set in cycle N.

A subordinate latches the address-phase control and applies it to the data phase one cycle later.

The essence: control and its data are one cycle apart, control first. This is a direct consequence of the one-cycle lead (5.2) applied to the control signals specifically. The control is part of the address phase, so it leads its data by one cycle, just as the address does. The practical upshot is a reading rule: to know what governs a data beat, look at the control one cycle before it — diagonally, not vertically.

2. Why Does It Exist?

The alignment exists because the control is part of the address phase (it must be available before the data, for the subordinate to prepare), and the address phase leads the data phase by one cycle (5.2) — so the control inevitably leads its data by one cycle.

Recall why the control is in the address phase (chapters 2.3, 3.2): the subordinate needs to know the access's direction, size, and burst before the data moves, so it can set up its data path (drive read data, or prepare to capture write data) and optimize (for a burst). If the control arrived with the data, the subordinate would have no time to prepare. So the control must lead the data — and since it rides in the address phase, it leads by exactly the address-to-data offset: one cycle. The alignment is therefore not a separate rule; it is the one-cycle lead (5.2) applied to the control signals, which travel in the address phase.

This is why it is a source of confusion: the control and the data it governs are never on the same cycle (except degenerate cases), yet the instinct when reading a waveform is to read a column top-to-bottom as one transfer. Because the control leads the data by a cycle, that vertical reading pairs a data beat with the next access's control (the control in the data beat's own column belongs to the access whose data comes next). So the alignment exists as a consequence of correct design (control before data), but it demands a non-obvious reading habit (diagonal, not vertical) — which is exactly what this chapter builds.

The alignment also exists to make the subordinate's job clean: by latching the address-phase control, the subordinate has the access fully described and held, ready to govern the data phase that follows. The control is stable and known one cycle ahead, so when the data phase arrives, the subordinate already knows exactly how to handle it (which direction, which byte lanes). So the alignment — control latched in the address phase, applied to the next-cycle data — is what lets the subordinate act correctly and immediately in the data phase. It is the timing that makes "describe the access, then move its data" work.

3. Mental Model

Model the alignment as a shipping label that travels one station ahead of the package.

The label (the control) — destination, handling instructions, size — arrives at the sorting station one beat before the package (the data) it belongs to. The sorter reads the label, sets up the right bin and handling, and then the package arrives and is processed according to that label. The label always precedes its package by one station. If you watched the conveyor and tried to match the label and package passing the same point at the same instant, you would mismatch — the label at any instant belongs to the package coming next, and the package at that instant belongs to the label that passed just before.

This captures the alignment exactly: the control (label) leads its data (package) by one cycle, the subordinate (sorter) reads the control first and applies it to the following data, and reading them "at the same instant" (same column) mismatches them. The correct match is diagonal — this control with the next cycle's data.

Watch the alignment on a write then read:

The model's lesson: the label leads its package by one station — the control for a data beat is one cycle before it. In the waveform, data A (cycle 2) is a write because HWRITE was high in cycle 1, not cycle 2 (cycle 2's HWRITE is low — that governs data B in cycle 3). Matching them vertically (data A with cycle-2 control) would wrongly call data A a read. The correct, diagonal match is the alignment.

4. Real Hardware Perspective

In hardware, the alignment is implemented by the subordinate latching the address-phase control and using the latched values in the next cycle's data phase.

A subordinate samples the address-phase control (HWRITE, HSIZE, etc.) at the clock edge ending the address phase and holds it for use in the data phase. So in the data phase (cycle N+1), the subordinate is acting on the control it latched from cycle N. For a write, the latched HWRITE = write tells it to capture HWDATA this cycle; the latched HSIZE tells it which byte lanes; the latched HADDR tells it where. For a read, the latched control tells it to drive HRDATA with the right data. So the alignment in hardware is: latch the control in the address phase, apply it in the data phase. This is the natural, correct implementation, and it is the one-cycle lead realized in the subordinate's logic.

The hardware reason the alignment causes reading errors is that, on a waveform, the signals in any single column belong to two different accesses: the control belongs to the access being described (whose data comes next cycle), while the data belongs to the access described last cycle. So a column is a snapshot of "the control for the next data" and "the data for the previous control." An engineer who reads a column as one access pairs the wrong control with the wrong data — for example, calling a data beat a read because the same-column HWRITE is low, when in fact that data beat was governed by the previous column's HWRITE (which was high, a write). The fix is the diagonal read: a data beat's control is one column to its left.

This matters most for debugging writes, where HWDATA (data phase) and HWRITE/HADDR (address phase) are visibly one cycle apart. When checking "did this write go to the right address with the right size?", you must look at the address-phase control one cycle before the HWDATA — not the control in the HWDATA's own cycle. Mis-aligning here leads to wrong conclusions about where data went or what size it was. So correct control/data alignment reading is essential for write debugging, and the diagonal habit is the safeguard.

5. System Architecture Perspective

At the system level, correct control/data alignment is essential for write correctness and for debugging and verification — and it is a property tools check.

The alignment is what makes writes land correctly. A write's data (HWDATA, data phase) must be governed by the write's own control (HWRITE, HSIZE, HADDR from the address phase one cycle earlier). The subordinate latching the address-phase control and applying it to the following HWDATA is what ensures the data goes to the right address with the right size and direction. If the alignment were wrong — if a subordinate applied the current cycle's control to the current cycle's data (vertical, not diagonal) — writes would be governed by the wrong access's control, corrupting where and how data is written. So at the system level, correct alignment is a correctness requirement, not just a reading convenience; the subordinate must implement it (latch then apply) and verification must confirm it.

For debugging, the alignment is a constant source of analysis error if not handled correctly. Engineers debugging data-path issues — "this write went to the wrong place," "this read returned the wrong size" — must align control with data correctly (diagonally) to draw right conclusions. A misaligned reading leads to misdiagnosis: blaming the wrong access, or concluding a write was a read. So the diagonal-read habit is a core debugging skill, and teaching it (this chapter) prevents a whole class of analysis mistakes. Debug tools and waveform viewers that understand AHB often annotate the alignment (linking each data beat to its address-phase control) precisely to remove this error.

For verification, the alignment is a checkable property: a protocol checker can verify that each data beat is governed by the control from one cycle earlier (the address phase that led it), and that a subordinate applies the latched address-phase control to the correct data phase. Deviations — a subordinate applying mis-timed control, or data governed by the wrong control — are flagged. So the alignment is part of the timing correctness that verification encodes, building on the one-cycle lead (5.2). This makes "control governs the next-cycle data" a precise, automatable assertion rather than a manual judgement.

So at the system level, control/data alignment is a write-correctness requirement (subordinates must latch-then-apply), a debugging skill (read diagonally to avoid misdiagnosis), and a verification property (control must govern the next-cycle data). It is the practical, correctness-critical form of the one-cycle lead.

6. Engineering Tradeoffs

The alignment is a consequence of the pipeline, so the "tradeoffs" are about the design it follows from.

• Control in the address phase vs with the data. Putting the control in the address phase (one cycle ahead of the data) lets the subordinate prepare before the data arrives, at the cost of the alignment offset (and the reading habit it demands). Control with the data would be simpler to read (same column) but would leave no setup time. AHB chooses control-ahead for the setup benefit, accepting the alignment offset.
• Latch-then-apply vs same-cycle. The subordinate latching the address-phase control and applying it next cycle is the natural implementation of the offset, and it is correct. The "alternative" (applying same-cycle control to same-cycle data) is simply wrong — it mis-aligns. So there is no real tradeoff; latch-then-apply is the only correct implementation, and the chapter's job is to make that clear.
• Diagonal reading vs vertical. The diagonal read (control one column left of its data) is the correct reading habit; vertical reading is the mistake. The "tradeoff" is purely that the correct habit is less intuitive than the wrong one — which is why it must be explicitly learned. Tools that annotate the alignment reduce the cognitive cost.
• Predictable alignment vs flexible. The fixed control-leads-data-by-one-cycle alignment makes the relationship predictable and checkable, at the cost of no flexibility (control is always one cycle ahead). This fixedness is a benefit — it makes alignment a precise property — and there is no useful flexibility to trade for.

The throughline: control/data alignment is the one-cycle lead applied to the control signals — a consequence of putting control in the address phase for setup time. It demands a non-intuitive diagonal reading habit and a latch-then-apply subordinate implementation, both of which are simply the correct way to handle the offset. The chapter exists because the offset, while correct by design, is a persistent source of reading and (if mis-implemented) correctness errors.

7. Industry Example

Trace control/data alignment through a write-debugging session.

An engineer is debugging a peripheral write that seems to go to the wrong register.

• The capture. The waveform shows, in cycle N, HADDR = register X, HWRITE = write, HSIZE = word; in cycle N+1, HWDATA = the value, and a new address phase (HADDR = register Y) for the next access.
• The vertical-read mistake. A hurried reading looks at cycle N+1 — the cycle with HWDATA — and reads the same-cycle HADDR (register Y) as the write's destination. It concludes the write went to register Y, and starts debugging the wrong register. This is the alignment error: pairing the write data with the same-cycle (next access's) address.
• The diagonal-read fix. The correct reading aligns the HWDATA in cycle N+1 with the address-phase control one cycle before it — cycle N: HADDR = register X, HWRITE = write, HSIZE = word. So the write data went to register X (correct destination, as a word write). The engineer was about to debug the wrong register; the diagonal alignment reveals the write was actually targeting X all along, and the bug is elsewhere.
• The subordinate-implementation angle. Separately, suppose the peripheral itself were mis-implemented — applying the same-cycle control to the HWDATA rather than the latched address-phase control. Then it would write the cycle-N+1 data using cycle-N+1's control (intended for the next access), corrupting the write. The fix is the correct latch-then-apply: latch the address-phase control (cycle N) and apply it to the data phase (cycle N+1). This is the same alignment, on the implementation side.
• The lesson. Both the reading error and the implementation error are the same misalignment — pairing data with same-cycle control instead of the control one cycle before. Whether debugging a capture or designing a subordinate, the rule is identical: a data beat's control is one cycle to its left. Getting this right is what makes write analysis and write correctness reliable.

The session shows the alignment's practical stakes: a vertical read sends the engineer to the wrong register, while the diagonal read correctly attributes the write — and the same alignment, mis-implemented in a subordinate, would corrupt writes. The diagonal habit is the safeguard for both.

8. Common Mistakes

9. Interview Insight

This tests whether you correctly align control with data — a frequent waveform-reading discriminator.

The answer that lands states the alignment and the reading habit: "The control signals — HWRITE, HSIZE, HBURST, HPROT — are driven in the address phase and govern the data that moves in the following data phase, so the control on cycle N governs the data on cycle N+1. A subordinate latches the address-phase control and applies it to the next cycle's data. The practical consequence is a reading rule: on a waveform, the control for a data beat is one cycle to its left — you read diagonally. Reading the control and data in the same column is the classic mistake; for a write, you find its address and size in the cycle before the HWDATA, not the same cycle." The control-governs-next-cycle-data alignment and the diagonal-read habit are the senior signals.

10. Practice Challenge

Reason from the control-leads-data-by-one-cycle alignment.

1. State the alignment. Which cycle's data does the address-phase control govern, and why?
2. Read diagonally. From Figure 2, identify the control that governs data A and the control that governs data B.
3. Find a write's destination. Describe how to find a write's address and size on a waveform, relative to the HWDATA cycle.
4. Implement it. Describe how a subordinate latches and applies the control to align with the data.
5. Diagnose the misread. A colleague reads a write's destination from the HWDATA cycle's address. Explain the error and the correct reading.

11. Key Takeaways

• The address-phase control governs the next cycle's data — control on cycle N governs the data on cycle N+1. They are one cycle apart, control first.
• It is the one-cycle lead applied to the control signals — the control rides in the address phase, which leads the data phase by one cycle.
• On a waveform, a data beat's control is one column to its left — read diagonally; reading control and data in the same column is the classic mistake.
• A subordinate latches the address-phase control and applies it to the following data phase (latch-then-apply) — applying same-cycle control corrupts the access.
• It is a write-correctness requirement and a debugging skill — to find a write's destination/size, look at the control one cycle before the HWDATA, not in its own cycle.
• Mis-alignment causes misdiagnosis (and, if mis-implemented, corruption) — the diagonal habit is the safeguard for both reading captures and designing subordinates.

12. What Comes Next

You can now align control with data correctly. The next chapters walk complete transfers through both phases:

• 5.4 — Read Transfer Timing (coming next) — a read walked cycle by cycle through the address and data phases.
• 5.5 — Write Transfer Timing (coming soon) — a write walked cycle by cycle, where control/data alignment is most visible.

To revisit the offset this alignment follows from, see Address Phase Leads Data Phase and The Two-Phase Pipeline; for the control signals themselves, see HADDR & HWRITE and HSIZE. For the broader protocol map, see the AMBA family overview.