AXI PROTOCOL CHEAT SHEET:

INTERVIEW QUESTIONS
SIMPLIFIED

IMPORTANT INTERVIEW QUESTIONS

CHALLENGING PROGRAMMING QUESTIONS
USEFUL INTERVIEW TIPS
PROJECT IMPLEMENTATION

Prasanthi Chanda
1. What is the purpose of BRESP and RRESP in AXI?

BRESP (Write Response) and RRESP (Read Response) are used to

indicate the status of write and read transactions, respectively.
BRESP (Write Response)
After a write transaction, the slave must inform the master
whether the write was successful or if an error occurred.
This response is sent on the B (write response) channel
using BRESP.
RRESP (Read Response)
When the master reads data from the slave, the slave must
indicate whether the data is valid or if there was an error.
This response is sent on the R (read data) channel using
RRESP.
Response Encoding for BRESP and RRESP
Both signals use a 2-bit encoding:

VALUE NAME MEANING

00 OK Normal operation, successful transaction

01 EXOK Exclusive access OK (for atomic transactions)

10 SLVERR Slave error (e.g., memory failure)

11 DECERR Decode error (e.g., invalid address)

Example:
If a read request is made to an invalid memory address, the
slave might return RRESP = 11 (DECERR).
If a write completes successfully, BRESP = 00 (OKAY) will be
sent.
2. What is the role of WSTRB in an AXI write transaction?

WSTRB (Write Strobe) is used to specify which bytes in a data word

are valid and should be written.
Why is WSTRB Needed?
AXI supports narrow writes, where only specific bytes within a
data word are modified instead of the entire word.
Without WSTRB, every write would overwrite the full data word,
even when unnecessary.
WSTRB Usage
Each bit in WSTRB corresponds to one byte in the write data
(WDATA).
A 1 means the byte is valid and should be written.
A 0 means the byte should not be written.
Example for a 32-bit bus (4 bytes per word)

WSTRB BYTE3 BYTE2 BYTE1 BYTE0 EFFECT

Full word write

1111
(32-bit)

Write upper 16
1100
bits only

Write lower 16 bits

0011
only

0001 Write only byte 0

3. What is the purpose of AxCACHE signals?

AxCACHE defines the cacheability and bufferability properties of

transactions in AXI. It helps in optimizing memory accesses by
reducing unnecessary memory operations.
Bit Definition (4-bit signal)

BIT NAME MEANING

Data can be buffered before writing to

0 BUFFERABLE
memory

1 MODIFIABLE Data can be merged with other writes

Data can be allocated in cache on a

2 READ ALLOCATE
read

Data can be allocated in cache on a

3 WRITE ALLOCATE
write

Common AxCACHE Values

AxCACHE MEANING

0000 Non-cacheable, non-bufferable

0011 Bufferable and modifiable (allows write merging)

1111 Fully cacheable and bufferable (best performance)

4. What is the function of AxPROT in AXI?

AxPROT (Protection Type) is a 3-bit signal used to indicate the

security level, privilege level, and access type of a transaction.
Bit Definition (3-bit signal)

BIT NAME MEANING

0 SECURE/NON-SECURE 0 = Secure, 1 = Non-secure

1 PRIVILEDGED/USER 0 = Privileged, 1 = User

2 INSTRUCTION/DATA 0 = Instruction, 1 = Data

Common AxPROT Values

AxPROT MEANING

000 Secure, privileged, instruction fetch

001 Secure, privileged, data access

010 Secure, user, instruction fetch

011 Secure, user, data access

110 Non-secure, user, instruction fetch

Use Case:
Memory protection in secure embedded systems.
Preventing unauthorized access to system registers.
5. What is the use of AWLOCK and ARLOCK?

AWLOCK and ARLOCK are used for atomic operations and exclusive
access transactions in AXI.
Bit Definition (2-bit signal)

VALUE MEANING

00 Normal transactions (No locking)

