The Five AXI Channels and the VALID/READY Rules

Every one of the five AXI channels moves information with the same VALID/READY handshake: the sender raises VALID when it has something, the receiver raises READY when it can take it, and the transfer happens at the clock edge where both are high. The handshake itself is simple. The rules around it, and the dependencies between channels, are what keep an AXI system from deadlocking. This article covers both.

9 min read | Intermediate

What You'll Learn

• Apply the VALID/READY rules on any AXI channel
• Explain why VALID must never wait for READY
• List the dependencies between the read and write channels
• Read a waveform with all five channels active

The Handshake

On every channel, the source drives the information and VALID, and the destination drives READY. A transfer occurs only at a rising edge of ACLK where both are high. Three cases are possible:

• VALID before READY: the source waits with its information on the channel until the destination is ready.
• READY before VALID: the destination is waiting, and the transfer takes place in the first cycle with VALID high.
• Both together: the transfer happens at the next edge.

Four rules from the specification govern every channel:

1. A source may not wait for READY before asserting VALID.
2. Once VALID is high, it stays high, with the information unchanged, until the handshake.
3. A destination may wait for VALID before asserting READY, and may raise and lower READY freely before VALID arrives.
4. On master and slave interfaces there must be no combinational path from inputs to outputs.

Rule 1 is the important one. If both sides waited for the other, nothing would ever move. Making the sender commit first breaks that circle.

Default READY Values

The specification recommends that a slave keeps AWREADY and ARREADY high by default when it can accept an address. A default of low forces every address transfer to take at least two cycles. WREADY, BREADY and RREADY may be tied high only if their side can always accept the transfer in one cycle.

Dependencies Between Channels

The channels are independent, but not completely. A few dependencies follow from what the transactions mean:

• Read: the slave must wait for both ARVALID and ARREADY before it asserts RVALID. Read data must follow its address.
• Write: the slave must wait for AWVALID, AWREADY, WVALID and WREADY, and the last beat (WLAST), before it asserts BVALID. In AXI4 the response must not come before the address is accepted.
• Everything else is free. Write data may arrive before its address, in the same cycle or after it. The slave may wait for AWVALID before raising WREADY, or for WVALID before raising AWREADY.

The deadlock trap is on the write side. A master must not wait for AWREADY before driving WVALID. If it did, and the slave happened to wait for WVALID before raising AWREADY, both would wait forever. Both behaviours are legal on their own; only the combination deadlocks, which is why the rule binds the master.

All Five Channels in a Simulation

The testbench writes two words and reads them back. Its master offers the write data three cycles before the write address. It is slow to accept the write response, and it stalls the read data twice:

// write(id, addr, len, size, burst, data, pattern, lock, delay)
write(2, 12'h040, 1, WORD, INCR, 32'hC0, 0, 0, 3);   // AWVALID waits 3 cycles, WVALID does not
bready_pat = 32'hFFFFFE3F;                          // BREADY low in cycles 6 to 8
rready_pat = 32'hFFFA7FFF;                          // RREADY low in cycles 15, 16 and 18
// read(id, addr, len, size, burst, lock, delay)
read(2, 12'h040, 1, WORD, INCR, 0, 12);

55  AW  id=2 addr=0x040 len=1 size=4 INCR
65  W   data=0x000000c0 strb=1111
75  W   data=0x000000c1 strb=1111 last
115  B   id=2 OKAY
145  AR  id=2 addr=0x040 len=1 size=4 INCR
195  R   id=2 data=0x000000c0 OKAY
215  R   id=2 data=0x000000c1 OKAY last

Follow the cases in the waveform:

• W: WVALID rises in cycle 1 and stays high, because this slave only raises WREADY once it has the address. Valid before ready.
• AW: AWREADY is already high when AWVALID rises in cycle 3, so the address moves in one cycle. Ready before valid.
• B: BVALID rises after the last data beat and waits through three cycles of BREADY low.
• R: the slave holds each beat while RREADY is low; RLAST marks the second beat.

The Master in the Testbench

Each channel of the testbench master is driven from its own command list, which is what makes it easy to create these situations. VALID is a function of the list and a delay counter only, never of READY:

assign AWVALID = run && awi < awn && aw_cnt >= aw_delay[awi] && rlasts >= aw_after[awi];
assign WVALID  = run && wi < wn && w_cnt >= w_delay[wi];
assign ARVALID = run && ari < arn && ar_cnt >= ar_delay[ari] && bn >= ar_after[ari] &&
                 (ari - rlasts) < max_reads;

always @(posedge ACLK) begin
  if (ARESETn) begin
    // ...
    if (AWVALID && AWREADY) begin
      awi    <= awi + 1;                 // next address
      aw_cnt <= 0;
    end
    if (WVALID && WREADY) begin
      wi    <= wi + 1;                   // next data beat
      w_cnt <= 0;
    end
    // ... the same for AR, and counting B and R
  end
end

Once a delay counter has expired, it keeps counting up, so VALID stays high until the handshake moves the list on. The aw_after and ar_after fields let a test order one channel after another, for example a read after a write response.

Running It in ChipVerify Lab

The example contains the AXI memory slave and this testbench. Change the delays and the ready patterns and watch how each channel waits.

Common Mistakes

55  AW  id=2 addr=0x040 len=1 size=4 INCR
65  W   data=0x000000c0 strb=1111
75  W   data=0x000000c1 strb=1111 last
85  B   id=2 OKAY
145  AR  id=2 addr=0x040 len=1 size=4 INCR
175  R   id=2 data=0x000000c0 OKAY
185  R   id=2 data=0x000000c1 OKAY last