AMBA AXI

Verification Plan

Version 0.2, 27th January 2009

Copyright Information

Please keep the latest version on top

Ver
0.1

Change
Description
Initial Draft

Sections

Date

Author

Reviewer(s)

All

0.2 Updated signal 2.1.1, 2.1.2,

diagram, signal 3.3, 3.4.3, 3.5,
list, checker list,
5
coverage. directory structure.

Reference

AMBA AXI Protocol v1.0 Specification

E Reuse Methodology version 2.0 (eRM)

Intended Audience
This document is intended for Project Managers, Design Team, Verification and Validation
Team.

Table of Contents
Revision History................................................................................................................................ ii
Reference........................................................................................................................................ ii
Intended Audience.................................................................................................................... ii
Purpose of this Document................................................................................................................ 5
Scope of this Document................................................................................................................... 5
Definitions, Abbreviation and Acronyms............................................................................................ 5
1

Introduction................................................................................................................................ 6

DUT Interface............................................................................................................................ 6
2.1

Top Interface................................................................................................................. 6

2.1.1

Signal Block Diagram................................................................................................ 6

2.1.2

Interface Signal Description.......................................................................................9

2.1.3

Feature List.............................................................................................................. 11

2.1.3.1

Single Master/Slave............................................................................................. 11

2.1.3.2

Unsupported Features:...........................................Error! Bookmark not defined.

Verification Setup..................................................................................................................... 12
3.1

Verification Strategy.................................................................................................... 12

3.2

Verification Approach.................................................................................................. 12

3.3

Verification Architecture.............................................................................................. 13

3.4

Environment Components........................................................................................... 13

3.4.1

Axi_evc_top - Environment Top...............................................................................14

3.4.2

Env.......................................................................................................................... 14

3.4.3

Agent....................................................................................................................... 14

3.5
3.5.1

Coverage Metrics........................................................................................................ 18
Functional Coverage...............................................................................................18

Tools Used.............................................................................................................................. 19

Directory / File Structure........................................................................................................... 20

List of Figures

Purpose of this Document

The purpose of this document is to provide with the Verification Plan for the AMBA AXI Bus Protocol.

Scope of this Document

This Document covers the Verification Methodology for AMBA AXI Bus Protocol module using Specman.

Definitions, Abbreviation and Acronyms

The terms in use in the document are explained / expanded below.

Acronym
AMBA

Description
Advanced Microcontroller Bus Architecture

AXI

Advanced eXtensible Interface

AMBAAXI
1 Introduction
The AMBA AXI protocol is targeted at high-performance, high-frequency system designs and includes a number of features that make it suitable for a high-speed submicron interconnect.
The objectives of the latest generation AMBA interface are to:
be suitable for high-bandwidth and low-latency designs
enable high-frequency operation without using complex bridges
meet the interface requirements of a wide range of components
be suitable for memory controllers with high initial access latency
provide flexibility in the implementation of interconnect architectures
be backward-compatible with existing AHB and APB interfaces.
2 DUT Interface
2.1

2.1.1

Top Interface

Signal Block Diagram

Master

DW_axi_gm Interface Diagram

Slave

DW_axi_gs Interface Diagram

2.1.2

Interface Signal Description

Considering AXI as Master
Signal Name
Direction

Size Description

ACLK

OUT

ARESETn

OUT

Global clock signal. All signals are sampled on the rising edge of the global clock.
Global reset signal. This signal is active LOW.

AWID

OUT

AWADDR

OUT

32

AWLEN

OUT

AWSIZE

OUT

AWBURST

OUT

AWLOCK

OUT

AWCACHE

OUT

AWPROT

OUT

AWVALID

OUT

AWREADY

IN

WID

OUT

WDATA

OUT

32

WSTRB

OUT

WLAST

OUT

WVALID

OUT

WREADY

IN

BID

IN

Write address ID. This signal is the identification tag