01 Exclusive access (Used for atomic operations)

Exclusive Access Sequence

1. Exclusive Read (ARLOCK = 1)
Master reads a value and reserves access.
2. Exclusive Write (AWLOCK = 1)
If no other writes occurred, the write succeeds (BRESP = 01
EXOKAY).
If another write occurred, the write fails (BRESP = 10
SLVERR).
Why Use Exclusive Transactions?
Prevents race conditions when multiple masters access shared
memory.
Ensures atomic read-modify-write operations.
Example:
Spinlocks in multi-core processors use exclusive accesses to
implement synchronization.
6. What are the different AXI channels and their purpose?

AXI uses five independent channels to support high-performance

transactions:

CHANNEL DIRECTION PURPOSE

Write Address Sends address and control

Master → Slave
(AW Channel) signals for a write transaction

Write Data Sends actual data to be

Master → Slave
(W Channel) written

Write Response Sends completion status of a

Slave → Master
(B Channel) write

Read Address Sends address and control

Master → Slave
(AR Channel) signals for a read transaction

Read Data Sends actual data and

Slave → Master
(R Channel) response status

Key Points:
Each transaction uses two or three channels:
Write transactions: Use AW, W, and B channels.
Read transactions: Use AR and R channels.
Decoupling of channels allows high throughput (e.g., the master
can send multiple addresses before data is returned).
7. What is the purpose of AWREADY, WREADY, ARREADY,
RREADY, and BREADY?
These are handshake signals used for flow control between the
master and slave.

SIGNAL PURPOSE

AWREADY Slave is ready to accept a write address

WREADY Slave is ready to accept a write data

ARRREADY Slave is ready to accept a read address

RREADY Master is ready to accept read data

BREADY Master is ready to accept write response

Key Points:
A transaction completes only when both VALID and READY are
high at the same time.
These signals allow backpressure handling, meaning a slave can
slow down a fast master.

8. What are the different types of bursts in AXI and explain their
purpose?
AXI supports different types of burst transactions, which define
how data is transferred in multiple beats (or data units) during
a single transaction.
There are three main types of burst modes:
1. INCR (Incrementing Burst)
Description: The address is incremented by the size of the data
unit (e.g., 32-bit, 64-bit) for each beat.
Purpose: Suitable for sequential memory accesses where data is
stored in contiguous memory locations.
Example: A 4-beat transaction in an INCR burst will have
addresses incremented by the size of each data unit.
2. WRAP (Wrapped Burst)
Description: After reaching the end of the specified burst
length, the address wraps back to the starting address.
Purpose: Ideal for cache line accesses where the burst needs to
loop back to the start address.
Example: For a 4-byte burst in a 32-byte cache, after the fourth
beat, the address will wrap back to the start.
3. FIXED (Fixed Burst)
Description: The address remains constant throughout the
entire burst.
Purpose: Useful for situations like memory-mapped IO where
data is written to the same location multiple times (e.g., control
registers).
Example: Writing to the same memory location repeatedly
without changing the address.
Real Use Case:
INCR bursts are typically used in memory transfers between
processors and main memory.
WRAP bursts are used in video memory and cache controllers.
FIXED bursts are useful for control register accesses.
9. What is the significance of QOS in AXI, and how does it affect
transaction priorities?
QOS (Quality of Service) is a signal used to indicate the priority or
quality of a transaction in an AXI system, which can help prioritize
critical transactions over non-essential ones.
Function of QOS:
Defines Transaction Priority: It is typically used to prioritize
transactions based on their importance. Higher values indicate
higher priority.
Helps in Resource Allocation: In systems with limited resources,
such as bandwidth or memory, the QOS signal helps arbitrate
which transaction should be granted access to resources first.
Example of Use:
High Priority Transactions (e.g., critical data fetching for a CPU)
might be assigned a higher QOS value, ensuring that these
transactions are handled before others.
Low Priority Transactions (e.g., background memory clean-up)
may have a lower QOS value.

