Professional Documents
Culture Documents
AMBA AXI
VMM User Guide
Version J-2014.12-SP2, July 2015
Copyright
♥
Notice and Proprietary Information
2015 Synopsys, Inc. All rights reserved. This software and documentation contain confidential and proprietary information that is
the property of Synopsys, Inc. The software and documentation are furnished under a license agreement and may be used or
copied only in accordance with the terms of the license agreement. No part of the software and documentation may be reproduced,
transmitted, or translated, in any form or by any means, electronic, mechanical, manual, optical, or otherwise, without prior written
permission of Synopsys, Inc., or as expressly provided by the license agreement.
Destination Control Statement
All technical data contained in this publication is subject to the export control laws of the United States of America.
Disclosure to nationals of other countries contrary to United States law is prohibited. It is the reader's responsibility to
determine the applicable regulations and to comply with them.
Disclaimer
SYNOPSYS, INC., AND ITS LICENSORS MAKE NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH
REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
Trademarks
Synopsys and certain Synopsys product names are trademarks of Synopsys, as set forth at
http://www.synopsys.com/Company/Pages/Trademarks.aspx.
All other product or company names may be trademarks of their respective owners.
Third-Party Links
Any links to third-party websites included in this document are for your convenience only. Synopsys does not endorse
and is not responsible for such websites and their practices, including privacy practices, availability, and content.
Synopsys, Inc.
690 E. Middlefield Road
Mountain View, CA 94043
www.synopsys.com
Verification IP for AMBA AXI VMM User Guide
Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
About This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Related Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Guide Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Web Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Customer Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter1
Introduction to the AMBA 3 AXI Verification IP Model Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1Product Suite Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.1AMBATM 3 Assured . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2Online Reference Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3Master Transactor Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4Slave Transactor Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5Monitor Transactor Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.6Interconnect Transactor Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.6.1 Supported Features Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter2
Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1Installation and Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1Hardware Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.2Software Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.3Preparing for Installation of the VIP Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.4Downloading and Installing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.5Setting Up an Example Testbench Design Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.6Running the Example Testbenches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.7QuickStart for the SystemVerilog/VMM Testbenches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.8The Example Testbenches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3Licensing Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.1Specifying License Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.2License Features for VIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.3Controlling License Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.4License Polling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.5Simulation License Suspension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4Environment Variable and Path Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.1Simulator-Specific Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5Determining Your Model Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SolvNet
July 2015 Synopsys, Inc. 3
Contents Verification IP for AMBA AXI VMM User Guide
Chapter3
Integration With VMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1Overview of VMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.1Base Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2Online Reference Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3Benefits of VIP and VMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4VIP in an VMM Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.1Sample Test Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.2VMM Support in Verification IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.3VIP Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.4Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.5Generators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.6Factories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.7Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.8Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5AMBA 3 AXI Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5.1AMBA 3 AXI Master Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5.2AMBA 3 AXI Slave Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5.3AMBA 3 AXI Bus Monitor Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5.4AMBA 3 AXI Port Monitor Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5.5AMBA 3 AXI Interconnect Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6AMBA 3 AXI VIP VMM Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6.1Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6.2Instantiating the Verification Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6.3Master Transactor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6.4Slave Transactor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6.5Accessing non-VMM Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6.6Accessing Slave Memory in VMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6.7Monitor Transactors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6.8Transaction Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6.9Interconnect Transactor and Bus Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6.10Setting a Bus Architecture Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6.11Bus Architectures and Arbitration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6.12Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6.13Factories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6.14Support for Channel Pre/Post Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6.15Transactor Model Callbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6.16VMM Configuration Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6.17VMM Transaction Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6.18Extended Master and Slave Transaction Classes for Protocol Enhancements . . . . . . . . . .
3.6.19Extended Burst Lengths Greater Than 16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6.20Sideband Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6.21Support for vmm_data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SolvNet
4 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Contents
Chapter4
Configuration Member Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2dw_vip_axi_port_configuration Configuration Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3dw_vip_axi_system_model_configuration Configuration Members . . . . . . . . . . . . . . . . . . . . . . .
AppendixA
Reporting Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.1Creating MCD Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.2Identifying an Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.2.1HDL Testbench Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.2.2OpenVera Testbench Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.2.3Naming VIP Instances in an OpenVera Testbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.3Checking if MCD has been Enabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.4Impact of Turning MCD On . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SolvNet
July 2015 Synopsys, Inc. 5
Tables Verification IP for AMBA AXI VMM User Guide
Tables
SolvNet
6 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Preface
Preface
This document describes how to use the object-based interface of the AXI Verification IP. A
Attention separate user manual is available for the command-based interface. For more information
about command-based usage, see Using the Synopsys Verification Models for the AMBA 3 AXI
Interface.
Related Documents
The document set also includes Release Notes for the Synopsys Verification Models for the AMBA 3 A
which contains new features, fixed problems, known problems, and limitations for the Verification IP f
the ARM AMBA 3 AXI interface.
For descriptions and access to any of the documents in the set, see Guide to Synopsys AMBA/AXI
Verification IP Suite.
In addition to the features documented here, common VMT features that can apply to the models are
documented in VMT Release Notes, which contains new features, fixed problems, known problems, a
limitations common to all VMT models.
Guide Overview
This guide contains the following chapters and appendixes:
❖ Chapter 1, “Introduction to the AMBA 3 AXI Verification IP Model Suite”, contains an overview o
the Synopsys AMBA AXI Verification and
IP its components.
❖ Chapter 2, “Getting Started”, contains an overview of the Synopsys AXI Verification IP and its
components.
❖ Chapter 3, “Integration with VMM”, describes the Verification Methodology Manual classes that
specific to the AXI Verification IP.
❖ Chapter 4, “Configuration Member Summary”, lists the configuration members found in the
configuration classes.
❖ Appendix A, “Reporting Problems”, provides procedures for creating detailed Customer Suppor
information when reporting problems.
❖ Appendix B, “Updating VIP Models”, describes ways to update your Library and provides detail
the dwh_update utility.
SolvNet
July 2015 Synopsys, Inc. 7
Preface Verification IP for AMBA AXI VMM User Guide
Web Resources
❖ Documentation through SolvNet: https://solvnet.synopsys.com (Synopsys password required)
❖ Synopsys Common Licensing (SCL): http://www.synopsys.com/keys
Customer Support
To obtain support for your product:
❖ Generate the information noted in Appendix A, “Reporting Problems” on page179.
❖ Then, contact Support Center, with a description of your question and supplying the above
information, using one of the following methods:
✦ For fastest response, use the SolvNet website. If you fill in your information as explained be
your issue is automatically routed to a support engineer who is experienced with your prod
The Sub Product entry is critical for correct routing.
Go to http://solvnet.synopsys.com/EnterACall and click on the link to enter a call.
Provide the requested information, including:
✧ Product: Synopsys Verification IP
✧ Sub Product: amba template
✧ Tool Version: J-2014.12-SP2
✧ Problem Type:
✧ Priority:
✧ Fill in the remaining fields according to your environment, the Synopsys AMBA 3 AXI
Verification IP model being used, and your issue.
✧ Description: For simulation issues, include the timestamp of any signals or locations in
waveforms that are not understood
After creating the case, attach any debug files you created in the previous step.
✦ Or, send an e-mail message to support_center@synopsys.com (your email will be queued a
then, on a first-come, first-served basis, manually routed to the correct support engineer):
✧ Include the Product name, Sub Product name, and Tool Version number in your e-mail (a
identified above) so it can be routed correctly.
✧ For simulation issues, include the timestamp of any signals or locations in waveforms th
are not understood
✧ Attach any debug files you created in the previous step.
✦ Or, telephone your local support center:
✧ North America:
Call 1-800-245-8005 from 7 AM to 5:30 PM Pacific time, Monday through Friday.
✧ All other countries:
http://www.synopsys.com/Support/GlobalSupportCenters
SolvNet
8 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Introduction to the AMBA 3 AXI Verification IP Model Suite
1
Introduction to the AMBA 3 AXI Verification IP
Model Suite
Models Description
Object-based Models These models have an object-based interface for use with the Reference
Verification Methodology (RVM) in testbenches.
axi_monitor_rvm_vera_vmt The Monitor transactor model supports protocol checking, including checks on
channel handshake ordering and transaction logging; see “Monitor Transactor
Overview” on page12.
SolvNet
July 2015 Synopsys, Inc. 9
Introduction to the AMBA 3 AXI Verification IP Model Suite Verification IP for AMBA AXI VMM User Guide
Models Description
Command-based Models These models have a command-based interface for use in a directed-test
methodology.
axi_master_vmt For information about using these models, see Using the Synopsys
axi_slave_vmt Verification Models for the AMBA 3 AXI Protocol.
axi_monitor_vmt
axi_interconnect_vmt
The Synopsys AMBA 3 AXI Verification IP suite is AMBA Assured by "AMBA 3 AXI Protocol
Attention Assertions Verilog OVL Assertions" BP062-VL-70002 based on "AMBA AXI Protocol
Specification" v1.0.
SolvNet
10 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Introduction to the AMBA 3 AXI Verification IP Model Suite
✦ Exclusive
✦ Locked Response
❖ Write re-ordering
✦ Support of interleaving patterns of write data beats
❖ Response through command and notification
❖ Supports more than 16 transfers per transaction
❖ Supports sideband signals on all buses
SolvNet
July 2015 Synopsys, Inc. 11
Introduction to the AMBA 3 AXI Verification IP Model Suite Verification IP for AMBA AXI VMM User Guide
❖ Configurable write interleave depth. Write data beats can be interleaved between multiple AW
user specifies the maximum number of writes that can be. Interleaving write transactions with
same AWID value is not allowed.
❖ Unaligned data transfers. Read and write data transfers can begin at an address that is not alig
the specified width of the data bus. The data is automatically sent or read on the correct byte l
the data channel. If the address is also not aligned to the data width specified for that transfer
narrower word is sent or read on the correct byte lanes. In the case of a write, the active byte
a transfer are specified by write strobe for each byte.
❖ Variable Slave response. The response behavior of the slave to a read or write transaction requ
the master is configurable by the user. The response behavior includes response delays, throu
delays, success or failure status and constraints for interleaving.
The user associates each set of response behaviors with a transaction signature. The signature
consists of address phase information such as which address bus (read/write), the address val
the address ID, the burst length and so on. When a transaction arrives it is compared to the lis
signatures. When a matching signature is found, the associated response behavior is selected
transaction.
Not only can the slave response vary with the transaction signature but also certain response
attributes can vary with each beat of the response such as the delay from WVALID to WREADY
❖ Atomic access. The slave supports monitoring and reporting for exclusive access. If the slave i
configured to support exclusive access, then it will indicate that to the master in the read resp
status. When the slave supports exclusive access it will indicate to the master in the write resp
status whether the exclusive write succeeded or failed because another master wrote to that a
space. The slave can monitor any number of exclusive accesses.
❖ FIFO memory support. The user can configure the slave address space to provide FIFO memory
depth of each FIFO memory is also configurable. If FIFO memory and RAM occupy the same
address space the FIFO memory takes precedence. Slave model commands provided control o
contents of the FIFO's independently from the AMBA 3 AXI port interface.
❖ More than 16 transfers per transaction. This is an extension to the protocol.
❖ Sideband signals for all buses. Every bus can be configure to have a 64-bit wide sideband.
SolvNet
12 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Introduction to the AMBA 3 AXI Verification IP Model Suite
✦ Configurable formats.
✦ Supported on a per port type (i.e., master or slave).
❖ Configurable coverage analysis and reporting:
✦ Predefined coverage groups and coverage bins
✦ Cumulative coverage support
✦ Activation and deactivation of selected coverage bins
✦ HTML and text report generation
✦ Runtime access to coverage bin hit counts
✦ Direct access to coverage capabilities.
❖ Available as an SystemVerilog Class.
❖ Interfaces to 32 master and 32 slave ports
❖ Independent of interconnect support for shared buses
✦ Shared address and data buses
✦ Shared address with multiple data buses
✦ Multi-layer, with multiple address and data buses
❖ Configurable data bus widths
✦ Data buses can be 2n bits wide, where n is in [3..10]
✦ Strobe bus widths sized to match
❖ Configurable ID bus widths
✦ Master ID ports configurable from 0 to 31bits
✦ Slave ID ports configurable from 0 to 31 bits
✧ Master ID port width plus 0 to 5 bits if interconnect present
✧ Matches master ID port width if simple master/slave system
❖ Support for aliased slave ports. To support slaves with multiple VALID lines, but single data line
For example: memory controllers.
❖ Supports more than 16 transfers per transaction.
❖ Supports sideband signals on all buses.
Each Master-to-Interconnect and Interconnect-to-Slave port connection has its own set of address, re
write, and response channels tracked by the Monitor. By providing the Monitor with the same type of
information provided to the Interconnect such as address-to-slave mappings and ID-to-Master mappin
the Monitor can also track Master-to-Slave communication across the Interconnect.
It is also possible to use the Monitor in a more limited fashion by monitoring a single Master-to-Slave,
Master-to-Interconnect, or Interconnect-to-Slave connection.
Protocol checking beings after the start command is issued. The Monitor waits for ARESET<n> to be
asserted (driven low) before it starts any activity.
An unknown value (X|Z) on a don't-care pin is ignored: for example, the wdata bit. An unknown value
any control port defaults to its inactive value.
If X-checking messages are enabled, then an unknown value on any pin generates a message.
SolvNet
July 2015 Synopsys, Inc. 13
Introduction to the AMBA 3 AXI Verification IP Model Suite Verification IP for AMBA AXI VMM User Guide
SolvNet
14 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Introduction to the AMBA 3 AXI Verification IP Model Suite
SolvNet
July 2015 Synopsys, Inc. 15
Introduction to the AMBA 3 AXI Verification IP Model Suite Verification IP for AMBA AXI VMM User Guide
SolvNet
16 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Getting Started
2
Getting Started
SolvNet
July 2015 Synopsys, Inc. 17
Getting Started Verification IP for AMBA AXI VMM User Guide
Memory
❖ For users of VCS or VCS MX, see VCS Installation Notes or VCS MX Installation Notes, which are
accessible from the Synopsys Installation Guide (search for synopsys installation guide on
www.synopsys.com).
❖ For users of other simulators, see the documentation for your simulator.
For a complete list of supported hardware platforms and the operating system versions for each, see
Note the Web-based Synopsys Verification IP Vera Modeling Technology (VMT) Qualified Tools Matrix
document at:
http://www.synopsys.com/products/designware/docs/vip/vmt/latest/doc/vmt_update.pdf
SolvNet
18 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Getting Started
Clicking on the above link takes you to the SolvNet login page. If you have not previously registered as
Note a SolvNet user, click on the “Register Today” link and provide the required information.
SolvNet
July 2015 Synopsys, Inc. 19
Getting Started Verification IP for AMBA AXI VMM User Guide
This command creates a design directory that contains a directory named include and a directory na
examples. It also creates a simulation script named “sim_axi_rvm_sys”, which is located at:
design_dir/examples/axi_rvm_sys/sim_axi_rvm_sys
For the full description of the dw_vip_setup script, refer to “Running dw_vip_setup” on page27.
The simulator run scripts use “cc” as the default compiler for any C modules that need to be compiled.
Note For example, when using the ModelSim-Verilog simulator, veriuser.c must be compiled for linking into
the Model-Sim executable.
If you use gcc, you must add the gcc options to the simulator run scripts.
For a walk-through example that demonstrates basic VMM concepts, see “QuickStart for the
Note SystemVerilog/VMM Testbenches” on page 26.
Invoke the simulation script that fits your simulation environment. If your simulation environment is n
listed here, see “Creating and Running a Simulation Script for an Example Testbench” on page31 for
examples.
To simulate the SystemVerilog example testbench using VCS, use the following command:
% design_dir /examples/axi_rvm_sys/sim_axi_rvm_sys vcsvlog svtb
Files generated as a result of the simulation may be placed in the current working directory where the
Note simulation script is called.
SolvNet
20 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Getting Started
❖ Static configuration
❖ Atomic transaction generator setup and use
❖ Random testing
❖ Directed testing
❖ End of Simulation control
❖ VMM log use
❖ VMM Env structure and use
❖ Example testbench structure
❖ Example makefile/runscript
SolvNet
July 2015 Synopsys, Inc. 21
Getting Started Verification IP for AMBA AXI VMM User Guide
axi_rvm_sys
Description: Object based interface testbench that uses 1 master, 1 monitor and 1 system monitor. It uses the
scenario generator to generate the read and write transactions from different masters. Scenario generator is
used to send the transactions from the Master side.
amba/tb_axi_vmm_10_basic_sys
Description: Object based interface testbench with 1 master, 1 slave, and 1 monitor VIP. The testbench
illustrates how to use the VIP and integrate it into your testbench. The environment uses simple atomic generator
and also illustrates how to generate directed transactions from the Master side.
SolvNet
22 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Getting Started
amba/tb_axi_vmm_10_intermediate_sys
Description: Object based interface testbench uses 1 master, 1 slave, and 2 monitor VIP. The example illustrates
scoreboarding using VMM datastream scoreboard and how to use predefined coverage and develop custom
coverage.
amba/tb_axi_vmm_10_advanced_sys
Description: Object based interface testbench that makes use of 1 master, 1 slave, and 2 port monitor VIP. The
testbench comprises of two subenv components - master/monitor and slave/monitor pairs. There is a scoreboard
class to do end to end checking of the data and a scenario generator to generate transactions from the master
side. The testbench uses VMM consensus class to arrive at the end of simulation.
SolvNet
July 2015 Synopsys, Inc. 23
Getting Started Verification IP for AMBA AXI VMM User Guide
For information on checking the license versions, see the Synopsys AMBA AXI Verification IP
Attention Release Notes.
SolvNet
24 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Getting Started
❖ If none of the features in the list are available, authorization for VIP is denied.
❖ If a specified license feature is not available, a license error message is issued.
Examples:
❖ To use only a Library license:
% setenv DW_LICENSE_OVERRIDE “DESIGNWARE”
❖ To exclude Library licenses from being used to authorize VIP:
% setenv DW_LICENSE_OVERRIDE “DESIGNWARE-REGRESSION VCS-VERIFICATION-LIBRARY \
DESIGNWARE-AMBA-VIP DESIGNWARE-<other_vip_suites_in_use>-VIP”
❖ To use only a DesignWare-Regression license, set DW_LICENSE_OVERRIDE to:
% setenv DW_LICENSE_OVERRIDE "DESIGNWARE-REGRESSION"
❖ To use only a VCS-Verification-Library license, set DW_LICENSE_OVERRIDE to:
% setenv DW_LICENSE_OVERRIDE "VCS-VERIFICATION-LIBRARY"
❖ To use only a Synopsys AMBA VIP suite license:
% setenv DW_LICENSE_OVERRIDE “DESIGNWARE-AMBA-VIP”
With this final example, authorization for VIP suites other than AMBA is denied.
SolvNet
July 2015 Synopsys, Inc. 25
Getting Started Verification IP for AMBA AXI VMM User Guide
Verification IP products are released and versioned by the suite and not by individual model. The
Note version number of a model indicates the suite version.
❖ To determine the versions of models installed in your $DESIGNWARE_HOME tree, use the setup
utility as follows:
% $DESIGNWARE_HOME/bin/dw_vip_setup -i home
❖ To determine the versions of models in your design directory, use the setup utility as follows:
% $DESIGNWARE_HOME/bin/dw_vip_setup design_dir_path
-p -i design
❖ To determine the version of a specific model instance in your testbench, use the get_version
command.
To determine the most recent version of the AXI Verification IP that is available from Synopsys, navig
your product beginning at the following web page:
http://www.synopsys.com/products/designware/
❖ An “include” directory – Contains all files and directories from the include directory of all curre
used models. Also contains Verilog and VHDL wrapper shells created by dw_vip_setup.
SolvNet
26 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Getting Started
❖ An “examples” directory – Contains all files required for model, suite, or system testbenches.
Note the following design directory characteristics:
✦ You must add the VMT model or models to your design directory using dw_vip_setup.
✦ You must use the supported OS, and simulator versions, as identified in the release notes.
✦ You should not move the design directory.
2.6.2.2 Invocation
The dw_vip_setup program controls AXI VIP model configuration, including adding and removing mod
from your design. You also use the program to configure model or system testbenches and get inform
about your installation or design directory.
Invoke dw_vip_setup from the command prompt. The general form is:
To list available system and stand-alone testbenches for any installed model, use the dw_vip_setup
Note -infohome switch invocation, described in Table2-2 on page 28.
SolvNet
July 2015 Synopsys, Inc. 27
Getting Started Verification IP for AMBA AXI VMM User Guide
model The model argument defines the model or models that dw_vip_setup acts
upon. This argument is not needed with the -info or -help switches. All
switches that require the model argument may also use a model list.
You may specify a version for each listed model, using the -version option.
omitted, dw_vip_setup uses the latest version. The -update switch ignores
model version information.
-m[odel_list] filename The -model_list argument causes dw_vip_setup to use a user-specified file
define the list of models that the program acts on. The model_list, like the
model argument, can contain model version information. Each line in the fi
contains:
model [-v version] –or–
# Comments
The dw_vip_setup program treats all lines beginning with “#” as comments.
Note
Switch Description
-a[dd] (model Adds the specified model or models to the specified design directory or
[-v[ersion] version]) … current working directory. If you do not specify a version, the latest
version is assumed.
The -add switch causes dw_vip_setup to build vro files for all models,
builds suite libraries from the same suite as the specified models, and
copies the VMT library from $DESIGNWARE_HOME.
-r[emove] model Removes all versions of the specified model or models from the
design. The dw_vip_setup program does not attempt to remove any
include files used solely by the specified model or models.
-u[pdate] (model Updates to the specified model version for the specified model or
[-v[ersion] version]) … models. The dw_vip_setup program updates to the latest models when
you do not specify a version.
The -update switch causes dw_vip_setup to build vro files for all models,
builds suite libraries from the same suite as the specified models, and
copies the VMT library from $DESIGNWARE_HOME.
-e[xample] {scenario | model/scenario}The dw_vip_setup program configures a testbench example for a single
[-v[ersion] version] model or a system testbench of a group of models. The program
creates a simulator run program for all supported simulators.
The scenario is an option of the -example switch. To specify a system
testbench, you do not need to specify model names; dw_vip_setup
automatically gets all of the models needed for that scenario. For
example, the dw_vip_setup command line to get the AXI system
testbench would be:
dw_vip_setup -e axi_rvm_sys
For a basic (single-model) testbench, you do not need to specify a
scenario.
Note: Use the -info switch to list all available examples.
SolvNet
28 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Getting Started
Switch Description
-c[lean] {scenario | model/scenario} Cleans the specified scenario in the specified design directory or
current working directory. This switch deletes all files in the specified
design, then restores all Synopsys created files to their original
contents.
-i[nfo] home When you specify the info home switch, dw_vip_setup prints a list of all
models, libraries, and examples available in the currently-defined
$DESIGNWARE_HOME installation, and their respective versions.The
report is printed to STDOUT. Output from info home can be used to
create a model_list file.
-i[nfo] design [p[ath] directory] If the current directory is the design directory, then the path switch is not
required. If the current directory is not the design directory, then the
path of the design directory should be specified.
When you specify the info design switch, dw_vip_setup prints a list of all
models and libraries installed in the specified design directory or current
directory and their respective versions. The report is printed to
STDOUT.
#---------------------------------------------------------------------#
# DESIGNWARE_HOME = installed_top_directory
# VERA_HOME = Vera_installation_directory
#
# Using vmt version vmt_version
#---------------------------------------------------------------------#
# LIBRARIES:
# amba amba_vip_version
# common com_version
# vmt vmt_version
SolvNet
July 2015 Synopsys, Inc. 29
Getting Started Verification IP for AMBA AXI VMM User Guide
# MODELS:
# ahb_bus_rvm_vera_vmt
# ahb_bus_vmt
# ahb_master_rvm_vera_vmt
# ahb_master_vmt
# ahb_monitor_rvm_vera_vmt
# ahb_monitor_vmt
# ahb_slave_rvm_vera_vmt
# ahb_slave_vmt
# apb_master_rvm_vera_vmt
# apb_master_vmt
# apb_monitor_rvm_vera_vmt
# apb_monitor_vmt
# apb_slave_rvm_vera_vmt
# apb_slave_vmt
# axi_interconnect_rvm_vera_vmt
# axi_interconnect_vmt
# axi_master_rvm_vera_vmt
# axi_master_vmt
# axi_monitor_rvm_vera_vmt
# axi_monitor_vmt
# axi_port_monitor_rvm_vera_vmt
# axi_port_monitor_vmt
# axi_slave_rvm_vera_vmt
# axi_slave_vmt
# EXAMPLES:
# ahb_rvm_sys
# ahb_sys
# apb_rvm_sys
# apb_sys
# axi_multi_sys
# axi_rvm_sys
# axi_sys
# ahb_vmm_simple_example
# axi_rvm_sideband_scenario
# ahb_bus_vmt/basic
# ahb_master_vmt/basic
# ahb_monitor_vmt/basic
# ahb_slave_vmt/basic
# apb_master_vmt/basic
# apb_monitor_vmt/basic
# apb_slave_vmt/basic
# axi_interconnect_vmt/basic
# axi_master_vmt/basic
# axi_monitor_vmt/basic
# axi_port_monitor_vmt/basic
# axi_slave_vmt/basic
# amba/tb_ahb_vmm_10_advanced_sys
# amba/tb_ahb_vmm_10_basic_sys
# amba/tb_ahb_vmm_10_intermediate_sys
# amba/tb_axi_vmm_10_advanced_sys
# amba/tb_axi_vmm_10_basic_sys
# amba/tb_axi_vmm_10_intermediate_sys
SolvNet
30 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Getting Started
#---------------------------------------------------------------------#
# The 'info' operation has successfully completed.
#---------------------------------------------------------------------#
To run any example with SystemVerilog as control language, specify 'svtb' as the control language
Note argument to simulation script.
SolvNet
July 2015 Synopsys, Inc. 31
Getting Started Verification IP for AMBA AXI VMM User Guide
SolvNet
32 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Getting Started
initial begin
setSystemClock(test_top.SystemClock);
The setSystemClock method needs to be provided with the clock that will be the "system cl
for all VIPs in the simulation (For NTB experts, this is the SystemClock for the NTB domain).
Some VIP models use the system clock when reporting simulation events in messages so it
should have some known relationship to the clock that is feeding each VIP's clock pin. If you
using only one VIP, it is easiest to use the same clock that is driving your transactors. If you
verifying a particular portion of a system, for example, the USB portion, you can use the ma
clock for that portion. If you are simulating with several VIPs, choose a top-level clock that h
known relationship with each VIP.
3. For a Verilog top testbench, continue with the following steps.
For a VHDL top testbench, see step 4.
a. Instantiate the required instances of the interface, and then complete the connection:
module test_top;
wire aresetn;
wire aclk;
reg SystemClock;
...
// Master 0
wire arvalid_m0;
wire [`DW_VIP_AXI_ARADDR_PORT_WIDTH-1:0] araddr_m0;
wire [`DW_VIP_AXI_ARLEN_PORT_WIDTH-1:0] arlen_m0;
...
// Slave 0
wire arvalid_s0;
SolvNet
July 2015 Synopsys, Inc. 33
Getting Started Verification IP for AMBA AXI VMM User Guide
${VCS_HOME}/bin/vcs -sverilog ${vcsflags} -ntb_define NTB -ntb_opts rvm -ntb_opts use_ntbpp -ntb_opts
vera_compat
-ntb_opts use_sigprop -ntb_opts add_dummy_bind -ntb_opts interop -ntb_opts dw_vip
+define+NTB +incdir+${include_dir}/verilog +incdir+${include_dir}/svtb ${vcslibs}
+pkgdir+${include_dir}/svtb -o simvcssvtb -ntb_incdir ${include_dir}/vera -ntb_incdir
${DESIGNWARE_HOME}/vip/vmt/latest/vera/src -ntb_incdir ${DESIGNWARE_HOME}/vip/amba/latest/vera/src
-ntb_incdir ${DESIGNWARE_HOME}/vip/amba/latest/axi_master_vmt/vera/src -ntb_incdir
${DESIGNWARE_HOME}/vip/amba/latest/axi_master_rvm_vera_vmt/vera/src axi_master_rvm.pkg axi_master_vmt_tst.s
axi_master_vmt_tst_svtb.v -ntb_incdir ${DESIGNWARE_HOME}/vip/amba/latest/axi_slave_vmt/vera/src -ntb_incdir
${DESIGNWARE_HOME}/vip/amba/latest/axi_slave_rvm_vera_vmt/vera/src axi_slave_rvm.pkg axi_slave_vmt_tst.sv
axi_slave_vmt_tst_svtb.v -ntb_incdir ${DESIGNWARE_HOME}/vip/amba/latest/axi_monitor_vmt/vera/src -ntb_incdi
${DESIGNWARE_HOME}/vip/amba/latest/axi_monitor_rvm_vera_vmt/vera/src axi_monitor_rvm.pkg
axi_monitor_vmt_tst.sv axi_monitor_vmt_tst_svtb.v
simvcssvtb run
In the example above, “-ntb_incdir” lines specify several include directories that VIP models re
In order of appearance, they specify the following:
✧ OpenVera include (one per executable)
✧ VMT include (one per executable)
SolvNet
34 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Getting Started
✧ VIP suite includes (one per VIP suite of models in the design)
✧ AXI protocol model includes (one per transactor model in the design)
✧ AXI transactor model includes (one per transactor model in the design)
For VCS MX, use the Unified Usage Model approach, as follows:
i. Compile (or analyze) the NTB testbench using vlogan. The DESIGNWARE_HOME source
directories must be specified for the NTB code. The model source files (.vrp) must also b
specified, accomplished by $DESIGN_DIR/include/vera in the sample below. The NTB
testbench is specified via the hdl_files option.
ii. Issue the vcs compile command. The following sample shows the vlogan and vcs comma
for the axi_rvm_sys example testbench:
// Master 0
arvalid_m0,
araddr_m0,
arlen_m0,
arsize_m0,
...
);
inout aresetn;
input aclk;
reg aclk;
reg SystemClock;
reg resetReg;
// Master 0
inout arvalid_m0;
inout [`DW_VIP_AXI_ARADDR_PORT_WIDTH-1:0] araddr_m0;
inout [`DW_VIP_AXI_ARLEN_PORT_WIDTH-1:0] arlen_m0;
SolvNet
July 2015 Synopsys, Inc. 35
Getting Started Verification IP for AMBA AXI VMM User Guide
...
AxiMonitorInterface AxiMonitor(
.aclk (aclk),
.aresetn (aresetn),
.arvalid_m0 (arvalid_m0),
...
);
AxiMasterInterface AxiMaster (
.aclk (aclk),
.aresetn (aresetn),
.arvalid (arvalid_m0),
...
);
AxiSlaveInterface AxiSlave (
.aclk (aclk),
.aresetn (aresetn),
.awvalid (awvalid_m0),
...
);
AxiRvmSystemTest test(AxiMonitor.Monitor, AxiMaster.Master, AxiSlave.Slave);
always @ (aclk) SystemClock <= aclk;
endmodule
Note the special treatment of the system clock above. It has to be a register in the Verilog
Attention wrapper testbench and connected by the SystemVerilog program with a call to
setSystemClock().
b. Instantiate and connect the module from the Verilog wrapper in a VHDL top-level testbench
LIBRARY IEEE;
...
USE work.dw_vip_axi_common_pkg.all;
USE work.all;
ENTITY test_top_vhdl IS
END test_top_vhdl;
SolvNet
36 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Getting Started
vhdlan $design_dir/include/vhdl/vmt_pkg.vhd
$DESIGN_DIR/include/vhdl/AmbaCommonDefines.vhd
$DESIGN_DIR/include/vhdl/AxiCommonDefines.vhd
$DESIGN_DIR/include/vhdl/AxiMonitorDefines.vhd
$DESIGN_DIR/include/vhdl/AxiMasterDefines.vhd
$DESIGN_DIR/include/vhdl/AxiSlaveDefines.vhd
$DESIGN_DIR/examples/axi_rvm_sys/ntb/axi_rvm_sys_tst.vhd
iii. Build the final simulator with a call to VCS, passing in the needed NTB options for the
OpenVera code (such as the models) invoked the SystemVerilog testbench:
SolvNet
July 2015 Synopsys, Inc. 37
Getting Started Verification IP for AMBA AXI VMM User Guide
-ntb_define DW_VIP_AXI_MAX_NO_MSTRS=<n>
-ntb_define DW_VIP_AXI_MAX_NO_SLVS=<m>
+define+DW_VIP_AXI_MAX_NO_MSTRS_<n>
+define+DW_VIP_AXI_MAX_NO_SLVS_<m>
Where <n> is the number of slaves or masters. <n> ranges from 1 to 31. For example, to specify fou
and seven slaves:
-ntb_define DW_VIP_AXI_MAX_NO_MSTRS=4
-ntb_define DW_VIP_AXI_MAX_NO_SLVS=7
+define+DW_VIP_AXI_MAX_NO_MSTRS_4
+define+DW_VIP_AXI_MAX_NO_SLVS_7
You should include all the directives pertaining to the type of the device. For example, if you specify t
maximum number of slaves, you should use both:
-ntb_define DW_VIP_AXI_MAX_NO_SLVS=<m>
+define+DW_VIP_AXI_MAX_NO_SLVS_<m>
Not defining the directives may lead to port mismatch error messages and may even impact the simu
performance.
SolvNet
38 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
3
Integration With VMM
SolvNet
July 2015 Synopsys, Inc. 39
Integration With VMM Verification IP for AMBA AXI VMM User Guide
The start_xactor() method for all transactor models should be called at the posedge of the AXI
Attention clock signal (aclk) in the transactor model's interface.
This chapter assumes that you are familiar with SystemVerilog and VMM. For more information:
❖ For the IEEE SystemVerilog standard, see:
✦ IEEE Standard for SystemVerilog—Unified Hardware Design, Specification, and Verification
Language
❖ For an essential reference guide describing the Reference Verification Methodology as it is
represented in SystemVerilog, along with a class reference, see:
✦ Verification Methodology Manual For SystemVerilog, by Janick Bergeron [et al.], at
$VCS_HOME/doc/UserGuide/vmm_sv.pdf
❖ For details about SystemVerilog constructs that are supported by VCS, see:
✦ SystemVerilog Testbench Constructs, at $VCS_HOME/doc/UserGuide/svtb.pdf
SolvNet
40 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
SolvNet
July 2015 Synopsys, Inc. 41
Integration With VMM Verification IP for AMBA AXI VMM User Guide
Test
Layer Note: dashed lines (- - - -)
Tests represent VMM channels
Scenario
Layer Generators
Functional Coverage
Functional
Layer Transactor Self Check Checker
Signal DUT
Layer
Channels provide the interface between verification components. Channels provide a consistent yet f
way to connect the elements within the verification environment and enhance modularity, layering, a
scalability. This allows the pieces to be stacked on top of each other or interchanged.
The remainder of this section contains the following topics:
❖ “Sample Test Environment”
❖ “VMM Support in Verification IP”
❖ “VIP Objects”
❖ “Constraints”
❖ “Generators”
❖ “Factories”
❖ “Messages”
SolvNet
42 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
VIP Transactor
Log Source
Sink DUT
Sink
In Out
Source
Generator Channel Out In
Channel
Scoreboard
Instead of defining many individual directed tests, as with traditional verification, the VMM flow is bas
on defining several objects that reflect the requirements of the design under test (DUT) and the test
environment. These objects contain randomizable attributes that vary within the constraints that are
defined. VIP provides valid range constraints that keep it within operating limits, and a set of reasona
constraints that define meaningful protocol traffic.
To implement tests, you extend the constraints for the random attributes in the transaction and
configuration classes. In the configuration classes, the random attributes define system-level configu
settings, such as data and address bus width. In the transaction classes, the random attributes define
protocol-specific characteristics. Typically, configuration attributes are held stable while multiple rand
transactions are performed.
As shown above in Figure7, a source generator creates transaction objects and puts them into a chan
connects with the transactor. You can define your own generator or you can use the atomic or scenar
generator provided by VMM macros. The transactor uses the vmm_log class to log messages and
notifications. You can use standard VMM methods to control these messages and notifications.
The source generator builds AXI transaction objects and submits them to the transactor input channe
transactor then creates the transaction bus protocol. You can define your own generator or you can c
macros provided by base classes to build generators for you.
The transaction classes define transaction-level settings, such as type (read or write) and burst lengt
Randomizing the transaction objects is the primary way to take advantage of the VMM approach.
SolvNet
July 2015 Synopsys, Inc. 43
Integration With VMM Verification IP for AMBA AXI VMM User Guide
VMM Testbench
Channels
VMM transactor
provides VMM
Protocol
compliance
Pins
VIP Transactor DUT
❖ VMM Testbench: User created; puts objects into and gets objects out of a channel. Typical ob
define the test configuration and transactions.
❖ Channels: Provide a conduit for passing data between the testbench and the VIP transactor. F
more information about channels, see “Channels” on page43.
❖ VIP transactor: Puts transaction objects into and gets transaction objects out of channels. Int
it translates objects into terms that the base protocol model understands. The VIP transactor m
fully compliant to fit into your VMM test environment.
3.4.3.1 Channels
Channels provide a standard interface for passing data objects between components in a VMM testbe
Channels natively handle objects of type vmm_data. To define a channel, VIP extends the vmm_chan
base class to support a data object that was derived from vmm_data. The data objects, which typical
represent protocol transactions, can be pushed into or pulled out of a channel. So, to interface two
SolvNet
44 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
components, one component puts objects into the channel and the other pulls them out. A channel,
therefore, is unidirectional and specific to a particular data object class. In this way, the interface bet
components can be standardized.
Given the definition of the data object class that a channel was created for, any component that can
that type of data object can put one into the channel, and any component that can operate on that ty
data object can get one out of the channel. Modularity is achieved because each side of the channel
knowledge of what is on the other side.
In general, channels are used in the following ways:
❖ Input: Channels can pass data objects from the testbench to a transactor. Typically, input cha
pass transaction objects from the testbench to a transactor to create stimulus to be driven on
❖ Output: Channels can pass objects from a transactor to the testbench. Typically, these object
constructed from observed protocol activity and generally represent response transactions.
❖ Activity: Used by monitors to provide a protocol observation point. They are similar to output
channels except that they are intended for monitoring purposes only.
Some channels do not have to be used and can be left unconnected. In the new() method for each tra
the channel arguments are optional. If a channel is not specified, a channel object is neither created
connected. For channels that are unused, this allows the simulation to run more efficiently.
SolvNet
July 2015 Synopsys, Inc. 45
Integration With VMM Verification IP for AMBA AXI VMM User Guide
3.4.3.4 Callbacks
Callbacks are an important part of the VMM and VIP architecture, and they can be used for several
applications. At their root, callbacks are an access mechanism. Among other uses, they enable the in
of user-defined code and allow access to objects for scoreboarding and functional coverage.
For each transactor, VIP includes a class that contains a set of callback methods. These methods are
part of the normal flow of procedural code. There are a few differences between callbacks and other
methods that set them apart. For example:
❖ Callbacks are virtual methods with no code initially so they do not provide any functionality un
they are extended. The exception to this rule is that some of the callback methods for function
coverage already contain a default implementation of a coverage model.
❖ The callback class is accessible to VIP users so the class can be extended and user code insert
❖ Callbacks are called within the sequential flow at places where external access would be usefu
addition, the arguments to the methods include references to relevant data objects. For examp
before a transactor puts a transaction object into an output channel is a good place to sample
functional coverage since the object reflects the activity that just happened on the pins. A callb
this point with an argument referencing the transaction object allows this exact scenario.
❖ If the callbacks are not extended, there is no need to invoke the callback methods. To avoid a
performance, callbacks are not executed by default. In order to use them, they must be registe
using the append_callback() method of the transactor.
VIP uses callbacks in four main applications:
❖ Access for functional coverage
❖ Access for scoreboarding
❖ Insertion of user-defined code
❖ Message processing
The following types of callbacks are part of VIP:
❖ post-channel get callbacks - called after a transaction is pulled from the input channel; prov
with a handle to the transaction gotten from the channel
SolvNet
46 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
❖ pre-channel put callbacks - called prior to putting a transaction out on output channel, prov
with a handle to the transaction being put
❖ traffic or dataflow event callbacks - called in response to critical traffic or dataflow events
providing a mechanism for responding to the event or introducing errors into the event proces
❖ channel coverage callbacks - called after the channel pre/post methods, providing a mecha
producing VMM transaction coverage.
❖ significant event coverage callbacks - called in response to significant events, such as a p
error, providing a mechanism for producing significant event coverage.
3.4.4 Constraints
VIP uses objects with constraints for transactions and configurations. The constraints define the rang
randomized values that are used to create each object during the simulation. Tests in an VMM flow a
primarily defined by constraints.
Classes that provide random attributes allow you to define the contents of the resulting object. When
call the randomize() method, which is a built-in method, all random attributes are randomized using a
constraints that are enabled.
Constraint randomization is sometimes misunderstood and seen as a process whereby the simulation
engine takes the control of class members away from the user. In fact, the opposite is true. Randomi
an additional way for the user to assign class members and there are several ways to control the pro
The follow techniques apply when working with randomization:
❖ Randomization only occurs when an object's randomize() method is called, and it is completely
to the test code when, or even if, this occurs.
❖ Constraints form a rule set to follow when randomization is performed. By controlling the
constraints, the testbench has influence over the outcome. Direct control can be exerted by
constraining a member to a single value. Constraints can also be enabled or disabled.
❖ Each rand member has a rand mode that can be turned ON or OFF, giving individual control of
what is randomized.
SolvNet
July 2015 Synopsys, Inc. 47
Integration With VMM Verification IP for AMBA AXI VMM User Guide
❖ A user can assign a member to a value at any time. Randomization does not affect the other m
of assigning class members.
The following diagram helps show the scope of the constraints that are part of the VMM solution for V
Reasonable
Constraints
Reasonable
Default Constraints
User-Defined Constraints
User-Defined
Constraints Constraints
SolvNet
48 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
3.4.5 Generators
You use generators to create constrained random objects, typically transactions. Generators make us
built-in randomize() method and rely on constraints to limit the scope of the randomizations. A gener
must be declared to handle a specific data type (the factory object).
The simplest form of generator is an atomic generator, which produces individual objects randomly w
particular relationship between them. The following generic code snippet illustrates an atomic genera
that operates on a transaction factory object:
while (gen_cnt < tb_cfg.test_len)
begin
// Randomize but don't generate completions or locked mem reads
int success = randomized_tr.randomize() with {
m_enType !inside {
dw_vip_anymodel_transaction::member_1,
dw_vip_anymodel_transaction::member_2,
dw_vip_anymodel_transaction::member_n
}
}
gen_cnt++;
// Make a copy of the transaction object, assign an ID, and push it into the
channel
$cast(anyXact, randomized_tr.copy());
anyXact.object_id = gen_cnt;
gen_out_chan.put (anyXact);
// Display the transaction
msg = $psprintf("Copy of Transaction #%0d has been put in the channel", gen_cnt);
‘vmm_note(log, msg);
anyXact.display("tbd TX In CH: ");
// The ENDED notification indicates the transaction has completed on the protocol
anyXact.notify.wait_for(vmm_data::ENDED);
msg = $psprintf("Transaction #%0d has ended", gen_cnt);
‘vmm_note(log, msg);
end end
This example shows the essential parts of a generator, which include a while loop to control how man
objects are generated. Inside the loop, randomize() is called. Then, a copy of the randomized transac
created and pushed into the channel interface. As part of the generator, you might also display each
transaction object that gets generated, as shown, and use the ENDED notification to confirm that the
transaction is completed.
The ‘randomize with’ construct used above is a convenient way of applying constraints to members “
the-spot”. In terms of reuse, the generator does not need to know anything about the factory object t
randomizing (except for the class name). In the code above, the definition of randomized_tr does not
the generator code. The constraints are the only object information included, and they could be inclu
elsewhere (in an extended class). As a result, the generator code can be independent from the testbe
code--it simply needs to be given a factory object to randomize. By simply providing another factory o
the generator produces objects based on the new template. This is one of the important opportunitie
VMM provides for reducing test-specific code and increasing reuse.
SolvNet
July 2015 Synopsys, Inc. 49
Integration With VMM Verification IP for AMBA AXI VMM User Guide
generator macros accept an argument that defines the class to be used as the factory object. For det
information about these macros, see the “Class Reference” appendix in the Verification Methodology
For SystemVerilog.
The vmm_scenario_gen macro creates a scenario generator that generates sequences of instances o
specified factory class. The sequence is represented as an array of objects. A scenario generator can
for protocols that define sequences of activity where the individual transactions are related. Constrai
define the rules governing the sequence of objects that the generator creates. When the array of tran
is randomized, an entire sequence is generated. An VMM scenario can even generate sequences of
sequences
The following is a sample use of the scenario generator macro:
// Macro to create scenario generator
// This macro will create the following classes:
// dw_vip_anymodel_transaction_scenario
// dw_vip_anymodel_transaction_scenario_gen
// dw_vip_anymodel_transaction_scenario_gen_callbacks
// dw_vip_anymodel_transaction_scenario_election
// Note: dw_vip_anymodel_transaction_channel is defined by VIP
vmm_scenario_gen (dw_vip_anymodel_transaction, "AnyModel Gen"
The vmm_scenario_gen macro creates several classes based on the factory class argument. Note tha
classes that are created rely on having a predefined channel, which is similarly named and provided
For detailed information about generators, see the Verification Methodology Manual For SystemVerilo
3.4.6 Factories
The object that is provided to a generator is referred to as a factory, or factory object. It is a blueprin
randomization and serves as the template for the generated objects. A generator uses the factory to
streams of randomized transactions. Also, VIP transactors rely on factory objects so user-defined exte
to a transaction class can be handled for scoreboarding.
Figure10 illustrates how a factory object works with a generator and a VIP transactor.
SolvNet
50 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
Output Channel
Transaction
Transaction
Transaction
Transaction
Scoreboard Transaction
When using VIP, the factory object is typically a transaction. In Figure10, the code excerpt extends a
transaction class and then establishes two instances to use as factory objects--one for the generator
for the transactor. Typically, extensions to a transaction class are user constraints that scope the
randomization to the desired test conditions. Based on the factory object and the extended constrain
generator creates transactions and puts them into the input channel of the transactor. The transacto
generates the protocol activity, handles any response, and optionally passes scoreboard information
through the output channel to the scoreboard.
When a transactor creates an object to be output on an activity or output channel, the allocate() met
used to ensure that the resulting object is of the extended type and not of the base type. Note that, f
type of object, the extended members are only initialized because the VIP does not process the funct
of the extra members. Handling any added members must be provided by the testbench.
Constructors for VIP transactors include optional factory arguments for the creation of user defined
transactions. Each output or activity channel has one factory associated with it in the constructor. De
transaction factories are created if the user fails to provide a factory in the constructor, as long as the
corresponding channel exists.
3.4.7 Messages
Messages generated by the VIP can be controlled individually or in groups. This section describes me
and how to use them.
Messages generated by VIP transactors are compatible with the vmm_log base class. The messages
in two scopes:
❖ Methodology messages, which report base class conditions and errors
❖ Protocol-specific messages that report protocol conditions, events, and errors
SolvNet
July 2015 Synopsys, Inc. 51
Integration With VMM Verification IP for AMBA AXI VMM User Guide
Messages can have a number of attributes, such as type, severity, ID, and text. Here are some qualit
these attributes:
❖ Type: Messages are categorized into types. The possible types are listed in the Verification
Methodology Manual For SystemVerilog in the description of the vmm_log class.
❖ Severity: Severity is similar to the urgency of the message or how serious it is. The possible v
for severity are listed in the Verification Methodology Manual For SystemVerilog in the descript
the vmm_log class.
❖ ID: Messages that are registered have a unique ID. The unique ID makes it easy to identify and
control specific messages. Not all messages have a unique ID.
❖ Text: This is the text of the message. Since the VIP supports and promotes identifying messag
string matching against a regular expression, the text is especially important for messages tha
not have a unique ID.
Some messages are registered and some are unregistered.
❖ Registered messages:
✦ Are registered with the vmm_log service for each transactor
✦ Come from the base protocol model
✦ Are protocol-specific
✦ Have a unique message ID
✦ Include notifications, which announce protocol conditions and events that you might want t
react to in your testbench, but do not display any text
For registered messages, the message descriptor that is returned from an vmm_log::wait_for_m
method includes the message ID in its ID field. You can use the vmm_log::wait_for_msg() meth
with the message ID to capture the message event, or you can use the wait_for() method as sh
next in “VMM Notify for Messages”.
The original message ID, is a fixed value represented by a macro. For example:
‘define VMT_MSGID_BLOCKED_STREAM 505
❖ Unregistered messages:
✦ Are not registered with the vmm_log service
✦ Do not have a unique ID
✦ Primarily report methodology and base class conditions (some unregistered messages are
protocol-specific)
You can use the message text to identify and control unregistered messages.
All NOTIFY_IDs are configured as ONE_SHOT. If different triggering is required, create your own
Note event ID and then indicate event activity using the virtual task
dw_vip_transactor_rvm_callbacks::pre_notify_send_msg callback.
SolvNet
52 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
Given the relationship that the notify ID is <MSG_ID>_NOTIFY_ID, waiting on a message event in an
VMM environment can be performed as follows:
// Wait for a AXIMASTER_MSGID_ILLEGAL_BUSY_RESP message
u1.notify.wait_for(
u1.AXIMASTER_MSGID_ILLEGAL_BUSY_RESP_NOTIFY_ID);
// … got the message event, now do something …
Note that a notify identifier is an integer typed member variable that is assigned by the VMM library,
value may change from one design to another.
3.4.8 Coverage
Functional coverage is used to measure the progress of a verification effort. In general, with VMM
technology, coverage is accomplished via one or more callback class instances registered with the m
transactor. By default, the monitor transactor does not have a coverage callback class instance regis
and so no coverage is reported. To enable coverage, the user must either extend one of the monitor
callback classes and register it, or register an instance of the predefined default coverage callback cl
is provided with the monitor transactor.
Functional coverage in a VMM environment supports the following:
❖ User defined coverage relative to any channel/transaction in any of the transactors
❖ User defined coverage relative to special events (typically provided in monitor models only, an
not present in all VIP suites)
❖ Predefined default coverage model for channels/transactions and special events (provided for
monitor transactors only)
As with all callbacks, the coverage callbacks must be registered with the transactor before they
Attention can be used. This applies for the default coverage callback (it is not registered by default) as well
as any user defined coverage callback.
The coverage data comes in the form of data objects that are exposed via the transactor. This includ
transaction information as well as data for “significant events”, such as protocol errors. Important da
about such events may also be available, such as the type of transaction that caused an error. The d
objects are provided to the testbench at appropriate times through coverage callbacks. The coverage
callbacks are responsible for processing the coverage data and triggering events to cause coverage
collection.
The following list summarizes the steps to create a functional coverage model:
1. Define the following on the extended callback class:
a. Events to sample on in the callback object
b. Data fields to map to the bins on the callback object
SolvNet
July 2015 Synopsys, Inc. 53
Integration With VMM Verification IP for AMBA AXI VMM User Guide
c. Cover groups to sample the event and tie the data to the bins on the callback object
2. Create the callback to:
a. Move the transaction or significant event data into the callback object data fields, and
b. Trigger the sample event
Reset
Port Polarity Direction value Size Description
ACLK - Input - 1 All signals are sampled on the rising edge of this
clock.
ARESETN Low Input Low 1 Reset Signal. Low indicates the model should do a
reset. The default value of this input signal is high for
normal operation.
AWVALID High Output Low 1 This single bit signal indicates, when high, that the
write address and control information is valid and will
remain stable until the address acknowledge signal,
AWREADY, is high.The default value of this signal is
low.
AWADDR - Output Low [63:0] The write address bus gives the initial address of a
write burst transaction. Only the start address of the
burst is provided and the control signals that are
broadcast alongside the address detail how the
address should be modified for the remaining
transfers in the burst.AWADDR width can be
configured as 32 or 64 bit by setting a configuration
parameter.
AWLEN - Output Low [9:0] The burst length gives the exact number of transfers
in a burst. This information is used to determine the
number of data transfers associated with the
address.
By default only the four LSB bits are used in
accordance with ARM’s specification.
AWSIZE - Output Low [2:0] Gives the size of each transfer in the burst. For write
transfers, byte lane strobes are used to indicate
exactly which byte lanes should be updated.
AWBURST - Output Low [1:0] The burst type, coupled with the size information,
details how the address for each transfer within the
burst should be calculated.
SolvNet
54 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
Reset
Port Polarity Direction value Size Description
AWLOCK - Output Low [1:0] Gives additional information about the atomic
characteristics of the transfer.
AWPROT - Output Low [2:0] Gives protection unit information for the transaction.
AWID - Output Low [31:0] The identification tag for the address group of
signals.
ARVALID High Output Low 1 This single bit 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.The default value of this signal is
low.
ARADDR - Output Low [63:0] The read address bus gives the initial address of a
read burst transaction. Only the start address of the
burst is provided and the control signals that are
broadcast alongside the address detail how the
address should be modified for the remaining
transfers in the burst.ADDR width can be configured
as 32 or 64 bit by setting a configuration parameter.
ARLEN - Output Low [3:0] The burst length gives the exact number of transfers
in a burst. This information is used to determine the
number of data transfers associated with the
address.
By default only the four LSB bits are used in
accordance with ARM’s specification.
ARSIZE - Output Low [2:0] Gives the size of each transfer in the burst.
ARBURST - Output Low [1:0] The burst type, coupled with the size information,
details how the address for each transfer within the
burst should be calculated.
ARLOCK - Output Low [1:0] Gives additional information about the atomic
characteristics of the transfer.
ARPROT - Output Low [2:0] Gives protection unit information for the transaction.
SolvNet
July 2015 Synopsys, Inc. 55
Integration With VMM Verification IP for AMBA AXI VMM User Guide
Reset
Port Polarity Direction value Size Description
ARID - Output Low [31:0] The identification tag for the address group of
signals.
RVALID High Input - 1 Indicates that the required read data is available and
the read transfer may complete.
RLAST High Input - 1 Indicates the last data transfer in a read burst.
RDATA - Input - [1023:0] Read data bus. The read data bus can be any width
that is a power of 2, (i.e. 8, 16, 32, 64, 128, 256, 512
or 1024 bits).
RRESP - Input - [1:0] The read response indicates if the read data is valid.
The allowable responses are OKAY, EXOKAY,
SLVERR and DECERR
RID - Input - [31:0] The identification tag for the read data group of
signals. The read ID is generated by the slave and
should match the AID of the transaction to which it is
responding.
RREADY High Output Low 1 The read ready signal is used to indicate if the
master can accept the read data and response
information.
WVALID High Output Low 1 The write valid signal is used to indicate that valid
write data and strobes are available.The default
value for this signal is low.
WLAST High Output Low 1 Indicates the last data transfer in a write burst.
WDATA - Output Low [1023:0] Write data bus. The write data bus can be any width
that is a power of 2, (i.e. 8, 16, 32, 64, 128, 256, 512
or 1024 bits).
WSTRB - Output Low [127:0] The write strobes are used to indicate which byte
lanes should be updated. One write strobe exists for
each 8 bits of the write data bus, so WSTRB[n]
corresponds to WDATA[(8*n)+7: (8*n)]. Only the
strobes for the configured data width are generated
unless the user sets others in the XACT buffer.
WID - Output Low [31:0] The identification tag for the write data group of
signals. The write ID is generated by the master and
should match the corresponding AID.
SolvNet
56 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
Reset
Port Polarity Direction value Size Description
WREADY High Input - 1 The write ready signal is used to indicate if the slave
can accept the write data.
BRESP - Input - [1:0] The write response indicates if the write data has
been successfully accepted. The allowable
responses are OKAY, EXOKAY, SLVERR and
DECERR.
BID - Input - [31:0] The identification tag for the buffered response group
of signals. The buffered response ID is generated by
the slave and should match the AID of the
transaction to which it is responding.
BREADY High Output Low 1 The response ready signal is used to indicate if the
master can accept the response information.
CSYSREQ Low Input - 1 The current 1.00a release does not support low
power mode. Low power mode be will supported in
future releases. This signal is currently inactive.
VHDL users must connect this signal.
CSYSACK Low Output High 1 The current 1.00a release does not support low
power mode. Low power mode will be supported in
future releases. This signal is currently inactive.
VHDL Users must connect this signal.
CACTIVE Low Output High 1 The current 1.00a release does not support low
power mode. Low power mode will be supported in
future releases. This signal is currently inactive.
VHDL customers must connect this signal.
ACLK Input — 1 System Clock signal. All signals are sampled on the
rising edge of this clock.
SolvNet
July 2015 Synopsys, Inc. 57
Integration With VMM Verification IP for AMBA AXI VMM User Guide
AWVALID Input High 1 Write Address Valid signal. When high, indicates that
the write address and control information is valid and
will remain stable until the Address Acknowledge
signal, AWREADY, is high.
AWADDR Input — [63:0] Write Address bus. Gives the initial address of a burst
transaction. Only the start address of the burst is
provided. Control signals detail how the address
should be modified for the remaining transfers in the
burst.
AWLEN Input — [9:0] Burst Length bus. Gives the exact number of transfers
in a burst. Used to determine the number of data
transfers associated with the address.
By default only the four LSB bits are used in
accordance with the AMBA 3 AXI specification.
AWSIZE Input — [2:0] Burst Size bus. Gives the size of each transfer in the
burst. For write transfers, byte lane strobes are used
to indicate exactly which byte lanes should be
updated.
AWBURST Input — [1:0] Burst Type bus. Coupled with AWSIZE, details how
the address for each transfer within the burst should
be calculated.
AWLOCK Input — [1:0] Lock Type bus. Gives information about atomic
characteristics of the transfer.
AWCACHE Input — [3:0] Cache Type bus. Gives information about cacheable
characteristics of the transfer.
AWPROT Input — [2:0] Protection Type bus. Indicates the protection level.
AWID Input — [31:0] Write Address ID bus. The identification tag for the
Write Address group of signals.
ARVALID Input High 1 Read Address Valid signal. When high, indicates that
the read address and control information is valid and
will remain stable until the Address Acknowledge
signal, ARREADY, is high.
SolvNet
58 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
ARADDR Input — [63:0] Read Address bus. Gives the initial address of a burst
transaction. Only the start address of the burst is
provided. Control signals detail how the address
should be modified for the remaining transfers in the
burst.
ARLEN Input — [3:0] Burst Length bus. Gives the exact number of transfers
in a burst. Used to determine the number of data
transfers associated with the address.
By default only the four LSB bits are used in line with
the AMBA 3 AXI specification.
ARSIZE Input — [2:0] Burst Size bus. Gives the size of each transfer in the
burst.
ARBURST Input — [1:0] Burst Type bus. Coupled with ARSIZE, details how
the address for each transfer within the burst should
be calculated.
ARLOCK Input — [1:0] Lock Type bus. Gives information about atomic
characteristics of the transfer.
ARCACHE Input — [3:0] Cache Type bus. Gives information about cacheable
characteristics of the transfer.
ARPROT Input — [2:0] Protection Type bus. Indicates the protection level.
ARID Input — [31:0] Read Address ID bus. The identification tag for the
Read Address group of signals.
RVALID Output High 1 Read Valid signal. Indicates that the required read
data is available and the read transfer may complete.
RLAST Output High 1 Read Last signal. Indicates the last data transfer in a
read burst.
RDATA Output — [1023:0] Read Data bus. Bus width can be 8, 16, 32, 64, 128,
256, 512, or 1024bits.
RRESP Output — [1:0] Read Response bus. Indicates if the read data is
valid. Allowable responses are OKAY, EXOKAY,
SLVERR and DECERR.
RID Output — [31:0] Read ID bus. The identification tag for the read data
group of signals. The read ID is generated by the
Slave and should match the AID of the transaction to
which it is responding.
SolvNet
July 2015 Synopsys, Inc. 59
Integration With VMM Verification IP for AMBA AXI VMM User Guide
RREADY Input High 1 Read Ready signal. Indicates if the Master can accept
the read data and response information.
WVALID Input High 1 Write Valid bus. Indicates that valid write data and
strobes are available.
WLAST Input High 1 Write Last bus. Indicates the last data transfer in a
write burst.
WDATA Input — [1023:0] Write Data bus. Bus width can be 8, 16, 32, 64, 128,
256, 512, or 1024bits.
WSTRB Input — [127:0] Write Strobes bus. Indicates which byte lanes should
be updated. One Write Strobe exists for each 8bits of
the Write Data bus, so WSTRB[n] corresponds to
WDATA[(8*n)+7: (8*n)].
WID Input — [31:0] Write ID bus. The identification tag for the write data
group of signals. The write ID is generated by the
Master and should match the corresponding AID.
WREADY Output High 1 Write Ready signal. Indicates if the Slave can accept
the write data.
BVALID Output High 1 Response Valid signal. Indicates that a valid buffered
response is available.
BRESP Output — [1:0] Write Response bus. Indicates if the write data has
been successfully accepted. The allowable responses
are OKAY, EXOKAY, SLVERR and DECERR.
BID Output — [31:0] Response ID bus. The identification tag for the
buffered response group of signals. The buffered
response ID is generated by the Slave and should
match the AID of the transaction to which it is
responding.
BREADY Input High 1 Response Ready signal. Indicates if the Master can
accept the response information.
CSYSREQ Input Low 1 The current release does not support low power
mode. Low power mode be will supported in future
releases. This signal is currently inactive.
CSYSACK Output Low 1 The current release does not support low power
mode. Low power mode be will supported in future
releases. This signal is currently inactive.
SolvNet
60 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
CACTIVE Output Low 1 The current release does not support low power
mode. Low power mode be will supported in future
releases. This signal is currently inactive.
AWVALID_ALIAS<n> Input High 1 AWVALID Alias strobes. Indicates which Slave alias
<n> = 0 | 1 | 2 should receive the valid data on the AWDDR bus.
These strobes are mutually exclusive with the
AWVALID signal.
ARVALID_ALIAS<n> Input High 1 ARVALID Alias strobes. Indicates which Slave alias
<n> = 0 | 1 | 2 should receive the valid data on the ARADDR bus.
These strobes are mutually exclusive with the
ARVALID signal.
WVALID_ALIAS<n> Input High 1 WVALID Alias strobes. Indicates which Slave alias
<n> = 0 | 1 | 2 should receive the valid data on the WDATA bus.
These strobes are mutually exclusive with the
WVALID signal.
RVALID_ALIAS<n> Output High 1 RVALID Alias strobes. Indicates which Slave alias is
<n> = 0 | 1 | 2 sending valid data on the RDATA bus.
These strobes are mutually exclusive with the RVALID
signal.
BVALID_ALIAS<n> Output High 1 BVALID Alias strobes. Indicates which Slave alias is
<n> = 0 | 1 | 2 sending valid data on the BRESP bus.
These strobes are mutually exclusive with the BVALID
signal.
Config Width
Port Polarity Default Width (bits) Description
ARESETn Low High NO 1 This is the system reset. A valid reset assertion
is required on the ARESETn pin for the Monitor
to start monitoring the AMBA 3 AXI interface
signals.
SolvNet
July 2015 Synopsys, Inc. 61
Integration With VMM Verification IP for AMBA AXI VMM User Guide
Config Width
Port Polarity Default Width (bits) Description
SolvNet
62 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
Config Width
Port Polarity Default Width (bits) Description
SolvNet
July 2015 Synopsys, Inc. 63
Integration With VMM Verification IP for AMBA AXI VMM User Guide
Config Width
Port Polarity Default Width (bits) Description
CSYSREQ Low Input - 1 The current 1.00a release does not support low
power mode. Low power mode be will
supported in future releases. This signal is
currently inactive.
CSYSACK Low Output High 1 The current 1.00a release does not support low
power mode. Low power mode will be
supported in future releases. This signal is
currently inactive.
CACTIVE Low Output High 1 The current 1.00a release does not support low
power mode. Low power mode will be
supported in future releases. This signal is
currently inactive.
Config Width
Port Polarity Default Width (bits) Description
ARESETn Low High NO 1 This is the system reset. A valid reset assertion
is required on the ARESETn pin for the Monitor
to start monitoring the AMBA 3 AXI interface
signals.
SolvNet
64 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
Config Width
Port Polarity Default Width (bits) Description
SolvNet
July 2015 Synopsys, Inc. 65
Integration With VMM Verification IP for AMBA AXI VMM User Guide
Config Width
Port Polarity Default Width (bits) Description
SolvNet
66 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
Config Width
Port Polarity Default Width (bits) Description
CSYSREQ Low Input - 1 The current 1.00a release does not support low
power mode. Low power mode be will
supported in future releases. This signal is
currently inactive.
CSYSACK Low Output High 1 The current 1.00a release does not support low
power mode. Low power mode will be
supported in future releases. This signal is
currently inactive.
CACTIVE Low Output High 1 The current 1.00a release does not support low
power mode. Low power mode will be
supported in future releases. This signal is
currently inactive.
SolvNet
July 2015 Synopsys, Inc. 67
Integration With VMM Verification IP for AMBA AXI VMM User Guide
Global Signals
AWADDR_<portID> Input Output — Yes 32, 64 Write Address bus. Gives the
initial address of a burst
transaction.
SolvNet
68 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
WDATA_<portID> Input Output — Yes 2n, Write Data bus. Bus width can
where be 8, 16, 32, 64, 128, 256,
n 512, or 1024bits.
is 3,
…, 10
WSTRB_<portID> Input Output — Yes 2n, Write Strobes bus. Indicates
where which byte lanes should be
n updated. One Write Strobe
is 0, exists for each 8bits of the
…, 7 Write Data bus, so WSTRB[n]
corresponds to
WDATA[(8*n)+7: (8*n)].
SolvNet
July 2015 Synopsys, Inc. 69
Integration With VMM Verification IP for AMBA AXI VMM User Guide
ARADDR_<portID> Input Output — Yes 32, 64 Read Address bus. Gives the
initial address of a burst
transaction.
SolvNet
70 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
RDATA_<portID> Output Input — Yes 2n, Read Data bus. Bus width can
where be 8, 16, 32, 64, 128, 256,
n 512, or 1024bits.
is 3,
…, 10
RRESP_<portID> Output Input — No 2 Read Response bus. Indicates
if the read data is valid.
SolvNet
July 2015 Synopsys, Inc. 71
Integration With VMM Verification IP for AMBA AXI VMM User Guide
SolvNet
72 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
3.6.1 Limitations
Classes derived from vmm_data have the following limitations:
❖ VIP classes do not support the “len” parameter of the byte_unpack. It is ignored by the Synops
models.
❖ The “byte” parameter of byte_unpack is originally declared as a constant, but the actual value
be changed by the Synopsys classes. For example, if the bytes array is too small, the classes w
adjust it.
.
Table3-7 Summary of VMM Class Interfaces
SolvNet
July 2015 Synopsys, Inc. 73
Integration With VMM Verification IP for AMBA AXI VMM User Guide
SolvNet
74 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
The start_xactor() method for all transactor models should be called at the posedge of the AXI
Attention clock signal (aclk) in the transactor model's interface.
SolvNet
July 2015 Synopsys, Inc. 75
Integration With VMM Verification IP for AMBA AXI VMM User Guide
SolvNet
76 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
A vmm_data derived class called dw_vip_axi_master_status allows you to notify the testbench when a
master transaction has completed and how it completed. The class object allows the model transacto
to return status along with the ENDED notification applied to objects put in the m_oInputChannel whe
they complete.
The status object provides information about the completion including error conditions which may ha
terminated the transaction without completing. Only completed transactions are copied to the
m_oOutputChannel. Terminated transactions are not copied to the m_oOutputChannel. Only transact
covered by the current set of status conditions result in the ENDED notification on the m_oInputChann
objects.
Following is an example on using dw_vip_axi_master_status:
dw_vip_axi_master_transaction mstr_xact;
vmm_data oRvmData;
dw_vip_axi_master_status oStatus;
mstr_xact.notify.wait_for(vmm_data::ENDED);
oRvmData = mstr_xact.notify.status(vmm_data::ENDED);
The start_xactor() method for all transactor models should be called at the posedge of the AXI
Attention clock signal (aclk) in the transactor model's interface.
SolvNet
July 2015 Synopsys, Inc. 77
Integration With VMM Verification IP for AMBA AXI VMM User Guide
The slave input channel requires transactions of type dw_vip_axi_slave_resp_transaction. The data in
transaction is transferred to a model buffer. After loading the buffer, the transactor model makes a ca
'add_to_match_list', queuing the response for use by the slave.
Following are the events which result in an ENDED notification with a return status:
❖ AXI_MSGID_REQUEST_XACT (output)
❖ AXI_MSGID_END_OF_RD_XACT (activity)
❖ AXI_MSGID_END_OF_WR_XACT (activity)
The constructor for the dw_vip_axi_slave_rvm transactor model takes a required instance name, port
configuration object argument, and up to five optional arguments. The configuration parameter requi
valid configuration object. The constructor arguments must be of the types indicated below. The cons
arguments must be of the types indicated below.
function new (string sInstName, AxiSlavePort oPort,
dw_vip_axi_port_model_configuration oVipCfg,
dw_vip_axi_slave_resp_transaction_channel oInputChannel = null,
dw_vip_axi_slave_resp_transaction_channel oOutputChannel = null,
dw_vip_axi_slave_resp_transaction_channel oActivityChannel = null,
dw_vip_axi_slave_resp_transaction oOutputFactory = null,
dw_vip_axi_slave_resp_transaction oActivityFactory = null
dw_vip_axi_slave_resp_transaction oAutoRespFactory = null);
SolvNet
78 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
Following is example code to demonstrate the usage of the getModel call with some basic memory
commands. The handle is of type AxiSlave.
// Note: Slave memory calls like fill_mem/set_mem must be after slave start
slave_model = slave.getAxiSlave();
slave_model.fill_mem (VMT_DEFAULT_STREAM_ID, 64'h0, 32, VMT_MEM_PATTERN_ONE, 0,
1024);
slave_model.set_mem (VMT_DEFAULT_STREAM_ID, 64'h10, 32, 1024'hdeadbeef);
SolvNet
July 2015 Synopsys, Inc. 79
Integration With VMM Verification IP for AMBA AXI VMM User Guide
You can get information about memory access commands from the Using the Synopsys Verification M
the AMBA 3 AXI Interface.
You can use the following commands to access Slave memory:
❖ set_mem. Writes data to a specified Slave memory array address.
❖ fill_mem. Writes a specified data pattern to a specified number of words of a Slave memory arr
❖ get_mem. Reads data from a specific Slave memory array address.
❖ clear_all_mem. Resets all Slave memory to the default fill pattern and resets all FIFOs to empty
❖ enable_fifo_address. Enables a Slave memory address as a FIFO memory.
❖ disable_fifo_address. Disables a previously-enabled FIFO memory address and returns the add
space to non-FIFO memory.
❖ enable_fifo_all. Enables all Slave memory addresses as FIFOs.
❖ disable_fifo_all. Disables all enabled Slave memory FIFO addresses and returns the address sp
non-FIFO memory.
❖ set_fifo. Writes data to a specified location within a specified FIFO.
❖ get_fifo. Reads data from a specified location within a specified FIFO.
❖ push_fifo. Writes data to the tail of a FIFO.
❖ pop_fifo. Reads data from the head of a FIFO.
❖ clear_fifo. Clears all locations in a specified Slave memory FIFO.
❖ clear_fifo_all. Clears all locations in all Slave memory FIFOs.
❖ set_fifo_read_message. Enables messages when the FIFO size reaches a specified index due to
pop_fifo command or a bus read.
❖ set_fifo_write_message. Enables messages when the FIFO size reaches a specified index due t
push_fifo command or a bus write.
❖ clear_fifo_read_message. Disables messages set by set_fifo_read_message.
❖ clear_fifo_write_message. Disables messages set by set_fifo_write_message.
Bus Monitor
Feature (64 Ports) Port Monitor
Typical AXI system using multiple Masters and Slaves with an Interconnect
SolvNet
80 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
Bus Monitor
Feature (64 Ports) Port Monitor
Multiple instantiations X
Transaction logs X X
SolvNet
July 2015 Synopsys, Inc. 81
Integration With VMM Verification IP for AMBA AXI VMM User Guide
Bus Monitor
Feature (64 Ports) Port Monitor
Coverage
Connection Features
The activity channel provides a mechanism for watching activity on the bus. It is used to convey tran
buffers to the user testbench. If user provides the oActivityFactory object, then the model will call the
method “allocate” to generate a transaction object with any required information.
Following are the events which result in an ENDED notification with a return status:
❖ AXI_MSGID_END_OF_RD_XACT
SolvNet
82 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
❖ AXI_MSGID_END_OF_WR_XACT
This results in dw_vip_axi_transaction objects being placed in the activity channel.
The start_xactor() method for all transactor models should be called at the posedge of the AXI
Attention clock signal (aclk) in the transactor model's interface.
The extended text of the message will be printed in a table format, and will show full address and con
information of all transfers.
List of outstanding transactions on all master ports are:
-------------------------------------------------------------------------------------------------
| Master Port # | AID | ADDRESS | AWRITE | ALEN | ASIZE | ABURST | ALOCK | ACACHE | APROT |
--------------------------------------------------------------------------------------------------
| 2|0000a|0000000000f00000|00000000|000000| 010| 01| 00| 0000| 000|
| 2|0000b|0000000000f00000|00000001|000000| 010| 01| 00| 0000| 000|
| 2|0000e|0000000000f00000|00000000|000000| 010| 01| 00| 0000| 000|
SolvNet
July 2015 Synopsys, Inc. 83
Integration With VMM Verification IP for AMBA AXI VMM User Guide
--------------------------------------------------------------------------------------------------
The Port Monitor supports the basic VMM control methods along with the VMM configuration capabilit
It does not support either the input channel or the output channel, but it does support the activity cha
The activity channel provides a mechanism for watching activity on the bus. It is used to convey tran
buffers to the user testbench. If user provides the oActivityFactory object, then the model can call the
method "allocate" to generate transaction object, and put information in it.
If error and/or flow coverage callbacks are implemented, the oErrorCovFactory and oFlowCovFactory
objects are used to allocate the data objects that are provided to the coverage callbacks. If no covera
factory objects are provided in the constructor call, then the coverage data objects will be created fro
classes dw_vip_axi_port_monitor_error_cov and dw_vip_axi_port_monitor_flow_cov.
The port monitor VMM model catches the following model notifications. These both result in
dw_vip_axi_port_monitor_transaction objects being placed in the activity channel.
AXI_MSGID_END_OF_RD_XACT
AXI_MSGID_END_OF_WR_XACT
The start_xactor() method for all transactor models should be called at the posedge of the AXI
Attention clock signal (aclk) in the transactor model's interface.
SolvNet
84 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
nPortType specifies the type of the model configuration to be created. The supported values are:
❖ DW_VIP_AXI_SLAVE_PORT_CFG for Slave
❖ DW_VIP_AXI_MASTER_PORT_CFG for Master
❖ DW_VIP_AXI_MONITOR_PORT_CFG for Monitor
nIdx specifies the master or slave port number, for which the port configuration needs to be created.
supported values are 0 to 31.
Returned dw_vip_axi_port_model_configuration can be used by master/slave constructor,
change_xactor_config, and get_xactor_config_t methods.
In the following example, assume the following:
❖ 8 masters (0 to 7)
❖ 16 slaves (0 to 15)
❖ 3 Port Monitors (0 to 2) attached to master 2, slave 0, and slave 7.
After configuring the system configuration object including the master and slave port configurations,
following.
// Create port configuration objects from preconfigured objects.
cast_assign(oSysCfg.m_ovPortCfgs[0], oSysCfg.m_ovMstrCfgs[2].copy());
cast_assign(oSysCfg.m_ovPortCfgs[1], oSysCfg.m_ovSlvCfgs[0].copy());
cast_assign(oSysCfg.m_ovPortCfgs[2], oSysCfg.m_ovSlvCfgs[7].copy());
// initialize the port id attributes
oSysCfg.m_ovPortCfgs[0].m_nPortId = 0;
oSysCfg.m_ovPortCfgs[1].m_nPortId = 1;
oSysCfg.m_ovPortCfgs[2].m_nPortId = 2;
SolvNet
July 2015 Synopsys, Inc. 85
Integration With VMM Verification IP for AMBA AXI VMM User Guide
configuration objects using the createPortMdlCfg() method, and then use the configuration objects to
instantiate the Port Monitor instances.
Start Time Indicates the simulation time of the first valid signal assertion for
a transaction. The first valid signal asserted for a transaction
can be address valid or write data valid signal.
Finish Time Indicates the simulation time when the transaction completes.
SolvNet
86 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
Phase Indicates the transaction phase. Valid values are: ADDR, DATA,
RESP. Please note that RESP phase is printed only for write
transactions. For read transactions, response is provided along
with the read data, and so no separate RESP phase exists.
Valid Assert Time Indicates the simulation time when valid signal is asserted for
that phase. For example, for a read address phase, this would
indicate the simulation time when signal ARVALID is asserted.
Ready Assert Time Indicates the simulation time when ready signal is asserted for
that phase. For example, for a read address phase, this would
indicate the simulation time when signal ARREADY is asserted.
ALEN Indicates the transaction length. The valid values are in the
range 1 - 16. In case of extended transactions, additional valid
values are: 32, 64, 128, 256, 512 or 1024
Source master Indicates the master which initiated the transaction. Please note
that this field is present only in AXI Bus monitor transaction log,
and is not present in AXI Port monitor transaction log.
SolvNet
July 2015 Synopsys, Inc. 87
Integration With VMM Verification IP for AMBA AXI VMM User Guide
Destination Slave Indicates the slave to which the transaction is destined. Please
note that this field is present only in AXI Bus monitor transaction
log, and is not present in AXI Port monitor transaction log.
Monitor Port Number Indicates which port on the monitor observed this transaction.
Valid values are: 0 - 63. Values in the range 0 - 31 indicate that
the transaction was observed on master port of the monitor.
Values in the range 32 - 63 indicate that the transaction was
observed on slave port of the monitor. The exact slave port can
be computed by (Monitor Port Number - 32). This is currently
not supported in AXI Port Monitor.
The following figure shows a log for a typical read transaction captured by the AXI Bus Monitor:
The following figure shows the log of a write transaction captured by the AXI Bus Monitor:
SolvNet
88 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
Field Description
SolvNet
July 2015 Synopsys, Inc. 89
Integration With VMM Verification IP for AMBA AXI VMM User Guide
Field Description
DIR-Phase DIR indicates the direction of the transaction. Valid values are READ
and WRITE. Phase indicates the transaction phase. Valid values are
ADDR, DATA, and RESP. The RESP phase is printed only for the
write transactions. For read transactions, response is provided along
with the read data, and so no separate RESP phase exists.
ALEN Indicates the transaction length. The valid values are in the range 1 -
16. In case of extended transactions, additional valid values are: 32,
64, 128, 256, 512 or 1024.
Valid Assert Time Indicates the simulation time when valid signal is asserted for that
phase. For example, for a read address phase, this would indicate
the simulation time when signal ARVALID is asserted.
Ready Assert Time Indicates the simulation time when ready signal is asserted for that
phase. For example, for a read address phase, this would indicate
the simulation time when signal ARREADY is asserted.
WSTRB Indicates the write strobe value for each data beat, in binary format.
DATA This represents the data. The data is represented in set of 32 bits (4
Bytes). For example, a 64 bit data can look like ffeeddaa 11223344.
LAST Indicates whether WLAST or RLAST signal has been asserted for
the beat.
MSTR SRC Indicates the master which initiated the transaction. This field is
present only in AXI Bus monitor transaction log, and is not present in
AXI Port monitor transaction log.
SolvNet
90 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
Field Description
SLV DST Indicates the slave to which the transaction is destined. This field is
present only in AXI Bus monitor transaction log, and is not present in
AXI Port monitor transaction log.
MON PORT NUM Indicates which port on the monitor observed this transaction.
Valid values are: 0 - 63. Values in the range 0 - 31 indicate that the
transaction was observed on master port of the monitor.
Values in the range 32 - 63 indicate that the transaction was
observed on slave port of the monitor.
The exact slave port can be computed by (Monitor Port Number -
32). This is not supported in AXI Port Monitor.
The following figure shows the log contents for a typical read-write phase-wise transaction captured b
AXI Monitor.
SolvNet
July 2015 Synopsys, Inc. 91
Integration With VMM Verification IP for AMBA AXI VMM User Guide
Field Description
Start Time Indicates the simulation time of the first valid signal assertion for a
transaction. The first valid signal asserted for a transaction can be
address valid or write data valid signal.
Finish Time Indicates the simulation time when the transaction completes.
DIR Indicates the direction of the transaction. Valid values are: READ,
WRITE
Phase Indicates the transaction phase. Valid values are: ADDR, DATA,
RESP. Please note that RESP phase is printed only for write
transactions. For read transactions, response is provided along with
the read data, and so no separate RESP phase exists.
Valid Assert Time Indicates the simulation time when valid signal is asserted for that
phase. For example, for a read address phase, this would indicate
the simulation time when signal ARVALID is asserted.
Ready Assert Time Indicates the simulation time when ready signal is asserted for that
phase. For example, for a read address phase, this would indicate
the simulation time when signal ARREADY is asserted.
SolvNet
92 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
Field Description
ALEN Indicates the transaction length. The valid values are in the range 1 -
16. In case of extended transactions, additional valid values are: 32,
64, 128, 256, 512 or 1024
WSTRB/ The WSTRB/DATA Lane column represents the WSTRB (for write
Date Lane [(datawitdh in bytes-1) to 0] transactions) and the corresponding data beat below the WSTRB.
As read transactions do not contain WSTRB, only data is captured.
WSTRB: Indicates the write strobe value for each data beat, in
binary format.
Data Lane: Indicates the data for each lane of the data bus, in
hexadecimal format. The transaction log will contain an individual
column for each data lane. The total number of data lane columns
will be equal to data width in bytes. For example, if data width is 32
bits, there will be 4 data lane columns. Data lane 0 will contain the
least significant byte.
LAST Indicates whether WLAST or RLAST signal has been asserted for
the beat
Following figures show the typical contents of log files for read and Write transactions captured by th
Monitor:
SolvNet
July 2015 Synopsys, Inc. 93
Integration With VMM Verification IP for AMBA AXI VMM User Guide
SolvNet
94 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
Field Description
DIR-Phase DIR indicates the direction of the transaction. Valid values are READ
and WRITE. Phase indicates the transaction phase. Valid values are
ADDR, DATA, and RESP. The RESP phase is printed only for the
write transactions. For read transactions, response is provided along
with the read data, and so no separate RESP phase exists.
ALEN Indicates the transaction length. The valid values are in the range 1 -
16. In case of extended transactions, additional valid values are: 32,
64, 128, 256, 512 or 1024.
Valid Assert Time Indicates the simulation time when valid signal is asserted for that
phase. For example, for a read address phase, this would indicate
the simulation time when signal ARVALID is asserted.
Ready Assert Time Indicates the simulation time when ready signal is asserted for that
phase. For example, for a read address phase, this would indicate
the simulation time when signal ARREADY is asserted.
WSTRB Indicates the write strobe value for each data beat, in binary format.
DATA This represents the data. The data is represented in set of 32 bits (4
Bytes). For example, a 64 bit data can look like ffeeddaa 11223344.
SolvNet
July 2015 Synopsys, Inc. 95
Integration With VMM Verification IP for AMBA AXI VMM User Guide
Field Description
LAST Indicates whether WLAST or RLAST signal has been asserted for
the beat.
The following figure shows the log contents for a read/write phase-wise transaction captured by the A
Port Monitor.
SolvNet
96 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
SolvNet
July 2015 Synopsys, Inc. 97
Integration With VMM Verification IP for AMBA AXI VMM User Guide
❖ getBusesCnt
❖ getMasterVisibility
❖ clear
When creating a bus architecture, note the following:
❖ For each channel, the maximum number of buses is 32.
❖ For non-predefined bus architectures, the user is responsible for ensuring that the address cha
and data/response channels are correctly looped together. For example, if the master can issu
write address to slave, then there must be a common write data bus for master and slave: the
a path so that data can flow from master to slave. In addition, there must also be a write respo
bus for both master and slave so that the BRESP response can flow from a slave back to a mas
2. Create a a predefined bus architecture. Note, you can only have one bus architecture, but the
example shows you how to allocate all three predefined architectures.
SASD:
oSysCfg. m_oBusArchCfg = new(oSysCfg.log, oSysCfg.m_nMstrCnt, oSysCfg.m_nSlvCnt);
if(oSysCfg. m_oBusArchCfg.allocate_buses(DW_VIP_AXI_IGNORE,
DW_VIP_AXI_PREDEFINED_SASD)== 1)
{ // User code. }
After the command, all five channels have one bus. All masters and slaves are attached to this
bus within the channel.
SAMD:
oSysCfg. m_oBusArchCfg = new(oSysCfg.log, oSysCfg.m_nMstrCnt, oSysCfg.m_nSlvCnt);
if(oSysCfg. m_oBusArchCfg.allocate_buses(DW_VIP_AXI_IGNORE,
DW_VIP_AXI_PREDEFINED_SAMD)== 1)
{ // User code. }
There is now one shared bus for each address channel. For the write data channel, the number
buses is determined by the number of active slave ports configured within the configuration ob
On every write data bus, only one slave port is attached to it. All masters are attached to every
data bus. In this way, write data from any master can be routed to any slave
For the read data channel, the number of read data buses is same as the number of active ma
ports configured through the configuration object. All slaves are attached to every read data b
and only one master is attached to one read data bus. In this way, the read data from any slav
be routed to any master.
The write response channel is configured the same way as the read data channel.
MAMD:
SolvNet
98 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
With an MAMD, all connections are the same as for a SAMD except for the address buses.
For the write address channel, the number of write address buses is same as the number of ac
slave ports set within the configuration object. On every write address bus, only one slave port
attached to it. All masters are attached to every write address bus. In this way, the write addre
from any master can be routed to any slave.
The read address buses is allocated in the same way as the write address buses for the predef
MAMD.
3. Detach any masters from address buses to make slave devices invisible to them if needed.
4. Call the method oSysCfg.updateVisibilityFromBusArch (m_bvVisibleSlavesOnWriteCh and
m_bvVisibleSlavesOnReadCh) in the master port configuration oSysCfg.m_ovMstrCfgs. This wil
override the current settings. If user does not use the VMM interconnect model, then steps 2 -4
not required.
5. Synchronize the arbitration tier configuration to the bus architecture with a call to the task
oSysCfg.udpateArbDfgFromBusArchCfg().
3.6.12 Channels
The interfaces to the model provide the dw_vip_axi_transaction_channel class, which is an extension
vmm_channel class. This class provides a channel interface that operates with dw_vip_axi_transactio
objects. If you are using either of the generator macros provided by VMM (vmm_atomic_gen and
vmm_scenario_gen), you should not use the vmm_channel macro to create the appropriate channel c
because it is already defined.
Potentially, each transactor model can support three different type of channels: the input channel, ou
channel and the activity channel. Each channel is strongly typed to specific interface: for example, th
master transactor model only uses the dw_vip_axi_master_channel for an input and output channel. T
are public and can be accessed directly through objects. Not all three channels are used by each spe
transactor model: that is, the interconnect transactor model does not have any channel. The monitor
transactor model only supports the activity channel. Every specific transactor model determines whic
channels are required or optional. If the required channel is passed as null in the transactor model
constructor, then the transactor model creates one internally.
The three channels are:
❖ m_oInputChannel
SolvNet
July 2015 Synopsys, Inc. 99
Integration With VMM Verification IP for AMBA AXI VMM User Guide
❖ m_oOutputChannel
❖ m_oActivityChannel
Table12 summarizes the use of channels by the various interfaces.
.
Table3-13 Summary of Channels Used by Transactors
Activity
VMM Transactor Output Channel Input Channel Channel
Interconnect No No No
The Monitor’s activity channel is optional. If the activity channel is not provided by the user, then the
does not create one. Instead, m_oTransactionActivityChan remains null. and no transactions are outp
through a channel.
3.6.13 Factories
Factories are objects who role is to produce other objects. By default, the factory object is optional to
transactor constructor. Each output or activity channel has one factory associated with it in the const
The transactor will call “allocate” if the factory is not null when the transactor model needs to genera
transaction object for a channel. If the factory is not null, the transactor internally creates one transa
object proper to the channel type.
In addition to the channel factory objects, the monitor constructor allows the user to specify factory o
for the dw_vip_axi_monitor_error_cov and dw_vip_axi_monitor_flow_cov coverage data objects.
SolvNet
100 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
SolvNet
July 2015 Synopsys, Inc. 101
Integration With VMM Verification IP for AMBA AXI VMM User Guide
SolvNet
102 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
configuration commands is an vmm_data object. The models require that these vmm_data objects ar
AMBA 3 AXI specific configuration objects.
SolvNet
July 2015 Synopsys, Inc. 103
Integration With VMM Verification IP for AMBA AXI VMM User Guide
The enumerate types listed in the following table are all scoped within the dw_vip_axi_configuration c
When setting enumerated type attributes of the dw_vip_axi_configuration object, use the scoped refe
to specify the enumerated type value.
For example:
m_enDataWidth = dw_vip_axi_configuration:: DATA_BUS_WIDTH_32;
m_enIcBusArch = dw_vip_axi_configuration:: INTERCONNECT_BUS_ARCH_SASD;
addr_bus_width_enum
ADDR_BUS_WIDTH_32
ADDR_BUS_WIDTH_64
data_bus_width_enum
DATA_BUS_WIDTH_8
DATA_BUS_WIDTH_16
DATA_BUS_WIDTH_32
DATA_BUS_WIDTH_64
DATA_BUS_WIDTH_128
DATA_BUS_WIDTH_256
DATA_BUS_WIDTH_512
DATA_BUS_WIDTH_1024
SolvNet
104 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
wstrb_value_enum
INACTIVE_LOW
INACTIVE_PREV
INACTIVE_HIGH
memory_default_pattern_enum
PATTERN_ZERO
PATTERN_ONE
PATTERN_A5
PATTERN_5A
PATTERN_WALK0
PATTERN_WALK1
PATTERN_INCR
PATTERN_DECR
PATTERN_X
interconnect_bus_architecture_enum
INTERCONNECT_BUS_ARCH_SASD
SolvNet
July 2015 Synopsys, Inc. 105
Integration With VMM Verification IP for AMBA AXI VMM User Guide
Access is through the public vmm_log log member of the class instance.
Example usage:
void’(oSlaveXact.reasonable_constraint_mode(OFF));
This method is a function which returns the value of nOnOff when successful, or returns -1 if it fails. L
values for the nOnOff argument are: ON, OFF. When turning OFF constraints, then this function produ
the following vmm_warning message:
"Reasonable constraints have been turned off, the system could appear hung or have
memory issues, see Synopsys AXI User Manual reasonable_constraint_mode command
reference for details."
This message warns that turning off these constraints without adding user defined constraints will all
some of the attributes to take on values during randomization which could lead to extremely large m
consumption, or extremely long simulation delays.
The following is a list of the attributes which must be constrained to prevent those undesirable condit
❖ m_nIdWidth
❖ m_nNumOutstandingXact
❖ m_nMaxExclAcc
❖ m_nWrIntrlvDepth
❖ m_nRdIntrlvDepth
❖ m_nAlias
❖ m_enumMemoryDefaultPattern
❖ m_nValidToAwreadyDelay
❖ m_nValidToArreadyDelay
❖ m_nValidToWreadyDelay
❖ m_nValidToRreadyDelay
❖ m_nValidToBreadyDelay
❖ m_nHighThreshold
❖ m_nLowThreshold
❖ m_nDelayCycles
❖ m_bvVisibleSlavesOnWriteCh
❖ m_bvVisibleSlavesOnReadCh
SolvNet
106 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
The system configuration requires necessary system information. The information is not randomizabl
includes the number of masters and slaves, as well as the system memory map. The memory map is
both monitor and interconnect. If the default memory map is used, then every slave (from 0 up to nS
1) will have 1Mbyte regions continuously allocated from address zero.
If user chooses their own memory map, then the memory map is described by adding AxiSlaveRange
objects to the dw_vip_axi_system_model_configuration through call “addRange”. Each AxiSlaveRange
object includes the slave associated with the range, and the start and end addresses for the range. T
ranges are stored in the dw_vip_axi_system_model_configuration m_ovRanges data member.
AxiSlaveRange is described in “Configuration Sub-Classes for Arbitration and Slave Memory”.
The port objects are all dw_vip_axi_port_configuration objects. The
dw_vip_axi_system_model_configuration object contains two arrays, m_ovMstrCfgs and m_ovSlvCfgs,
holding configuration information describing the different masters and slaves in the system. These ar
have space for 32 masters and 32 slaves. Only the index less than or equal to nMstrCnt-1 or nSlvCnt-
used.
To insure that the configuration of the test system is consistent, the testbench should start by creatin
dw_vip_axi_system_model_configuration defining the system configuration. This
dw_vip_axi_system_model_configuration can be fed to the dw_vip_axi_interconnect_rvm transactor
models directly via the constructor or by using the change_xactor_config command.
The dw_vip_axi_master_rvm and dw_vip_axi_slave_rvm need a simpler object, one that describes the
master or slave port being represented by the model. This object is the
dw_vip_axi_port_model_configuration.
The vmm_log log object for each instance of a configuration class can be provided via the constructo
constructor log object is null, then a default vmm_log object is used which is shared among all config
objects that were not provided a log in the constructor. The following code example shows the declar
of the shared log object.
local static vmm_log m_oSharedLog = new ("dw_vip_axi_system_model_configuration",
"class");
Access is through the public vmm_log log member of the class instance.
SolvNet
July 2015 Synopsys, Inc. 107
Integration With VMM Verification IP for AMBA AXI VMM User Guide
Example usage:
void’(oSlaveXact.reasonable_constraint_mode(OFF));
This method is a function which returns the value of nOnOff when successful or returns -1 if it fails. Le
values for the nOnOff argument are: ON, OFF.
function new (
integer nSlvIdx,
bit [DW_VIP_AXI_ADDR_PORT_WIDTH-1:0] bvStartAddr,
bit [DW_VIP_AXI_ADDR_PORT_WIDTH-1:0] bvEndAddr);
SolvNet
108 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
}endclass
SolvNet
July 2015 Synopsys, Inc. 109
Integration With VMM Verification IP for AMBA AXI VMM User Guide
3.6.18 Extended Master and Slave Transaction Classes for Protocol Enhancements
The Synopsys AMBA 3 AXI VMM provides two additional transaction classes for features beyond the
protocol. These features are meant to provide additional testing capabilities. These features are turn
by default and must be turned on by using several system configuration members. There is a transac
class for both slave and master:
❖ dw_vip_axi_master_extended_transaction is an extension of axi_vip_master_transaction class.
❖ dw_vip_axi_slave_extended_transaction is an extension of axi_vip_slaver_transaction class.
SolvNet
110 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
SolvNet
July 2015 Synopsys, Inc. 111
Integration With VMM Verification IP for AMBA AXI VMM User Guide
In addition to enumerated type, the global Boolean enumerated type declared by VMT is used. The B
enumerated type is
enum VmtBooleanEnum =
VMT_BOOLEAN_FALSE = VMT_FALSE,
VMT_BOOLEAN_TRUE = VMT_TRUE;
The enumerate types are all scoped within the dw_vip_axi_transaction class. When setting enumerate
attributes of the dw_vip_axi_transaction, dw_vip_axi_master_transaction and
dw_vip_axi_slave_resp_transaction classes, use the scoped reference to specify the enumerated type
For example:
m_enXactDir = dw_vip_axi_transaction:: DIR_READ;
m_envStatusError = dw_vip_axi_transaction::NO_FORCE;
The enumerated type attributes are as follows:
m_envResp[*]
m_enXactBurst
m_enXactCache
m_enXactDir
m_enXactLength
m_enXactLock
m_enXactProt
m_enXferSize
SolvNet
112 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
SolvNet
July 2015 Synopsys, Inc. 113
Integration With VMM Verification IP for AMBA AXI VMM User Guide
For complete reference on VMM model class libraries, a HTML-based help system is available. Refer
Note to this help system at:
$DESIGNWARE_HOME/vip/amba/doc/axi_vmm_html/index.html
SolvNet
114 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
3.6.22.7.1 m_nAvalidWvalidDelay
Figure3-12 shows a waveform depicting how m_nAvalidWvalidDelay works. Figure3-12 shows that th
delay begins when the master asserts AWVALID. After the delay expires, the master asserts WVALID.
delay can take the following two forms:
❖ Positive (AWVALID to WVALID)
❖ Negative (WVALID to AWVALID)
For the positive value, the delay begins when the master is ready to drive the address, that is AWVAL
gets asserted. After the delay expires, the master asserts WVALID.
For the negative value, WVALID gets asserted and after the delay expires, the master asserts the
corresponding AWVALID.
Transaction 1 has the following values:
❖ m_nAvalidWvalidDelay=4
❖ m_bvAddr=0010
❖ m_bvvData[0]=0000
Transaction 2 has the following values:
❖ m_nAvalidWvalidDelay=-3
❖ m_bvAddr=0020
SolvNet
July 2015 Synopsys, Inc. 115
Integration With VMM Verification IP for AMBA AXI VMM User Guide
❖ m_bvvData[0]=5555
3.6.22.7.2 m_nNextAvalidDelay
Figure3-13 shows a waveform illustrating how m_nNextAvalidDelay works. The delay starts after the
address phase data handshake completes, that is, both AVALID and AREADY are sampled high. After
delay expires, the master asserts the next AVALID. This delay holds good for both write and read add
channels.
The transaction in the waveform shown in Figure3-13 has the following values:
❖ m_bvAddr=0010
❖ m_nNextAvalidDelay=3
3.6.22.7.3 m_nBvalidBreadyDelay
Figure3-14 shows a waveform illustrating how m_nBvalidBreadyDelay works. The delay begins when
master samples BVALID high. After the delay expires, the master asserts BREADY.
SolvNet
116 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
3.6.22.7.4 m_nBreadyDelay
Figure3-15 shows a waveform illustrating how m_nBreadyDelay works. The delay starts after the writ
response data handshake completes, that is, both BVALID and BREADY are sampled high. After the d
expires, the master asserts BREADY.
For the transaction in the following waveform, m_nBreadyDelay=12.
Figure3-15m_nBreadyDelay Waveform
3.6.22.7.5 m_nvRreadyDelay
Figure3-16 shows a waveform illustrating how the delay member m_nvRreadyDelay works.
m_nvRreadyDelay is an array and individual values correspond to each beat of the transaction. The d
begins after the master completes one read data transfer handshake, that is, both RVALID and RREA
sampled high. After the delay for the transfer expires, the master asserts RREADY for the next data t
to occur.
Transaction 1 has the following values:
❖ m_bvvData[0]=0004
SolvNet
July 2015 Synopsys, Inc. 117
Integration With VMM Verification IP for AMBA AXI VMM User Guide
❖ m_nvRreadyDelay[0]=4
Transaction 2 has the following values:
❖ m_bvvData[2]=0006
❖ m_nvRreadyDelay[2]=2
3.6.22.7.6 m_nvNextWvalidDelay
Figure3-17 shows a waveform illustrating how the delay member m_nvNextWvalidDelay works.
m_nvNextWvalidDelayis an array and individual values correspond to each beat of the transaction. Th
delay begins after the master completes one write data transfer handshake, that is, both WVALID and
WREADY are sampled high. After the delay for the transfer expires, the master asserts WVALID for th
next data transfer to occur.
Transaction 1 has the following values:
❖ m_bvvData[0]=0000
❖ m_nvNextWvalidDelay[0]=4
Transaction 2 has the following values:
❖ m_bvvData[1]=1111
❖ m_nvNextWvalidDelay[1]=6
SolvNet
118 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
3.6.22.7.7 m_nvRvalidRreadyDelay
Figure3-18 shows the waveform illustrating how the delay member m_nvRvalidRreadyDelay works.
m_nvRvalidRreadyDelay is an array and individual values correspond to each beat of the transaction.
The delay begins after the time the master samples RVALID high. After the delay expires, the master
RREADY.
If the default state of Rready is configured to VMT_BOOLEAN_TRUE, then this delay is not seen for the
first transfer.
Transaction 1 has the following values:
❖ m_bvvData[0]=0004
❖ m_nvRvalidRreadyDelay[0]=6
Transaction 2 has the following values:
❖ m_bvvData[2]=0006
❖ m_nvRvalidRreadyDelay[2]=4
SolvNet
July 2015 Synopsys, Inc. 119
Integration With VMM Verification IP for AMBA AXI VMM User Guide
SolvNet
120 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
SolvNet
July 2015 Synopsys, Inc. 121
Integration With VMM Verification IP for AMBA AXI VMM User Guide
The dw_vip_axi_slave_resp_transaction object turns rand_mode and constraint_mode OFF for all of th
dw_vip_axi_transaction attributes, so that only the response attributes added by the
dw_vip_slave_resp_transaction class are randomized. This allows a copy of the output channel reques
object to be randomized without affecting the signature attributes and then sent to the input channel
response.
When used as the response to a request, two specific signature attributes must be copied from the re
object to the response object: m_enXactDir and m_enWriteBeforeAddr. Those two are needed by the
model to match the response to the request since there can be multiple requests in a single cycle. Ho
as a general practice, copy all the signature information to the response object for debugging purpos
this way, a display of the response object will also provide all of the corresponding signature informa
without requiring complex tracking methods.
Note the following:
❖ The dw_vip_axi_slave_resp_transaction object turns the dw_vip_axi_transaction valid_ranges
constraint OFF, since randomization is turned off for these fields.
❖ The dw_vip_axi_slave_resp_transaction object turns the dw_vip_axi_transaction reasonable_*
constraints OFF since randomization is turned off for these fields.
The vmm_log log object for each instance of a slave transaction class can be provided via the constru
the constructor log object is null then a default vmm_log object is used which is shared among all
configuration objects that were not provided a log in the constructor. The following code example sho
declaration of the shared log object.
local static vmm_log m_oSharedLog = new ("dw_vip_axi_slave_resp_transaction", "class");
Access is through the public vmm_log log member of the class instance.
SolvNet
122 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
This method is a function which returns the value of nOnOff when successful, or returns -1 if it fails. L
values for the nOnOff argument are: ON, OFF. When turning OFF constraints this function produces th
following vmm_warning message:
"Reasonable constraints have been turned off, the system could appear hung or have
memory issues, see Synopsys AXI User Manual reasonable_constraint_mode command
reference for details."
This message warns that turning off these constraints without adding user defined constraints will all
some of the attributes to take on values during randomization which could lead to extremely large m
consumption, or extremely long simulation delays.
3.6.22.13.1 m_nvNextRvalidDelay[*]
3.6.22.13.2 shows a waveform explaining how m_nvNextRvalidDelay works. 3.6.22.13.2 shows that t
delay begins after the handshake when a read data phase is complete. The next rvalid goes high afte
m_nvNextRvalidDelay expires.
The rvalid assertion of the next transaction (m_bvAddr = 0x700) is delayed since the
m_nvNextRvalidDelay[15] value of the previous transaction is 5.
3.6.22.13.2 shows the following values:
❖ m_bvAddr = 0x100
❖ m_nvNextRvalidDelay[0] = 5
❖ m_nvNextRvalidDelay[1] = 5
❖ m_nvNextRvalidDelay[15] = 5
❖ m_enXactLength = LENGTH_3
SolvNet
July 2015 Synopsys, Inc. 123
Integration With VMM Verification IP for AMBA AXI VMM User Guide
3.6.22.13.2 m_nWriteBvalidDelay
3.6.22.13.3 shows an example waveform on how m_nWriteBvalidDelay works. Transaction 1 has the
following values:
❖ m_bvAddr = 0x200
❖ m_nWriteBvalidDelay = 5
❖ m_enXactLength = LENGTH_1
The delay begins after a handshake when the 1st (which is also the last) data phase completes. After
delay expires, then the bvalid signal is asserted by the slave.
Transaction 2 has the following values:
❖ m_bvAddr = 0x900
❖ m_nWriteBvalidDelay = 5
❖ m_enXactLength = LENGTH_7
The delay begins after handshake when the 7th (last) data phase completes. After the delay expires,
bvalid signal is asserted by the slave.
SolvNet
124 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
3.6.22.13.3 m_nAddressRvalidDelay
3.6.22.13.4 shows a waveform on how the m_nAddressRvalidDelay works. Refer to the figure for the
following. Transaction 1 values:
❖ m_bvAddr = 0x300
❖ m_nAddressRvalidDelay = 10
❖ m_enXactLength = LENGTH_1
The delay takes effect after the address phase handshake is complete. Signal rvalid for first read dat
is asserted by the slave after the m_nAddressRvalidDelay delay expires.
Transaction 2 values:
❖ m_bvAddr = 0x400
❖ m_nAddressRvalidDelay = 10
❖ m_enXactLength = LENGTH_7
The delay takes effect after the address phase handshake is complete. Signal rvalid for the first read
phase is asserted by the slave after m_nAddressRvalidDelay delay expires.
SolvNet
July 2015 Synopsys, Inc. 125
Integration With VMM Verification IP for AMBA AXI VMM User Guide
3.6.22.13.4 m_nAvalidAreadyDelay
3.6.22.13.5 shows how the delay member m_nAvalidAreadyDelay works. Refer to the figure for the
following explanation and values. Transaction 1 values:
❖ m_bvAddr = 0x700
❖ m_nAvalidAreadyDelay = 6
❖ m_enXactLength = LENGTH_7
Transaction 2 values:
❖ m_bvAddr = 0x800
❖ m_nAvalidAreadyDelay = 6
❖ m_enXactLength = LENGTH_7
The member m_nAvalidAreadyDelay defines the minimum delay, in clock cycles, from the clock that
samples AVALID high until AREADY is high.
If 0, AREADY becomes high at the clock cycle following AVALID high. During this delay, AREADY is
driven low unless it has already been driven high by default. If AREADY is already driven high by the
default setting, then this delay has no effect for the transaction that caused AREADY to be driven hig
AVALID has gone high, then AREADY will remain low until both the m_nAvalidAreadyDelay and
m_nDefaultAreadyDelay timing constraints have been satisfied.
SolvNet
126 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
3.6.22.13.5 m_nDefaultAreadyDelay
3.6.22.13.6 shows the delay member m_nDefaultAreadyDelay works. Refer to the figure for the follow
explanation and values. Transaction 1 has the values:
❖ m_bvAddr = 0x600
❖ m_nDefaultAreadyDelay = 6
❖ m_enDefaultAwready =1
❖ m_enXactLength = LENGTH_7
The delay member m_nDefaultAreadyDelay specifies the minimum delay, in clock cycles, that is appl
after the previous cycle in which AVALID and AREADY were both high until AREADY is driven with the
default value.
During this delay, the signal AREADY is driven low. The value driven on the AREADY signal after this
delay elapses is specified by the setting of m_enDefaultAwready (if it is a write transaction) or
m_enDefaultArready (if it is a read transaction). If AVALID goes high anytime before this default delay
expires, then AREADY goes high after both the m_nDefaultAreadyDelay and m_nAvalidAreadyDelay
delays have expired.
SolvNet
July 2015 Synopsys, Inc. 127
Integration With VMM Verification IP for AMBA AXI VMM User Guide
SolvNet
128 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
3.6.22.13.7 m_nvWvalidWreadyDelay[*]
3.6.22.13.8 shows how the delay member m_nvWvalidWreadyDelay works. Refer to the figure for the
following values and explanation. Values for Transaction 1:
❖ m_bvAddr = 0x1400
❖ m_nvWvalidWreadyDelay = 4
❖ m_enXactLength = LENGTH_7
The member m_nvWvalidWreadyDelay specifies the minimum delay, in clock cycles that is applied af
the clock that samples WVALID high, to setting WREADY high.
If 0, then WREADY goes true in the cycle following WVALID going high. If WREADY is already driven
high by the default setting, then this delay has no effect for that transfer. During this delay the WREA
signal is driven LOW unless it has already been driven high by default. If WVALID has gone high, then
WREADY remains low until both the m_nvWvalidWreadyDelay[n] and m_nDefaultWreadyDelay values
have been satisfied.
SolvNet
July 2015 Synopsys, Inc. 129
Integration With VMM Verification IP for AMBA AXI VMM User Guide
Figure3-25 m_nvWvalidWreadyDelay
3.6.22.13.8 m_nDefaultWreadyDelay
3.6.22.14 shows how the delay member m_nDefaultWreadyDelay works. Refer to the figure for the
following values and explanation. Transaction 1 values:
❖ m_bvAddr = 0x1400
❖ m_nDefaultWreadyDelay = 7
❖ m_enDefaultWready = 1
❖ m_enXactLength = LENGTH_3
m_nDefaultWreadyDelay specifies the minimum delay in clock cycles that is applied after the previou
cycle that WVALID and WREADY were both true until WREADY is driven with the default value.
During this delay, the WREADY signal is driven LOW. The default value driven on WREADY signal afte
this delay elapses is specified by the setting of the m_enDefaultWready in configuration. If WVALID g
true anytime before this default delay expires, then WREADY will go true after both
m_nDefaultWreadyDelay and m_nvWvalidWreadyDelay[n] delays have expired, where n is for the be
position starting from zero.
SolvNet
130 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
Figure3-26 m_nDefaultWreadyDelay
SolvNet
July 2015 Synopsys, Inc. 131
Integration With VMM Verification IP for AMBA AXI VMM User Guide
Data
Field name type Default value Description
m_nDestinatio integer DW_VIP_AXI_UNSPECIFIED. Indicate from which slave this transaction ends.
n Valid value range in [-1… 31]
Note that the dw_vip_axi_monitor_transaction turns rand_mode and constraint_mode OFF for all of th
dw_vip_axi_transaction attributes.
SolvNet
132 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
SolvNet
July 2015 Synopsys, Inc. 133
Integration With VMM Verification IP for AMBA AXI VMM User Guide
❖ psdisplay
❖ allocate
❖ copy
❖ compare
❖ byte_size
❖ byte_pack
❖ byte_unpack
SolvNet
134 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
dw_vip_axi_port_monitor_transaction oVipXact );
virtual task error_significant_event_cov(
dw_vip_axi_port_monitor_rvm oRvmModel,
dw_vip_axi_port_monitor_error_cov oCovData);
virtual task flow_significant_event_cov(
dw_vip_axi_port_monitor_rvm oRvmModel,
dw_vip_axi_port_monitor_flow_cov oCovData);
}
dw_vip_axi_port_monitor_def_cov_data_callbacks extends
dw_vip_axi_port_monitor_rvm_callbacks
SolvNet
July 2015 Synopsys, Inc. 135
Integration With VMM Verification IP for AMBA AXI VMM User Guide
AxiPortMonitor oMon;
oMon = oRvmModel.getAxiPortMonitor();
oMon.get_config_param(VMT_DEFAULT_STREAM_ID, DW_VIP_AXI_SIDEBAND_ENABLE_PARAM,
nSideEnable);
oMon.get_config_param(VMT_DEFAULT_STREAM_ID, DW_VIP_AXI_MAX_BURST_LENGTH_PARAM,
nMaxNumberOfBeats);
if (oVipXact != null) {
m_oActivityXact = oVipXact;
m_nPortIdx = oVipXact.getInterfaceId();
case(oVipXact.m_enXactDir)
{
SolvNet
136 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
dw_vip_axi_port_monitor_transaction::DIR_READ :
{
trigger(m_evAddrRdChReady);
if (nSideEnable || nMaxNumberOfBeats) {
for (i = 0; i <= oVipXact.m_bvXactLength ; i++)
{
m_envResp = oVipXact.m_envResp[i];
trigger(m_evRdChReady);
}
} else {
for (i = 0; i <= oVipXact.m_enXactLength ; i++)
{
m_envResp = oVipXact.m_envResp[i];
trigger(m_evRdChReady);
}
}
}
dw_vip_axi_port_monitor_transaction::DIR_WRITE :
{
trigger(m_evAddrWrChReady);
trigger(m_evRespChReady);
}
}
}
}
task dw_vip_axi_port_monitor_def_cov_data_callbacks :: error_significant_event_cov(
dw_vip_axi_port_monitor_rvm oRvmModel,
dw_vip_axi_port_monitor_error_cov oCovData)
{
if (oCovData != null) {
m_oErrorCovData = oCovData;
trigger(m_evProtoErrMsg);
}
}
SolvNet
July 2015 Synopsys, Inc. 137
Integration With VMM Verification IP for AMBA AXI VMM User Guide
Local Variables
Type Name
dw_vip_axi_monitor_error_cov m_oErrorCovData
dw_vip_axi_monitor_flow_cov m_oFlowCovData
integer m_nMstrIdx
integer m_nSlvIdx
integer m_nPortIdx
dw_vip_axi_monitor_transaction::resp_type_enum m_envResp
Local Events
Type Name
event m_evAddrWrChReady
event m_evAddrRdChReady
event m_evRdChReady
event m_evRespChReady
event m_evErrMsg
event m_evRdHsChange
event m_evWrHsChange
event m_evRdXactComplete
event m_evWrXactComplete
event m_evRdDepthChange
event m_evWrDepthChange
Coverage Groups
ERROR_MSGID
PROTO_ERROR_MSGID
SolvNet
138 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
BURST_ADDR_WRITE
BURST_ADDR_READ
BURST_RRESP
BURST_BRESP
FLOW_RD_HSORDER
FLOW_WR_HSORDER
FLOW_RD_XACT
FLOW_WR_XACT
FLOW_RD_INTRLV_DEPTH
FLOW_WR_INTRLV_DEPTH
sample_event = m_evErrMsg
sample m_oErrorCovData.m_nErrMsgId
INVALID_SLV_IDX AXI_MSGID_INVALID_SLV_IDX
SYSTEM_MEM_OVERLAP AXI_MSGID_SYSTEM_MEM_OVERLAP
MEMCONFIG_OUTSIDE_IDLE AXI_MSGID_MEMCONFIG_OUTSIDE_IDLE
SMALL_MEMMAP_PAGE AXI_MSGID_SMALL_MEMMAP_PAGE
START_ADDRESS_NOT_ALIGNED AXI_MSGID_START_ADDRESS_NOT_ALIGNED
END_ADDRESS_NOT_ALIGNED AXI_MSGID_END_ADDRESS_NOT_ALIGNED
CLEAR_MEM_OUTSIDE_IDLE AXI_MSGID_CLEAR_MEM_OUTSIDE_IDLE
NOTES_DISABLED AXI_MSGID_NOTES_DISABLED
INVALID_INT_VALUE AXI_MSGID_INVALID_INT_VALUE
INVALID_STR_VALUE AXI_MSGID_INVALID_STR_VALUE
CANT_SET_PARAM_BEFORE_START AXI_MSGID_CANT_SET_PARAM_BEFORE_
START
CANT_SET_PARAM_AFTER_START AXI_MSGID_CANT_SET_PARAM_AFTER_START
SolvNet
July 2015 Synopsys, Inc. 139
Integration With VMM Verification IP for AMBA AXI VMM User Guide
ALIAS_CHAIN_INVALID AXI_MSGID_ALIAS_CHAIN_INVALID
MSTR_ID_WIDTH_EXCEEDS_IC_MSTR_ID_ AXI_MSGID_MSTR_ID_WIDTH_EXCEEDS_IC_
WIDTH MSTR_ID_WIDTH
SLV_ID_WIDTH_EXCEEDS_IC_SLV_ID_WIDTH AXI_MSGID_SLV_ID_WIDTH_EXCEEDS_IC_SLV_ID
_WIDTH
IC_SLV_ID_WIDTH_LESS_THAN_IC_MSTR_ID_WID AXI_MSGID_IC_SLV_ID_WIDTH_LESS_THAN_IC_M
TH STR_ID_WIDTH
NONZERO_ALIASED_SLV_ID_WIDTH AXI_MSGID_NONZERO_ALIASED_SLV_ID_WIDTH
ALIAS_EXCEEDS_SLV_COUNT AXI_MSGID_ALIAS_EXCEEDS_SLV_COUNT
INVALID_PARAMETER AXI_MSGID_INVALID_PARAMETER
WRONG_CONFIG_ACCESS AXI_MSGID_WRONG_CONFIG_ACCESS
LATE_SET_COV_CLASS AXI_MSGID_LATE_SET_COV_CLASS
COV_CLASS_MISMATCH AXI_MSGID_COV_CLASS_MISMATCH
CMD_ILLEGAL_AFTER_START AXI_MSGID_CMD_ILLEGAL_AFTER_START
INSTANCE_GROUP_MISMATCH AXI_MSGID_INSTANCE_GROUP_MISMATCH
IC_SLV_ID_WIDTH_TOO_SMALL AXI_MSGID_IC_SLV_ID_WIDTH_TOO_SMALL
SLV_INVALID_ADDR AXI_MSGID_SLV_INVALID_ADDR
MISSING_PORT_CONNECTION AXI_MSGID_MISSING_PORT_CONNECTION
INVALID_PORT_WIDTH AXI_MSGID_INVALID_PORT_WIDTH
LOCK_ACC_EARLY_TERM AXI_MSGID_LOCK_ACC_EARLY_TERM
RD_BLOCK_DEADLOCK AXI_MSGID_RD_BLOCK_DEADLOCK
ALIAS_VALID_COLLISION AXI_MSGID_ALIAS_VALID_COLLISION
BUFFER_GETS_WRONG_MODEL_TYPE AXI_MSGID_BUFFER_GETS_WRONG_MODEL_TYP
E
BUFFER_CREATION_BEFORE_START AXI_MSGID_BUFFER_CREATION_BEFORE_START
BUFFER_CROSS_4KB_BOUNDARY AXI_MSGID_BUFFER_CROSS_4KB_BOUNDARY
UNALIGNED_WRAP_ADDR AXI_MSGID_UNALIGNED_WRAP_ADDR
INVALID_WRAP_LENGTH AXI_MSGID_INVALID_WRAP_LENGTH
INVALID_XACCESS_LENGTH AXI_MSGID_INVALID_XACCESS_LENGTH
INVALID_XACCESS_ACACHE AXI_MSGID_INVALID_XACCESS_ACACHE
SolvNet
140 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
INVALID_POSITION AXI_MSGID_INVALID_POSITION
INVALID_BUFFER_HANDLE AXI_MSGID_INVALID_BUFFER_HANDLE
INVALID_BUFFER_INDEXED_ATTRIBUTE_ AXI_MSGID_INVALID_BUFFER_INDEXED_
VALUE ATTRIBUTE_VALUE
BUFFER_ATTRIBUTE_VALUE_EXCEEDS_CONFIGU AXI_MSGID_BUFFER_ATTRIBUTE_VALUE_
RATION EXCEEDS_CONFIGURATION
BUFFER_ATTRIBUTE_VALUE_RESERVED AXI_MSGID_BUFFER_ATTRIBUTE_VALUE_
RESERVED
INVALID_ATTRIBUTE_ID_FOR_BITVEC_GET AXI_MSGID_INVALID_ATTRIBUTE_ID_FOR_BITVEC
_GET
DROP_INVALID_BUFFER AXI_MSGID_DROP_INVALID_BUFFER
BUFFER_ATTRIBUTE_OPERATION_ERROR AXI_MSGID_BUFFER_ATTRIBUTE_OPERATION_ER
ROR
SET_BUFFER_ATTRIBUTE_VALUE_EXCEEDS_CON AXI_MSGID_SET_BUFFER_ATTRIBUTE_VALUE_EX
FIGURATION CEEDS_CONFIGURATION
SET_BUFFER_ATTRIBUTE_VALUE_RESERVED AXI_MSGID_SET_BUFFER_ATTRIBUTE_VALUE_RE
SERVED
SET_BUFFER_ATTRIBUTE_VALUE_UNKNOWN AXI_MSGID_SET_BUFFER_ATTRIBUTE_VALUE_UN
KNOWN
INVALID_ATTRIBUTE_INT AXI_MSGID_INVALID_ATTRIBUTE_INT
INVALID_BUFFER_DATA_FILL_PATTERN AXI_MSGID_INVALID_BUFFER_DATA_FILL_
PATTERN
UNKNOWN_BUFFER_TYPE AXI_MSGID_UNKNOWN_BUFFER_TYPE
INVALID_ATTRIBUTE_ID AXI_MSGID_INVALID_ATTRIBUTE_ID
MISMATCH_LOCK_AID AXI_MSGID_MISMATCH_LOCK_AID
MISMATCH_XACCESS_CTRL AXI_MSGID_MISMATCH_XACCESS_CTRL
RDATA_MISMATCH AXI_MSGID_RDATA_MISMATCH
RRESP_MISMATCH AXI_MSGID_RRESP_MISMATCH
EXCEEDS_MAX_INTERLEAVE AXI_MSGID_EXCEEDS_MAX_INTERLEAVE
NO_RESULT_BUF_FOR_CMD_HANDLE AXI_MSGID_NO_RESULT_BUF_FOR_CMD_
HANDLE
UNALIGNED_XACCESS_ADDR AXI_MSGID_UNALIGNED_XACCESS_ADDR
FAILED_XACCESS AXI_MSGID_FAILED_XACCESS
SolvNet
July 2015 Synopsys, Inc. 141
Integration With VMM Verification IP for AMBA AXI VMM User Guide
UNMATCHED_XACCESS_WR AXI_MSGID_UNMATCHED_XACCESS_WR
UNKNOWN_VID_ON_PORT AXI_MSGID_UNKNOWN_VID_ON_PORT
UNKNOWN_ADDR_ON_PORT AXI_MSGID_UNKNOWN_ADDR_ON_PORT
INVALID_MIX_MSTRCNT_VID AXI_MSGID_INVALID_MIX_MSTRCNT_VID
INVALID_MASTER_IDX AXI_MSGID_INVALID_MASTER_IDX
INVALID_SLAVE_IDX AXI_MSGID_INVALID_SLAVE_IDX
INVALID_PORT_ID AXI_MSGID_INVALID_PORT_ID
DELAY_CYCLE_LESS_ZERO AXI_MSGID_DELAY_CYCLE_LESS_ZERO
INVALID_COUNT_TYPE AXI_MSGID_INVALID_COUNT_TYPE
INVALID_HIGH_THRESHOLD AXI_MSGID_INVALID_HIGH_THRESHOLD
INVALID_LOW_THRESHOLD AXI_MSGID_INVALID_LOW_THRESHOLD
CLEAR_COUNTER_THRESHOLD_OUTSIDE_IDLE AXI_MSGID_CLEAR_COUNTER_THRESHOLD_
OUTSIDE_IDLE
INVALID_COUNT_AID AXI_MSGID_INVALID_COUNT_AID
CMD_CALLED_BEFORE_START AXI_MSGID_CMD_CALLED_BEFORE_START
INVALID_BUS_ID AXI_MSGID_INVALID_BUS_ID
ARBITER_REQ_ID_NOT_ON_ANY_TIER_FOR_ARB AXI_MSGID_ARBITER_REQ_ID_NOT_ON_ANY_TIE
TRATION R_FOR_ARBTRATION
ARBITER_INVALID_TIER AXI_MSGID_ARBITER_INVALID_TIER
ARBITER_INVALID_REQ_ID AXI_MSGID_ARBITER_INVALID_REQ_ID
ARBITER_INTERNAL_ERROR_INVALID_REQ_ID AXI_MSGID_ARBITER_INTERNAL_ERROR_
INVALID_REQ_ID
ARBITER_INVALID_INDEX_TO_TIER AXI_MSGID_ARBITER_INVALID_INDEX_TO_TIER
INVALID_ATTRIBUTE_ENABLE AXI_MSGID_INVALID_ATTRIBUTE_ENABLE
INVALID_ATTRIBUTE_ENABLE_ID AXI_MSGID_INVALID_ATTRIBUTE_ENABLE_ID
sample_event = m_evErrMsg (
SolvNet
142 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
sample m_oErrorCovData.m_nProtoErrMsgId
VALID_HIGH_DURING_RESET AXI_MSGID_VALID_HIGH_DURING_RESET
VALID_EARLY_RESET_EXIT AXI_MSGID_VALID_EARLY_RESET_EXIT
INVALID_WRAP_BURST_LEN AXI_MSGID_INVALID_WRAP_BURST_LEN
INVALID_EXCL_ACC_BURST_LEN AXI_MSGID_INVALID_EXCL_ACC_BURST_LEN
INVALID_ASIZE_FOR_DATA_WIDTH AXI_MSGID_INVALID_ASIZE_FOR_DATA_
WIDTH
INVALID_WSTRB_FOR_ASIZE AXI_MSGID_INVALID_WSTRB_FOR_ASIZE
INVALID_BURST_TYPE AXI_MSGID_INVALID_BURST_TYPE
INVALID_WRAP_ADDR AXI_MSGID_INVALID_WRAP_ADDR
BURST_CROSSES_4K AXI_MSGID_BURST_CROSSES_4K
INVALID_EXCL_ACC_CACHE AXI_MSGID_INVALID_EXCL_ACC_CACHE
INVALID_CACHE_TYPE AXI_MSGID_INVALID_CACHE_TYPE
INVALID_LOCK_TYPE AXI_MSGID_INVALID_LOCK_TYPE
DECERR_FROM_SLV AXI_MSGID_DECERR_FROM_SLV
LOCK_ACC_INTER AXI_MSGID_LOCK_ACC_INTER
RD_DATA_ORDER_NOT_PRESERVED AXI_MSGID_RD_DATA_ORDER_NOT_PRESERVED
ADDR_ORDER_NOT_PRESERVED AXI_MSGID_ADDR_ORDER_NOT_PRESERVED
WR_DATA_ORDER_NOT_PRESERVED AXI_MSGID_WR_DATA_ORDER_NOT_
PRESERVED
WR_INTRLV_EXCEEDS_DEPTH AXI_MSGID_WR_INTRLV_EXCEEDS_DEPTH
WR_INTRLV_DATA_OUT_OF_ORDER AXI_MSGID_WR_INTRLV_DATA_OUT_OF_
ORDER
SURPRISE_RD_DATA AXI_MSGID_SURPRISE_RD_DATA
SURPRISE_WR_DATA AXI_MSGID_SURPRISE_WR_DATA
ADDR_CONSISTENCY AXI_MSGID_ADDR_CONSISTENCY
WR_CONSISTENCY AXI_MSGID_WR_CONSISTENCY
RD_CONSISTENCY AXI_MSGID_RD_CONSISTENCY
RESP_CONSISTENCY AXI_MSGID_RESP_CONSISTENCY
VALID_UNSTABLE AXI_MSGID_VALID_UNSTABLE
SolvNet
July 2015 Synopsys, Inc. 143
Integration With VMM Verification IP for AMBA AXI VMM User Guide
VALID_CHNL_UNSTABLE AXI_MSGID_VALID_CHNL_UNSTABLE
EARLY_LAST AXI_MSGID_EARLY_LAST
MISSING_LAST AXI_MSGID_MISSING_LAST
HS_RVALID_EARLY AXI_MSGID_HS_RVALID_EARLY
HS_BVALID_EARLY AXI_MSGID_HS_BVALID_EARLY
INVALID_WSTRB_FOR_ADDR AXI_MSGID_INVALID_WSTRB_FOR_ADDR
INVALID_WSTRB_FOR_UNALIGNED_ADDR AXI_MSGID_INVALID_WSTRB_FOR_
UNALIGNED_ADDR
INVALID_EXOKAY AXI_MSGID_INVALID_EXOKAY
EXCL_ACC_WR_WO_RD AXI_MSGID_EXCL_ACC_WR_WO_RD
EXCL_ACC_WR_WO_RD_INVALID_EXOKAY AXI_MSGID_EXCL_ACC_WR_WO_RD_INVALID_EX
OKAY
EXCL_ACC_CTRL_INFO_MISMATCH AXI_MSGID_EXCL_ACC_CTRL_INFO_
MISMATCH
MISSING_DECERR AXI_MSGID_MISSING_DECERR
INVALID_DECERR AXI_MSGID_INVALID_DECERR
INVALID_XACT_ID AXI_MSGID_INVALID_XACT_ID
EXCL_ACC_NOT_ALIGNED AXI_MSGID_EXCL_ACC_NOT_ALIGNED
DEFAULT_SLAVE_RESPONSE_NOT_DECERR AXI_MSGID_DEFAULT_SLAVE_RESPONSE_
NOT_DECERR
EXCEEDS_WRITE_INTERLEAVE_DEPTH AXI_MSGID_EXCEEDS_WRITE_INTERLEAVE_
DEPTH
UNKNOWN no tstate
sample_event = m_evAddrWrChReady
sample m_nMstrIdx
SRC_0 0
SRC_1 1
SolvNet
144 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
SRC_2 2
SRC_3 3
SRC_4 4
SRC_5 5
SRC_6 6
SRC_7 7
SRC_8 8
SRC_9 9
SRC_10 10
SRC_11 11
SRC_12 12
SRC_13 13
SRC_14 14
SRC_15 15
SRC_16 16
SRC_17 17
SRC_18 18
SRC_19 19
SRC_20 20
SRC_21 21
SRC_22 22
SRC_23 23
SRC_24 24
SRC_25 25
SRC_26 26
SRC_27 27
SRC_28 28
SRC_29 29
SRC_30 30
SolvNet
July 2015 Synopsys, Inc. 145
Integration With VMM Verification IP for AMBA AXI VMM User Guide
SRC_31 31
SRC_INVALID notstate
sample m_nSlvIdx
DEST_0 0
DEST_1 1
DEST_2 2
DEST_3 3
DEST_4 4
DEST_5 5
DEST_6 6
DEST_7 7
DEST_8 8
DEST_9 9
DEST_10 10
DEST_11 11
DEST_12 12
DEST_13 13
DEST_14 14
DEST_15 15
DEST_16 16
DEST_17 17
DEST_18 18
DEST_19 19
DEST_20 20
DEST_21 21
DEST_22 22
DEST_23 23
DEST_24 24
DEST_25 25
SolvNet
146 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
DEST_26 26
DEST_27 27
DEST_28 28
DEST_29 29
DEST_30 30
DEST_31 31
DEST_INVALID notstate
sample m_nPortIdx
PORT_MASTER 0:31
PORT_SLAVE 32:64
PORT_INVALID notstate
sample m_oActivityXact.m_enXactLength
LEN_1XFRS dw_vip_axi_monitor_transaction::LENGTH_1
LEN_2XFRS dw_vip_axi_monitor_transaction::LENGTH_2
LEN_3XFRS dw_vip_axi_monitor_transaction::LENGTH_3
LEN_4XFRS dw_vip_axi_monitor_transaction::LENGTH_4
LEN_5XFRS dw_vip_axi_monitor_transaction::LENGTH_5
LEN_6XFRS dw_vip_axi_monitor_transaction::LENGTH_6
LEN_7XFRS dw_vip_axi_monitor_transaction::LENGTH_7
LEN_8XFRS dw_vip_axi_monitor_transaction::LENGTH_8
LEN_9XFRS dw_vip_axi_monitor_transaction::LENGTH_9
LEN_10XFRS dw_vip_axi_monitor_transaction::LENGTH_10
LEN_11XFRS dw_vip_axi_monitor_transaction::LENGTH_11
LEN_12XFRS dw_vip_axi_monitor_transaction::LENGTH_12
LEN_13XFRS dw_vip_axi_monitor_transaction::LENGTH_13
LEN_14XFRS dw_vip_axi_monitor_transaction::LENGTH_14
LEN_15XFRS dw_vip_axi_monitor_transaction::LENGTH_15
LEN_16XFRS dw_vip_axi_monitor_transaction::LENGTH_16
sample m_oActivityXact.m_enXferSize
SolvNet
July 2015 Synopsys, Inc. 147
Integration With VMM Verification IP for AMBA AXI VMM User Guide
SIZE_8BITS dw_vip_axi_monitor_transaction::SIZE_8BIT
SIZE_16BITS dw_vip_axi_monitor_transaction::SIZE_16BIT
SIZE_32BITS dw_vip_axi_monitor_transaction::SIZE_32BIT
SIZE_64BITS dw_vip_axi_monitor_transaction::SIZE_64BIT
SIZE_128BITS dw_vip_axi_monitor_transaction::SIZE_128BIT
SIZE_256BITS dw_vip_axi_monitor_transaction::SIZE_256BIT
SIZE_512BITS dw_vip_axi_monitor_transaction::SIZE_512BIT
SIZE_1024BITS dw_vip_axi_monitor_transaction::SIZE_1024BIT
sample m_oActivityXact.m_enXactBurst
TYPE_FIXED dw_vip_axi_monitor_transaction::BURST_FIXED
TYPE_INCR dw_vip_axi_monitor_transaction::BURST_INCR
TYPE_WRAP dw_vip_axi_monitor_transaction::BURST_WRAP
sample m_oActivityXact.m_enXactLock
LOCK_NORMAL dw_vip_axi_monitor_transaction::NORMAL
LOCK_EXCLUSIVE dw_vip_axi_monitor_transaction::EXCLUSIVE
LOCK_LOCKED dw_vip_axi_monitor_transaction::LOCKED
sample m_oActivityXact.m_enXactCache
CACHE_NULL dw_vip_axi_monitor_transaction::NON_
CACHEABLE_NON_BUFFERABLE
CACHE_B dw_vip_axi_monitor_transaction::BUFFERABLE_
ONLY
CACHE_C dw_vip_axi_monitor_transaction::CACHEABLE_
BUT_NO_ALLOC
CACHE_BC dw_vip_axi_monitor_transaction::CACHEABLE_
BUFFERABLE_BUT_NO_ALLOC
CACHE_CR dw_vip_axi_monitor_transaction::CACHEABLE_
WR_THRU_ALLOC_ON_RD_ONLY
CACHE_BCR dw_vip_axi_monitor_transaction::CACHEABLE_
R_BACK_ALLOC_ON_RD_ONLY
SolvNet
148 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
CACHE_CW dw_vip_axi_monitor_transaction::CACHEABLE_
WR_THRU_ALLOC_ON_WR_ONLY
CACHE_BCW dw_vip_axi_monitor_transaction::CACHEABLE_WR_B
ACK_ALLOC_ON_WR_ONLY
CACHE_CRW dw_vip_axi_monitor_transaction::CACHEABLE_
WR_THRU_ALLOC_ON_BOTH_RD_WR
CACHE_BCRW dw_vip_axi_monitor_transaction::CACHEABLE_
WR_BACK_ALLOC_ON_BOTH_RD_WR
PROT_NORM_SEC_DATA dw_vip_axi_monitor_transaction::DATA_SECURE_
NORMAL
PROT_PRIV_SEC_DATA dw_vip_axi_monitor_transaction::DATA_SECURE_
PRIVILEGED
PROT_NORM_NSEC_DATA dw_vip_axi_monitor_transaction::DATA_NON_
SECURE_NORMAL
PROT_PRIV_NSEC_DATA dw_vip_axi_monitor_transaction::DATA_NON_
SECURE_PRIVILEGED
PROT_NORM_SEC_INST dw_vip_axi_monitor_transaction::INSTRUCTION_
SECURE_NORMAL
PROT_PRIV_SEC_INST dw_vip_axi_monitor_transaction::INSTRUCTION_
SECURE_PRIVILEGED
PROT_NORM_NSEC_INST dw_vip_axi_monitor_transaction::INSTRUCTION_
NON_SECURE_NORMAL
PROT_PRIV_NSEC_INST dw_vip_axi_monitor_transaction::INSTRUCTION_
NON_SECURE_PRIVILEGED
cross BURST_ADDR_WRITE_CTRL
m_nMstrIdx
m_nSlvIdx
m_oActivityXact.m_enXactLength
m_oActivityXact.m_enXferSize
m_oActivityXact.m_enXactBurst
m_oActivityXact.m_enXactLock
m_oActivityXact.m_enXactCache
m_oActivityXact.m_enXactProt
SolvNet
July 2015 Synopsys, Inc. 149
Integration With VMM Verification IP for AMBA AXI VMM User Guide
The following table shows defines for the BURST_ADDR_READ coverage group:
Table3-22 BURST_ADDR_READ Coverage Group
sample_event = m_evAddrRdChReady
sample m_nMstrIdx
SRC_0 0
SRC_1 1
SRC_2 2
SRC_3 3
SRC_4 4
SRC_5 5
SRC_6 6
SRC_7 7
SRC_8 8
SRC_9 9
SRC_10 10
SRC_11 11
SRC_12 12
SRC_13 13
SRC_14 14
SRC_15 15
SRC_16 16
SRC_17 17
SRC_18 18
SRC_19 19
SRC_20 20
SRC_21 21
SRC_22 22
SRC_23 23
SRC_24 24
SRC_25 25
SolvNet
150 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
SRC_26 26
SRC_27 27
SRC_28 28
SRC_29 29
SRC_30 30
SRC_31 31
SRC_INVALID notstate
sample m_nSlvIdx
DEST_0 0
DEST_1 1
DEST_2 2
DEST_3 3
DEST_4 4
DEST_5 5
DEST_6 6
DEST_7 7
DEST_8 8
DEST_9 9
DEST_10 10
DEST_11 11
DEST_12 12
DEST_13 13
DEST_14 14
DEST_15 15
DEST_16 16
DEST_17 17
DEST_18 18
DEST_19 19
SolvNet
July 2015 Synopsys, Inc. 151
Integration With VMM Verification IP for AMBA AXI VMM User Guide
DEST_20 20
DEST_21 21
DEST_22 22
DEST_23 23
DEST_24 24
DEST_25 25
DEST_26 26
DEST_27 27
DEST_28 28
DEST_29 29
DEST_30 30
DEST_31 31
DEST_INVALID notstate
sample m_nPortIdx
PORT_MASTER 0:31
PORT_SLAVE 32:64
PORT_INVALID notstate
sample m_oActivityXact.m_enXactLength
LEN_1XFRS dw_vip_axi_monitor_transaction::LENGTH_1
LEN_2XFRS dw_vip_axi_monitor_transaction::LENGTH_2
LEN_3XFRS dw_vip_axi_monitor_transaction::LENGTH_3
LEN_4XFRS dw_vip_axi_monitor_transaction::LENGTH_4
LEN_5XFRS dw_vip_axi_monitor_transaction::LENGTH_5
LEN_6XFRS dw_vip_axi_monitor_transaction::LENGTH_6
LEN_7XFRS dw_vip_axi_monitor_transaction::LENGTH_7
LEN_8XFRS dw_vip_axi_monitor_transaction::LENGTH_8
LEN_9XFRS dw_vip_axi_monitor_transaction::LENGTH_9
LEN_10XFRS dw_vip_axi_monitor_transaction::LENGTH_10
LEN_11XFRS dw_vip_axi_monitor_transaction::LENGTH_11
SolvNet
152 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
LEN_12XFRS dw_vip_axi_monitor_transaction::LENGTH_12
LEN_13XFRS dw_vip_axi_monitor_transaction::LENGTH_13
LEN_14XFRS dw_vip_axi_monitor_transaction::LENGTH_14
LEN_15XFRS dw_vip_axi_monitor_transaction::LENGTH_15
LEN_16XFRS dw_vip_axi_monitor_transaction::LENGTH_16
sample m_oActivityXact.m_enXferSize
SIZE_8BITS dw_vip_axi_monitor_transaction::SIZE_8BIT
SIZE_16BITS dw_vip_axi_monitor_transaction::SIZE_16BIT
SIZE_32BITS dw_vip_axi_monitor_transaction::SIZE_32BIT
SIZE_64BITS dw_vip_axi_monitor_transaction::SIZE_64BIT
SIZE_128BITS dw_vip_axi_monitor_transaction::SIZE_128BIT
SIZE_256BITS dw_vip_axi_monitor_transaction::SIZE_256BIT
SIZE_512BITS dw_vip_axi_monitor_transaction::SIZE_512BIT
SIZE_1024BITS dw_vip_axi_monitor_transaction::SIZE_1024BIT
sample m_oActivityXact.m_enXactBurst
TYPE_FIXED w_vip_axi_monitor_transaction::BURST_FIXED
TYPE_INCR dw_vip_axi_monitor_transaction::BURST_INCR
TYPE_WRAP dw_vip_axi_monitor_transaction::BURST_WRAP
sample m_oActivityXact.m_enXactLock
LOCK_NORMAL dw_vip_axi_monitor_transaction::NORMAL
LOCK_EXCLUSIVE dw_vip_axi_monitor_transaction::EXCLUSIVE
LOCK_LOCKED dw_vip_axi_monitor_transaction::LOCKED
sample m_oActivityXact.m_enXactCache
CACHE_NULL dw_vip_axi_monitor_transaction::NON_CACHEABLE_
NON_BUFFERABLE
CACHE_B dw_vip_axi_monitor_transaction::BUFFERABLE_
ONLY
CACHE_C dw_vip_axi_monitor_transaction::CACHEABLE_
BUT_NO_ALLOC
SolvNet
July 2015 Synopsys, Inc. 153
Integration With VMM Verification IP for AMBA AXI VMM User Guide
CACHE_BC dw_vip_axi_monitor_transaction::CACHEABLE_
BUFFERABLE_BUT_NO_ALLOC
CACHE_CR dw_vip_axi_monitor_transaction::CACHEABLE_WR_T
HRU_ALLOC_ON_RD_ONLY
CACHE_BCR dw_vip_axi_monitor_transaction::CACHEABLE_WR_B
ACK_ALLOC_ON_RD_ONLY
CACHE_CW dw_vip_axi_monitor_transaction::CACHEABLE_WR_T
HRU_ALLOC_ON_WR_ONLY
CACHE_BCW dw_vip_axi_monitor_transaction::CACHEABLE_WR_B
ACK_ALLOC_ON_WR_ONLY
CACHE_CRW dw_vip_axi_monitor_transaction::CACHEABLE_WR_T
HRU_ALLOC_ON_BOTH_RD_WR
CACHE_BCRW dw_vip_axi_monitor_transaction::CACHEABLE_WR_B
ACK_ALLOC_ON_BOTH_RD_WR
sample m_oActivityXact.m_enXactProt
PROT_NORM_SEC_DATA dw_vip_axi_monitor_transaction::DATA_SECURE_
NORMAL
PROT_PRIV_SEC_DATA dw_vip_axi_monitor_transaction::DATA_SECURE_
PRIVILEGED
PROT_NORM_NSEC_DATA dw_vip_axi_monitor_transaction::DATA_NON_
SECURE_NORMAL
PROT_PRIV_NSEC_DATA dw_vip_axi_monitor_transaction::DATA_NON_
SECURE_PRIVILEGED
PROT_NORM_SEC_INST dw_vip_axi_monitor_transaction::INSTRUCTION_
SECURE_NORMAL
PROT_PRIV_SEC_INST dw_vip_axi_monitor_transaction::INSTRUCTION_
SECURE_PRIVILEGED
PROT_NORM_NSEC_INST dw_vip_axi_monitor_transaction::INSTRUCTION_
NON_SECURE_NORMAL
PROT_PRIV_NSEC_INST dw_vip_axi_monitor_transaction::INSTRUCTION_
NON_SECURE_PRIVILEGED
cross BURST_ADDR_READ_CTRL
m_nMstrIdx
m_nSlvIdx
m_oActivityXact.m_enXactLength
SolvNet
154 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
m_oActivityXact.m_enXferSize
m_oActivityXact.m_enXactBurst
m_oActivityXact.m_enXactLock
m_oActivityXact.m_enXactCache
m_oActivityXact.m_enXactProt
sample_event = m_evRdChReady
sample m_envResp
OKAY dw_vip_axi_monitor_transaction::OKAY
EXOKAY dw_vip_axi_monitor_transaction::EXOKAY
SLVERR w_vip_axi_monitor_transaction::SLVERR
DECERR dw_vip_axi_monitor_transaction::DECERR
State
Name State Value)
sample_event = m_evRespChReady
sample m_oActivityXact.m_envResp[0]
OKAY dw_vip_axi_monitor_transaction::OKAY
EXOKAY dw_vip_axi_monitor_transaction::EXOKAY
SLVERR dw_vip_axi_monitor_transaction::SLVERR
DECERR dw_vip_axi_monitor_transaction::DECERR
sample_event = m_evRdHsChange
SolvNet
July 2015 Synopsys, Inc. 155
Integration With VMM Verification IP for AMBA AXI VMM User Guide
Table3-25 FLOW_RD_HSORDER
sample m_oFlowCovData.m_nRdHsSeq
STRICT DW_VIP_AXI_STRICT_HSORDER
ARDY_AVLD DW_VIP_AXI_ARDY_AVLD_HSORDER
RRDY_RVLD DW_VIP_AXI_RRDY_RVLD_HSORDER
INVALID DW_VIP_AXI_INVALID_HSORDER
sample_event = m_evWrHsChange
sample m_oFlowCovData.m_nWrHsSeq
STRICT DW_VIP_AXI_STRICT_HSORDER
ARDY_AVLD DW_VIP_AXI_ARDY_AVLD_HSORDER
WRDY_WVLD DW_VIP_AXI_WRDY_WVLD_HSORDER
BRDY_BVLD DW_VIP_AXI_BRDY_BVLD_HSORDER
WVLD_AVLD DW_VIP_AXI_WVLD_AVLD_HSORDER
INVALID DW_VIP_AXI_INVALID_HSORDER
sample_event = m_evRdXactComplete
sample m_oFlowCovData.m_bvRdSameMstrInfo
SAME_MSTR_NO_INT DW_VIP_AXI_NO_INT_XACT
SAME_MSTR_ADDR_INT DW_VIP_AXI_ADDR_INT_XACT
SAME_MSTR_BRST_INT DW_VIP_AXI_BRST_INT_XACT
SAME_MSTR_INTRLV_INT DW_VIP_AXI_INTRLV_INT_XACT
SAME_MSTR_WR_INT DW_VIP_AXI_OTHER_DIR_INT_XACT
sample m_oFlowCovData.m_bvRdDiffMstrInfo
S DIFF_MSTR_NO_INT DW_VIP_AXI_NO_INT_XACT
DIFF_MSTR_ADDR_INT DW_VIP_AXI_ADDR_INT_XACT
SolvNet
156 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
DIFF_MSTR_BRST_INT DW_VIP_AXI_BRST_INT_XACT
DIFF_MSTR_INTRLV_INT DW_VIP_AXI_INTRLV_INT_XACT
DIFF_MSTR_WR_INT DW_VIP_AXI_OTHER_DIR_INT_XACT
sample m_oFlowCovData.m_bvRdSameSlvInfo
SAME_SLV_NO_INT DW_VIP_AXI_NO_INT_XACT
SAME_SLV_ADDR_INT DW_VIP_AXI_ADDR_INT_XACT
SAME_SLV_BRST_INT DW_VIP_AXI_BRST_INT_XACT
SAME_SLV_INTRLV_INT DW_VIP_AXI_INTRLV_INT_XACT
SAME_SLV_WR_INT DW_VIP_AXI_OTHER_DIR_INT_XACT
sample m_oFlowCovData.m_bvRdDiffSlvInfo
DIFF_SLV_NO_INT DW_VIP_AXI_NO_INT_XACT
DIFF_SLV_ADDR_INT DW_VIP_AXI_ADDR_INT_XACT
DIFF_SLV_BRST_INT DW_VIP_AXI_BRST_INT_XACT
DIFF_SLV_INTRLV_INT DW_VIP_AXI_INTRLV_INT_XACT
DIFF_SLV_WR_INT DW_VIP_AXI_OTHER_DIR_INT_XACT
sample_event = m_evWrXactComplete
sample m_oFlowCovData.m_bvWrSameMstrInfo
SAME_MSTR_NO_INT DW_VIP_AXI_NO_INT_XACT
SAME_MSTR_ADDR_INT DW_VIP_AXI_ADDR_INT_XACT
SAME_MSTR_BRST_INT DW_VIP_AXI_BRST_INT_XACT
SAME_MSTR_INTRLV_INT DW_VIP_AXI_INTRLV_INT_XACT
SAME_MSTR_BRSP_INT DW_VIP_AXI_BRSP_INT_XACT
SAME_MSTR_RD_INT DW_VIP_AXI_OTHER_DIR_INT_XACT
sample m_oFlowCovData.m_bvWrDiffMstrInfo
DIFF_MSTR_NO_INT DW_VIP_AXI_NO_INT_XACT
DIFF_MSTR_ADDR_INT DW_VIP_AXI_ADDR_INT_XACT
SolvNet
July 2015 Synopsys, Inc. 157
Integration With VMM Verification IP for AMBA AXI VMM User Guide
DIFF_MSTR_BRST_INT DW_VIP_AXI_BRST_INT_XACT
DIFF_MSTR_INTRLV_INT DW_VIP_AXI_INTRLV_INT_XACT
DIFF_MSTR_BRSP_INT DW_VIP_AXI_BRSP_INT_XACT
DIFF_MSTR_RD_INT DW_VIP_AXI_OTHER_DIR_INT_XACT
sample m_oFlowCovData.m_bvWrSameSlvInfo
SAME_SLV_NO_INT DW_VIP_AXI_NO_INT_XACT
SAME_SLV_ADDR_INT DW_VIP_AXI_ADDR_INT_XACT
SAME_SLV_BRST_INT DW_VIP_AXI_BRST_INT_XACT
SAME_SLV_INTRLV_INT DW_VIP_AXI_INTRLV_INT_XACT
SAME_SLV_BRSP_INT DW_VIP_AXI_BRSP_INT_XACT
SAME_SLV_RD_INT DW_VIP_AXI_OTHER_DIR_INT_XACT
sample m_oFlowCovData.m_bvWrDiffSlvInfo
DIFF_SLV_NO_INT DW_VIP_AXI_NO_INT_XACT
DIFF_SLV_ADDR_INT DW_VIP_AXI_ADDR_INT_XACT
DIFF_SLV_BRST_INT DW_VIP_AXI_BRST_INT_XACT
DIFF_SLV_INTRLV_INT DW_VIP_AXI_INTRLV_INT_XACT
DIFF_SLV_BRSP_INT DW_VIP_AXI_BRSP_INT_XACT
DIFF_SLV_RD_INT DW_VIP_AXI_OTHER_DIR_INT_XACT
sample_event = m_evRdDepthChange
sample m_oFlowCovData.m_nRdIntrlvDepth
DEPTH_1 1
DEPTH_2 2
DEPTH_3 3
DEPTH_4 4
DEPTH_5 5
DEPTH_6 6
SolvNet
158 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
DEPTH_7 7
DEPTH_8 8
DEPTH_9 9
DEPTH_10 10
DEPTH_11 11
DEPTH_12 12
DEPTH_13 13
DEPTH_14 14
DEPTH_15 15
DEPTH_16 16
State
State Name Value
sample_event = m_evWrDepthChange
sample m_oFlowCovData.m_nWrIntrlvDepth
DEPTH_1 1
DEPTH_2 2
DEPTH_3 3
DEPTH_4 4
DEPTH_5 5
DEPTH_6 6
DEPTH_7 7
DEPTH_8 8
DEPTH_9 9
DEPTH_10 10
DEPTH_11 11
DEPTH_12 12
SolvNet
July 2015 Synopsys, Inc. 159
Integration With VMM Verification IP for AMBA AXI VMM User Guide
State
State Name Value
DEPTH_13 13
DEPTH_14 14
DEPTH_15 15
DEPTH_16 16
SolvNet
160 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
AXI_MSGID_INVALID_WRAP_LENGTH
In buffer <buffer_handle>, wrapping burst length <alen> must be 2, 4, 8 or 16
Msg Type: VMT_MSG_ERROR
Fields: Type:
AXI_MSGID_INVALID_WRAP_LENGTH_ARG_BUFFER_HANDLE Integer
AXI_MSGID_INVALID_WRAP_LENGTH_ARG_ALEN bit[3:0]
The VMM interface models use this source message to create the VMM message. After being mapped
VMM message, the message would appear as follows, with real values for <buffer_handle> and <ale
*ERROR* [Failure] on axi_master_vmt(test_top.u1) at 450 ns:
In buffer <buffer_handle>, wrapping burst length <alen> must be 2, 4, 8 or 16
In the VMM form, the original message text has remained intact, while the VMT_MSG_ERROR type ha
been mapped to *ERROR*. The mapping of VMT message types to VMM message type and severity is
shown in the following table:
Table3-31 VMT-to-VMM Message Type and Severity Mapping
The VMT message ID and label are registered with the vmm_log service for each VMM interface. The
message descriptor (VmtNotifyMsgData) that is returned from an vmm_log::wait_for_msg_t() method
includes the VMT message ID in its ID field. You can use the vmm_log::wait_for_msg_t method with th
message ID to capture the message event, or you can use the wait_for() method as shown in the exa
the next section.
You can format message display to include the message label, as described in the Reference Verifica
Methodology Testbench User Manual.
SolvNet
July 2015 Synopsys, Inc. 161
Integration With VMM Verification IP for AMBA AXI VMM User Guide
void’(u1.notify.wait_for(
u1.AXI_MSGID_MASTER_SEND_XACT_COMPLETE_NOTIFY_ID));
// … got the notification event, now do something …
SolvNet
162 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
{
printf("Error : bad notification data type\n");
errorCount++;}
SolvNet
July 2015 Synopsys, Inc. 163
Integration With VMM Verification IP for AMBA AXI VMM User Guide
❖ Scenario 4 is that of multiple write responses with different AWIDs destined to the same Maste
port.
Not every case needs arbitration when clashing occurs. Scenario 1 and Scenario 3 can have the same
arbitration scheme. Scenario 2 and Scenario 4 can use round-robin starting with the lower slave inde
result, one arbitration scheme can address Scenario 1 and Scenario 3.
The basis for the Arbiter is a three tier, round robin arbitration scheme. Using various configuration v
this scheme can be used to implement everything from a simple Pure Rotation scheme to a more com
Weighted Reverse Rotation scheme. Figure3-27, Figure3-28, and Figure3-29 show graphical
representations of this arbitration scheme while demonstrating its flexibility.
Selection Order
0 - High
High 5 0 5 - High
Priority 1 - Medium*
0 - High
5 - High
3 - Medium*
2
3 0 - High
5 - High
Medium 2 - Medium*
Priority
1 0 - High
5 - High
4 - Medium**
.
.
Low .
Priority
4 * Pass-thru on high priority
** Both pass-thru holes aligned
The Weighted Reverse Rotation arbitration scheme can be pictured as three concentric disks, each ro
on their own. Each disk has positions for as many master indices as desired, with the High and Mediu
Priority disks also having a single pass-through hole that allows someone from above to view the nex
priority disk.
The driver for the rotation is the high priority disk. After reset, the high priority disk rotates one posit
for each time a new master needs to be granted the bus with the pass-through hole being the last po
the rotation. The pointer on the high priority disk stays fixed, and points to the index of the next mas
be granted bus access. When the pass-through hole is in the pointer position, the index chosen come
the next lower priority (medium) disk. If both pass-through holes are aligned, then the index is chose
the low priority disk.
The High priority disk rotates after every master index selection, and the lower level disks only rotate
time a selection is made from their level or below. The result is a weighted priority arbitration as show
SolvNet
164 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
Figure3-27. This process keeps rotating a “disk” until the selected index is actively requesting. In
Figure3-27, Figure3-28, and Figure3-29, all are assumed to be actively requesting.
With the ability to load each priority “disk” in any order, and with any amount of desired indices, man
variations of priority schemes can be created as shown in the following figure.
Selection Order
High 0 - Low **
Priority 1 - Low **
2 - Low **
3 - Low **
4 - Low **
5 - Low **
.
Medium .
Priority .
3
Low 4 2
Priority
5 1
0 ** Both pass-thru holes aligned
SolvNet
July 2015 Synopsys, Inc. 165
Integration With VMM Verification IP for AMBA AXI VMM User Guide
5 Selection Order
High
Priority 5 - High
4 - Low **
5 - High
2 - Low **
5 - High
Medium 1 - Low **
Priority 5 - High
0 - Low **
.
.
.
1
Low
Priority 0 2
4
** Both pass-thru holes aligned
The model internally maintains a dummy tier below the Low Priority Tier to make ensure no valid inde
neglected. All valid indices are put on the dummy tier initially.
SolvNet
166 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
ICM1
SP1 Slave 1
(MP1)
DW_axi_1
ICM1
SP1 Slave 2
(MP1)
DW_axi_2
AXI_SIDW
In , System Master 1, connected to interconnect DW_axi_1, can access Slave 2, connected to intercon
DW_axi_2; and, System Master 2, connected to interconnect DW_axi_2, can access Slave 1, connecte
interconnect DW_axi_1.
The bidirectional command support can be enabled in the Bus Monitor by setting configuration param
m_enHasBicmd to 1. This will enable the AXI monitor VIP to monitor a cascaded interconnect.
One bus monitor instance can only monitor one bidirectional interconnect.
Note
When bidirectional command support is enabled in AXI monitor VIP, the number of master ports c is
expected to be greater than 1. If not, then the warning message
AXI_MSGID_INVALID_MASTER_COUNT_FOR_BICMD is issued. For an interconnect to be bidirectional,
it should have at least have 2 master ports: one configured as an interconnecting master (ICM) port,
configured as system master port.
Cascaded interconnects can have two type of master ports:
❖ System master ports
❖ Interconnecting master (ICM) ports.
SolvNet
July 2015 Synopsys, Inc. 167
Integration With VMM Verification IP for AMBA AXI VMM User Guide
The AXI bus monitor VIP master ports can be configured as either ICM ports or system master ports.
SolvNet
168 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Integration With VMM
3.9 Loader
VMM model interface loading is done via multiple files. This includes a shared loader file and loader f
for the individual model interfaces.
<axi_root>/include/Axi.pkg
AxiInterconnect_rvm.pkg
AxiMaster_rvm.pkg
AxiMonitor_rvm.pkg
AxiSlave_rvm.pkg
SolvNet
July 2015 Synopsys, Inc. 169
Integration With VMM Verification IP for AMBA AXI VMM User Guide
be portable to other uses. In the VMM example testbench, the user_sink class is an example of buildin
upon the VMM infrastructure.
Boolean bl m_blStartNewInterleave
Class data members are prefixed with a leading “m_” to distinguish from variables. For examp
integer m_nInstanceCount;
bit m_bValidData;
Classes are prefixed with a leading “o”, with no underscore.
SolvNet
170 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Configuration Member Summary
4
Configuration Member Summary
4.1 Overview
This section lists out configuration members found the configuration classes. These members are crit
setting transactor behavior and creating constrained random tests.
dw_vip_axi_port_configuration
BUS MONITOR
When set to 1, this parameter enables transaction logging for master port n. In a
disabled state, no transaction logging is done for master port n.
PORT MONITOR.
When set to 1, this parameter enables transaction logging for the port.
BUS MONITOR
When set to 1, this parameter enables transaction notification for slave port n.
PORT MONITOR.
When set to 1, this parameter enables transaction notification. In a disabled state, no
transaction notification is done.
BUS MONITOR
Defines the read visibility of a slave port to a given master port. Each bit corresponds to
one slave, bit 0 for slave port 0 and so on.
SolvNet
July 2015 Synopsys, Inc. 171
Configuration Member Summary Verification IP for AMBA AXI VMM User Guide
dw_vip_axi_port_configuration
SLAVE
If this configuration parameter is set to 1 (TRUE) then the slave will automatically provide
a random response by randomizing an instance of the factory object oAutoRespFactory
passed to the slave's constructor. If no output factory object is given from the testbench
to the constructor, then the slave will create an object of type
dw_vip_axi_slave_resp_transaction and randomize this object to generate a response.
This parameter is used only by the slave model.
BUS MONITOR
Defines the write visibility of a slave port to a given master port.
INTERCONNECT
Sets the default value of output pin ARREADY_M<n>.
SLAVE.
Sets the default value of output pin ARREADY_M<n>.
INTERCONNECT
Sets the default value of output pin AWREADY_M<n>.
SLAVE:
Specifies the default value the Slave drives on the AWREADY signal:
MASTER
Specifies the default value of BREADY that AXI master would drive.
INTERCONNECT
Sets the default value of output pin RREADY_S<n>.
MASTER.
Specifies the default value of RREADY that Master would drive.
INTERCONNECT
Sets the default value of output pin WREADY_M<n>.
SLAVE.
Specifies the default value the Slave drives on the WREADY signal.
SolvNet
172 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Configuration Member Summary
dw_vip_axi_port_configuration
PORT MONITOR
When 1, indicates exclusive access supported by slave.
BUS MONITOR:
When set to 1,this parameter indicates exclusive access supported by slave n.
SLAVE
Specifies the default pattern of values that memory locations contain prior to any specific
write operation from bus transactions or memory commands.
MASTER
When WVALID is low, the WSTRB signals are inactive.
BUS MONITO
Indicates whether slave port n is aliased to another slave port.
INTERCONNEC
Defines whether Slave port <n> is aliased to another Slave port.
INTERCONNECT
Helps to set the thresholds for counting the number of transactions.
INTERCONNECT
Helps to set the thresholds for counting the number of transactions.
MASTER
This parameter defines the bit width of the virtual channel ID tag. parameter cannot be
changed after the model is started except after a VMT_HARD reset.
SLAVE
Defines the bit width of the ID ports of the Slave (AWID, ARID, WID, RID, BID). The
model drives zero on the unused portion of RID and BID ports.
PORT MONITOR
Width required for all ID buses (i.e., ARID, AWID, RID, WID, BID) seen by the port
monitor.
INTERCONNECT
Helps to set the thresholds for counting the number of transactions.
SolvNet
July 2015 Synopsys, Inc. 173
Configuration Member Summary Verification IP for AMBA AXI VMM User Guide
dw_vip_axi_port_configuration
SLAVE
Specifies the max number of active exclusive access monitors supported by the slave.
MASTER
Specifies the number of outstanding transaction a master supports.
SLAVE
Specifies the number of outstanding transactions a Slave supports. For example, when
1, only 1 transaction can be outstanding.
SLAVE
Specifies the maximum number of read transactions that can have interleaved
responses at the same time. Each transaction ID must be unique.
INTERCONNECT
SETS the delay cycles for READY signals after their respective VALID signals are
asserted.
INTERCONNECT
Sets the delay cycles for READY signals after their respective VALID signals are
asserted.
INTERCONNECT
Sets the delay cycles for READY signals after their respective VALID signals are
asserted.
INTERCONNECT
Sets the delay cycles for READY signals after their respective VALID signals are
asserted.
INTERCONNECT
Sets the delay cycles for READY signals after their respective VALID signals are
asserted.
SolvNet
174 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Configuration Member Summary
dw_vip_axi_port_configuration
SLAVE
Specifies the number of write transactions that can be interleaved.
MASTER
Specifies the number of write transactions that can be interleaved.
dw_vip_axi_system_model_configuration
BUS MONITOR
This configuration parameter controls the behavior of the flow coverage bins
which track transaction that gets interrupted by another transaction (coverage
bins ending with "INTRLV_INT"). When set to 1, these flow coverage bins would
be hit only if a transaction is interrupted by another transaction from the same
master or slave. When set to 0 (default), these bins would be hit if a transaction
is interrupted by another transaction from the same or different
master/slave.This parameter cannot be modified after the start command is
issued.
BUS MONITOR
When set to 1, this parameter enables transaction logging for the system.
ALL MODELS
Defines the width of both the AWADDR and ARADDR address buses.
SolvNet
July 2015 Synopsys, Inc. 175
Configuration Member Summary Verification IP for AMBA AXI VMM User Guide
dw_vip_axi_system_model_configuration
ALL MODELS
Specifies the data bus width of the Master.
ALL MODELS
A value of 1 makes sure that model follows the specification. When set to 0, it
will allow some traffic that is not following protocol, i.e. burst cross 4K boundary.
This configuration can not be changed after start command is called.
INTERCONNECT
Defines the bus architecture. It can only be a shared-address, shared-data bus
(SASD).
ALL MODELS
By default, the protocol allows up to 16 transfers in one burst.
Defines whether the system may contain non AMBA 3 AXI interface-compliant
devices.
ALL MODELS
Each of the five buses has a 64-bit sideband bus. By default, the sideband
signals are off.] When sideband buses are disabled, note the following:
Sideband output buses are driven with zeros, and sideband inputs are ignored.
SolvNet
176 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Configuration Member Summary
dw_vip_axi_system_model_configuration
BUS MONITOR
Defines the number of masters hooked to monitor.
INTERCONNECT
Defines the number of Masters connected to the Interconnect. rand integer
m_nMstrIdWidth = 4
BUS MONITOR
Internal width required for all master ID buses (i.e., ARID, AWID, RID, WID, BID)
seen by the interconnect.This parameter cannot be modified after the start
command is issued.
BUS MONITOR
Defines the number of slaves hooked to monitor. r only' system).
INTERCONNECT
Defines the number of Slaves connected to the Interconnect.
BUS MONITOR
Internal width required for all slave ID buses (i.e., ARID, AWID, RID, WID, BID)
seen by the interconnect.
AxiArbSchemeCfg m_oArbSchemeCfg
dw_vip_axi_bus_architecture_configuration m_oBusArchCfg
INTERCONNECT
SolvNet
July 2015 Synopsys, Inc. 177
Configuration Member Summary Verification IP for AMBA AXI VMM User Guide
SolvNet
178 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Reporting Problems
A
Reporting Problems
If you think a transactor model is not working properly, contact a Synopsys Support Center. Before yo
contact technical support, create an MCD (Model Change Dump) file for the model. The MCD file capt
all of a transactor model’s activity during simulation (that is, stimulus and response) in ASCII text form
Transmitting a MCD file to technical support will help ensure accurate diagnosis of the problem.
SolvNet
July 2015 Synopsys, Inc. 179
Reporting Problems Verification IP for AMBA AXI VMM User Guide
The path separator for most VHDL simulator is “/”, but the separator may be different for you simulator.
Note Refer to your simulator documentation for the correct path separator.
A.2.2.0.1 Example
top.u1.u1
Here the name of the Verilog module is 'top' and this module has an instance of the VMT model and t
instance is called “u1.”
Also, when the instance was created in, the string “u1” was passed to the new() constructor of the m
program AxiSystemTest
SolvNet
180 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Reporting Problems
// reset signal
driveReset();
@(posedge CLOCK);
......
SolvNet
July 2015 Synopsys, Inc. 181
Reporting Problems Verification IP for AMBA AXI VMM User Guide
SolvNet
182 Synopsys, Inc. July 2015
Verification IP for AMBA AXI VMM User Guide Index
Index
A running 20
AXI VIP H
product overview 11 Help, contacting Synopsys 8
A I
Adobe Acrobat Reader 18 Installation
AXI VIP overview 17
product overview 9 preparing for 19
C L
Channels, overview 44 Licensing 23
Class naming conventions, RVM 170 DW_LICENSE_FILE variable 24
Class summary, RVM 170 keys 23
D licensing features 23
Design directory LM_LICENSE_FILE variable 19, 24, 25
creating 19 polling 25
DESIGNWARE_HOME variable 19, 25 SNPSLMD_LICENSE_FILE variable 19, 24, 25
Documentation suspension 25
overview 7 LM_LICENSE_FILE variable 19, 24, 25
Downloading VIP 19 M
DW_LICENSE_FILE variable 24 MCD (Model Change Dump) file
DW_LICENSE_OVERRIDE 24 and model messages 181
dw_vip_setup utility creating 179
creating simulation scripts 31 impact of 181
determining model version 26 instance name, VERA 180
DW_WAIT_LICENSE 25 instance name, Verilog or VHDL 180
E introduction 179
Environment m_nAvalidWvalidDelay 115
DESIGNWARE_HOME variable 19, 25 m_nBreadyDelay 117
DW_LICENSE_FILE variable 24 m_nBvalidBreadyDelay 116
DW_LICENSE_OVERRIDE 24 m_nNextAvalidDelay 117
DW_WAIT_LICENSE 25 m_nvNextWvalidDelay 118
LM_LICENSE_FILE variable 19, 24, 25 m_nvRreadyDelay 117
simulator-specific settings 25 m_nvRvalidRreadyDelay 119
SNPSLMD_LICENSE_FILE variable 19, 24, 25 Model version, determining 26
variable and path settings 25 R
Ethernet VIP RVM
version, determining 26 class summary 170
Example testbenches naming conventions 170
SolvNet
July 2015 Synopsys, Inc. 1
Index Verification IP for AMBA AXI VMM User Guide
sample environment 43
S
Simulation script 31
simulator 20
Simulators
creating simulation scripts 31
environment settings 25
license suspension 25
run scripts and C compiler 20
running simulation script 31
SNPSLMD_LICENSE_FILE variable 19, 24, 25
Support Matrix 18
Support, contacting 8
Support, websites 8
Synopsys, websites 8
System Verilog users 32
T
Testbench
using in System Verilog 32
Testbench, sim script 31
V
Version, determining 26
W
Websites, Synopsys 8
SolvNet
2 Synopsys, Inc. July 2015