for the write address group of signals.
Write address. The write address bus gives the address of the first transfer in a write burst transaction.
The associated control signals are used to determine
the addresses of the remaining transfers in the burst.
Burst length. The burst length gives the exact number
of transfers in a burst. This information determines the
number of data transfers associated with the address.
Burst size. This signal indicates the size of each transfer in the burst. Byte lane strobes indicate exactly
which byte lanes to update.
Burst type. The burst type, coupled with the size information, details how the address for each transfer within the burst is calculated.
Lock type. This signal provides additional information
about the atomic characteristics of the transfer.
Cache type. This signal indicates the bufferable,
cacheable, write-through, write-back, and allocate attributes of the transaction
Protection type. This signal indicates the normal, privileged, or secure protection level of the transaction and
whether the transaction is a data access or an instruction access.
Write address valid. This signal indicates that valid
write address and control
information are available:
1 = address and control information available
0 = address and control information not available.
The address and control information remain stable until the address acknowledge signal,
AWREADY, goes HIGH.
Write address ready. This signal indicates that the
slave is ready to accept an address and
associated control signals:
1 = slave ready 0 = slave not ready.
Write ID tag. This signal is the ID tag of the write data
transfer. The WID value must match
the AWID value of the write transaction.
Write data. The write data bus can be 8, 16, 32, 64,
128, 256, 512, or 1024 bits wide.
Write strobes. This signal indicates which byte lanes to
update in memory. There is one
write strobe for each eight bits of the write data bus.
Therefore, WSTRB[n] corresponds
to WDATA[(8 n) + 7:(8 n)].
Write last. This signal indicates the last transfer in a
write burst.
Write valid. This signal indicates that valid write data
and strobes are available:
1 = write data and strobes available
0 = write data and strobes not available.
Write ready. This signal indicates that the slave can
accept the write data:
1 = slave ready
0 = slave not ready.
Response ID. The identification tag of the write response. The BID value must match the

AWID value of the write transaction to which the slave

is responding.
Write response. This signal indicates the status of the
write transaction. The allowable
2 responses are OKAY, EXOKAY, SLVERR, and DECERR.
Write response valid. This signal indicates that a valid
write response is available:
1 1 = write response available
0 = write response not available.
Response ready. This signal indicates that the master
can accept the response information.
1 1 = master ready
0 = master not ready.
Read address ID. This signal is the identification tag
4 for the read address group of
signals.
Read address. The read address bus gives the initial
address of a read burst transaction.
Only the start address of the burst is provided and the
32 control signals that are issued
alongside the address detail how the address is calculated for the remaining transfers in
the burst.
Burst length. The burst length gives the exact number
of transfers in a burst. This
4 information determines the number of data transfers
associated with the address.

BRESP

IN

BVALID

IN

BREADY

OUT

ARID

OUT

ARADDR

OUT

ARLEN

OUT

ARSIZE

OUT

ARBURST

OUT

ARLOCK

OUT

ARCACHE

OUT

ARPROT

OUT

ARVALID

OUT

ARREADY

IN

RID

IN

Burst size. This signal indicates the size of each transfer in the burst.
Burst type. The burst type, coupled with the size information, details how the address for
each transfer within the burst is calculated.
Lock type. This signal provides additional information
about the atomic characteristics
of the transfer.
Cache type. This signal provides additional information
about the cacheable
characteristics of the transfer.
Protection type. This signal provides protection unit information for the transaction.
Read address valid. This signal indicates, when HIGH,
that the read address and control
information is valid and will remain stable until the address acknowledge signal,
ARREADY, is high.
1 = address and control information valid
0 = address and control information not valid.
Read address ready. This signal indicates that the
slave is ready to accept an address and
associated control signals:
1 = slave ready
0 = slave not ready.
Read ID tag. This signal is the ID tag of the read data
group of signals. The RID value is

generated by the slave and must match the ARID value of the read transaction to which it
is responding.
RDATA

IN

32

RRESP

IN

RLAST

IN

RVALID

IN

RREADY

OUT

2.1.3

Feature List

2.1.3.1

Supported Features

