AXI Responses and Exclusive Access

Every AXI write ends with a response on B, and every AXI read beat carries a response on R. The two-bit response says whether the access worked: OKAY, EXOKAY, SLVERR or DECERR. EXOKAY belongs to exclusive accesses, AXI's way of building semaphores and atomic updates without locking the bus. This article covers the four responses, how errors behave in bursts, and the exclusive access mechanism, with a simulation of each.

9 min read | Intermediate

What You'll Learn

• Choose the right response: OKAY, EXOKAY, SLVERR or DECERR
• Explain how errors are reported in read and write bursts
• Walk through an exclusive read and write that succeed and that fail
• List the restrictions on exclusive accesses

The Four Responses

The specification lists typical SLVERR causes: a FIFO overrun or underrun, an unsupported transfer size, a write to a read-only location, a timeout inside the slave, and an access to a disabled or powered-down function. It recommends using error responses only for real errors, not to signal normal events.

Errors in Bursts

Errors never shorten a burst. A write burst gets a single response for the whole transaction. A read burst gets a response per beat, so a slave can return OKAY for some beats and SLVERR for others, and it must send every beat in either case.

In the example slave, addresses from 0xF00 upwards belong to a disabled function. A write there gets SLVERR. A four-beat read starting at 0xEF8 runs into the region on its third beat:

35  AW  id=1 addr=0xf00 len=1 size=4 INCR
35  AR  id=1 addr=0xef8 len=3 size=4 INCR
45  W   data=0x000000e0 strb=1111
55  W   data=0x000000e1 strb=1111 last
65  B   id=1 SLVERR
65  R   id=1 data=0x00000000 OKAY
75  R   id=1 data=0x00000000 OKAY
85  R   id=1 data=0x00000000 SLVERR
95  R   id=1 data=0x00000000 SLVERR last

The write and the read run at the same time on their own channels. The read returns all four beats, two OKAY and two SLVERR; the master must not use the data of the failed beats.

Exclusive Accesses

A semaphore needs "read a value, then write a new one, with nobody else writing in between". AHB solved this by locking the bus. AXI4 does it without blocking anybody:

1. The master does an exclusive read (ARLOCK = 1). The slave records the address and ID in an exclusive monitor and answers EXOKAY.
2. Later, the master does an exclusive write (AWLOCK = 1) to the same address with the same ID.
3. If nobody wrote the location in between, the write updates memory and gets EXOKAY.
4. If somebody did, the monitor was cleared: the write does not update memory and gets OKAY. The master reads again and retries.

Here is that sequence in the simulation. ID 5 succeeds once; the second time, ID 6 writes the location between the exclusive read and the exclusive write:

75  AR  id=5 addr=0x200 len=0 size=4 INCR exclusive
105  R   id=5 data=0x00000000 EXOKAY last
115  AW  id=5 addr=0x200 len=0 size=4 INCR exclusive
125  W   data=0x00000055 strb=1111 last
135  B   id=5 EXOKAY
145  AR  id=5 addr=0x200 len=0 size=4 INCR exclusive
175  R   id=5 data=0x00000055 EXOKAY last
185  AW  id=6 addr=0x200 len=0 size=4 INCR
195  W   data=0x00000066 strb=1111 last
205  B   id=6 OKAY
215  AW  id=5 addr=0x200 len=0 size=4 INCR exclusive
225  W   data=0x00000057 strb=1111 last
235  B   id=5 OKAY
245  AR  id=5 addr=0x200 len=0 size=4 INCR
275  R   id=5 data=0x00000066 OKAY last

The first exclusive write returns EXOKAY and memory holds 0x55. The second returns OKAY and memory keeps ID 6's 0x66: the final read proves the failed exclusive write changed nothing. Note that OKAY is the failure signal here, which is why an exclusive-capable master must check for EXOKAY rather than for "not an error".

The slave's monitor is a few registers. An exclusive read sets it, any write to the monitored location clears it, and an exclusive write passes only if it matches:

// at the AW handshake
w_pass <= !AWLOCK || (mon_valid && mon_id == AWID && mon_addr == AWADDR);

// monitor updates
if (can_load && q_lock[q_head]) begin
  mon_valid <= 1'b1;                     // an exclusive read starts monitoring
  mon_id    <= q_id[q_head];
  mon_addr  <= q_addr[q_head];
end
else if (WVALID && WREADY && w_pass && |WSTRB && w_addr[11:2] == mon_addr[11:2]) begin
  mon_valid <= 1'b0;                     // any write to the location ends it
end

This slave has one monitor for the whole system. The specification recommends one monitor per exclusive-capable master ID, so that two masters doing exclusive accesses to different locations do not reset each other's monitor.

Exclusive Access Rules

• The exclusive read and write must use the same address, ID, size, length and control signals.
• The address must be aligned to the total size of the transfer, which must be a power of two, at most 128 bytes, and in AXI4 at most 16 beats.
• The master must not start the exclusive write until the exclusive read has completed.
• AxCACHE must make sure the access reaches the slave with the monitor; an exclusive access must not be cacheable.
• A slave without exclusive support ignores AxLOCK and returns OKAY. Its "exclusive" writes always update memory, so a master that gets OKAY for an exclusive read should treat exclusive access as unsupported.

Running It in ChipVerify Lab

The example runs the error accesses and both exclusive sequences. Follow BRESP and RRESP through the log.

Common Mistakes

185  AW  id=6 addr=0x204 len=0 size=4 INCR
195  W   data=0x00000066 strb=1111 last
205  B   id=6 OKAY
215  AW  id=5 addr=0x200 len=0 size=4 INCR exclusive
225  W   data=0x00000057 strb=1111 last
235  B   id=5 EXOKAY
245  AR  id=5 addr=0x200 len=0 size=4 INCR
275  R   id=5 data=0x00000057 OKAY last