Design of AXI

Verification IP in a
Nutshell
Overview and Implementation using UVM

by Anoushka Tripathi

preencoded.png
 Table of Contents
Introduction

AXI Protocol overview

UVM Based AXI Verification IP Design

Components of AXI Verification IP

AXI Read/Write Operations

Burst transactions

AXI Testbench design

AXI Protocol Constraints and Randomization

Error Handling

Results and conclusion

preencoded.png
Introduction
Background Importance Objective
The AXI protocol is a key component Verification ensures the correct The goal is to design an AXI
in modern System-on-Chip (SoC) functionality of SoCs by thoroughly Verification IP using UVM, which will
designs, enabling high-performance validate AXI transactions, burst
data communication between testing the AXI protocol. It helps modes, and protocol compliance
processors, memory, and peripherals. identify potential issues early, through a reusable, coverage-driven
Its support for burst transfers and ensuring the system performs reliably testbench.
parallel transactions makes it ideal for
under various conditions and meets
complex SoC architectures.
design specifications.
preencoded.png
 AMBA Overview
Open standard for SoCs : Allows components in System-on-Chip (SoC) designs to communicate efficiently.

Efficient communication: AMBA enables smooth data transfers between different blocks in a chip,
improving system performance.

Supports IP reuse: Designers can reuse verified intellectual property (IP) blocks, reducing
development time and costs.

Compatibility and flexibility: AMBA supports various SoCs with different power, performance, and
area requirements, ensuring compatibility across devices.

Widely used: AMBA is found in microcontrollers, smartphones, IoT devices, and more, due to its adaptability
and efficiency.

preencoded.png
 AXI Overview
Part of AMBA protocol: AXI is a key protocol within the AMBA family, tailored
for high-performance system interconnects.

Independent read/write channels: AXI allows simultaneous data

transfers, boosting efficiency by separating read and write channels.

Supports burst transactions: AXI can transfer data in bursts, which

improves data flow for large transfers.

Handles multiple outstanding transactions: Multiple transactions can

be processed concurrently without waiting for earlier ones to finish.

Optimizes bandwidth and latency: AXI’s design minimizes delays and

maximizes data throughput, critical for modern SoCs
preencoded.png
AXI protocol – Master Slave Communication

Communication between the

master and slave occurs over
multiple channels:
• Write Address Channel
• Write Data Channel
• Write Response Channel
• Read Address Channel
• Read Data Channel

preencoded.png
 Read Transaction Flow

arvalid to indicate
master have applied
valid address

arready indicates slave

is ready to accept
address

araddr contains the address

from which data will be read.

preencoded.png
 Read Transaction Flow
rvalid indicates slave is
ready to accept data

master asserts rready

when it is ready to
accept the data.

rdata contains the

actual data read from
the specified address.
Rstrb indicates lane
have valid data.

preencoded.png
Write Transaction Flow
Write Transaction Flow:
1.Write Address (awaddr):
•The AXI master sends the write
address to the slave, which is
indicated by the valid signal
(awvalid) and acknowledged by the
ready signal (awready).
2.Write Data (wdata):
•After the address is transferred,
the data is sent over the write data
channel. The data transfer is valid
when wvalid is high and
acknowledged by the slave with
wready.
3.Write Response (bresp):
•Once the data is successfully
written, the slave responds with a
write response (bresp), confirming
the completion of the write
transaction. The response can indicate
success or an error.

preencoded.png
master asserts rready when it is ready to accept the data.

Importance of Burst Modes in AXI

preencoded.png
Universal Verification Methodology (UVM)
Overview

Modular Components Transaction-based Constrained random testing

UVM utilizes reusable Focuses on verifying the Allows for generating
blocks such as drivers, flow of transactions randomized test scenarios
monitors, and agents to between components, within specified constraints,
streamline testbench making it easier to increasing the probability of
design and improve validate complex data catching edge-case bugs.
verification efficiency. exchanges in a system. preencoded.png
AXI Testbench Architecture
UVM Test: The test is at the top of the hierarchy that initiates the environment component construction. It is also
responsiblefor the testbench configuration and stimulus generation process.

UVM Environment :An environment provides a well-mannered hierarchy and container for agents, scoreboards.

UVM Agent : An agent is a container that holds the driver, monitor, and sequencer. This is helpful to have a
structured hierarchy based on the protocol or interface requirement

UVM Sequence Item : The transaction is a packet that is driven to the DUT or monitored by the monitor as a
pin-level activity

UVM Driver : The driver interacts with DUT. It receives randomized transactions or sequence items and drives
them to the DUT as a pin-level activity

UVM Sequencer : The sequencer is a mediator who establishes a connection between the sequence and the
driver.

UVM Monitor : The monitor observes pin-level activity on the connected interface at the input and output of the design.
This pin-level activity is converted into a transaction packet and sends tothe scoreboard for checking purposes.
preencoded.png
Enum for AXI Operation Modes
Different of Burst
Modes in AXI

Example usage

We update operation to wrrdincr. op is a variable which is of enum type

which will store the type of operation which we are
verifying

preencoded.png
UVM Transaction class for
AXI Transactions
Purpose of UVM Sequence Item
The sequence-item consist of data fields required for
generating the stimulus.In order to generate the
stimulus, the sequence items are randomized in
sequences.

• Randomization: The keyword rand is used to randomize fields like awaddr

and wdata, which generate different stimulus for the DUT.
• Constraints: Constraints ensure valid AXI protocol operations, such as:
• constraint txid { awid == id; wid == id; bid == id; arid == id; rid == id; }
ensures that all ID fields remain consistent within a transaction.
• constraint burst {awburst inside {0,1,2}; arburst inside {0,1,2};} restricts
the burst types to valid AXI values.
• constraint valid {awvalid !=arvalid} at a time we can either read or write,
that is why at same time awvalid and arvalid should not be equal