Read data. The read data bus can be 8, 16, 32, 64,
128, 256, 512, or 1024 bits wide.
Read response. This signal indicates the status of the
read transfer. The allowable responses
are OKAY, EXOKAY, SLVERR, and DECERR.
Read last. This signal indicates the last transfer in a
read burst.
Read valid. This signal indicates that the required read
data is available and the read
transfer can complete:
1 = read data available 0 = read data not available.
Read ready. This signal indicates that the master can
accept the read data and response
information:
1= master ready 0 = master not ready.

The key features of the AXI protocol are:

1. Separate address/control and data phases
2. Unaligned data transfers using byte strobes
3. Burst-based transactions with only start address issued
4. Separate read and write data channels
5. Variable length Burst. (Range 1-16).
6. Bursts with transfer size of 8-1024.
7. Burst types: Fixed, Wrap, Incremental.
8. Maximum burst boundary 4KB.
9. Burst length limit on wrapping burst
a. Length of the burst must be 2, 4, 8 or 16.
b. Start address must be aligned to the size of the transfer.
10. Narrower bus transfer.
11. Response signaling: OKAY, SLVERR.
12. Ordering model: Generation of different ID tags.
a. Same IDs (for ordered transaction)
13. Ability to issue multiple outstanding addresses.
2.1.3.2
1.
2.
3.
4.
5.
6.
7.
8.

Unsupported Features

System cache support.

Protection unit support.
Response signaling: EXOKAY, DECERR.
Atomic operations.
Out-of-order transaction completion.
Easy addition of register stages to provide timing closure.
Low Power operation.
Handling error for an earlier response while later transfers are already underway.
9. Write data interleaving
10. All multi Master/slave scenarios.
11. Byte invariance.

3 Verification Setup
3.1

Verification Strategy
The verification methodology deployed is based on eRM (e Reusable Methodology). The environment is completely automated for data integrity and functionality checks to minimize
waveform level checks. The environment is architected with the following considerations.
Modularized for Re-Use, Easy Integration & Debugging

Verification Environment
Test Scenarios

Stimulus
Generation

DUT

BFM

Scoreboard

Checker /
Coverage

Figure 2: Verification strategy flow

3.2

Verification Approach

The module level verification approach is followed. HVL ( e) is used to build the test environ ment. White box/Black box verification is followed. Verification approach is explained below
Targeting different AXI supported transaction (write and read) patterns.

Targeting the AXI supported multiple transactions (writes and reads).

Targeting to get all the response types from slave during transactions.

3.3

Targeting to achieve 100% functional & code coverage.

Verification Architecture

axi_evc_top

env
Test
Cases

Agent
Config
Monitor

Sequence
Generator
&
Driver

Coverage
Protocol
Checker

Master BFM

Slave BFM

Port

DUT
Scoreboard

GIF Master BFM

GIF Slave BFM

Figure 3: Verification Environment Architecture Diagram

3.4

Environment Components

The Verification of AMBA AXI Protocol is done using several Verification components, built according
to their role.
3.4.1

Axi_evc_top - Environment Top

This is the top level test bench file in which we are instantiating all the other files. Here we are
including all the files using import directive.
This file instantiates following files:
Env,
Agent,
Sequence Driver,
BFM,
Monitor,
Coverage Model.

3.4.2

Env
Here the Environment is Instantiated in the sys. Integration of Agent and DUT signal assignment to top is done.
This will also configure as to which Agent should be Active and which agent should be Pas sive in case of multiple agents.

3.4.3

Agent
Agents are either ACTIVE or PASSIVE. ACTIVE agents drive DUT signals.
Agents are considered proactive if they initiate transactions, and reactive if they only respond
to requests.
Both ACTIVE and PASSIVE agents have a monitor. The monitor can be instantiated directly
in the
Agent.

