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
2
DUT Interface............................................................................................................................ 6 2.1
3
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
4
Tools Used.............................................................................................................................. 19
5
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
1
ARESETn
OUT
1
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
4
AWSIZE
OUT
3
AWBURST
OUT
2
AWLOCK
OUT
2
AWCACHE
OUT
4
AWPROT
OUT
3
AWVALID
OUT
1
AWREADY
IN
1
WID
OUT
4
WDATA
OUT
32
WSTRB
OUT
4
WLAST
OUT
1
WVALID
OUT
1
WREADY
IN
1
BID
IN
4
4
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
3
ARBURST
OUT
2
ARLOCK
OUT
2
ARCACHE
OUT
4
ARPROT
OUT
3
ARVALID
OUT
1
ARREADY
IN
1
RID
IN
4
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
2
RLAST
IN
1
RVALID
IN
1
RREADY
OUT
1
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 agent’s 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 2’b11 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
W
B
AR
R
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y Y
Y
Y
Y Y
Y
Y Y
Y Y
Y
Y
Y Y
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
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
4
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 2’b00 to 2’b10 for Write Address phase. All the values of arburst signal from 2’b00 to 2’b10 for Read Address phase. All the values of awsize signal from 2’b00 to 2’b10 for Write Address phase. All the values of arsize signal from 2’b00 to 2’b10 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 2’b00 to 2’b11 except 2’b01 (Exclusive Write) for Write Response Channel. All the values of rresp signal from 2’b00 to 2’b11 except 2’b01 (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.
