Articles
AXI Protocol Interview Questions: Channels, Handshakes, and Backpressure
Prepare for AXI4 interviews with five channels, clock-edge handshakes, stable stalled beats, independent AW/W arrival, burst counters, and backpressure checks.
An AXI waveform becomes much easier to explain when you stop counting asserted signals and start counting accepted transfers. AXI protocol interview questions usually need that distinction before any discussion of bandwidth: a beat transfers at a rising clock edge only when its channel's VALID and READY are both high.
This guide scopes the exercises to AXI4 memory-mapped interfaces, with single-clock examples. It does not mix AXI3, AXI5, AXI4-Lite, and AXI4-Stream rules. Official facts are linked to Arm and AMD documents checked on October 1, 2026; original traces and engineering recommendations are labelled separately. These are technical practice exercises, not candidate reports or employer question predictions.
A version trap matters: Arm's newer IHI 0022 Issue L records removal of AXI3/AXI4/Lite content. For the AXI4 scope here, use the corresponding earlier specification and AXI4 introduction, rather than silently importing AXI5 features. Arm Issue L revision history, Arm AXI4 introduction
Which five channels should you identify first?
Official fact: AXI4 separates write address, write data, write response, read address, and read data into five channels. Each has its own handshake. Arm AXI4 channel overview
| Channel | Source → destination | What the receiver accepts |
|---|---|---|
| AW | Manager → subordinate | Write address and control attributes |
| W | Manager → subordinate | A write-data beat and its associated qualifiers |
| B | Subordinate → manager | A write response |
| AR | Manager → subordinate | Read address and control attributes |
| R | Subordinate → manager | A read-data beat, response, and qualifiers |
“Manager” and “subordinate” name the roles; older documents use “master” and “slave.” VALID belongs to the source for that channel. READY belongs to the destination. Thus the manager drives WVALID but receives BVALID. Do not describe the entire manager as always being the source.
Original interview prompt: “The address is accepted, so has the write completed?” Answer by locating the remaining obligations. Address receipt, data receipt, and response receipt are distinct events. A single address handshake is insufficient evidence of a completed write transaction.
What exactly happens at a handshake edge?
Use a four-case ledger at the sampling edge. If VALID is low, high READY alone accepts no transfer. If VALID is high and READY is low, the offered transfer remains pending. If both are high, that edge accepts the transfer. Arm handshake and interface requirements, A3
Original waveform exercise: these are sampled W-channel values, not values changed by sequential logic after the edge. The burst has two beats:
| Edge | WVALID | WREADY | WDATA | WLAST | Accepted beat |
|---|---|---|---|---|---|
| 1 | 1 | 0 | 0x10 | 0 | None |
| 2 | 1 | 0 | 0x10 | 0 | None |
| 3 | 1 | 1 | 0x10 | 0 | First |
| 4 | 1 | 1 | 0x20 | 1 | Second and final |
There are two accepted beats, not four. Keeping VALID high across adjacent accepted beats is allowed; no mandatory low bubble separates them. The source may move to the next beat after acceptance, but must not overwrite an unaccepted one.
Now change edge 2's data to 0x99. Even if the receiver never accepted 0x99, the source changed an offered payload while stalled. That is the defect to identify; waiting until the final stored data differs misses the protocol violation.
What must stay stable under backpressure?
Official fact: while WVALID is high and WREADY is low, the offered data, strobes, and last-beat qualifier must remain stable; VALID must remain asserted until acceptance. Other channels have corresponding payload stability obligations. AMD PG101 protocol checks
For a W-channel monitor, this original teaching property captures one local obligation:
assert property (@(posedge aclk) disable iff (!aresetn)
wvalid && !wready |=>
wvalid && $stable({wdata, wstrb, wlast}));
Include implemented sideband fields such as WUSER where applicable. This is not a complete AXI checker: it does not establish address legality, burst length, response association, or functional data correctness. Its clock/reset and simulator semantics must also be reviewed.
Engineering recommendation: test a stall immediately before a final beat. A design may hold WDATA correctly while recomputing WLAST from a counter that increments every cycle. That produces a malformed burst even though the visible data seems stable. Increment the accepted-beat count from the handshake event, not merely from VALID.
May VALID wait for READY?
The source must not make VALID dependent on receiver READY. A receiver may wait for VALID before raising READY. Interface inputs must not have combinational paths to outputs. These are separate rules about progress dependencies and interface timing. Arm A3 interface and dependency rules
Original deadlock exercise: a source has a queued beat but asserts VALID only after observing READY. The receiver raises READY only after observing VALID. Both remain low indefinitely. Explain the forbidden source dependency before suggesting a larger FIFO.
Registered logic is not automatically correct either. A registered source that waits forever for READY before offering its available beat still has the progress problem. Conversely, asserting READY early is fine only if the receiver can honor every handshake it advertises.
An original capacity check makes this concrete. Suppose a receiver has room for two beats and advertises READY through registered control. It accepts one beat while downstream is blocked, then another on the next edge. If the design leaves READY high for a further edge without another free slot, it has promised a third acceptance it cannot store. Either reserve capacity for that control latency or stop advertising acceptance early enough. A skid buffer can retain a transfer arriving around backpressure propagation, but naming the buffer is not proof: show occupancy, every accepted beat, and the edge when READY changes. Test full, almost-full, and simultaneous enqueue/dequeue cases independently.
Ask what storage backs READY. “The downstream block is usually ready” is not a capacity invariant. Show what happens if it stops for several cycles at exactly the moment a transfer is accepted.
Can write data arrive before the address?
Yes. AXI4 allows leading write data, so AW and W need independent receipt state. The channels can arrive in either order. Arm AXI4 transaction overview
For AXI4, the subordinate cannot offer BVALID until the address handshake and final write-data handshake have completed. It must also preserve a pending response under B-channel backpressure. AMD write-response checks
Original one-outstanding write trace: AWADDR is held unchanged while AW is stalled; the two-beat W burst is allowed to finish first.
| Edge | Accepted event | Receipt state after edge | Response eligibility |
|---|---|---|---|
| 1 | W beat 1; AW stalled | Data started, address absent | Not eligible |
| 2 | Neither; final W beat stalled | Same receipt state | Not eligible |
| 3 | Final W beat; AW still stalled | All data received, address absent | Not eligible |
| 4 | AW address | Address and all data received | May offer response afterward |
| 5 | B, if response ready and BREADY high | Response accepted | Transaction retired |
The response might take longer; edge 5 is an illustrative earliest sampled response, not a fixed latency guarantee. Do not join AW and W by assuming their handshakes happen on the same cycle.
For a simple receiver, keep separate address-received and data-complete state, plus response-pending state. Clear the transaction's ownership at the appropriate response retirement point. If it accepts another transaction before that point, it needs explicit additional storage and association rules; one Boolean per channel is no longer a sufficient design.
How do burst length and byte strobes affect the answer?
AxLEN encodes beats minus one; AxSIZE encodes the maximum bytes per transfer. WLAST identifies the final write beat, and RLAST the final read beat. WSTRB qualifies written byte lanes. AMD register-slice signal definitions, AMD FIFO interface ports
Original aligned example: a 32-bit interface with AWSIZE 2 and AWLEN 3 describes four beats with four bytes per transfer. Stalls extend elapsed cycles without increasing the required beat count. A narrow transfer changes the byte-lane reasoning; a wider physical bus alone does not make every lane valid. AMD aligned and narrow examples
Check burst legality separately from counting. AXI4 bursts must not cross a 4 KB boundary; FIXED and WRAP have restrictions different from an INCR burst. AMD AXI VIP burst checks
An implementation can support less than the protocol permits. For example, AMD's AXI Switch documents that its IP does not support FIXED bursts and describes configurable conversions for other forms. That is a particular IP's contract, not evidence that AXI4 forbids FIXED generally. AMD AXI Switch burst conversion
What do IDs change, and what do they not change?
AXI4 permits outstanding transactions and uses IDs for association and ordering. Different IDs can allow out-of-order completion; that does not mean every transaction can reorder arbitrarily. AXI4 removed WID and write-data interleaving. Arm AXI4 ordering overview
Original scoreboard exercise: issue read A with ID 3 and read B with ID 7. Permit B's response first if the implementation supports it, but match each accepted R beat to its correct outstanding request. Then issue two reads with the same ID and check their required order. A scoreboard keyed only by arrival position cannot cover both tests correctly.
For write data, do not invent a WID field to identify beats in AXI4. Track the required write-data order and transaction boundaries. For every supported concurrency level, state how many address records, data records, and pending responses can be retained. IDs label association; they do not create storage capacity.
How would you debug low throughput or a stuck interface?
Original measurement: at 100 MHz, a 64-bit channel accepts 16 full-byte beats over 40 measured cycles. The interval rate is 16/40 = 0.4 beats per cycle, or 320 MB/s using decimal megabytes. This says nothing about unmeasured intervals or partial strobes.
Separate cycles with no offered work from cycles where offered work is blocked. Measure each channel: W may be fast while B backpressure exhausts pending-response capacity. A bandwidth number without channel, interval, and useful-byte definition cannot locate the bottleneck.
Reset also needs a contract. The protocol defines reset behavior for VALID signals; a reset during an outstanding transaction requires an agreed recovery policy for the system. Do not retain a stale scoreboard entry indefinitely or silently treat reset as successful completion. Arm reset requirements
Distinguish a required safety check from a progress expectation. AMD lists MAXWAITS checks as recommendations. A bounded completion property needs the environment or product latency assumptions that justify its bound. AMD checker classifications
Finally, configure the monitor correctly. PG101 warns that exceeding its outstanding-transaction tracking capacity can invalidate subsequent monitoring results without itself proving a system failure. Checker capacity warning, Checker parameters
Sources and Further Reading
- Arm: AXI and ACE Protocol Specification, Issue H
- Arm: Introduction to AMBA AXI4
- Arm: Issue L revision history and variant boundary
- AMD: PG101 Protocol Checks
- AMD: PG101 Global Parameters
- AMD: PG267 AXI VIP Checks
- AMD: PG373 Register-Slice Signals
- AMD: PG080 FIFO Ports
- AMD: PG353 Aligned and Narrow Transactions
- AMD: PG453 Burst Conversion