AXI stands for Advanced eXtensible Interface. It is an AMBA protocol used for high-performance, high-frequency, and high-throughput communication in SoCs.
AXI is used when the design needs independent read and write channels, burst transfers, multiple outstanding transactions, and efficient data movement between processors, DMA engines, memories, accelerators, and interconnects.
AXI is more advanced than AHB because it separates address, data, and response channels and allows greater concurrency. From a verification point of view, this also makes AXI more complex because ordering, IDs, handshake rules, bursts, and responses must all be checked carefully.

2. What is the difference between AXI and AHB?

AHB is a pipelined bus with a shared address/control structure, while AXI uses separate independent channels for write address, write data, write response, read address, and read data.

AXI supports multiple outstanding transactions and can allow out-of-order completion based on transaction IDs. AHB is simpler and generally has less concurrency. AXI also uses a VALID/READY handshake on each channel, while AHB relies heavily on HREADY for transfer completion.

AXI improves performance by increasing parallelism. Write address and write data can move independently, read and write traffic can happen simultaneously, and responses can be decoupled from requests.

3. What are the five AXI channels?

AXI has five independent channels: Write Address channel, Write Data channel, Write Response channel, Read Address channel, and Read Data channel.

The Write Address channel carries AWADDR and write control information. The Write Data channel carries WDATA, WSTRB, and WLAST. The Write Response channel returns BRESP. The Read Address channel carries ARADDR and read control information. The Read Data channel returns RDATA, RRESP, and RLAST.

Each channel has its own VALID/READY handshake. This is one of the most important AXI concepts because every channel can be stalled independently, and verification must track each channel separately.

4. What is the VALID/READY handshake in AXI?

The VALID/READY handshake is the transfer mechanism used on every AXI channel. The source asserts VALID when it has valid information to send. The destination asserts READY when it can accept the information.
A transfer occurs only on a rising clock edge where both VALID and READY are HIGH. If VALID is HIGH and READY is LOW, the source must hold the payload stable. If READY is HIGH and VALID is LOW, no transfer occurs because there is no valid payload.
A key rule is that VALID must not depend on READY. The source should assert VALID when data or control information is available, and then hold it until the handshake occurs.

5. Explain an AXI write transaction.

An AXI write transaction uses three channels: Write Address, Write Data, and Write Response. The manager sends address and control information on the AW channel, sends write data beats on the W channel, and receives the write response on the B channel.

The AW and W channels are independent. The write address may arrive before the write data, or write data may arrive before the write address, depending on interconnect and buffering. The subordinate must combine the accepted address/control and all write data beats to complete the transaction.

The write response is returned after the write address has been accepted and all write data beats, including the beat with WLAST, have been accepted. Verification must check channel independence, correct beat count, correct WLAST, correct WSTRB, and legal BRESP.

6. Explain an AXI read transaction.

An AXI read transaction uses two channels: Read Address and Read Data. The manager sends address and control information on the AR channel. The subordinate returns one or more data beats on the R channel.

For a burst read, each data beat is transferred using RVALID and RREADY. The last beat is marked using RLAST. The response for each read beat is carried using RRESP.

The read data may come later and may be stalled independently from the address channel. A monitor must record the AR request and then match the returned R beats using transaction ID, beat count, and RLAST.

Intermediate level questions

1. Can AXI VALID wait for READY before asserting?

No. In AXI, VALID must not wait for READY before asserting. When the source has valid information, it should assert VALID and keep the payload stable until the handshake occurs.
This rule prevents deadlock. If the source waits for READY and the destination waits for VALID, neither signal may ever assert. That would stop the channel permanently.
In verification, this is an important assertion. A design should not create a combinational or logical dependency where VALID is asserted only after READY is seen. Once VALID is asserted, the payload must remain stable until VALID and READY are both HIGH.

2. Can AXI READY wait for VALID before asserting?

Yes. AXI allows READY to be asserted before VALID, after VALID, or in the same cycle as VALID. The destination can decide when it is ready to accept information.
For maximum performance, a destination may keep READY HIGH whenever it has buffer space. For power or flow-control reasons, it may assert READY only after seeing VALID. Both styles are legal.
VALID has a stricter independence rule, while READY is more flexible. Verification should allow all legal READY timing patterns and should not assume READY is always HIGH.

3. Why does AXI have separate read and write channels?

AXI separates read and write channels to improve concurrency and throughput. A system can issue read and write requests independently, transfer write data while read data is returning, and avoid forcing all traffic through a single shared channel.
The five-channel structure also allows backpressure on one channel without necessarily blocking all other channels. For example, the write data channel may be stalled while the read address channel continues to accept requests.
The performance benefit is parallelism. The verification challenge is that related information may arrive on different channels at different times and must be matched correctly.

4. What are outstanding transactions in AXI?

