AXI4 Channels and Handshake

Learning objectives

• Explain the core mental model behind AXI4 Channels and Handshake
• Apply AXI4 Channels and Handshake within What AXI4 Is Really Doing
• Identify important boundaries, trade-offs, and failure modes
• Produce concrete evidence from the practice exercise

Related: AXI4 Overview and Architecture | AXI4 Write Transactions | AXI4 Read Transactions | AXI4 Verification and Debug

Why the Handshake Rules Matter

Most AXI4 bugs are not "wrong signal list" bugs. They are handshake bugs:

• dropping payload before transfer
• waiting for READY before asserting VALID
• combinational loops between VALID and READY
• forgetting that each channel is independent

Once the VALID/READY contract is internalized, the rest of AXI4 becomes much easier.

The Universal AXI4 Handshake

Every AXI4 channel uses the same rule:

A transfer occurs on a rising clock edge when both VALID and READY are HIGH.

That means:

• the source drives VALID when payload is available
• the destination drives READY when it can accept payload
• neither side needs a separate acknowledge signal beyond the shared handshake

Source and Destination Responsibilities

Source

The source:

• asserts VALID when payload is available
• presents the payload signals at the same time
• keeps payload stable while VALID=1 and transfer has not yet occurred

Examples:

• master is source for AW, W, AR
• slave is source for B, R

Destination

The destination:

• asserts READY when it can accept a transfer
• may assert or deassert READY freely as system conditions change

Examples:

• slave is destination for AW, W, AR
• master is destination for B, R

The Most Important Rule Newcomers Miss

The source must not wait for READY before asserting VALID.

If both sides wait:

• source waits for READY
• destination waits for VALID

then nothing ever happens.

This is why AXI4 documentation explicitly calls out dependency rules such as:

• master must not wait for AWREADY before asserting AWVALID
• master must not wait for WREADY before asserting WVALID
• slave must not wait for BREADY before asserting BVALID

Payload Stability Rule

If VALID=1 and READY=0, the source must hold payload stable until the handshake completes.

For example:

• if AWVALID=1 and AWREADY=0, then AWADDR, AWLEN, AWSIZE, and the other AW payload fields must stay stable
• if RVALID=1 and RREADY=0, then RDATA, RRESP, RID, and RLAST must stay stable

This rule is one of the best candidates for assertions.

Channel Independence

Each AXI4 channel handshakes independently.

Consequences:

• AW can stall while W moves
• AR can continue while B is stalled
• read and write channels can progress in parallel

Do not assume one channel's transfer implies anything about another channel in the same cycle unless the protocol explicitly says so.

Backpressure

Backpressure is simply the receiver deasserting READY.

Examples:

• a slave drops WREADY because its write buffer is full
• a master drops RREADY because downstream logic cannot accept another beat

Backpressure is normal AXI4 behavior. The protocol is built to tolerate it cleanly.

Write-Specific Dependency That AXI4 Tightens

AXI4 adds an important write-response dependency:

• a slave must not assert BVALID until after the write address has been accepted
• and until the last write data beat has been accepted

So a write response depends on both:

• AWVALID && AWREADY
• final WVALID && WREADY && WLAST

This tightened a legacy corner case from AXI3.

See AXI4 AXI3 vs AXI4 and AXI4 Write Transactions.

Timing Intuition

Three common legal patterns:

READY first

The destination keeps READY=1 and waits. When source raises VALID, the handshake completes immediately.

VALID first

The source raises VALID with stable payload and waits until destination raises READY.

Same-cycle assertion

Both sides raise their signals in the same cycle and transfer completes immediately.

All three are legal.

Common Bad Assumptions

• "Address must always come before data on the same cycle."
• "READY should stay high all the time."
• "If VALID goes high for one cycle, the transfer happened."
• "A master can change address while waiting for READY."

All four are wrong or incomplete.

High-Value Assertions

Useful protocol checks include:

• if VALID && !READY, payload stays stable
• source never depends combinationally on READY in a way that breaks the protocol
• beat counters advance only on handshake
• WLAST and RLAST align with burst completion

See AXI4 Verification and Debug for more verification patterns.

Practice lab

Draw or encode one legal transaction trace for AXI4 Channels and Handshake. Annotate fields, channel events, ordering points, and completion conditions; then construct one illegal or adversarial trace and define the checker that should catch it.

Review questions

1. What problem does AXI4 Channels and Handshake solve, and what assumptions does it rely on?
2. Which boundary or failure case is easiest to miss, and how would you expose it?
3. What alternative design would you consider, and what trade-off would change the decision?
4. What artifact, trace, test, or metric proves that your implementation is correct?

Completion evidence

• A working artifact, annotated trace, or reproducible experiment
• At least one normal case and one deliberately failing or boundary case
• A concise explanation of the design choice and its trade-offs
• Saved output showing how correctness was evaluated