Configuration:
The agent configuration specifies an agent.s interface with the rest of the verification environment. It contains the mode of operation (for example, active_passive, has_checker, has_coverage) and additional static information needed for the agent.s operation, such as the bus
width, endianness, etc. These parameters are encapsulated in a config struct to present a
well-defined interface for the agent.
Sequence Driver:
The sequence driver is a unit instantiated in the active agent. By default, it is connected to the
BFM in pull mode. (Push mode is not recommended.) Items generated in the sequence driver
are sent to the BFM whenever an item is available and the BFM is ready to accept a new
item. The sequence driver must support both standalone operation (generation of items inde pendent of higher-level protocols) and layering of higher-level protocols (generation of items
based on higher-level protocols).
Monitor:
The monitor is responsible for extracting signal information from the DUT and translating it
into meaningful events and status information. Its functionality is limited to the basic monitoring that is always required. Additional high-level functionality that might be required is implemented separately on top of the monitor. This includes protocol checkers, scoreboards, and
coverage.
The events recognized by the monitor depend on the actual protocol. Typically, for the
basic data item the monitor provides an item_started and an item_ended event (for example,
packet_started and packet_ended). The monitor collects the item data from the signals and
creates a current_item that has the complete item data, ready to be used when the item_ended event occurs. In addition to the raw data, the monitor should collect relevant timing infor mation such as the duration of the transaction.

Monitor Checker and Coverage

Coverage and checkers should be implemented on top of the monitor in subtypes of the monitor such as has_checker and has_coverage. That minimizes performance overhead if those
units are not used. The has_checker and has_coverage flags should be propagated to the
monitor so that the monitor code can be optimized.
Protocol errors are caught and reported by the checker part of the monitor.
BFM (Bus Functional Model):
BFMs do all of the signal driving from agents.

The BFM is a unit instantiated only in ACTIVE agents.

No generation is done in the BFM. The BFM receives a data item (from the sequence driver)
and
performs all operations required to send the data item to the DUT according to the protocol
rules. The
item should contain all necessary information to complete the transaction.
To perform its task correctly, the BFM must know the current state of the DUT. The BFM can
sense the DUT signals directly or use signal information extracted by the monitor.

Coverage:
Coverage can be implemented either as a separate unit in the agent or in a has_coverage
subtype of the monitor. By default, the has_coverage flag is TRUE in passive mode and
FALSE in active mode. If an end user wants to verify the eVC active agents capabilities, the
has_coverage flag can be set to TRUE.
Coverage operates based on events and data collected by the monitor. If it is implemented as
a separate unit, it has a pointer to the monitor that is set by the agent when the coverage unit
is instantiated.

Checker:
The checker operates based on events and data collected by the monitor. If it is implemented
as a separate unit, it has a pointer to the monitor that is set by the agent when the checker is
instantiated.
At a minimum, the checker should check:
The validity of the basic data item (for example, packet) and
The related timing requirements according to the protocol.
The checker can be implemented either as a separate unit in the agent or in a
has_checker subtype of the monitor.
By default, the has_checker flag should be TRUE in passive mode and FALSE in ac tive mode.
Group of Checkers implemented:
Sr.
Rule Details
No.
1
Address and other control signals should not have a value of x
and z after valid is asserted.
2
Check if delay between valid and ready signal is less than
MAXWAIT or not?
3
Check if all the address and control signals are stable in the duration when valid is high and ready is low?
4
Check if valid signal is going low before ready is asserted?
5
A transaction with a burst type of WRAP must have an aligned
address.
6
A write burst can not cross a 4KB boundary.
7
A write transaction with a burst type wrap should have length of
2, 4, 8, 16.
8
The size of a write transfer should not be more than the width of
the data bus.
9
Value of 2b11 not allowed in AWBURST bus.
10
When AWVALID is high and AWCACHE[1] is low then AWCACHE[3:2] should also be low
11
A value of x is not allowed in any address and control signal
when AWVALID is high.
12
AWVALID should be low for the first cycle after ARESETN goes
high.

AW

AR

Y
Y

Y
Y

Y
Y

Y
Y

Y
Y

Y
Y

13
14
15
16
17
18
19
20
21