Outstanding transactions are transactions that have been issued but have not yet completed. For example, a manager may send multiple read addresses before all read data returns, or multiple write addresses before all write responses return.
AXI supports outstanding transactions to improve performance. Instead of waiting for one transaction to finish before starting the next, the manager can keep the interconnect and subordinate busy.
From a verification perspective, outstanding transactions require tracking. The monitor and scoreboard must maintain pending queues using ID, address, burst length, and direction. Without correct tracking, responses may be matched to the wrong request.

5. What is the role of AXI transaction ID?

AXI IDs are used to identify and track transactions. They allow multiple outstanding transactions and help match responses to requests.
For read transactions, the ID on the read address channel is returned with the read data. For write transactions, the ID associated with the write address is returned with the write response. This allows the manager to know which request a response belongs to.
Ordering is an important part of AXI ID handling. Transactions with the same ID must follow the required ordering rules, while transactions with different IDs may be allowed to complete out of order depending on the interconnect and subordinate behavior. A verification environment must model these ordering rules correctly.

6. What are AxLEN, AxSIZE, and AxBURST?

AxLEN, AxSIZE, and AxBURST define an AXI burst. The prefix Ax means the concept applies to both AW and AR channels.

AxLEN indicates the number of beats in the burst encoded as beats minus one. AxSIZE indicates the number of bytes in each beat as a power-of-two encoding. AxBURST indicates the burst type, such as FIXED, INCR, or WRAP.

These fields control address generation and beat counting. Verification must check that the number of data beats matches AxLEN + 1, that each beat has the correct size, that WLAST/RLAST appears on the final beat, and that address progression follows AxBURST.

7. What is the purpose of WLAST and RLAST?

WLAST marks the last beat of a write data burst. RLAST marks the last beat of a read data burst.

For a burst with AxLEN = N, the total number of beats is N + 1. The last signal should be asserted on the final beat of that burst. For a single-beat transaction, the last signal is asserted on the only data beat.

In verification, last-signal checking is essential. If WLAST or RLAST is early, late, missing, or asserted multiple times, the burst is malformed. Scoreboards and monitors should count accepted beats, not just cycles, because stalls can occur when VALID or READY is LOW.

8. What is the use of WSTRB in AXI?

WSTRB indicates which byte lanes of WDATA are valid during a write transfer. Each bit of WSTRB corresponds to one byte lane.

This allows partial writes. For example, on a 32-bit data bus, a write can update only one byte, two bytes, or all four bytes depending on WSTRB. The subordinate should update only the selected byte lanes.

From a verification perspective, WSTRB is very important for memory and register scoreboards. A full-word write and a byte-lane write should not update expected memory state in the same way. The expected model must apply the strobe mask correctly.

9. What are AXI response types?

AXI response types commonly include OKAY, EXOKAY, SLVERR, and DECERR. These responses indicate the completion status of read or write transactions.

OKAY means normal successful access. EXOKAY is used for successful exclusive accesses. SLVERR indicates that the subordinate received the transfer but could not complete it successfully. DECERR usually indicates a decode error, such as an address that does not map to a valid subordinate.

Read responses are returned on the R channel and write responses are returned on the B channel. For reads, each data beat has an RRESP. For writes, one BRESP is returned for the whole write transaction.

10. What is the AXI 4KB boundary rule?

An AXI burst must not cross a 4KB address boundary. All beats of the burst must remain within the same 4KB address region.
The reason is address decoding. Many systems decode the upper address bits to select a subordinate or memory region. If a burst crossed a 4KB boundary, it could cross into a different decode region in the middle of the burst, which would complicate routing and response behavior.
Verification should include bursts that start near a 4KB boundary and confirm that legal bursts stay inside the boundary while illegal bursts are either prevented by the manager or flagged by protocol checks.

11. How are unaligned transfers handled in AXI?

AXI can support unaligned transfers depending on the access type and system design. An unaligned transfer starts at an address that is not naturally aligned to the transfer size.

For writes, WSTRB helps indicate which byte lanes are valid, especially for partial or unaligned accesses. For reads, the subordinate returns data according to the address and size rules, and the manager interprets the correct bytes.

In verification, unaligned transfers require careful modeling. The checker must consider start address, transfer size, byte lanes, burst type, and boundary restrictions. Many bugs appear when a design handles aligned word accesses correctly but fails byte or halfword cases.

Difficult level questions

1. Can AXI write data arrive before write address?

Yes. AXI allows the write data channel and write address channel to operate independently, so write data can arrive before write address, write address can arrive before write data, or both can progress in parallel.
This is possible because the AW and W channels have separate VALID/READY handshakes. A subordinate or interconnect must be designed to handle the allowed ordering, usually through buffering and transaction tracking.
AXI channel independence allows either address-first or data-first ordering, but the write response cannot be completed until the write address and all required write data beats have been accepted.

2. When can BVALID be asserted?

BVALID can be asserted only after the subordinate has accepted the write address and all write data beats for that write transaction. The final write data beat is identified by a successful handshake with WLAST asserted.

The write response represents completion of the entire write transaction, not just one channel. Therefore, the subordinate must know both where the write goes and that all data beats have arrived before returning BRESP.

