AMBA AXI4 PROTOCOL
WHAT IS AMBA AXI4 PROTOCOL?
The ARM Advanced Microcontroller Bus Architecture (AMBA) is an open-standard, on-chip
interconnects specification for the connection and management of functional blocks in system-
on-a-chip (SOC) designs.
AXI4: Memory mapped AXI masters and slaves can be connected together using a structure
called an Interconnect block. The AXI Interconnect IP contains AXI-compliant master and slave
interfaces, and can be used to route transactions between one or more AXI masters and slaves.
WHY AXI4 PROTOCOL?
AMBA AXI4 supports data transfers up to 256 beats and unaligned data transfers using byte
strobes. In AMBA AXI4 system 16 masters and 16 slaves are interfaced. Each master and slave
has their own 4 bit ID tags. AMBA AXI4 system consists of master, slave and bus (arbiters and
decoders). The system consists of five channels namely write address channel, write data
channel, read data channel, read address channel, and write response channel. The AXI4 protocol
supports the following mechanisms:
Unaligned data transfers and up-dated write response requirements.
Variable-length bursts, from 1 to 16 data transfers per burst.
A burst with a transfer size of 8, 16, 32, 64, 128, 256, 512 or 1024 bits wide is supported.
support for multiple region interfaces
updated write response requirements
updated AWCACHE and ARCACHE signaling details
additional information on ordering requirements
details of optional User signaling
removal of locked transactions
removal of write interleaving
APPLICATIONS OF AXI4:
1) DESIGN AND VERIFICATION FOR AMBA AXI4 PROTOCOL FOR
SOC INTEGRATION :The work is proposed in this project is the achievement of
communication between one master and one slave using Verilog, then verifying the design
using System Verilog.
SPECIFICATION:
Operating frequency: 100MHz
Clock cycle of duration: 10ns
Maximum data transfers per burst: 256 data transfer per burst
One master, one slave.
5 channels between AXI master and slave.
It defines both bus specification and a technology independent methodology for
designing, implementing and testing customized high-integration embedded interface
METHOD IMPLEMENTED FOR THE DESIGN:
FIG: Block Diagram of a system
There are 5 different channels between the AXI master and AXI slave namely write address
channel, write data channel, read data channel, read address channel, and write response channel.
In AXI protocol, every transfer is done using hand shake mechanism. Each channel uses the
same VALID/READY handshake to transfer control and data information. This two-way flow
control mechanism enables both the master and slave to control the rate at which the data and
control information moves. The source generates the VALID signal to indicate when the data or
control information is available. The destination generates the READY signal to indicate that it
accepts the data or control information. Transfer occurs only when both the VALID and READY
signals are HIGH. There must be no combinatorial paths between input and output signals on
both master and slave interfaces.
Verification Environment of AXI Protocol:
FIG: The Test bench Architecture
The main aim is to verify the design “AXI”, by applying different inputs.
Test Case: The „Test case‟ includes the list of test cases. Each test case is connected to the
“sequences” which written for the different scenarios like, single_write_operation,
single_read_operation, write_followed_read_operation, multiple_write_single_read,
single_wite_multiple_read, etc., Any one of the test case is connected to the Verification
Environment to verify the design for a particular scenario.
AXI_Transaction_Generator Transaction generator is also known as the “sequence item”.
Sequence_item is a class which includes all the port signals as its property. All these signals are
declared using a “rand” keyword, so that after calling the randomize function this class should
assign the random value to the each signal. This generated input values are assigned later to the
DUV.
AXI_Master_Transaction: It includes the signals which are driven from the master. This class
has the instance of the AXI_transaction_generator. The master transaction can override the
values that are generated in the AXI_transaction_generator. Suppose we have not over ridden
any signals, then the values that are generated in the AXI_transaction_generator are passed to the
DUV.
AXI_Slave_Transaction It includes the functionality similar to AXI_Master_Transaction,
except it includes the signals which are driven from the slave.
AXI_Scoreboard The values generated in the AXI_Master_Transaction and
AXI_Slave_Transaction are also stored in the AXI_scoreboard. Later we can use these signals
for the comparison of expected output and the actual output.
Functional Coverage This class includes the list different coverage scenarios, which checks for
the how much part of the design is covered during verification. AXI_Master_Transaction and
AXI_Slave_Transaction classes will invoke this functional coverage.
AXI_Master This is the main block of master part, it includes the two sub-blocks
Write/read/get data and AXI master BFM.
Write/read/get data: This sub-block includes the objects of classes‟ sequencer, driver, and
monitor. Sequencer picks the assigned sequence and drops it into the driver. It drives these
signals according to the protocol. Monitor monitors whether signals are changing according to
protocol or not
AXI master BFM: This is the class which includes the functions related to the buses. BFM
stands for Bus Function Modules. Finally the signals driven from the driver are passed to the
DUV.
AXI_Slave has the functionality similar to AXI_Master.
AXI_Assertions It includes the list of assertions which are written according to the signal
description. These are written using assert statements. These assertions are applied to the signals
that are driving from the driver before applying to the DUV.
The data is to be read or written to the slave is assumed to be given by the master and is read or
written to a particular address location of slave. In this paper, an effective verification
environment can simulate most cases of the AXI signal, check all the transmitted data
automatically and complete coverage analysis during the simulation. So the environment can
improve the coverage and reduce the time spending in the verification.