Data Bus width can be 8, 16, 32, 64, 128, 256, 512, 1024 bits
wide.
A slave must only give a write response after the wlast signal is
asserted.
An EX-OKAY response should only be given to a exclusive write
access.
Master must give read response for every read data beat
For a fixed burst Transfer only fixed address location should be
used.
The same AWID/ARID should not be repeated until the response for that ID is received.
RLAST signal should be asserted for last transfer.
The number of write data items must match the length value.
The address ID should match the data ID.

Y
Y

Y
Y
Y

Y
Y

Y
Y
Y

Group of Checkers not implemented:

Locked Access Rules
1) A unlocked transaction must follow after a locked transaction
2) Locked transactions should use the same id
3) Master should wait for all locked transactions to complete before starting another unlocked write transaction.
4) Master should let complete all outstanding transactions before starting a locked write
transaction.
5) AWPROT & AWCACHE should not change during a locked transaction.
6) Locked transaction sequences should be limited to two transactions.
Ex-Access:
7) A master must not start the write portion of an exclusive access until the read is done.
8) The address of an exclusive access is aligned to the total number of bytes in the
transaction.
9) The number of bytes to be transferred must be a power of 2, i. e. 1, 2, 4, 8, 16, 32, 64
or 128.
10) In Ex-Access maximum of 128 bytes can be transferred.
11) Address, size & length of an ex access write with a given ID should be the same as
of read with same ID.
12) Recommended: Every Ex- write has an earlier outstanding ex-read with the same ID.
13) A slave that supports exclusive access must have hardware to monitor it.
14) The value of the ARCACHE[3:0] or AWCACHE[3:0] signals must guarantee that the
slave that is monitoring the ex-access sees the transaction.
Low Power Rules:
15) CSYSREQ is allowed to change from high to low when CSYSACK is high.
16) CSYSACK is allowed to change from high to low when CSYSREQ is low.
17) CSYSREQ is allowed to change from low to high when CSYSACK is low.
18) CSYSACK is allowed to change from low to high when CSYSREQ is high.
19) A master is allowed to interleave a maximum of WDEPTH write data bursts.

3.5

Coverage Metrics

3.5.1

Functional Coverage
100% functional coverage achieved
The cover groups we have used are:
TBD
Cover
Cover Group Feature Covered
Group
Name
No.
1.
cov_awaddr
All the Address locations within a
AXI_ADDR_LOW
&
AXI_ADDR_HIGH
AXI_FIXED_ADDR for Master write.
2.
cov_araddr
All the Address locations within a

range of
and
for
range

of

3.

cov_awid

4.

cov_wid

5.

cov_bid

6.

cov_arid

7.

cov_rid

8.

cov_awlen

9.

cov_arlen

10.

cov_awburst

11.

cov_arburst

12.

cov_awsize

13.

cov_arsize

14.

cov_wlast

15.

cov_rlast

16.

cov_wdata

17.

Cov_rdata

18.

cov_wstrb

19.

cov_bresp

20.

cov_rresp

Tools Used
Synopsis VCS
Specman Elite 6.0

AXI_ADDR_LOW
&
AXI_ADDR_HIGH
and
for
AXI_FIXED_ADDR for Master read.
All the values of awid signal from 0x0 to 0xF for Write Address phase.
All the values of awid signal from 0x0 to 0xF for Write
Data phase.
All the values of awid signal from 0x0 to 0xF for Write Response phase.
All the values of awid signal from 0x0 to 0xF for Read Address phase.
All the values of awid signal from 0x0 to 0xF for Read
Data phase.
All the values of awlen signal from 0x0 to 0xF for Write
Address phase.
All the values of arlen signal from 0x0 to 0xF for Read
Address phase.
All the values of awburst signal from 2b00 to 2b10 for
Write Address phase.
All the values of arburst signal from 2b00 to 2b10 for
Read Address phase.
All the values of awsize signal from 2b00 to 2b10 for
Write Address phase.
All the values of arsize signal from 2b00 to 2b10 for
Read Address phase.
Both the values of wlast signal (0 or 1) for Write Data
phase.
Both the values of rlast signal (0 or 1) for Read Data
phase.
All the values of wdata signal from 0x0000_0000 to
0XFFFF_FFFF for Write Data Channel.
All the values of rdata signal from 0x0000_0000 to
0XFFFF_FFFF for Read Data Channel.
All the values of wstrb signal from 0x0 to 0XF for Write
Data Channel.
All the values of bresp signal from 2b00 to 2b11 except
2b01 (Exclusive Write) for Write Response Channel.
All the values of rresp signal from 2b00 to 2b11 except
2b01 (Exclusive read) for Read Response in Read Data
Channel.

