Protocols

AXI4 & AXI4-Lite protocol basics

AXI — the Advanced eXtensible Interface, part of Arm's AMBA family — is the dominant on-chip interconnect protocol for memory-mapped traffic in modern SoCs. Get its handshake right and your IP plugs into the rest of the chip cleanly; get it subtly wrong and you get deadlocks, dropped beats, and bugs that only appear under back-to-back traffic. This guide covers the five channels, the VALID/READY handshake and its two unforgiving rules, how bursts work (AWLEN, AWSIZE, AWBURST, WLAST), the AXI4-Lite subset, and the protocol bugs that bite real designs most often.

The five channels

AXI4 is not one bus — it is five independent channels, each with its own handshake. A write transaction uses three of them; a read transaction uses two:

• AW — Write Address. The master sends the target address and the burst attributes (AWLEN, AWSIZE, AWBURST, AWID).
• W — Write Data. One or more data beats, each with byte-lane strobes (WSTRB) and a WLAST flag on the final beat.
• B — Write Response. The slave returns a single response (BRESP) for the whole burst — OKAY, SLVERR, and so on.
• AR — Read Address. Same idea as AW, but for reads (ARLEN, ARSIZE, ARBURST, ARID).
• R — Read Data. The returned data beats, each carrying its own response (RRESP) and an RLAST on the final beat.

The point of splitting address, data, and response onto separate channels is concurrency: a master can issue a new address while data from a previous transaction is still in flight, and a slave can return responses out of order using transaction IDs. That decoupling is the source of AXI's throughput — and of most of its subtlety.

The VALID/READY handshake — and its two rules

Every one of the five channels moves data the same way: a two-wire VALID/READY handshake. The source raises VALID when it has a payload to offer; the destination raises READY when it can accept one. A transfer happens on the rising clock edge where both are high at the same time. Simple — but two rules trip up nearly every first AXI implementation:

• VALID must not depend on READY. The source may not wait to see READY before asserting VALID. If both sides wait for the other to move first, the channel deadlocks. (The reverse is fine: READY may freely depend on VALID.)
• VALID, once asserted, stays asserted. After the source raises VALID, it must keep it high — and hold the payload stable — until the handshake completes. It may not drop VALID just because READY is still low, and it may not change the address or data mid-offer.

// AXI VALID/READY handshake on the write-address (AW) channel.
// A beat is accepted on the clock edge where AWVALID && AWREADY.
//
//          ___     ___     ___     ___     ___
// clk   __|   |___|   |___|   |___|   |___|   |__
//          ____________________
// AWVALID _|                    |________________   (held until accepted)
//                      ________________
// AWREADY ____________|                |__________
//                          ^
//                          |  handshake here: both high on this edge
// AWADDR  <===== ADDR held stable while AWVALID =====><...>
//
// Rule 1: AWVALID must NOT be a function of AWREADY.
// Rule 2: once AWVALID is high it stays high, payload stable,
//         until the AWVALID && AWREADY edge.

These two rules are exactly the kind of property that SystemVerilog assertions were made to express: “VALID high and READY low this cycle implies VALID still high next cycle, with stable payload.” Get an assertion like that in place and the deadlock and stability bugs surface immediately instead of three months later in the lab.

Bursts: AWLEN, AWSIZE, AWBURST, WLAST

A single AXI address transfer can move a whole burst of data beats, which is how AXI achieves high throughput without re-arbitrating per word. The address channel carries the burst shape:

