The Write Address (AW) Channel

Module 3 taught the handshake every channel shares; now Module 4 walks the write transaction channel by channel, starting where a write begins — the AW (write address) channel. One AW handshake launches one write: it carries the address and a compact description of the write's shape (how many beats, how wide, what pattern) plus its identity, but no data — that comes on W. This chapter details what each AW signal does and how they combine to launch a write, then watches the AW handshake on a waveform. The exhaustive bit-by-bit decode of the address/burst signals is Module 6; here the goal is to read an AW handshake and know exactly what write it just started.

1. AW Launches the Write — The Request, Not the Data

The AW channel is the manager saying "I'm about to write — here's where and what shape." It is purely a request: it names the target and describes the transfer, and one AW handshake commits the manager to one write transaction. Critically, AW carries no write data — the bytes travel on the W channel (next chapter). This separation is the decoupling from Chapter 2.4 made concrete: the address can be accepted while the data is still arriving, or even after.

So everything on AW is metadata about the write: where it goes, how big it is, how to step the address, and which transaction it is. Get the AW right and the W and B channels just follow the shape it declared.

2. What AW Carries

AW's signals group into four roles. The handshake (AWVALID/AWREADY) moves the whole bundle in one transfer.

In code, AW is just a write-request descriptor — one struct, launched by one handshake:

// Conceptual — the AW channel as a write-request descriptor.
typedef struct packed {
  logic [ADDR_W-1:0] awaddr;   // start address — where the write begins
  logic [7:0]        awlen;    // beats - 1  (AXI4: 0..255 → 1..256 beats)
  logic [2:0]        awsize;   // bytes per beat = 2**awsize
  logic [1:0]        awburst;  // FIXED / INCR / WRAP — how the address steps
  logic [ID_W-1:0]   awid;     // transaction id — for outstanding & ordering
  // + awlock, awcache, awprot, awqos, awregion, awuser (attributes)
} aw_payload_t;                // moved by one AWVALID/AWREADY handshake

3. The Address and the Shape

Four signals describe what write is being launched — the address plus the three that define its burst shape:

• AWADDR — the start address of the write. For a burst, it's the address of the first beat; the burst type then says how subsequent beats step.
• AWLEN — the burst length as beats − 1. AWLEN = 0 is a single beat; AWLEN = 7 is 8 beats. AXI4 allows up to 256-beat INCR bursts (AWLEN is 8 bits).
• AWSIZE — the bytes per beat, encoded as a power of two (bytes = 2^AWSIZE): size 0 = 1 byte, size 2 = 4 bytes, size 4 = 16 bytes, etc. It must not exceed the data-bus width.
• AWBURST — the burst type, i.e. how the address advances beat to beat: FIXED (same address — e.g. a FIFO port), INCR (incrementing — the workhorse for memory), or WRAP (incrementing then wrapping at a boundary — for cache-line fills).

Together these say: start here, move this many beats of this width, stepping the address this way. That's the entire geometry of the write, declared up front on AW.

4. The Identity — AWID

AWID is the transaction identifier the manager attaches to this write. It's the hook that makes concurrency work: writes with the same AWID must keep order, while writes with different IDs may complete out of order — and the matching BID on the response pairs each completion back to its write. So AWID is how a manager can have multiple writes outstanding and still know which B belongs to which (Module 8 goes deep on this).

For a simple, in-order master, AWID may be a constant; for a high-throughput one, it's how the interconnect routes responses and how ordering guarantees are scoped. Either way, it rides AW and is fixed for the whole transaction.

5. The Attributes

The remaining AW signals are access attributes — hints about how the access should be treated, not what data moves:

• AWLOCK — normal vs exclusive access (for atomic read-modify-write).
• AWCACHE — cacheability/bufferability memory attributes.
• AWPROT — protection: privileged/unprivileged, secure/non-secure, data/instruction.
• AWQOS — a quality-of-service priority hint for arbitration.
• AWREGION — a region identifier the interconnect can use for decoding.
• AWUSER — user-defined sideband.

These shape policy (security, caching, priority) rather than the transfer geometry, and most simple slaves can ignore several of them. Module 6 decodes each in full; for launching a write, know that they exist, ride AW, and are constant for the transaction.

6. The AW Handshake

AW uses the same VALID/READY handshake as every channel (Module 3): the manager drives AWVALID with the whole AW bundle; the subordinate raises AWREADY; on the edge where both are high, the address is accepted and the write is launched.

Everything you've learned about the handshake applies here: AWVALID must not wait for AWREADY (cardinal rule), the AW payload must stay stable while waiting (stability rule), and AWREADY may be asserted before or after AWVALID. Once the AW handshake completes, the manager's address-phase job is done; the write continues on W.

7. AW in the Write Lifecycle

AW is the opener of the three-channel write (Chapter 2.3): the AW handshake launches the transaction, the W channel then delivers the beats whose count and shape AW declared, and the B channel finally confirms it.

8. Common Misconceptions

9. Debugging Insight

10. Verification Insight

11. Interview Questions

12. Summary

The AW channel launches a write: one AWVALID/AWREADY handshake commits the manager to one write transaction and carries everything about it except the data. AWADDR gives the start address; the shape is declared by AWLEN (beats − 1), AWSIZE (bytes per beat = 2^AWSIZE), and AWBURST (FIXED/INCR/WRAP address stepping); AWID tags the transaction for outstanding/ordering and pairs with the response's BID; and the attributes (AWLOCK/AWCACHE/AWPROT/AWQOS/AWREGION/AWUSER) carry access policy. AW carries no write data — that's the W channel.

Because AW fully declares the write's geometry, it's the anchor for both debugging and verification: capture the AW handshake, and you know to expect exactly AWLEN+1 W beats of AWSIZE width stepping per AWBURST, ending in WLAST, with a B whose BID matches AWID — and most write bugs are a later channel disagreeing with what AW declared. The handshake rules from Module 3 apply unchanged (cardinal rule, stability). Next, the data the AW shape described actually moves: the W channel, with WDATA, WSTRB, and WLAST.

13. What Comes Next

AW launched the write; now the data flows:

• 4.2 — The Write Data (W) Channel (coming next) — WDATA, the WSTRB byte strobes, beat sequencing, and WLAST.
• 4.3 — The Write Response (B) Channel (coming soon) — why writes need an explicit response, and BRESP/BID.

Previous: 3.6 — Common Handshake Bugs. For the broader protocol catalog, see the AMBA family overview doc.