5 Directory / File Structure

Directory & File Structure Path

Directory
Description

: @mtw02lfs01:/cvs/axi/Repository/AXI/
: AXI
: It has all the verification environment related files for the
axi_evc.

LIBRARY_README.txt
AXI_eVC/PACKAGE_README.txt

: It contains a description of the library on a single line,

: The format of the PACKAGE_README.txt file satisfies

the following requirements:

. Standardization of information (version, for example)

. Easy to read
. Easy to search
. Easy to process automatically
AXI_eVC/demo.sh

: Usually, there will be several examples in the Package /

examples directory. demo.sh should be able to run one of
them (perhaps loading an e file called demo.e).
AXI_eVC/e
: Contains all essential e code files belonging to the package
AXI_eVC/e/AXI_eVC_top.e
: This file imports the other necessary e files.
AXI_eVC/e/axi_env_h.e
: This file makes an instance of Agent.
AXI_eVC/e/axi_agent_h.e
: This file contains declaration of units of Agent, Monitor &
BFM. Port instantiation is also done here.
AXI_eVC/e/axi_agent.e
: Here the agent is extended and monitor is instance is con
figured as read only. Also BFM unit is extended and master
sequence driver is configured as read only.
AXI_eVC/e/axi_bfm_h.e
: This file contains a back pointer to agent inside extended
bfm unit.
AXI_eVC/e/axi_defines.e
: This file contains all the defined parameters.
AXI_eVC/e/axi_ports.e
: This is a ports file. Here all the axi DUT signals are binded
to port signals.
AXI_eVC/e/axi_trans_h.e
: Here all the signals of axi (physical fields) are declared.
AXI_eVC/e/axi_types_h.e
: This file contains declarations of common types to be used
in axi evc package.
AXI_eVC/e/axi_master_sequences_h.e : This file contains basic write and read methods with the
valid soft constraints.
AXI_eVC/e/axi_master_seq_lib.e
: This file contains library of different sequences.
AXI_eVC/e/axi_master_bfm.e
: This file contains e code for Master BFM.
AXI_eVC/e/axi_slave_bfm.e
: This file contains e code for axi Slave BFM.
AXI_eVC/e/axi_monitor.e
: This file contains e code for snooping on the axi bus. All the
events for coverage and protocol checker are declared here.
AXI_eVC/e/axi_protocol_checker.e
: This file contains e code for protocol checking.
AXI_eVC/e/axi_coverage.e
: This file contains e code for coverage.
AXI_eVC/e/axi_scoreboard.e
: This file contains all the fields to be used in scoreboard.
AXI_eVC/e/axi_master_scoreboard.e : This file contains e code for master scoreboard.
AXI_eVC/e/axi_slave_scoreboard.e
: This file contains e code for slave scoreboard.
AXI_eVC/e/axi_gif_ports.e
: This file contains e code GIF port signal bindings.
AXI_eVC/e/axi_gif_master_bfm.e
: This file contains e code GIF Master BFM.
AXI_eVC/e/axi_gif_slave_bfm.e
: This file contains e code GIF Slave BFM.
AXI_eVC/docs
: This directory contains the documentation for the package.
AXI_eVC/examples
: This directory contains files to configure the axi evc
Environment to either as a Master or as a slave
AXI_eVC/rtl
: contains the RTL design files.
AXI_eVC/eVC
: Contains a test suite to verify the main features of the eVC.
AXI_eVC/evc_ve
: Contains a Coverage plan, Test Descriptions, Tests,
Sequence definitions, Coverage Results, Script to activate
self-verification, script to display coverage results.