• AWLEN — the burst length encoded as beats minus one. AWLEN = 3 means four beats. (Full AXI4 allows up to 256 beats for INCR.)
• AWSIZE — the number of bytes transferred per beat, as a power of two (3'b010 = 4 bytes).
• AWBURST — the address pattern: FIXED (same address each beat, e.g. a FIFO port), INCR (address increments by the transfer size), or WRAP (increments then wraps within an aligned boundary, used for cache-line fills).
• WLAST — asserted by the master on the final data beat so the slave knows the burst is complete.

// A 4-beat INCR write burst (AWLEN = 3, so beats = AWLEN + 1 = 4).
// AWSIZE encodes bytes-per-beat (e.g. 3'b010 = 4 bytes).
// AWBURST = 2'b01 = INCR (address increments each beat).
//
//   AW: AWADDR=0x1000  AWLEN=3  AWSIZE=2  AWBURST=INCR  (one handshake)
//   W : beat0 WDATA  WLAST=0
//       beat1 WDATA  WLAST=0
//       beat2 WDATA  WLAST=0
//       beat3 WDATA  WLAST=1   <-- final beat asserts WLAST
//   B : BRESP  (one response for the whole burst)
//
// Beat count on W must equal AWLEN+1, and WLAST must land on
// exactly the last of those beats -- not earlier, not later.

The contract that ties this together: the number of W beats must equal AWLEN + 1, and WLAST must be high on exactly that last beat. A slave typically tracks the burst with a beat counter derived from AWLEN; if the master's WLAST and the slave's counter disagree, every subsequent transaction is shifted — a classic, hard-to-debug corruption.

AXI4-Lite: the register-friendly subset

Not every block needs bursts. For memory-mapped control and status registers — the kind of single-word accesses a CPU makes to configure a peripheral — full AXI4 is overkill. AXI4-Lite is the deliberately stripped-down subset for exactly that job. It keeps the same five channels and the same VALID/READY handshake, so it interoperates naturally, but it removes the complexity:

• No bursts. Every transaction is a single beat, so there is no AWLEN/ARLEN, and WLAST/RLAST are effectively always set.
• Fixed data width of 32 or 64 bits, with byte strobes still available on writes.
• No transaction IDs and no out-of-order completion — one outstanding transaction at a time is the common assumption.

The result is a protocol simple enough to implement in a few dozen lines of RTL, which is why most auto-generated register blocks and CSR interfaces speak AXI4-Lite. The trade-off is throughput: it is built for correctness and simplicity, not bandwidth.

The protocol bugs that bite most often

AXI bugs cluster around a handful of recurring mistakes. Knowing them is half the battle:

• VALID waiting on READY (handshake deadlock). The master gates AWVALID behind seeing AWREADY, the slave gates AWREADY behind AWVALID, and the channel locks. This is rule one of the handshake, violated.
• VALID dropping or payload changing mid-offer. The source de-asserts VALID before the handshake or mutates the address/data while waiting — the transfer the slave finally accepts is not the one the master meant to send.
• WLAST / beat-count mismatch. A burst that sends more or fewer W beats than AWLEN + 1, or asserts WLAST on the wrong beat, desynchronizes the slave's counter and corrupts every following transaction.
• Back-to-back burst handling. Many designs work for one isolated transaction but mishandle the moment a new AW handshake arrives in the same cycle the previous burst's WLAST or BVALID lands — the beat counter resets late, or a response is attributed to the wrong burst.
• Missing or extra responses. Exactly one BRESP per write burst and one RRESP per read beat — a slave that drops a B response leaves the master's outstanding-transaction tracker hung forever.

Notice how many of these only appear under sustained, overlapping traffic. A single directed test passes; the bug needs concurrency to show, which is why structured functional coverage closure and a real verification plan matter as much as the assertions themselves.

Where ChipVerify AI fits: structural protocol-formal evidence

ChipVerify AI runs structural protocol-formal checks over your bus interfaces — APB, AHB, and AXI handshake and burst assertions — using open-source engines (Verilator, Yosys, SymbiYosys). It turns the handshake and burst rules above into concrete, machine-checked properties: that VALID never waits on READY, that VALID holds with stable payload until accepted, and that WLAST lands on exactly the AWLEN + 1 beat. When a property is exercised and holds, you get evidence with file-and-line context; when a property is never triggered, that gap is surfaced rather than rounded up to “passed.”

This is pre-signoff structural evidence on open tools — a fast, honest way to catch handshake deadlocks and beat-count mismatches early, alongside your broader RTL verification, RTL lint checklist, and clock domain crossing analysis (AXI interconnects routinely span clock domains, so the two checks complement each other). It is not a protocol-compliance signoff, not a certification, and not a replacement for a commercial AXI VIP or EDA flow — it is structural evidence to help you trust your RTL earlier in the cycle.

FAQ