In verification, this is checked by tracking AW handshakes and W handshakes. An assertion or monitor should flag a BVALID response that appears before the required address and final data beat have been accepted.

3. When can RVALID be asserted?

RVALID can be asserted when the subordinate has valid read data and response information for a previously accepted read address transaction.

For burst reads, each accepted R beat transfers one data beat. The final beat must assert RLAST. The number of accepted R beats must match the burst length specified by ARLEN + 1.

A verification engineer should not assume read data appears immediately after the AR handshake. The subordinate may add latency, return data later, or interleave responses according to supported ID and ordering rules. The monitor should match R beats back to the correct AR request.

4. Why must VALID not depend on READY?

VALID must not depend on READY because such dependency can create deadlock. If the source waits for READY before asserting VALID, and the destination waits for VALID before asserting READY, the channel can become stuck forever.
The AXI handshake is designed so the source independently announces that payload is available using VALID. The destination independently announces capacity using READY. A transfer occurs only when both are HIGH.
This is also a common assertion topic: once VALID is asserted, it should remain asserted until handshake, and the payload should remain stable during that time.

5. How does AXI handle write data ordering?

AXI4 removed write data interleaving. That means write data beats on the W channel must correspond to write transactions in the correct accepted write-address order.

The W channel does not carry a separate write data ID in AXI4. Because of that, the receiving logic must associate write data with write addresses based on ordering rules rather than a WID signal.

This is important because AXI has IDs, but the write data channel in AXI4 is not independently tagged with an ID. Verification should check that write data beats and WLAST align with the expected AW transaction order.

6. Does AXI support early burst termination?

AXI does not support arbitrary early termination of a burst. Once a burst transaction is issued, the expected number of data beats is defined by AxLEN + 1.

For writes, the manager must provide all write data beats and assert WLAST on the final expected beat. For reads, the subordinate must return all requested read beats and assert RLAST on the final beat.

If a manager no longer needs the remaining data, the protocol still requires the burst to complete. System-level cancellation must be handled outside the normal burst mechanism. Verification should flag missing, extra, early, or late last beats.

7. What is the difference between SLVERR and DECERR?

SLVERR means the transfer reached a subordinate, but the subordinate reported an error. This could happen because of an unsupported access, protection violation, internal error, or access to an invalid register within a valid subordinate.

DECERR means decode error. It usually occurs when the address does not map to any valid subordinate or target region in the interconnect.

This distinction is useful in debugging. DECERR points to address map or decode problems. SLVERR points to the selected subordinate rejecting or failing the access. A verification environment should check both response types using directed invalid-address and invalid-access tests.

8. What is the effect of register slices in AXI?

Register slices add pipeline stages between AXI endpoints. They are used to improve timing closure by breaking long combinational paths on VALID, READY, and payload signals.
A register slice may add latency, but it should not change the functional meaning of transactions. Handshakes, data order, IDs, responses, and burst structure must remain correct.
In verification, this means checkers should be latency-tolerant. They should not expect a fixed number of cycles between request and response unless the design specification requires it. Instead, they should check ordering, payload stability, and eventual completion.

9. What AXI assertions are commonly written?

Common AXI assertions check VALID/READY handshake behavior, payload stability, legal burst length, correct WLAST/RLAST, response ordering, 4KB boundary compliance, and no illegal early burst termination.

For example, if AWVALID is HIGH and AWREADY is LOW, the AW payload must remain stable. Similar checks apply to W, B, AR, and R channels. Another common assertion counts accepted W beats and checks that WLAST appears exactly on the final beat.

Each assertion should connect to a failure it prevents. Stability assertions prevent payload corruption during backpressure. Last-beat assertions prevent malformed bursts. Boundary assertions prevent illegal address crossing. Ordering assertions prevent response mismatches.

10. How would you debug an AXI hang?

First identify which channel is stuck. Check whether VALID is HIGH and READY remains LOW, or READY is HIGH and VALID never arrives. Since AXI has independent channels, a hang may occur on AW, W, B, AR, or R independently.

Next check dependencies between channels. A common design bug is waiting for events in an order that the protocol does not require. For example, a design may incorrectly wait for AW before accepting W, while the system sends W first and expects buffering.

Then check outstanding transaction tracking, buffer fullness, and response generation. For writes, confirm that AW and all W beats including WLAST were accepted before expecting B. For reads, confirm that AR was accepted and that the subordinate has a path to return all R beats including RLAST.

11. What functional coverage is useful for AXI verification?

Useful AXI coverage includes read/write transactions, all burst types, different burst lengths, transfer sizes, aligned and unaligned addresses, legal boundary-near bursts, response types, and different WSTRB patterns.

Coverage should also include backpressure on every channel. For example, stall AW, W, B, AR, and R independently and in combination. This helps expose bugs caused by incorrect channel dependency assumptions.

For advanced AXI verification, coverage should include multiple outstanding transactions, same-ID and different-ID ordering cases, out-of-order completions where supported, and stress scenarios with simultaneous read and write traffic.

Interview Questions