10. Explain the AXI protocol's support for out-of-order transactions

and how it helps in improving performance.
Out-of-order execution in AXI allows transactions to be completed
in a different order from how they were initiated, providing
several performance benefits.
How does AXI support Out-of-Order Transactions?
Multiple Outstanding Transactions: AXI allows the master to
send multiple transactions (reads/writes) before waiting for a
response, without needing to wait for the completion of one
before initiating the next.
 Transaction ID (AxID): Each transaction is assigned a unique
AxID, enabling the slave to process transactions in any order
while ensuring the correct responses are sent back to the
master.
Benefits of Out-of-Order Execution:
Higher Throughput: The master doesn't have to wait for one
transaction to finish before sending another, improving the
overall throughput.
Improved Latency: The slave can process the transactions in the
most efficient order based on its internal resources, potentially
improving response times.
Efficient Resource Utilization: Resources like buses, memory,
and data paths are kept active, reducing idle time and
optimizing bandwidth.
11. Write Verilog code for an AXI Master to perform a write
transaction. Ensure proper handshaking with the AXI Slave.
module axi_master_write (
input logic clk,
input logic resetn,

// Write address channel

output logic [31:0] AWADDR,
output logic [3:0] AWLEN,
output logic [2:0] AWSIZE,
output logic AWVALID,
input logic AWREADY,
module axi_master_write (
input logic clk,
input logic resetn,

// Write address channel

output logic [31:0] AWADDR,
output logic [3:0] AWLEN,
output logic [2:0] AWSIZE,
output logic AWVALID,
input logic AWREADY,

// Write data channel

output logic [31:0] WDATA,
output logic [3:0] WSTRB,
output logic WVALID,
input logic WREADY,
output logic WLAST,

// Write response channel

input logic [1:0] BRESP,
input logic BVALID,
output logic BREADY
);

typedef enum logic [1:0] {IDLE, ADDR_PHASE, DATA_PHASE,

RESP_PHASE} state_t;
state_t state;
always_ff @(posedge clk or negedge resetn) begin
if (!resetn) begin
AWVALID <= 0;
WVALID <= 0;
WLAST <= 0;
BREADY <= 0;
state <= IDLE;
end else begin
case (state)
IDLE: begin
AWADDR <= 32'h8000_0000; // Target address
AWLEN <= 4'd3; // 4-beat burst
AWSIZE <= 3'b010; // 4-byte transfer
AWVALID <= 1;
if (AWREADY) begin
state <= ADDR_PHASE;
AWVALID <= 0;
end
end

ADDR_PHASE: begin
WDATA <= 32'hA5A5_A5A5;
WVALID <= 1;
WSTRB <= 4'b1111;
WLAST <= (AWLEN == 0); // Last beat of burst
 if (WREADY) begin
AWLEN <= AWLEN - 1;
if (AWLEN == 0) begin
state <= RESP_PHASE;
WVALID <= 0;
end
end
end

RESP_PHASE: begin
BREADY <= 1;
if (BVALID) begin
BREADY <= 0;
state <= IDLE; // Transaction complete
end
end
endcase
end
end

endmodule
12. Write a UVM-based AXI verification testbench that generates
write and read transactions.
AXI Transaction Class (UVM)
class axi_transaction extends uvm_sequence_item;
rand bit [31:0] addr;
rand bit [31:0] data;
rand bit write;

`uvm_object_utils(axi_transaction)

function new(string name = "axi_transaction");

super.new(name);
endfunction
endclass

AXI Driver (UVM)

class axi_driver extends uvm_driver#(axi_transaction);
virtual axi_if vif;
`uvm_component_utils(axi_driver)

function new(string name = "axi_driver", uvm_component

parent);
super.new(name, parent);
endfunction

task run_phase(uvm_phase phase);

axi_transaction txn;
forever begin
seq_item_port.get_next_item(txn);
 if (txn.write) begin
vif.AWADDR <= txn.addr;
vif.WDATA <= txn.data;
vif.AWVALID <= 1;
vif.WVALID <= 1;
@(posedge vif.clk);
vif.AWVALID <= 0;
vif.WVALID <= 0;
end else begin
vif.ARADDR <= txn.addr;
vif.ARVALID <= 1;
@(posedge vif.clk);
vif.ARVALID <= 0;
$display("Read Data: %h", vif.RDATA);
end

seq_item_port.item_done();
end
endtask
endclass
13. Write a UVM sequence to generate multiple AXI transactions
with random addresses and data.

class axi_sequence extends uvm_sequence#(axi_transaction);

`uvm_object_utils(axi_sequence)

function new(string name = "axi_sequence");

super.new(name);
endfunction

task body();
axi_transaction txn;
for (int i = 0; i < 10; i++) begin
txn = axi_transaction::type_id::create("txn");
txn.addr = $random;
txn.data = $random;
txn.write = $random % 2; // Randomly choose read or
write
start_item(txn);
finish_item(txn);
end
endtask
endclass
14. Implement an AXI arbiter that handles two AXI masters
requesting access to a single AXI slave.

module axi_arbiter (
input logic clk,
input logic resetn,

// Master 0 Request & Grant

input logic M0_REQ,
output logic M0_GRANT,

// Master 1 Request & Grant

input logic M1_REQ,
output logic M1_GRANT
);

typedef enum logic [1:0] {IDLE, MASTER0, MASTER1} state_t;

state_t state;

always_ff @(posedge clk or negedge resetn) begin

if (!resetn) begin
state <= IDLE;
M0_GRANT <= 0;
M1_GRANT <= 0;
end else begin
case (state)
IDLE: begin
if (M0_REQ) state <= MASTER0;
else if (M1_REQ) state <= MASTER1;
end
 MASTER0: begin
M0_GRANT <= 1;
M1_GRANT <= 0;
if (!M0_REQ) state <= MASTER1;
end

MASTER1: begin
M1_GRANT <= 1;
M0_GRANT <= 0;
if (!M1_REQ) state <= MASTER0;
end
endcase
end
end

endmodule

15. Implement a UVM monitor that captures AXI transactions and

logs them.
class axi_monitor extends uvm_monitor;
`uvm_component_utils(axi_monitor)

uvm_analysis_port#(axi_transaction) mon_ap;
virtual axi_if vif;

function new(string name = "axi_monitor", uvm_component

parent);
super.new(name, parent);
mon_ap = new("mon_ap", this);
endfunction
 virtual function void build_phase(uvm_phase phase);
if (!uvm_config_db#(virtual axi_if)::get(this, "", "vif", vif))
`uvm_fatal("AXI_MONITOR", "Virtual interface not set")
endfunction

task run_phase(uvm_phase phase);

axi_transaction txn;
forever begin
wait (vif.AWVALID);
txn = axi_transaction::type_id::create("txn");
txn.addr = vif.AWADDR;
txn.write = 1;
mon_ap.write(txn);
`uvm_info("AXI_MONITOR", $sformatf("Captured write at
address %h", txn.addr), UVM_MEDIUM);
end
endtask
endclass
 FINAL NOTE
This document has provided detailed and advanced AXI interview
questions along with full solutions, focusing on both theoretical
concepts and practical implementations.

INTERVIEW TIPS:
✅ Be clear and concise when explaining AXI transactions.
✅ Use diagrams to illustrate your answers in interviews.
✅ Highlight real-world debugging experiences with AXI protocols.
✅ Understand AXI timing, burst modes, and transaction
dependencies.

CONTACT DETAILS:
For the interview guidance, or any additional support, feel free to
contact ProV Logic :
Email : [email protected]
Phone : +91 91822 80927
LinkedIn : @ProV Logic