preencoded.png
 Sequence Class for
Sequence Class for Fixed Mode Incrementing Mode

a write transaction object.

preencoded.png
Error Transaction Sequence
Error Transaction Handling
Error handling is a critical aspect of verification, ensuring that the
system responds correctly to
erroneous transactions. Error conditions may arise when accessing
out-of-bound addresses or
when performing unsupported operations.
Error Write Transaction
The task err_wr simulates an error scenario by writing to an invalid
or out-of-bound address
(awaddr = 128). This task tests how the system responds to such
conditions, verifying whether
appropriate error responses are generated. It is essential in
ensuring the robustness of the AXI
protocol in handling erroneous writes.
Error Read Transaction
The task err_rd handles an error condition during a read
transaction by reading from an invalid
address (araddr = 128). Similar to the error write task, it ensures
that the system can detect and
respond to read errors appropriately.

preencoded.png
Error Transaction Sequence
Error Read Transaction Logic

- The `err_rd()` task initiates an error read

transaction in AXI protocol simulation.
- Logs the start of the transaction using
`uvm_info("DRV", "Error Read Transaction
Started", UVM_NONE)`.
- The read transaction starts at the positive edge
of the clock (`@posedge vif.clk`).
- **Control Signals:**
- `vif.arvalid <= 1'b1`: Master initiates a valid
read address transaction.
- `vif.rready <= 1'b1`: Master is ready to accept
data.
- Configures the read transaction's parameters
(e.g., ID, address, burst type).
- After reading all data (`vif.arlen`), deasserts the
control signals (`vif.arvalid <= 1'b0`, `vif.rready
<= 1'b0`) to end the transaction.

preencoded.png
UVM Driver for AXI Protocol
• The run_phase is a virtual task that defines what
actions the UVM driver will take during the
simulation's run phase. This task is continuously active
during the main execution
of the testbench.
• seq_item_port.get_next_item(tr); This function gets
the next transaction item from the sequence (driven
by the sequencer) and assigns it to tr (a transaction
object). It indicates that the driver should now
perform the operation
specified in tr.op
• if (tr.op == rstdut), The first condition checks if the
operation is to reset the DUT. If the operation is rstdut,
the driver will call the reset_dut() task to reset the
DUT.

preencoded.png
UVM Driver for AXI Protocol

preencoded.png
Monitor
Overview:The monitor class (mon) is responsible for observing signals in the AXI protocol and
comparing expected vs actual behavior.It extends the uvm_monitor class and includes key
methods for initialization, monitoring, and error-checking.

Key Components:
• Transaction Object:transaction tr: Used to
capture the transactions observed during the
simulation.
• Virtual Interface:virtual axi_if vif: Interface
through which the monitor observes the
signals (like clk, resetn, awaddr, etc.) in the AXI
protocol.Error
• Handling and Responses:logic [1:0] rdresp,
wrresp: Stores read and write responses.int
err: Tracks the number of errors encountered
during the read-write operations.

preencoded.png
Monitor
Overview:The monitor class (mon) is responsible for observing signals in the AXI protocol and
comparing expected vs actual behavior.It extends the uvm_monitor class and includes key
methods for initialization, monitoring, and error-checking.
Phases:
• Build Phase:Creates the transaction object
(tr=transaction::type_id::create("tr")).Sets up the
interface to the vif using uvm_config_db and raises an
error if it cannot be accessed.
• Run Phase:Monitors the AXI protocol transactions
(awvalid, arvalid, rdata, wdata).Captures write data into
an array arr[] and checks read data against it.Waits for
valid write (awvalid) and read (arvalid) signals, ensuring
data correctness.
• Error Checking and Comparison:The compare() task
checks if errors occurred and logs the results (either
success or failure) based on the read/write responses
and error count.Displays appropriate messages using
UVM info methods.

preencoded.png
 Monitor
Error Increment Concept Explained
Monitoring Read Transaction (arvalid, rdata, and rresp):
1. Wait for Read Address Valid (arvalid):
o The monitor waits for the arvalid signal to go high, indicating that the DUT has a
valid read address on the AXI bus.
2. Data Beat Loop:
o The loop iterates over the number of data beats specified by arlen + 1. This
means it waits for the data transfers based on how many beats were specified in
the read transaction.
3. Waiting for Read Valid (rvalid):
o Inside the loop, the code waits for rvalid to be asserted, indicating that the DUT
has valid read data on the bus.
4. Error Detection (rdata mismatch):
o The condition checks if the received data (vif.rdata) does not match the
expected data from the memory array (arr[vif.next_addrrd]). If there’s a
mismatch, it increments the error counter (err++).
o This process ensures that any discrepancy between what was written and what
was read back is counted as an error
preencoded.png
The env class acts as a container for the agent.

Agent
The agent class is responsible for coordinating the driver, sequencer, and monitor.

Phases:
•Build Phase: Creates the driver, sequencer, and
monitor instances.
•Connect Phase: Connects the sequencer's port to the
driver's export for transaction flow.
Environment (env) Class:
The env class acts as a container for the agent.

preencoded.png
Test Class:
The test class is the top-level control for UVM testing.

Environment (e): Holds an instance of the environment.

Sequences: Multiple sequences for different scenarios (e.g.,
valid_wrrd_fixed, valid_wrrd_incr, valid_wrrd_wrap,
err_wrrd_fix).
Reset DUT Sequence: Handles the reset of the DUT.
Phases:
Build Phase: Creates instances of the environment and different
sequences.
Run Phase: Manages the test execution, running sequences one
by one.

preencoded.png
Testbench (TB) Module:
The tb module instantiates the DUT and handles clock/reset logic.

preencoded.png