Axi SV Amba

Synopsys Verification IP for
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
2.6Setting Up the AXI VIP Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.6.1Creating a Design Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.6.2Running dw_vip_setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.6.3Using Verification IP in Your Testbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.7Simulation Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.7.1Related Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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
3.6.22Transaction Object Enumerated Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.6.23VMM Monitor Interface Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6.24Port Monitor Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6.25Default Coverage Class Declaration and Defines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6.26VMM Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.7Interconnect Arbitration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.8Bidirectional Transaction Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.8.1Interconnecting Master (ICM) Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.8.2System Master Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.8.3ID Width and Bidirectional Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.9Loader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.9.1Shared Interface Loader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.9.2Loaders for Individual Model Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.9.3Testbench Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.10VMM Class Reference for AMBA 3 AXI VIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.10.1Class and Variable Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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
Tables Verification IP for AMBA AXI VMM User Guide
Tables
Table 1-1: AMBA 3 AXI Verification IP Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Table 2-1: Example Testbenches for AXI VIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 2-2: Setup Program Switch Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 3-1: Display Bases for Numeric Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 3-2: AXI Master VIP Port Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 3-3: Slave Port Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 3-4: Bus Monitor Port Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 3-5: Monitor Port Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 3-6: Interconnect Port Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 3-7: Summary of VMM Class Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 3-8: Comparison of Bus Monitor and Port Monitor Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 3-9: Transaction Log Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 3-10: Bus Monitor Phase-wise Log Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 3-11: Port Monitor Transaction Log Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 3-12: Port Monitor Phase-wise Log Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 3-13: Summary of Channels Used by Transactors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 3-14: Configuration Class dw_vip_axi_configuration Enumerated Types . . . . . . . . . . . . . . . . . . . . .
Table 3-15: Randomizable Attributes of dw_vip_master_extended_transaction . . . . . . . . . . . . . . . . . . . . .
Table 3-16: Randomizable Members of dw_vip_slave_extended_transaction . . . . . . . . . . . . . . . . . . . . . .
Table 3-17: dw_vip_monitor_transaction Non-Randomizable Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 3-18: Default Coverage Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 3-19: ERROR_MSGID Coverage Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 3-20: PROTO_ERROR_MSGID Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 3-21: BURST_ADDR_WRITE Coverage Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 3-22: BURST_ADDR_READ Coverage Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 3-23: BURST_RRESP cov group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 3-24: BURST_BRESP Coverage Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 3-25: FLOW_RD_HSORDER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 3-26: FLOW_WR_HSORDER Coverage Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 3-27: FLOW_RD_XACT Coverage Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 3-28: FLOW_WR_XACT Coverage Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 3-29: FLOW_RD_INTRLV_DEPTH Coverage Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 3-30: FLOW_WR_INTRLV_DEPTH Coverage Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 3-31: VMT-to-VMM Message Type and Severity Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 3-32: Prefix Conventions for Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 4-1: Summary of dw_vip_axi_port_configuration Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 4-2: Summary of dw_vip_axi_System_Model_configuration Members . . . . . . . . . . . . . . . . . . . . . .
SolvNet
Verification IP for AMBA AXI VMM User Guide Preface
Preface
About This Guide

This guide contains introductory, usage, and reference for the Synopsys Verification Models for the A
AMBA 3 AXI Interface. All verification models are implemented in Vera Modeling Technology (VMT).
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
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
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
1.1 Product Suite Overview

Synopsys Verification Models for the ARM AMBA 3 AXI Interface includes a Master, Slave, Monitor, and
Interconnect model. Each model supports key features of the ARM AMBA 3.0 AXI interface such as:
separate address/control and data phases, unaligned data transfer support, burst-based transactions
separate read and write channels, and out-of-order transaction completion.
There are two sets of models for verifying ARM AMBA 3 AXI Interface, as listed in Table1-1.
Table1-1 AMBA 3 AXI Verification IP Models
Models Description
Object-based Models These models have an object-based interface for use with the Reference
Verification Methodology (RVM) in testbenches.
axi_master_rvm_vera_vmt The Master transactor model supports configurable transactions, unaligned

data transfers, locked access, and transaction messaging; see “Master
Transactor Overview” on page10.
axi_slave_rvm_vera_vmt The Slave transactor model supports configurable transactions, unaligned

data transfers, variable slave response behavior, and FIFO memory; see
“Slave Transactor Overview” on page11.
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.
axi_interconnect_rvm_vera_vmt The Interconnect transactor model supports up to 32 Masters and 32 Slaves,

data buses up to 1024bits, 32-bit or 64-bit address buses, independent
arbitration on each bus, unlimited memory mapping, all burst types, all
response types, interleaved writes, and pipelined operation; see “Interconnect
Transactor Overview” on page14.
SolvNet
Introduction to the AMBA 3 AXI Verification IP Model Suite Verification IP for AMBA AXI VMM User Guide
Table1-1 AMBA 3 AXI Verification IP Models
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
1.1.1 AMBATM 3 Assured
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.
1.2 Online Reference Documentation

For a complete listing and description of all classes and members, consult the HTML-based online
documentation at:
$DESIGNWARE_HOME/vip/amba/doc/axi_vmm_html/index.html
1.3 Master Transactor Overview

The Synopsys Master Verification IP is a transactor that can generate master ARM AMBA 3 AXI
transactions as defined by the AMBA® AXI Protocol v1.0 specification. The purpose of Master VIP is to
generate all types of read & write cycles on AMBA 3 AXI bus. While all AMBA 3 AXI transactions are
initiated by the Master verification model, there may be more than one Master in a system. The Mast
be used to verify the AMBA 3 AXI interconnect or a slave device. A Simple Master Testbench
Read and write transactions are accomplished using five independent bus channels, each with its ow
handshake signals. The address, data and response transfers can happen on independent cycles whi
allows maximum use of the buses, especially if they are shared.
Following is a list of the major features supported by the AXI Master Verification IP model:
❖ MAMD: Multiple address, multiple data buses. Includes multiple write response buses.
❖ Multiple outstanding transactions
❖ Out of order completion
❖ Unaligned data transfers using byte strobes
❖ Protected accesses
✦ Normal/Privileged
✦ Secure/Non-secure
✦ Data/Instruction
❖ Atomic access
SolvNet
✦ 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
1.4 Slave Transactor Overview

The Slave VIP is a transasctor that can respond to ARM AMBA 3 AXI interface transactions. It can be u
verify an AMBA 3 AXI interconnect or master.
Read and write transactions are accomplished using five independent bus channels each with its own
handshake signals. The address, data and response transfers can happen on independent cycles whi
allows maximum use of the buses especially if they are shared. The slave supports multiple address,
multiple data buses. this includes multiple write response buses.
Transactions are always in data bursts of one to sixteen transfers or “beats”. The data buses can be
configured to support transfers up to 128 bytes wide. The Buffer Response channel returns write stat
results and consists of a single summary transfer for each write burst. Read status is returned with e
data transfer.
The Slave VIP provides user configurable memory space with RAM blocks and FIFO's that have variab
data and variable response behavior. The Slave responds to Read and Write transaction requests from
Master by using the configured memory space data and attributes.
Following is a summary of supported features:
❖ Automatic Reaction to Transaction Requests. The model responds to transaction requests and
initiate any transactions. The slave responds to the AMBA 3 AXI interface automatically, and do
not require any action using commands. Therefore, the Slave must be configured prior to the
transactions. The configuration parameters control the default settings for responses, but the s
can also respond dynamically to specific transaction requests using the response (RESP) buffe
❖ Configurable multiple transactions. The Slave can receive transactions that are configured for
bus widths, data widths, burst lengths and addressing modes. The Slave can accept and buffer
multiple requests for read and write transactions and process them sequentially or out of orde
according to the configuration of the slave and the AMBA 3 AXI protocol constraints.
If the outstanding transaction limit is reached, no new transactions are accepted from the read
write address or write data buses. Only write data for pending transactions will be accepted.
Otherwise, the read and write address buses and write data buses will be stalled until a transa
is completed by the slave and the outstanding transaction count is below the max configured
number.
❖ Out of order completions. Multiple Read responses or multiple write responses with the same A
must be in the same order as the addresses were issued but can be in any order if the AID's ar
the same. A Read response and a Write response can complete in either order regardless of th
issued address order and regardless of whether they have the same AID or not.
SolvNet
❖ 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.
1.5 Monitor Transactor Overview

The Synopsys Monitor Verification IP transactor for the AMBA 3 AXI interface has the followin
major features
:
❖ Complete AXI Protocol checking:
✦ Checks on channel handshake ordering.
✦ Run time control of protocol checking.
❖ Transaction logging and notification:
✦ Create log of transactions.
✦ Testbench notification of completed read and write transactions.
✦ Notification includes XACT buffer containing transaction information.
✦ Run time control of logging.
✦ Statistical reports are available for both valid and error states.
SolvNet
✦ 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
1.6 Interconnect Transactor Overview

The Interconnect Verification IP is a transactor model that provides a means of easily interconnecting
AMBA 3 AXI interface Masters and Slaves as part of verification platform for designs using the AMBA®
AXI Protocol (v1.0). The Interconnect VIP model contains:
❖ Separate Arbiters for each channel (read address, read data, write address, write data, write
response).
❖ Separate Decoders for each address channel.
❖ Multiple data buses.
❖ A built-in default Slave.
Figure1-1 on page 15 shows the internal architecture of the Interconnect model. A DUT can replace a
the Master or Slave models shown. The “Supported Features Summary” on page15 provides a more
detailed list of Interconnect model features.
The axi_interconnect_vmt model, by default, implements the Interconnect as a shared address bus, s
data buses, and shared write response buses. You can switch between the predefined architectures S
and SAMD.
The Interconnect does not insert registers on any channel. Every bus has its own arbiter associated w
and can be operated with specific configuration settings. The arbiter controls proper bus-to-pass data
address bus and write data channels use a three-tier arbitration scheme; the write response and the
data channels use a round-robin scheme.
The Interconnect model maintains a global routing order table, with which the Interconnect maintains
order of transactions (A[W|R]ID) on the write or read channels from the same Master based on record
“being-routed transactions”. The decoder only resides on the address channel and decodes the selec
master's address. The Interconnect supports the interleave feature on write and read channels.
SolvNet
Figure1-1 Interconnect and System Block Diagram
1.6.1 Supported Features Summary

The Interconnect VIP transactor model supports these features:
❖ Fully customizable bus architectures. Supports shared multiple address, data buses, and multi
Write Response buses.
❖ Supports up to 32 Masters and 32 Slaves
❖ Data bus width up to 1024 bits
❖ System Address bus width of 32 or 64 bits
SolvNet
❖ Supports all types of burst transactions and atomic accesses

❖ Pipelined operation on each channel with input-stage concept
❖ Supports interleaved write data
❖ Supports all type of responses
❖ Unlimited memory map for each Slave
❖ Default Slave
❖ Independent arbitration on different buses
✦ Address bus Arbiter and Decoder
✦ Write and Read Data bus Arbiters
✦ Response Bus Arbiters
❖ Aliased Slave interface
❖ Deadlock solutions
❖ All inputs sampled at clock edge
❖ Supports more than 16 transfers per transaction.
❖ Supports sideband signals on all buses.
SolvNet
Verification IP for AMBA AXI VMM User Guide Getting Started
2
Getting Started
2.1 Installation and Setup

This section leads you through installing and setting up the AXI Verification IP for use with the Verifica
Methodology Manual (VMM) for SystemVerilog. When you complete this checklist, the provided exam
testbench will be operational and the AXI Verification IP will be ready to use.
The installation and setup consists of the following major steps:
❖ “System Requirements” on page17
❖ “The Example Testbenches” on page22
❖ “Licensing Information” on page23
❖ “Determining Your Model Version” on page26
❖ “Setting Up the AXI VIP Models” on page26
2.2 System Requirements

Before you download and install the models, you should verify that your system meets the following
hardware and software configuration requirements, and that you have any required libraries installed
2.2.1 Hardware Requirements

Platforms
See “Platform/OS and Simulator Software” on page18.
Disk Space
❖ Approximately 400 MB available disk space for installation and basic use, broken down as follo
✦ Approximately 200 MB to install a VIP product in DESIGNWARE_HOME.
✦ Approximately 200 MB when Vera engine executable files (.vro) files are created. These .vr
are not needed for SystemVerilog testbenches or when simulating natively in VCS using its
OpenVera Native Testbench capability.
Note that each unique version of Vera creates a unique set of .vro files and the storage requirements
same for each set.
SolvNet
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
2.2.2 Software Requirements
2.2.2.1 Your Version of VMT

The Vera Modeling Technology (VMT) is an internal portion of VIP, as illustrated below. It provides bas
VIP functionality, some utilities, and support for installation and licensing. The version of VMT is the
primary key for determining the qualified versions of your platform/OS and simulator.
❖ For the latest VMT version, refer Synopsys AMBA Verification IP Release Notes,
❖ For release notes information about VMT, see the Synopsys Verification IP Vera Modeling Techn
(VMT) Release Notes.
2.2.2.2 Platform/OS and Simulator Software

You need versions of your platform/OS and VCS that have been qualified for use. As noted above, the
version of VMT is the key to determining qualified versions. To see which versions have been qualifie
your version of VMT, see the following document:
Qualified Tools Matrix for VIP:
http://www.synopsys.com/dw/doc.php/vip/vmt/latest/doc/vmt_update.pdf
2.2.2.3 Synopsys Common Licensing (SCL) Software

The SCL software provides the licensing function for the AMBA 3 AXI Verification IP. Acquiring the SCL
software is covered here in “Licensing Information” on page23.
2.2.2.4 Other Third Party Software

❖ Adobe Acrobat: Synopsys AMBA 3 AXI Verification IP documents are available in Acrobat PDF
files. You can get Adobe Acrobat Reader from http://www.adobe.com.
❖ HTML browser: Synopsys Synopsys AMBA 3 AXI Verification IP includes class reference in HT
The following browser/platform combinations are supported:
✦ Microsoft Internet Explorer 6.0 or later (Windows)
✦ Firefox 1.0 or later (Windows and Linux)
✦ Netscape 7.x (Windows, Linux and UNIX)
SolvNet
2.2.3 Preparing for Installation of the VIP Image

1. Ensure that the Synopsys Common Licensing (SCL) software and the necessary licensing struc
established. For detailed instructions, refer to “Licensing Information” on page23.
2. Set DESIGNWARE_HOME to the absolute path where Synopsys VIP is to be installed:
setenv DESIGNWARE_HOME absolute_path_to_designware_home
3. Ensure that your environment and PATH variables are set correctly, including:
✦ License File Variable – For VIP, set either the DW_LICENSE_FILE, SNPSLMD_LICENSE_FILE,
or LM_LICENSE_FILE variable as described in “Licensing Information” on page23.
✦ DESIGNWARE_HOME/bin – The absolute path as described in the previous step.
✦ SNPSLMD_LICENSE_FILE – The absolute path to a file that contains the license keys for
Synopsys Common Licensing software, or the port@host reference to this file.
✦ LM_LICENSE_FILE – The absolute path to a file that contains the license keys for your third-
party tools. Also, include the absolute path to the third party executable in your PATH varia
2.2.4 Downloading and Installing

If you have not yet downloaded and installed the AMBA 3 AXI Verification IP image, follow this proced
1. In your internet browser, navigate to the Synopsys IPDirectory:
http://www.synopsys.com/products/designware/ipdir/
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.
2. In the IP table, click Verification IP.

3. In the page that opens, select AMBA -> Downloads and Documentation.
4. This brings up a page showing multiple AMBA VIP models. Click on the link in the “Download”
row for the model you want to download.
2.2.5 Setting Up an Example Testbench Design Directory

The dw_vip_setup utility allows you to:
❖ Create a directory called the design directory, which contains the models, files for programmin
support called as include files, and example testbenches. You can specify the path of the desig
directory or you can use the current working directory.
❖ Add models to the specified design directory or current working directory.
❖ Build the models in the specified design directory or current working directory.
❖ Add example testbenches to the specified design directory or current working directory.
❖ Create a simulation script for the example testbenches in the specified design directory or curr
working directory.
Invoke the following command to create the design directory, add the models and example testbench
the models, and generate the testbench simulation script:
design_dir -e axi_rvm_sys -svtb
% $DESIGNWARE_HOME/bin/dw_vip_setup -path
SolvNet
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.
2.2.6 Running the Example Testbenches

The example testbenches are provided as part of the AXI Verification IP to demonstrate key model us
and serves as a starting point for you to develop your own testbenches. Successfully running an exam
testbench validates your installation. The remainder of this section shows how to set up and run an e
provided with VIP. The example described here also serves as a starting point to help you begin build
your own testbench.
To run an example testbench, you use the simulation script created in the previous step.
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.
2.2.7 QuickStart for the SystemVerilog/VMM Testbenches

The QuickStart is an HTML-based walk-through of live examples that are included with the Synopsys
AMBA/AXI Verification IP. These examples demonstrate how to use VIP in a SystemVerilog/VMM
testbench.
After the Synopsys AMBA VIP is installed, you can see the QuickStart HTML at:
$DESIGNWARE_HOME/vip/amba/latest/examples/svtb/index.html
The QuickStart provides instructions on installing, setting up, and running the SV/VMM examples.
2.2.7.1 Basic SV/VMM Examples

The basic example (tb_axi_vmm_10_basic_sys) is fully explained in the QuickStart. It demonstrates th
following:
❖ Instantiation
❖ Interconnection at the HDL level
SolvNet
❖ 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
2.2.7.1.1 Installing and Running a Basic SV/VMM Example

This section shows you how to install and run a basic VMM system example, which can help you learn
VMM usage concepts through demonstration.
1. Set up the basic VMM system example in a directory called ‘design_dir’:
$DESIGNWARE_HOME/bin/dw_vip_setup -path ./design_dir -e amba/tb_axi_vmm_10_basic_sys -
svtb
Note that the design_dir directory cannot be located in the directories containing model files.
2. View the QuickStart HTML for this example. After Synopsys AMBA VIP is installed, it is located a
3. Navigate to the ‘design_dir’ directory you created and use either of the following methods to ru
example:
a. Use the provided make file:
gmake USE_SIMULATOR=vcsvlog example WAVES=1
To show more options, invoke ‘gmake help’.
b. Use the generated sim script produced by dw_vip_setup:
./run_axi_vmm_10_basic_sys -w example vcsvlog
To show more options, invoke ‘./run_axi_vmm_10_basic_sys -help’.
The ‘example’ parameter in the sim script invocation points to the file having the program block. It is
stripped of all prefixes and suffixes. The original file is named ‘ts.example.sv’, and exists in the ‘tests
directory.
2.2.7.2 Intermediate SV/VMM Example

The intermediate example (tb_axi_vmm_10_intermediate_sys) is fully explained in the QuickStart. It b
on the basic example to demonstrate the following:
❖ Scenario generators
❖ Responder transactions
❖ Scoreboard
❖ Functional coverage
SolvNet
2.2.7.3 Advanced SV/VMM Example

The advanced example (tb_axi_vmm_10_advanced_sys) builds on the intermediate example to demo
the following:
✦ Master and slave subenvironments
✦ Ending simulation with consensus
For information on installing and running an advanced example, see the ‘Running Examples’ section
QuickStart. After Synopsys AMBA VIP is installed, the QuickStart is located at:
2.2.8 The Example Testbenches

Table2-1 lists and describes the example testbenches. For each testbench, it provides the dw_vip_se
command that creates a design directory, installs and sets up the testbench, and creates the sim scr
command. Table2-1 also provides the specific sim script commands you use to run the example testb
for any supported simulation environment.
Table2-1 Example Testbenches for AXI VIP
Testbench Name and Details
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.
Install/setup: $DESIGNWARE_HOME/bin/dw_vip_setup -p design_dir -e axi_rvm_sys -svtb
Sim script location: design_dir/examples/axi_rvm_sys/ (select the command from below)
Testbench Languages: Simulator: Sim Script Command
SVTB VCS: sim_axi_rvm_sys vcsvlog svtb

VCS MX: sim_axi_rvm_sys vcsmxvlog svtb
sim_axi_rvm_sys vcsvhdl svtb
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.
Install/setup: $DESIGNWARE_HOME/bin/dw_vip_setup -e amba/tb_axi_vmm_10_basic_sys -path ./design_dir

-svtb
Sim script location: design_dir/examples/svtb/amba/tb_axi_vmm_10_basic (select the command from below)
SVTB VCS: run_axi_vmm_10_basic_sys example vcsvlog

run_axi_vmm_10_basic_sys all vcsvlog
VCS MX: run_axi_vmm_10_basic_sys example vcsmxvlog
run_axi_vmm_10_basic_sys all vcsmxvlog
SolvNet
Table2-1 Example Testbenches for AXI VIP
Testbench Name and Details
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.
Install/setup: $DESIGNWARE_HOME/bin/dw_vip_setup -e amba/tb_axi_vmm_10_intermediate_sys -path

./design_dir -svtb
Sim script location: design_dir/examples/svtb/amba/tb_axi_vmm_10_intermediate (select the command from

below)
SVTB VCS: run_axi_vmm_10_intermediate_sys example

vcsvlog
run_axi_vmm_10_intermediate_sys all vcsvlog
VCS MX: run_axi_vmm_10_intermediate_sys example
vcsmxvlog
run_axi_vmm_10_intermediate_sys all vcsmxvlog
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.
Install/setup: $DESIGNWARE_HOME/bin/dw_vip_setup -e amba/tb_axi_vmm_10_advanced_sys -path

./design_dir -svtb
Sim script location: design_dir/examples/svtb/amba/tb_axi_vmm_10_advanced (select the command from

below)
SVTB VCS: run_axi_vmm_10_advanced_sys example vcsvlog

run_axi_vmm_10_advanced_sys all vcsvlog
VCS MX: run_axi_vmm_10_advanced_sys example vcsmxvlog
run_axi_vmm_10_advanced_sys all vcsmxvlog
2.3 Licensing Information

The AMBA 3 AXI Verification IP uses the Synopsys Common Licensing (SCL) software to control its usa
You can find general SCL information at:
http://www.synopsys.com/keys
The AXI Verification IP uses a licensing mechanism that is enabled by one of several license features.
default order for a ASIC Regression Library model is:
1. DesignWare-AMBA-VIP, if available
2. DesignWare-Regression license or VCS-Verification-Library license, if available
SolvNet
3. DesignWare license, if available

Only one license is consumed per simulation session, no matter how many VIP models are instantiate
the design.
The licensing keys must reside in files that are indicated by specific environment variables. For inform
about setting these licensing environment variables, refer to “Environment Variable and Path Setting
page25.
For information on checking the license versions, see the Synopsys AMBA AXI Verification IP
Attention Release Notes.
2.3.1 Specifying License Files

Synopsys license keys must be in a file location defined by one of the following environment variable
These variables are listed in order of precedence for VIP.
1. DW_LICENSE_FILE
If set, VIP ignores all other license file variables in this list. To improve the performance of licen
checkout for VIP, use this variable and set it only to snpslmd license servers that contain VIP
licenses.
2. SNPSLMD_LICENSE_FILE
If set, it overrides the LM_LICENSE_FILE variable, if also set.
3. LM_LICENSE_FILE
Used only when the other variables in this list are unset.
2.3.2 License Features for VIP

All VIP suites have a common licensing mechanism, which is enabled by one of several license featur
order for acquiring a license during a run is:
1. DESIGNWARE-suite-VIP, if available (for example, AMBA-VIP)
2. DESIGNWARE-REGRESSION or
VCS-VERIFICATION-LIBRARY, if available
3. DESIGNWARE
To limit the features that are used, see the next section, “Controlling License Usage”.
Only one license is consumed per simulation session no matter how many VIP models are instantiate
the design.
2.3.3 Controlling License Usage

To limit the type of licenses that Synopsys VIP uses, define the DW_LICENSE_OVERRIDE environment
variable. The general form is:
% setenv DW_LICENSE_OVERRIDE “feature1 feature2 ...”
When this variable is set, VIP licensing behavior is as follows:
❖ Only the features specified in this list are used for licensing VIP.
❖ If more than one feature is specified, the order for acquiring a license is the same as what is
documented in “License Features for VIP”. Ranking features or changing the checkout request
is not supported.
SolvNet
❖ 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.
2.3.4 License Polling

If you request a license and none are available, license polling allows your request to exist until a lice
becomes available instead of exiting immediately. To control license polling, you use the
DW_WAIT_LICENSE environment variable as follows:
❖ To enable license polling, set the DW_WAIT_LICENSE environment variable to 1.
❖ To disable license polling, unset the DW_WAIT_LICENSE environment variable. By default, licen
polling is disabled.
2.3.5 Simulation License Suspension

All Synopsys/VCS Verification IP products support license suspension. Simulators that support license
suspension allow a model to check in its license token while the simulator is suspended, then check t
license token back out when the simulation is resumed.
2.4 Environment Variable and Path Settings

The following are environment variables and path settings required by the AMBA 3 AXI Verification IP
verification models:
❖ DESIGNWARE_HOME – The absolute path to where the models are installed.
❖ SNPSLMD_LICENSE_FILE – The absolute path to a file that contains the license keys for Vera an
Synopsys Common Licensing software, or the port@host reference to this file.
❖ LM_LICENSE_FILE – The absolute path to a file that contains the license keys for your third-part
tools. Also, include the absolute path to the third party executable in your PATH variable.
2.4.1 Simulator-Specific Settings

Your simulation environment and PATH variables must be set up as required to support your simulato
Additionally, if you use NC-Verilog or NC-VHDL, make the following additional settings:
SolvNet
❖ CDS_INST_DIR: Set this variable to the NC-Verilog or NC-VHDL installation directory.

❖ Include the following in your PATH environment variable:
$CDS_INST_DIR/tools/bin
2.5 Determining Your Model Version

The following steps tell you how to check the version of the models you are using.
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/
2.6 Setting Up the AXI VIP Models

After installing the AXI VIP models, follow these procedures to prepare for using the models.
❖ “Creating a Design Directory” on page26
❖ “Running dw_vip_setup” on page27
2.6.1 Creating a Design Directory

You must use dw_vip_setup to copy all necessary files to a user-specified design directory, or to the c
working directory when no design directory is specified. The design directory has a testbench configu
and can contain example testbenches provided by Synopsys.
The design directory includes:
❖ A design configuration file – A database of all models being used for this testbench configuratio
This file also tracks the VMT library. The dw_vip_setup program can read this database to rebu
recreate a design setup.
You are not allowed to modify the design configuration file.

Note
❖ 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
❖ 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 Running dw_vip_setup

In order to use a AXI VIP model, you must run dw_vip_setup. The setup program performs the followin
operations:
❖ Builds all required library files.
❖ Adds or removes models from a design.
❖ Retrieves individual AXI model or system testbenches.
This section details dw_vip_setup usage:
❖ Environment Variables
❖ Invocation
❖ Usage Examples
2.6.2.1 Environment Variables

Before running dw_vip_setup, the following environment variables must be set:
❖ DESIGNWARE_HOME – Points to where the VIP models are installed.
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:
% dw_vip_setup [-p[ath]directory] switch \

(model [-v[ersion] latest|version_no]) …
or
% dw_vip_setup [-p[ath]directory] switch -m[odel_list] filename

[-p[ath]directory] The optional -path argument specifies the relative path to your design
directory. When omitted, dw_vip_setup uses the current working directory.
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.
switch The switch argument defines dw_vip_setup operation. Table2-2 on page 28

lists the switches and their applicable sub-switches.
SolvNet
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
Table2-2 Setup Program Switch Descriptions
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
Table2-2 Setup Program Switch Descriptions (Continued)
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.
-h[elp] Returns a list of valid dw_vip_setup switches and syntax.
2.6.2.3 Usage Examples

This section contains three usage examples, which cover common usage scenarios.
❖ “Getting Installation or Design Information”
❖ “Adding Models” on page31
❖ “Removing Models” on page31
2.6.2.3.1 Getting Installation or Design Information

This example shows how to obtain information. The dw_vip_setup program command line is:
% $DESIGNWARE_HOME/bin/dw_vip_setup -i home
The setup program sends output to STDOUT that resembles the following:
#---------------------------------------------------------------------#
# DesignWare VIP Setup; Copyright(C) 1994-2010 Synopsys, Inc. #
#---------------------------------------------------------------------#
#---------------------------------------------------------------------#
# 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
# 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
#---------------------------------------------------------------------#
# The 'info' operation has successfully completed.
#---------------------------------------------------------------------#
2.6.2.4 Adding Models

The following example shows how to set up the AXI Master model:
% $DESIGNWARE_HOME/bin/dw_vip_setup -a axi_master_vera_vmt
The setup program does the following:
1. Creates an include directory where it copies all files in the a AXI Master model include director
include files in the AMBA AXI VIP suite, and the latest VMT library include files.
2. Creates the AXI MAster .vro file, AXI VIP suite libraries, and VMT libraries.
2.6.2.5 Removing Models

This example shows how to remove the models in the design directory at “/d/test2/daily”, based on t
model list in “del_list”. This command removes the models, but not the vro files or include files.
% $DESIGNWARE_HOME/bin/dw_vip_setup -p /d/test2/daily -r -m ~/scratch/del_list
2.6.2.6 Creating and Running a Simulation Script for an Example Testbench

The dw_vip_setup utility can create a simulation script to run an example testbench. This simulation s
can run the example testbench using various simulators depending on the parameters you pass to it.
Following is an example of how to create the simulation script for the system example testbench:
% $DESIGNWARE_HOME/bin/dw_vip_setup -path my_design -example axi_rvm_sys -svtb
Given this example, the simulation script resides at:
my_design/examples/axi_rvm_sys/sim_axi_rvm_sys
To simulate the system testbench you use the simulation script, which has the following form:
% path_to_simulation_script [-64] [-w] [-h] sim svtb
The arguments are as follows:
-64 – Optional. When using VCS (or VCS MX) with NTB on a 64-bit platform, specify this argume
to achieve a full 64-bit run. The default is a 32-bit run.
-w – Enables simulator waves interactively
-h – Displays command help
sim – Required. Specify any supported simulator. The choices are:
✦ vcsvlog – Synopsys VCS with a top-level testbench in Verilog
✦ vcsmxvlog – Synopsys VCS MX with a top-level testbench in Verilog (Unified Use Model)
✦ vcsvhdl – Synopsys VCS MX with a top-level testbench in VHDL
The following sample command runs the SystemVerilog VMM example with Verilog at the top level:
% my_design /examples/axi_rvm_sys/sim_axi_rvm_sys vcsvlog svtb
To run any example with SystemVerilog as control language, specify 'svtb' as the control language
Note argument to simulation script.
SolvNet
2.6.2.7 Viewing Qualified Simulator Switches

This section describes how to view the set of simulation switches used during product qualification. T
additional simulator switches may work, but are not qualified.
The set of qualified simulation switches have the following features:
❖ They are used during Synopsys qualification testing.
❖ They represent the minimal set to successfully run the simulation.
To view the qualified simulator switches:
1. Use the dw_vip_setup utility to create a simulation script for VIP example testbench. Make sure
the command matches your simulation environment.
The following command is appropriate when running VIP in VCS using OpenVera Native
Testbench capability. Specify an example testbench that is included in your VIP. Here, the
axi_rvm_sys example is used:
% dw_vip_setup -path <design_dir> -example axi_rvm_sys -ntb
For a full description of the dw_vip_setup command, see “Invocation” on page27
2. Change directory to the example:
% cd <design_dir>/examples/axi_rvm_sys
3. Run the simulation script that fits your simulation environment, and make sure to include
-n the
switch (described in “Creating and Running a Simulation Script for an Example Testbench”).
For this example, the command is:
% ./sim_axi_rvm_sys -n vcsvlog ntb
The output for this example is:
# rm -f simvcsntb
# vcs -l compile.log -q -sverilog -ntb_define NTB -ntb_opts rvm
-ntb_opts use_sigprop -ntb_opts vera_compat -ntb
+define+NTB+incdir+/project_x/design_dir/include/verilog+/project_x/design_dir/examples/
axi_rvm_sys/ntb -o simvcsntb -f hdl_files -ntb_incdir
/project_x/design_dir/include/vera+/project_x/design_dir/src/vera
# simvcsntb +rad +v2k +prof -l simulate.log run
2.6.3 Using Verification IP in Your Testbench

This AMBA 3 AXI Verification IP release can be used in testbenches. After running dw_vip_setup, follo
the procedure
2.6.3.1 SystemVerilog Users

Follow these steps to use the transactor models in a SystemVerilog environment:
1. Create a SystemVerilog program (testbench) that will control the model. For each transactor th
are using, include the appropriate interface file in the testbench:
design_dir/include/svtb/AxiInterconnectInterface.svi
design_dir/include/svtb/AxiMonitorInterface.svi
design_dir/include/svtb/AxiMasterInterface.svi
design_dir/include/svtb/AxiSlaveInterface.svi
design_dir/include/svtb/VmtDefines (common constants)
These files define the interface modport that the AXI transactors use for proper connections.
SolvNet
2. Do the following four things in your SystemVerilog testbench:

a. Pass a reference to the desired modport to connect to the transactor. Do this for each insta
each transactor you are using.
program AxiRvmSystemTest(AxiMonitorInterface.Monitor AxiMonitorBind,
AxiMasterInterface.Master AxiMasterBind, AxiSlaveInterface.Slave
AxiSlaveBind);
b. Import the entire contents of the model package for each transactor you are using. This ste
gives you access to all the elements of the transactor. For example:
import AxiMaster_rvm::*;
import AxiSlave_rvm::*;
import AxiMonitor_rvm::*;
import AxiInterconnect_rvm::*;
c. Connect to the interface when you instantiate and construct the transactor. For example:
dw_vip_axi_master_rvm master ;
dw_vip_axi_slave_rvm slave ;
dw_vip_axi_monitor_rvm monitor ;
...
master = new("AXI MASTER",AxiMasterBind,cfg_m1, gen.out_chan, master_outchan);
slave = new("AXI SLAVE", AxiSlaveBind, cfg_s1, slave_input_ch,
slave_output_ch, slave_activity_ch);
monitor = new("AXI MONITOR",AxiMonitorBind,cfg_sys,monitor_activity_ch);
...
d. Within your program's initial block, include a call to the setSystemClock method, as shown
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
wire [`DW_VIP_AXI_ARADDR_PORT_WIDTH-1:0] araddr_s0;

wire [`DW_VIP_AXI_ARLEN_PORT_WIDTH-1:0] arlen_s0;
...
//Master
AxiMasterInterface AxiMaster(
.aclk (aclk),
.aresetn (aresetn),
.arvalid_m0 (arvalid_m0),
...
);
//Slave
AxiSlaveInterface AxiSlave (
.aclk (aclk),
.aresetn (aresetn),
.awvalid (awvalid_m0),
...
);
AxiRvmSystemTest test(AxiMonitor.Monitor, AxiMaster.Master, AxiSlave.Slave);
...
initial begin
SystemClock = 0 ;
forever begin
#(simulation_cycle/2)
SystemClock = ~SystemClock ;
end
end
...
endmodule
b. Build the simulator executable and run the test:
For VCS, use the following:
Figure2-1 VCS Command for SystemVerilog Testbench with Verilog Top
${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
✧ 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:
Figure2-2 VCS MX Command for SystemVerilog Testbench with Verilog Top

vlogan -q -sverilog -ntb_define NTB -ntb_opts rvm -ntb_opts use_ntbpp -ntb_opts use_sigprop \
-ntb_opts add_dummy_bind -ntb_opts check -ntb_opts dw_vip -ntb_opts vera_compat +define+NTB
+incdir+$DESIGN_DIR/include/verilog+$DESIGN_DIR/include/svtb+$DESIGN_DIR/examples/axi_rvm_sys/svtb
+pkgdir+$DESIGN_DIR/include/svtb -f hdl_files -ntb_incdir
$DESIGN_DIR/include/vera+$DESIGNWARE_HOME/vip/vmt/latest/vera/src+$DESIGNWARE_HOME/vip/amba/latest/vera/src
SIGNWARE_HOME/vip/amba/latest/axi_master_vmt/vera/src+$DESIGNWARE_HOME/vip/amba/latest/axi_slave_vmt/vera/s
$DESIGNWARE_HOME/vip/amba/latest/axi_monitor_vmt/vera/src+$DESIGNWARE_HOME/vip/amba/latest/axi_master_rvm_v
vmt/vera/src+$DESIGNWARE_HOME/vip/amba/latest/axi_slave_rvm_vera_vmt/vera/src+$DESIGNWARE_HOME/vip/amba/lat
axi_monitor_rvm_vera_vmt/vera/src
vcs -ntb_opts use_sigprop -o simvcssvtb test_top
4. For a VHDL top testbench, use the following steps.

a. Create a Verilog wrapper for the SystemVerilog testbench. The following excerpt is from a
wrapper named axi_rvm_sys_tst_svtb_wrap.v:
ìnclude "AxiMonitorInterface.svi"
ìnclude "AxiSlaveInterface.svi"
ìnclude "AxiMasterInterface.svi"
...
module test_top(
aresetn,
aclk,
// 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
...
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;
ARCHITECTURE cfgtest OF test_top IS

CONSTANT AXI_CLOCK_PERIOD : time := 100 ns;
...
SIGNAL aclk : std_logic;
SIGNAL SystemClock : std_logic;
...
COMPONENT test_top
PORT (
aclk : in std_logic;
...
);
END COMPONENT;
BEGIN
u1 : test_top
port map (
aresetn=> aresetn
aclk=> aclk,
...
);
clkgen : PROCESS
BEGIN
SolvNet
if(testDone /= '1') then

...
END PROCESS clkgen;
...
c. Compile the simulation using the VCS MX Unified Usage Model, as follows:
i. Compile (or analyze) the SystemVerilog testbench using vlogan. The VIP's
DESIGNWARE_HOME source directories must be specified for the NTB code. The model
source files (.vrp) in the design directory must also be specified, accomplished by
$DESIGN_DIR/include/vera in the sample below. The VHDL packages for the models are
specified in using the pkg_files option and the NTB testbench is specified via the vlog_fil
option.
Figure2-3 Vlogan Command for SystemVerilog Testbench with VHDL Top
vlogan -q -sverilog +define+DW_VIP_USE_SVTB_WRAPPER -ntb_define NTB -ntb_opts rvm -ntb_opts

use_ntbpp -ntb_opts use_sigprop -ntb_opts add_dummy_bind -ntb_opts check -ntb_opts vera_compat -
ntb_opts dw_vip -ntb
+incdir+{$DESIGN_DIR}/include/verilog+{$DESIGN_DIR}/include/svtb+{$DESIGN_DIR}/examples/axi_rvm_sys
/svtb +pkgdir+{$DESIGN_DIR}/include/svtb -f pkg_files -f vlog_files -ntb_incdir
{$DESIGN_DIR}/include/vera+{$DESIGNWARE_HOME}/vip/vmt/latest/vera/src+{$DESIGNWARE_HOME}/vip/amba/l
atest/vera/src+{$DESIGNWARE_HOME}/vip/amba/latest/axi_monitor_vmt/vera/src+{$DESIGNWARE_HOME}/vip/a
mba/latest/axi_master_vmt/vera/src+{$DESIGNWARE_HOME}/vip/amba/latest/axi_slave_vmt/vera/src+{$DESI
GNWARE_HOME}/vip/amba/latest/axi_slave_vmt/vera/src+{$DESIGNWARE_HOME}/vip/amba/latest/axi_monitor_
rvm_vera_vmt/vera/src+{$DESIGNWARE_HOME}/vip/amba/latest/axi_master_rvm_vera_vmt/vera/src+{$DESIGNW
ARE_HOME}/vip/amba/latest/axi_slave_rvm_vera_vmt/vera/src
ii. Analyze the VHDL code. This includes all of the model and suite packages in addition to
VHDL top-level design:
Figure2-4 Vhdlan Command for SystemVerilog Testbench with VHDL Top
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:
Figure2-5 VCS MX Command for SystemVerilog Testbench with VHDL Top

vcs cfgtest -ntb_opts use_ntbpp -ntb_opts use_sigprop -ntb_opts rvm -ntb_opts
add_dummy_bind -ntb_opts vera_compat -ntb_opts check -ntb_opts dw_vip -o simv
2.7 Simulation Performance

To greatly enhance compilation and simulation performance and to avoid generating errors, specify t
maximum number of slaves and masters on the VCS compilation line. Add the following to your VCS
compilation directives to achieve enhanced performance:
SolvNet
-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.
2.7.1 Related Documentation

For the IEEE SystemVerilog standard, see IEEE Standard for SystemVerilog—Unified Hardware Design
Specification, and Verification Language.
For an essential reference guide describing the SystemVerilog Verification Methodology, along with a
reference, see Verification Methodology Manual For SystemVerilog</i>, by Janick Bergeron [et al.], a
$VCS_HOME/doc/UserGuide/vmm_sv.pdf.
For details about SystemVerilog constructs that are supported by VCS, see SystemVerilog Testbench
Constructs</i>, at $VCS_HOME/doc/UserGuide/svtb.pdf.
SolvNet
Verification IP for AMBA AXI VMM User Guide Integration With VMM
3
Integration With VMM
3.1 Overview of VMM

The Verification Methodology Manual (VMM) for SystemVerilog is an object-oriented approach. It prov
a blueprint methodology so that testbench code is effectively organized for constrained random testi
resulting structure also supports directed testing, so it serves all verification needs. VMM consists of
major elements:
❖ Set of base classes
❖ Verification methodology
❖ Modeling approach
The guiding principles of the methodology are to:
❖ Emphasize constrained random verification
❖ Maximize reuse
❖ Minimize test-specific code
❖ Enable more testing with less code
The shift to object-oriented programming techniques, the dynamic nature of constrained random test
and the need to develop code efficiently are all encapsulated in the VMM approach. To achieve its go
VMM prescribes an overall testbench organization that impacts the way testbench code is written.
Here are some highlights of the VMM approach:
❖ Most of the code is dedicated to setting up dynamic processes in advance. Everything is alread
programmed by the time the test is started.
❖ Test conditions are controlled by constraints instead of procedural code.
❖ Tests react to significant events dynamically. For example, a testbench must be able to detect
of the testing sequence since the length of the sequence is not predefined.
❖ Checking mechanisms are dynamic. Scoreboards or other self-checking mechanisms store
information on-the-fly and sometimes perform all checks on-the-fly.
❖ Objects use base classes whenever possible to maximize reuse and guarantee interoperability
❖ A standard testbench sequence template is used (build-configure-execute-report). Each testbe
uses the template and fills in the details according to its needs.
❖ Orientation shifts from procedures and directed tests to objects, randomization, and constraint
SolvNet
Integration With VMM Verification IP for AMBA AXI VMM User Guide
3.1.1 Base Classes

In an object-oriented programming environment, a set of base classes form the foundation for the en
system. Base classes provide common functionality and structure. Because most objects will be deriv
from them, a well-architected set of base classes is essential to the end goal of an effective program
environment.
The SystemVerilog verification methodology (VMM) base classes are specifically designed for the VM
approach to verification. They provide common functionality and structure needed for simulation (suc
logging) and they support any sort of verification function.
The VIP classes are extended from these base classes, providing an actual implementation and
demonstrating that VMM is not simply a set of guidelines and recommendations. So, instead of writin
your own logging routine, you can reuse the vmm_log class. And, with inheritance, extension, and
polymorphism, many opportunities exist for customization.
Important VMM base classes used by VIP include:
❖ vmm_channel--object-based interface; connects elements in a verification environment
❖ vmm_data--base class for all data objects (such as transactions, configuration, and so on)
❖ vmm_xactor--base class for transactor models
❖ vmm_log--standard logging object
❖ vmm_env--base class for the verification environment that is built in the testbench
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
3.2 Online Reference Documentation

For a complete listing and description of all classes and members, refer to the HTML-based online
documentation at:
SolvNet
3.3 Benefits of VIP and VMM

3.3.0.1 Improved modularity
VMM promotes a layered testbench architecture and provides a standard object-based interface that
connects components within a test environment. Coupled with the natural encapsulation abilities of a
object-oriented language, improved modularity is a key element in any VMM system. Better modulari
simplifies development and reduces maintenance. VIP models provide both protocol functionality and
control features in a complete, self-contained package that fully supports the modular architecture of
and simplifies the development of VMM testbenches. This gives you a modular foundation layer over
which you can quickly build a robust testbench.
3.3.0.2 Efficiency of Abstraction

VMM is based on object oriented programming (OOP). VIP abstracts protocol transactions into objects
provides an object-based interface allowing the engineer to work in logical protocol terms without wo
about implementation details. With protocols becoming more complex, this abstraction is a big boost
dealing with the details of a standard protocol is time-consuming and does not add value to the end
product. Another benefit of the modular, layered approach allows the stacking of components to crea
complex systems. For example, a typical webcam transports video data stacked on top of the Ethern
protocol.
3.3.0.3 Rapid creation of complex tests

While modularity enables the construction of complex test infrastructures, constrained random verific
and efficiency of abstraction allow the easy development of complex tests. Tests that exercise differe
scenarios within a given set of constraints can easily be created. In encapsulating protocol functional
allows you to code with abstracted objects where creating tests for intricate and complex combinatio
transactions can be done quickly. These sequences are used to mirror real-world traffic, create stress
corner-case conditions, or simply cover a wide range of conditions. More conditions are created by si
letting the test run for a longer time.
3.3.0.4 Increased Reuse

Opportunities for reuse are pervasive when using VIP and VMM. VIP models are inherently reusable b
that all have the same look and feel, simplifying the integration of multiple components. The VMM
methodology is architected for maximum reuse and it fosters testbench code that maximizes reusabl
components. VMM even provides a template for a standard testbench flow which can be customized
specific needs. The base classes provide reuse through inheritance. Reuse is a central theme for VIP
VMM, enabling maximum leverage of this critical design concept.
3.4 VIP in an VMM Environment

Figure6 shows where the VIP fits into the VMM methodology. In the layered approach that is typical fo
VMM, VIP (light green) fits into the lower levels, which allows you to focus on higher levels of abstract
SolvNet
Figure3-1 VIP in VMM Architecture
Test
Layer Note: dashed lines (- - - -)
Tests represent VMM channels
Scenario
Layer Generators
Functional Coverage
Functional
Layer Transactor Self Check Checker
Command Driver Monitor

VIP Capabilities
Layer
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”
3.4.1 Sample Test Environment

VIP includes VMM elements that allow you to create reusable testbench objects to form data models,
transactors, generators, and tests. You can use callbacks to insert additional behavior in the testbenc
these elements, you can create a test environment that might resemble Figure7 below.
SolvNet
Figure3-2 Sample Test Environment
Port Model Configuration

System Port Model
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.
3.4.2 VMM Support in Verification IP

In VIP, VMM-compliant classes and attributes (members) are provided to represent protocol activity a
the characteristics of that activity. For example, a transaction object has members that might define
requestor ID, the payload size, routing, and so on. The definitions of these transaction objects, along
the channels that handle them, form the interface between testbench and VIP. To create traffic, a use
generates an object of the appropriate type and calls the put() task of the corresponding input chann
SolvNet
VIP includes transactor models that interact with an VMM testbench.
Figure3-3 Verification IP for VMM
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 VIP Objects

VIP defines several classes that were designed for a VMM environment. This section introduces the m
VIP objects, which define channels, configurations, transactions, and callbacks.
As mentioned earlier, the VIP classes extend base classes to handle the specific needs of the protoco
provide predefined constraints. The predefined constraints can be used “as is” to produce a wide ran
stimulus, or extended to create specific test conditions. For information about constraints, see “Cons
on page46.
When constructed, an object and its constraints are referred to as a factory object, or factory. Genera
factories to create streams of randomized objects, which is especially useful for generating transactio
Generators are discussed in “Generators” on page48 and factories are discussed in “Factories” on pa
The remainder of this section describes the following VIP objects:
❖ Channels
❖ Configuration Objects
❖ Transaction Objects
❖ Callbacks
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
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.
3.4.3.2 Configuration Objects

You configure VIP to fit your application. For this purpose, predefined configuration objects (extended
the vmm_data base class) are provided for use by transactors. The configuration objects support
randomization and constraints, as described in “Constraints” on page46.
The configuration objects are used by VIP transactors. All configuration objects sent through the trans
constructor must not be null and must be valid. If the object is not null, the constructor calls the is_va
method of the configuration object. If this method returns true(1), then the transactor continues the
construction; otherwise, a message is displayed and the simulation is halted.
You can specify a configuration object as an argument to the constructor for the transactor. Also, to r
the current configuration, you use the 'get_xactor_config_t' method. After the configuration object is
created, you can change it using the change_xactor_config method. When change_xactor_config is us
is_valid method ensures that the configuration object is valid. If it is not valid, the configuration is not
changed.
When a master or slave transactor is constructed, one of the arguments is a reference to the corresp
master or slave configuration. When a monitor or bus transactor is constructed, one of the arguments
reference to the AXI system configuration, which provides all the configuration information they requ
3.4.3.3 Transaction Objects

Transaction objects, which are extended from the vmm_data base class, define a unit of bus protocol
information that is passed across the bus. The attributes of transaction objects are public and are acc
directly for setting and getting values. The transaction object can represent the desired activity to be
simulated on the bus, or the actual bus activity that was monitored. A protocol may have several type
transaction objects, such as for different protocol layers.
The transaction objects support randomization and constraints, as described in “Constraints” on page
Transaction objects support the use of generators and factories (for more, see “Generators” on page
“Factories” on page50).
The AXI transaction objects are passed through the transactor channels and can be used to hold:
SolvNet
❖ A transaction request; for example:

✦ Master transactor gets dw_vip_axi_master_transaction from input channel
✦ Master transactor initiates transaction on bus
❖ A completed transaction trapped by the monitor; for example:
✦ Transaction completed on the bus
✦ Monitor transactor sends dw_vip_axi_monitor_transaction to the testbench
❖ A completed transaction, trapped by the master transactor; for example:
✦ Master transactor triggers notify at end of transaction
✦ Master transactor sends dw_vip_axi_master_transaction result to output channel
The payload for all transaction types are stored in byte arrays. All transaction payloads are stored in
endian. If the system is configured as big endian, the transaction data is byte swapped by the model.
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
❖ 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.3.5 Displaying VIP Objects

You can access a formatted presentation of the contents of a VIP transaction or configuration object.
is provided by the display() or psdisplay methods, which are provided with VMM base classes.
For some VIP objects that are extended from rvm_data, the formatting follows a mapping convention
numeric values. The resulting numerical base that is used relates to the data type. These relationship
shown in Table4.
Table3-1 Display Bases for Numeric Data
Data Type Display Base Example
integer (n) decimal 256
bit (b) binary 8‘b01101110
bit vector (bv) hexadecimal 32‘hdfedbedf
enum (en) string <alpha-numeric characters>
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
❖ 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
Figure3-4 Valid Ranges, Reasonable Constraints, and User-Defined Constraints
Valid Ranges Valid Ranges
Reasonable
Constraints
Valid Ranges Valid Ranges
Reasonable
Default Constraints
User-Defined Constraints
User-Defined
Constraints Constraints
❖ Valid range constraints:

✦ Provided with VIP
✦ Keep values within a range that the transactors can handle
✦ Are not tied to protocol limits
✦ On by default, and should not be turned off or modified
❖ Reasonable constraints:
✦ Provided with VIP
✦ Keep values within protocol limits (typically) to generate worthwhile
✦ In some cases, keep simulations to a reasonable length and size
✦ Defined to be “reasonable” by Synopsys (user can override)
✦ May result in conditions that are a subset of the protocol
✦ On by default and can be turned off or modified (user should review these constraints)
❖ User-defined constraints:
✦ Provide a way for you to define specific tests
✦ Constraints that lie outside of the valid ranges are not included during randomization
All constraints that are enabled are included in the simulation. The constraint solver resolves any con
SolvNet
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.
3.4.5.1 Generator Macros in VMM

There are numerous ways to code a random generator. As a recommended alternative, VMM provide
macros (vmm_atomic_gen and vmm_scenario_gen) that you can use to define a generator class. The
SolvNet
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
Figure3-5 Factories with VIP
class my_xact extends dw_vip_any_transaction {

... }
... factory1 Generator Transaction
factory1 = my_xact::new( ... ) Transaction
Transaction
... Transaction
factory2 = my_xact::new( ... ) Transaction
factory2
Input Channel
Pins
DW VIP
Transactor
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
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.
3.4.7.1 VMM Notify for Messages

Each registered message or notification has an additional notify identifier member. The name of the n
ID is the original message ID with a suffix of “_NOTIFY_ID”.
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
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)
3.4.8.1 Coverage Model

The predefined coverage model consists of numerous covergroups. Each covergroup defines bins in t
of coverpoints (signals, variables, and so on), cross coverpoints (optional), and sample events, all of w
are defined outside of the covergroup.
The predefined coverage model can be used without alteration or you can extend it. You can also cre
your own coverage model, either as an addition or as a replacement. Coverage data is provided via
callbacks that are applied to the data flowing through the monitor transactor.
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
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
3.5 AMBA 3 AXI Ports

3.5.1 AMBA 3 AXI Master Ports
Table3-2 AXI Master VIP Port Interface
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
Table3-2 AXI Master VIP Port Interface (Continued)
Reset
AWLOCK - Output Low [1:0] Gives additional information about the atomic
characteristics of the transfer.
AWCACHE - Output Low [3:0] Gives additional information about cacheable

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.
AWREADY High Input - 1 Write Address ready is used by a slave interface to

indicate the acceptance of an address.
AWSIDEBAND - Output - 64 Sideband signal on write address channel.
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.
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
ARCACHE - Output Low [3:0] Gives additional information about cacheable

ARPROT - Output Low [2:0] Gives protection unit information for the transaction.
SolvNet
Reset
ARID - Output Low [31:0] The identification tag for the address group of
signals.
ARREADY High Input - 1 Read Address ready is used by a slave interface to

indicate the acceptance of an address.
ARSIDEBAND - Output - 64 Sideband signal on read address channel.
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.
RSIDEBAND - Input - 64 Sideband signal on read data channel.
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
Reset
WREADY High Input - 1 The write ready signal is used to indicate if the slave
can accept the write data.
WSIDEBAND - Output - 64 Sideband signal on write data channel.
BVALID High Input - 1 Indicates that a valid buffered response is available.
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.
BSIDEBAND - Input - 64 Sideband signal on write response channel.
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
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
VHDL customers must connect this signal.
3.5.2 AMBA 3 AXI Slave Ports

Table3-3 Slave Port Descriptions
Port Direction Polarity Size Description
ACLK Input — 1 System Clock signal. All signals are sampled on the
rising edge of this clock.
ARESETN Input Low 1 System Reset signal.
SolvNet
Table3-3 Slave Port Descriptions (Continued)
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.
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
AWCACHE Input — [3:0] Cache Type bus. Gives information about cacheable
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.
AWREADY Output High 1 Write Address Ready signal. Used by a Slave

interface to indicate the acceptance of an address
and associated control signals.
AWSIDEBAND Input - 64 Sideband signal on write address channel.
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
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
ARCACHE Input — [3:0] Cache Type bus. Gives information about cacheable
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.
ARREADY Output High 1 Read Address Ready signal. Used by a Slave

interface to indicate the acceptance of an address
and associated control signals.
ARSIDEBAND Input - 64 Sideband signal on write address channel.
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
RREADY Input High 1 Read Ready signal. Indicates if the Master can accept
the read data and response information.
RSIDEBAND Output - 64 Sideband signal on read address channel.
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.
WSIDEBAND Output - 64 Sideband signal on write data channel.
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.
BSIDEBAND Output - 64 Sideband signal on write response channel.
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
SolvNet
CACTIVE Output Low 1 The current release does not support low power
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.
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.
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.
3.5.3 AMBA 3 AXI Bus Monitor Ports
Table3-4 Bus Monitor Port Interface
Config Width
Port Polarity Default Width (bits) Description
ACLK High NA NO 1 All the signals are sampled by the Monitor on

the rising edge of ACLK.
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.
AWVALID_<portID> High Low NO 1 Indicates address and control information are

valid.
SolvNet
Table3-4 Bus Monitor Port Interface (Continued)
Config Width
AWADDR_<portID> - NA YES 32, Initial address for a write transaction. May be

64 configured via the
DW_VIP_AXI_ADDR_WIDTH_PARAM
configuration parameter.
AWLEN_<portID> - NA NO 4, 5, 6, 7, Number of data transfers in write transaction.

8, 9, 10 By default only the four LSB bits are used in
line with the AMBA 3 AXI specification.
AWSIZE_<portID> - NA NO 3 Size of each write transaction.
AWBURST_<portID> - NA NO 2 Write burst type
AWLOCK_<portID> - NA NO 2 Write lock type.
AWCACHE_<portID> - NA NO 4 Write cache type.
AWPROT_<portID> - NA NO 3 Write protection type.
AWID_<portID> - NA YES 0-31 Identification tag for address channel.

Since the slave ID includes bits to identify the
source master, the slave ID width must always
be greater than the master ID width unless the
slave is setup with zero width.
AWREADY_<portID> High Low NO 1 Used by the slave interface to indicate

acceptance of write associated control signals.
ARVALID_<portID> High Low NO 1 Indicates write address and control information

are valid.
ARADDR_<portID> - NA YES 32, 64 Initial address for a transaction.
ARLEN_<portID> - NA NO 4, 5, 6, 7, Number of data transfers in read transaction.

ARSIZE_<portID> - NA NO 3 Size of each transfer in read transaction.
ARBURST_<portID> - NA NO 2 Read burst type.
ARLOCK_<portID> - NA NO 2 Read lock type.
ARCACHE_<portID> - NA NO 4 Read cache type.
ARPROT_<portID> - NA NO 3 Read protection type.
SolvNet
Config Width
ARID_<portID> - NA YES 0-31 Identification tag for address channel.

Unless the Slave is setup with a a width of zero,
the slave ID includes bits to identify the source
master, the slave ID width must always be
greater than the master ID width.
ARREADY_<portID> High Low NO 1 Used by slave interface to indicate acceptance

of read address and associated control signals.
RVALID_<portID> High Low NO 1 Indicates read data and response information

are available.
RLAST_<portID> High NA NO 1 Indicates the last data transfer in a read burst.
RDATA_<portID> - NA YES 2n where Read data bus. May be configured to be 8, 16,

n is in 32, 64, 128, 256, 512, or 1024.
[3..10]
RRESP_<portID> - NA NO 2 Indicates if read data is valid.
RID_<portID> - NA YES 0-31 Identification tag for read channel.

(master)
0-31
(slave)
RREADY_<portID> High Low NO 1 Used by master interface to indicate

acceptance of read data and response
information.
WVALID_<portID> High Low NO 1 Indicates that write data is available.
WLAST_<portID> High NA NO 1 Indicates the last data transfer in a write burst.
WDATA_<portID> - NA YES 2n where Write data bus. May be configured to be 8, 16,

n is in 32, 64, 128, 256, 512, or 1024.
[3..10]
WSTRB_<portID> - NA YES 2n where Strobe for write data bus. Configured to be

n is in consistent with WDATA width.
[0..7]
WID_<portID> - NA YES 0-31 Identification tag for write channel.

(master)
0-31
(slave)
WREADY_<portID> High Low NO 1 Used by slave interface to indicate acceptance

of write data.
SolvNet
Config Width
BVALID_<portID> High Low NO 1 Indicates write response info is available.
BRESP_<portID> - NA NO 2 Indicates if the write data has been

successfully accepted.
BID_<portID> - NA YES 0-31 Identification tag for write response channel.

(master)
0-31
(slave)
BREADY_<portID> High Low NO 1 Used by master interface to indicate

acceptance of response information.
power mode. Low power mode be will
supported in future releases. This signal is
currently inactive.
power mode. Low power mode will be
currently inactive.
currently inactive.
3.5.4 AMBA 3 AXI Port Monitor Ports
Table3-5 Monitor Port Interface
Config Width
ACLK High NA NO 1 All the signals are sampled by the Monitor on

the rising edge of ACLK.
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.
AWVALID High Low NO 1 Indicates address and control information are

valid.
SolvNet
Table3-5 Monitor Port Interface (Continued)
Config Width
AWADDR - NA YES 32, Initial address for a write transaction. May be

64 configured via the
DW_VIP_AXI_ADDR_WIDTH_PARAM
configuration parameter.
AWLEN - NA NO 4 ,5, 6, 7, Number of data transfers in write transaction.

AWSIZE - NA NO 3 Size of each write transaction.
AWBURST - NA NO 2 Write burst type.
AWLOCK - NA NO 2 Write lock type.
AWCACHE - NA NO 4 Write cache type.
AWPROT - NA NO 3 Write protection type.
AWID - NA YES 0-31 Identification tag for address channel.

Since the slave ID includes bits to identify the
source master, the slave ID width must always
be greater than the master ID width unless the
slave is setup with zero width.
AWREADY High Low NO 1 Used by the slave interface to indicate

acceptance of write associated control signals.
ARVALID High Low NO 1 Indicates write address and control information

are valid.
ARADDR - NA YES 32, 64 Initial address for a transaction.
ARLEN - NA NO 4, 5, 6, 7, Number of data transfers in read transaction.

ARSIZE - NA NO 3 Size of each transfer in read transaction.
ARBURST - NA NO 2 Read burst type.
ARLOCK - NA NO 2 Read lock type.
ARCACHE - NA NO 4 Read cache type.
ARPROT - NA NO 3 Read protection type.
SolvNet
Config Width
ARID - NA YES 0-31 Identification tag for address channel.

Unless the Slave is setup with a a width of zero,
the slave ID includes bits to identify the source
master, the slave ID width must always be
greater than the master ID width.
ARREADY High Low NO 1 Used by slave interface to indicate acceptance

of read address and associated control signals.
RVALID High Low NO 1 Indicates read data and response information

are available.
RLAST High NA NO 1 Indicates the last data transfer in a read burst.
RDATA - NA YES 2n where Read data bus. May be configured to be 8, 16,

n is in 32, 64, 128, 256, 512, or 1024.
[3..10]
RRESP - NA NO 2 Indicates if read data is valid.
RID - NA YES 0-31 Identification tag for read channel.

(master)
0-31
(slave)
RREADY High Low NO 1 Used by master interface to indicate

acceptance of read data and response
information.
WVALID High Low NO 1 Indicates that write data is available.
WLAST High NA NO 1 Indicates the last data transfer in a write burst.
WDATA - NA YES 2n where Write data bus. May be configured to be 8, 16,

n is in 32, 64, 128, 256, 512, or 1024.
[3..10]
WSTRB - NA YES 2n where Strobe for write data bus. Configured to be

n is in consistent with WDATA width.
[0..7]
WID - NA YES 0-31 Identification tag for write channel.

(master)
0-31
(slave)
WREADY High Low NO 1 Used by slave interface to indicate acceptance

of write data.
SolvNet
Config Width
BVALID High Low NO 1 Indicates write response info is available.
BRESP - NA NO 2 Indicates if the write data has been

BID - NA YES 0-31 Identification tag for write response channel.

(master)
0-31
(slave)
BREADY High Low NO 1 Used by master interface to indicate

acceptance of response information.
power mode. Low power mode be will
currently inactive.
currently inactive.
currently inactive.
SolvNet
3.5.5 AMBA 3 AXI Interconnect Ports

Table3-6 Interconnect Port Descriptions
Master Slave Config

Port Direction Direction Polarity Width Size Description
Global Signals
ACLK Input N/A High No 1 System Clock signal. All

signals are sampled on the
rising edge of this clock.
ARESETN Input N/A Low No 1 System Reset signal. The

ARESETN signal must be
asserted before the
Interconnect model will start
operating.
Write Address Channel Signals
AWVALID_<portID> Input Output — No 1 Write Address Valid signal.

When high, indicates that the
write address and control
information is valid.
AWADDR_<portID> Input Output — Yes 32, 64 Write Address bus. Gives the
initial address of a burst
transaction.
AWLEN_<portID> Input Output — No 4, 5, 6, Burst Length bus. Gives the

7, 8, exact number of transfers in a
9,10 burst.
AWSIZE_<portID> Input Output — No 3 Burst Size bus. Gives the size

of each transfer in the burst.
AWBURST_<portID> Input Output — No 2 Burst Type bus.

AWLOCK_<portID> Input Output — No 2 Lock Type bus. Gives
information about atomic
AWCACHE_<portID> Input Output — No 3 Cache Type bus. Gives

information about cacheable
AWPROT_<portID> Input Output — No 2 Protection Type bus. Indicates

the protection level.
AWID_<portID> Input Output — Yes Master: Write Address ID bus. The

0..31 identification tag for the Write
Slave: Address group of signals.
0...31
AWSIDEBAND_ Input Output - No 64 Sideband signal on write
<portID> address channel.
SolvNet
Table3-6 Interconnect Port Descriptions (Continued)
Master Slave Config

AWREADY_<portID> Output Input High No 1 Write Address Ready signal.

Used by a Slave interface to
indicate the acceptance of an
address and associated
control signals.
Write Data Channel Signals
WVALID_<portID> Input Output High No 1 Write Valid bus. Indicates that

valid write data and strobes
are available.
WLAST_<portID> Input Output High No 1 Write Last bus. Indicates the

last data transfer in a write
burst.
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)].
WID_<portID> Input Output — Yes Master: Write ID bus. The identification

0..31 tag for the write data group of
Slave: signals.
0..31
WSIDEBAND_ Input Output - No 64 Sideband signal on write data

<portID> channel.
WREADY_<portID> Output Input High No 1 Write Ready signal. Indicates

if the Slave can accept the
write data.
Write Response Channel Signals
BVALID_<portID> Output Input High No 1 Response Valid signal.

Indicates that a valid buffered
response is available.
SolvNet
Master Slave Config

BRESP_<portID> Output Input — No 2 Write Response bus. Indicates

if the write data has been
BID_<portID> Output Input — Yes Master: Response ID bus. The

0..31 identification tag for the
Slave: buffered response group of
0..31 signals.
BSIDEBAND_ Input Output - No 64 Sideband signal on write

<portID> response channel.
BREADY_<portID> Input Output High No 1 Response Ready signal.

Indicates if the Master can
accept the response
information.
Read Address Channel Signals
ARVALID_<portID> Input Output High No 1 Read Address Valid signal.

When high, indicates that the
read address and control
information is valid.
ARADDR_<portID> Input Output — Yes 32, 64 Read Address bus. Gives the
initial address of a burst
transaction.
ARLEN_<portID> Input Output — No 4, 5, 6, Burst Length bus. Gives the

7, 8, 9, exact number of transfers in a
10 burst.
ARSIZE_<portID> Input Output — No 3 Burst Size bus. Gives the size

of each transfer in the burst.
ARBURST_<portID> Input Output — No 2 Burst Type bus.

ARLOCK_<portID> Input Output — No 2 Lock Type bus. Gives
information about atomic
ARCACHE_<portID> Input Output — No 3 Cache Type bus. Gives

information about cacheable
ARPROT_<portID> Input Output — No 2 Protection Type bus. Indicates

the protection level.
SolvNet
Master Slave Config

ARID_<portID> Input Output — Yes Master: Read Address ID bus.

0..31
Slave:
0..31
ARSIDEBAND_ Input Output - No 64 Sideband signal on read

ARREADY_<portID> Output Input High No 1 Read Address Ready signal.

Used by a Slave interface to
indicate the acceptance of an
address and associated
control signals.
Read Data Channel Signals
RVALID_<portID> Output Input High No 1 Read Valid signal. Indicates

that the required read data is
available and the read transfer
may complete.
RLAST_<portID> Output Input High No 1 Read Last signal. Indicates the

last data transfer in a read
burst.
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.
RID_<portID> Output Input — Yes Master: Read ID bus.

0..31
Slave:
0..31
RREADY_<portID> Input Output High No 1 Read Ready signal. Indicates

if the Master can accept the
read data and response
information.
RSIDEBAND_ Input Output - No 64 Sideband signal on read

SolvNet
3.6 AMBA 3 AXI VIP VMM Features

To connect a VMM testbench to the master, slave, interconnect, or monitor models, you use a VMM
transactor representing the base protocol model. The transactor models are as follows:
❖ axi_master_rvm_vera_vmt
❖ axi_slave_rvm_vera_vmt
❖ axi_interconnect_rvm_vera_vmt
❖ axi_monitor_rvm_vera_vmt
❖ axi_port_monitor_rvm_vera_vmt
These transactor models provide the following capabilities:
❖ Support for basic VMM control methods
✦ VMM methods: start_xactor, stop_xactor, and reset_xactor
✦ Stop/start support limited to channel activity
✧ Support for pre channel put actions
✧ Callback stored with the transactor
✧ Support for the VMM factory via activity/output channel
✦ Factory can be provided in constructor
✦ The factory class's allocate will be called when model generates channel transaction.
✦ Supported only for transactors with activity and/or output channel
✦ Support for stop_xactor/start_xactor
❖ Support for configuration objects
✦ Configuration can be provided in the constructor
✦ VIP functions change_xactor_config and get_xactor_config_t member
❖ Support for input via interface channels
✦ Supported by master transactor
✦ Supported by slave transactor
✦ NOT supported by transactor for interconnect or monitor
✦ Support for post channel get actions
✧ Via callback stored with transactor
❖ Support for VMM 'ENDED' notification
✦ When input requests complete, notification sent via VMM
✦ Supported by master transactor model
✦ Completion of requests sent in on input channel
✦ NOT supported by transactor model for interconnect, monitor, or slave
❖ Support for output via interface channel
✦ Done in response to internal model events
✦ Generates channel transactions
SolvNet
✦ Supported by master, slave, and monitor transactor models

✦ NOT supported by interconnect transactor model
✦ Support for pre channel put actions
✧ Via callback stored with transactor model
❖ Support for factories via transactor model activity/output channel
✦ Factory can be provided in constructor
✦ The factory class's allocate will be called when model generates channel transaction.
✦ Supported only for transactor models with activity and/or output channel
❖ Transactor model automatically instantiates models
❖ Support for functional coverage in an VMM environment, including:
✦ User defined coverage relative to any channel/transaction in any of the transactor models
✦ User defined coverage relative to special events (provided for monitor transactor model on
✦ Predefined default coverage model for channels/transactions and special events (provided
monitor transactor model only)
❖ Extended protocol behaviors. Device transactors allow you to go beyond the 16 transfer limit a
by the protocol. In addition, transactor models support sideband signals for all buses
❖ Port Monitor allows you to monitor any one port.
The AMBA 3 AXI transactor contains a separate class transactor model for the master, slave, intercon
and monitor models which are derived from vmm_xactor. The classes that the AXI Verification IP
implements for VMM are listed in Table10, along with the base VMM class from which they were deriv
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
AXI VMM Class Base Class
VMM Model Transactor Classes
dw_vip_axi_interconnect_rvm -- Defines channels, transactions, and configuration vmm_xactor

data objects allowing a user to interface their testbench to the Synopsys AMBA 3 AXI
Interconnect Verification IP. For usage information, refer to “Interconnect Transactor and
Bus Architectures” on page97.
dw_vip_axi_master_rvm -- Defines channels, transactions, and configuration data vmm_xactor

objects allowing a user to interface their testbench to the Synopsys AMBA 3 AXI Master
Verification IP. For usage information, refer to “Master Transactor” on page76.
SolvNet
Table3-7 Summary of VMM Class Interfaces (Continued)
dw_vip_axi_monitor_rvm -- Defines channels, transactions, and configuration data vmm_xactor

objects allowing a user to interface their testbench to the Synopsys AMBA 3 AXI Monitor
Verification IP. For usage information, refer to “Monitor Transactors” on page80.
dw_vip_axi_slave_rvm -- Defines channels, transactions, and configuration data vmm_xactor

objects allowing a user to interface their testbench to the Synopsys AMBA 3 AXI Slave
Verification IP. For usage information, refer to “Slave Transactor” on page77.
dw_vip_axi_port_monitor_rvm-- Defines channels, transactions, and configuration vmm_xactor

data objects allowing a user to interface their testbench to the Synopsys AMBA 3 AXI
Port Monitor Verification IP.
VMM Channel Classes
dw_vip_axi_master_channel, dw_vip_slave_channel, dw_vip_monitor_channel -- vmm_channel

An extension of the vmm_channel class. These classes provides a channel interface
that operates with transaction objects. Refer to the section “Channels” on page99 for
additional information.
dw_vip_axi_master_channel, dw_vip_slave_channel, dw_vip_monitor_channel -- vmm_channel

An extension of the vmm_channel class. These classes provides a channel interface
that operates with transaction objects. Refer to the section “Channels” on page99 for
additional information.
VMM Configuration Classes
dw_vip_axi_port_model_configuration -- A class for configuring the port vmm_data

characteristics of an AMBA 3 AXI model. For usage information, refer to “VMM
Configuration Classes” on page102“.
dw_vip_axi_system_model_configuration -- A class for configuring the system vmm_data

characteristics of an AMBA 3 AXI model. This class also has sub-classes for defining
arbitration and memory maps. For usage information, refer to “VMM Configuration
Classes” on page102“.
dw_vip_axi_bus_architecture_configuration -- A class to create and change the bus vmm_data

architecture of the testbench. For usage information, refer to “Bus Architectures and
Arbitration” on page99.
VMM Transaction Classes
dw_vip_axi_master_transaction -- A class for implementing master transactions. For vmm_data

usage information, refer to “VMM Transaction Classes” on page109.
dw_vip_axi_slave_resp_transaction -- A class for implementing slave responses. For vmm_data

dw_vip_axi_monitor_transaction -- A class for implementing monitor transactions. For vmm_data

dw_vip_axi_port_monitor_transaction -- Transaction class for the port monitor. vmm_data
SolvNet
Table3-7 Summary of VMM Class Interfaces (Continued)
dw_vip_master_extended_transaction -- This class implements extended features dw_vip_axi_master_trans

which are not part of the AMBA 3AXI bus protocol specification. This class supports action
more than 16 transfers per transaction and sideband signals on all buses. Refer to
“Extended Master and Slave Transaction Classes for Protocol Enhancements” on
page110 for additional information.
dw_vip_axi_slave_extended_resp_transaction -- This class implements extended dw_vip_axi_slave_resp_tr

features which are not part of the AMBA 3AXI bus protocol specification. This class ansaction
supports more than 16 transfers per transaction and sideband signals on all buses.
Refer to “Extended Master and Slave Transaction Classes for Protocol Enhancements”
on page110 for additional information.
VMM Callback Classes
dw_vip_axi_master_rvm_callbacks, dw_vip_axi_slave_rvm_callbacks, vmm_xactor_callbacks

dw_vip_axi_monitor_rvm_callbacks, dw_vip_axi_interconnect_rvm_callbacks --
Callback classes for each transactor. Refer to “Transactor Model Callbacks” on page101
VMM Master Status Classes
dw_vip_axi_master_status -- A class which communicates the end of a transaction vmm_data

and its status. For more information, refer to “Master Transactor” on page76.
VMM AXI Monitor Coverage Classes
dw_vip_axi_monitor_error_cov -- Defines coverage attributes. Refer to “VMM Monitor vmm_data

Interface Coverage” on page132 for additional information.
dw_vip_axi_monitor_flow_cov -- Defines coverage attributes. Refer to “VMM Monitor vmm_data

Interface Coverage” on page132 for additional information.
dw_vip_axi_monitor_def_cov_callbacks -- Callback class used for coverage vmm_xactor_callbacks

collection. Refer to “VMM Monitor Interface Coverage” on page132 for additional
information.
3.6.2 Instantiating the Verification Models

Calling the new() method of a model’s transactor will automatically instantiate a model of the same t
the interface. For example, dw_vip_axi_master_rvm call to new will create one instance of AxiMaster.
model handle can be obtained from the transactor either by direct access to the m_model attribute (i
case it must be cast to the type of model), or by using the transactor’s getModel() method, which retu
specific model type for each interface. For example, dw_vip_axi_master_rvm::getModel() returns type
AxiMaster.
SolvNet
3.6.3 Master Transactor

The class that implements the transactor model for the master VIP is called dw_vip_axi_master_rvm a
derived from vmm_xactor. The master transactor model supports the basic VMM control methods alo
with the configuration capabilities. It does not support the activity channel, but it does support the inp
and output channels. The activity channel provides a mechanism for watching activity on the bus. It i
to convey transaction buffers to the user testbench.
The usage model for the master channels is straight forward. The input channel is used to initiate
transactions, the output channel is used to retrieve transaction results.
The master input channel expects transactions of type dw_vip_axi_master_transaction. The data in th
transaction is transferred to a model buffer. After loading the buffer the transactor model makes a ca
'send_xact', queuing the transaction for transmission.
The constructor for the dw_vip_axi_master_rvm transactor model takes a required instance name, po
object and configuration object and up to three optional arguments:
function new (string sInstName, AxiMasterPort oPort,
dw_vip_axi_port_model_configuration oVipCfg,
dw_vip_axi_master_transaction_channel oInputChannel = null,
dw_vip_axi_master_transaction_channel oOutputChannel = null,
dw_vip_axi_master_transaction oOutputFactory = null);
Note the following:
❖ The oOutputFactory object must be extended from the dw_vip_axi_master_transaction class.
❖ oVipCfg and oInputChannel are required in the constructor for the transactor model.
❖ If the oOutputChannel is not provided, then the transactor model will not create a default chan
In addition, it will not output any results that would normally be sent on that channel.
❖ If the oOutputFactory object is not provided, then the master transactor model will use
dw_vip_axi_master_transaction type objects to send through the oOutputChannel if present.
❖ If the oInputChannel is created by default, then the handle to it can be obtained through the
transactor model public member m_oInputChannel.
If the constructor is provided for an oOutputFactory object, then the transactor model will call the allo
method which must be implemented by the extended factory class to create a new object. The transa
model will populate the values corresponding to the dw_vip_axi_master_transaction attributes, and th
send the object through the output channel.
The master transactor model also generates an ENDED notification for transactions coming in via the
channel. The following could be used to wait for the ENDED notification on the 'oMasterXactWr'
transaction sent in via the master transactor model input channel.
void’(oMasterXactWr.notify.wait_for(vmm_data::ENDED));
Only the AXI_MSGID_MASTER_SEND_XACT_COMPLETE results in the dw_vip_axi_master_transaction

object being placed in the output channel. Following are the events which result in an ENDED notifica
with a return status:
❖ AXI_MSGID_MASTER_SEND_XACT_COMPLETE
❖ AXI_MSGID_MASTER_FLUSH_XACT_IN_PROTOCOL_RESET
❖ AXI_MSGID_MISMATCH_XACCESS_CTRL
❖ AXI_MSGID_UNMATCHED_XACCESS_WR
SolvNet
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);
if ($cast(oStatus, oRvmData)) begin

case (oStatus.m_enStatus)
dw_vip_axi_master_status::MASTER_SEND_XACT_COMPLETE : $display("SNPS Return status
is MASTER_SEND_XACT_COMPLETE\n");
dw_vip_axi_master_status::MASTER_FLUSH_XACT_IN_PROTOCOL_RESET : $display("SNPS
Return status is MASTER_FLUSH_XACT_IN_PROTOCOL_RESET\n");
dw_vip_axi_master_status::MISMATCH_XACCESS_CTRL : $display("SNPS Return status is
MISMATCH_XACCESS_CTRL\n");
dw_vip_axi_master_status::UNMATCHED_XACCESS_WR : $display("SNPS Return status is
UNMATCHED_XACCESS_WR\n");
default : $display("Return status is unknown\n");
endcase
end
3.6.4 Slave Transactor

The class that implements the transactor model for the slave VIP is called dw_vip_axi_slave_rvm and
derived from vmm_xactor.
The output channel is used to notify the testbench that a transaction has arrived and that the model
know how to respond. The testbench must submit a response via the input channel in zero cycles. Th
model assumes a zero cycle reply. If the response is not returned within zero cycles, then the transac
model stops the simulation until the testbench provides a response. The testbench can also set
m_blSlaveAutoResponse=VMT_TRUE, in which case the slave model will automatically generate a ran
response, and the testbench need not provide a response. Details of this automatic random response
are in the HTML help pages.
The activity channel provides a mechanism for watching activity on the bus. It is used to convey tran
buffers to the user’s testbench.
SolvNet
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_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);
Note the following:

❖ The oOutputFactory and oActivityFactory objects must be extended from the
dw_vip_axi_slave_resp_transaction class.
❖ oVipCfg, oInputChannel, and oOutputChannel are required in the constructor for the transactor
model.
❖ If the oActivityChannel is not provided, then the slave transactor model will not create a defau
activity channel and will not output any results that would normally be sent on that channel.
❖ If the oOutputFactory or oActivityFactory object is not provided, then the slave transactor mod
will use dw_vip_axi_slave_resp_transaction type objects to send through the corresponding cha
if present.
❖ If the oInputChannel or oOutputChannel are created by default, then the handles to them can b
obtained through the transactor model public members m_oInputChannel and m_oOutputChan
If the constructor is provided for an oOutputFactory or oActivityFactory object, then the transactor mo
will call the allocate method which must be implemented by the extended factory class to create a ne
object. The VMM transactor model will populated the values corresponding to the
dw_vip_axi_slave_resp_transaction attributes, and then send the object through the corresponding ou
or activity channel.
3.6.5 Accessing non-VMM Models

Synopsys provides methods to access the underlying HDL verification model for each transactor. Refe
the next section for an example on how to use these methods.
❖ dw_vip_axi_slave_rvm::getAxiSlave() returns a reference to a base AXI slave model that does n
have RVM/VMM interface. This model should only be used for work around of RVM/VMM
interface limitations.
SolvNet
❖ dw_vip_axi_master_rvm::getAxiMaster() returns a reference to a base AXI master model that d

not have RVM/VMM interface. This model should only be used for work around of RVM/VMM
interface limitations.
❖ dw_vip_axi_interconnect_rvm::getAxiInterconnect() returns a reference to a base AXI interconn
model that does not have RVM/VMM interface. This model should only be used for work around
RVM/VMM interface limitations.
❖ dw_vip_axi_monitor_rvm::getAxiMonitor() returns a reference to a base AXI system monitor mo
that does not have RVM/VMM interface. This model should only be used for work around of
❖ dw_vip_axi_port_monitor_rvm::getAxiPortMonitor() returns a reference to a base AXI port moni
model that does not have RVM/VMM interface. This model should only be used for work around
3.6.6 Accessing Slave Memory in VMM

The VMM methodology does not currently define a mechanism for memory usage. This section will
describe how get/set/clear memory in the AXI Slave Verification IP models.
The first action to manipulate memory is to call a function to get a handle to the base models. For the
the call is getAxiSlave(). This handle should only be used for memory related calls. Any other use ma
problems with the model as there is a tight coupling between the VMM transactor and the base Slave
Next, you can call the base model commands related to memory like fill_mem or get_mem or set_me
using the handle you obtained in the previous step. The calls to change slave memory must take plac
the slave model has been started via the slave.start_xactor() call. Failure to do this will result in a run
error similar to the following:
*ERROR* [Failure] on axi_slave_vmt(test_top.vshell.AXI SLAVE) at 0secs:
Non configure command 'fill_mem' is not valid before 'start'
*ERROR* [Failure] on axi_slave_vmt(test_top.vshell.AXI SLAVE) at 0secs:
Non configure command 'set_mem' is not valid before 'start'
Following is example code to demonstrate the usage of the getModel call with some basic memory
commands. The handle is of type AxiSlave.
// Handle to the base model

AxiSlave slave_model;
// Start the Slave model

rvm_debug (this.log, "Starting Slave");
slave.start_xactor();
// 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);
// Wait for RESET

@ (posedge AxiMasterBind.$aresetn);
@ (posedge AxiMasterBind.$aclk);
SolvNet
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.
3.6.7 Monitor Transactors

The AXI Verification Suite contains two monitors. One monitor is called a port monitor and is used to t
transactions and coverage on one port only (you can have a Port Monitor on every port if you wish). T
second monitor is called the Bus Monitor and is intended to monitor an entire AXI design with an
interconnect. Following is a table comparing the capabilities of both monitors.
Table3-8 Comparison of Bus Monitor and Port Monitor Features
Bus Monitor
Feature (64 Ports) Port Monitor
Typical AXI system using multiple Masters and Slaves with an Interconnect
SolvNet
Table3-8 Comparison of Bus Monitor and Port Monitor Features (Continued)
Bus Monitor
Multiple instantiations X
Interfaces to only one port X
Must interface to all ports simultaneously X
Supports any number of ports (more than 64) by X

using multiple independent instances
Independent of bus architecture (multiple X

address/data channels)
Can track multiple-address, multiple-data X

architectures
Data Bus Widths
Data buses can be 2n bits wide, where n is in [3..10] X X
Strobe bus widths sized to match X X
ID ports configurable from 0 to 32 bits X X
Protocol Checking. Messages, Transaction Logs
Complete AXI Protocol checking X X
Checks on channel handshake ordering X X
Run time control of protocol checking X X
Transaction logs X X
Warning and error messages involving multiple X

ports
Warnings if slave side transfers do not match a X

master side transfer
Warnings if an address is out of range for the slave X

device (no memory map)
Tracks transactions to slave aliases X
Track master and slave ID's for error checking and X

coverage.
SolvNet
Table3-8 Comparison of Bus Monitor and Port Monitor Features (Continued)
Bus Monitor
Coverage
Predefined coverage groups and coverage bins X X
Activation and deactivation of selected coverage X X

bins
Cumulative coverage support X X
HTML and text report generation X X
Runtime access to coverage bin hit counts X X
Direct access to OpenVera coverage capabilities X X
Coverage report has unused Src/Dest states X
Coverage states that involve multiple ports X
Coverage states that require cross-port tracking X
Connection Features
No unused ports to tie off X
Requires a memory map X
Support for the AXI 'Low Power Interface'
3.6.7.1 Bus Monitor Transactor

The transactor model for the monitor is called dw_vip_axi_monitor_rvm. The monitor transactor mode
supports the basic VMM control methods along with the configuration capabilities. It does not support
either the input channel or the output channel. However, it does support the activity channel.
The constructor for the dw_vip_axi_monitor_rvm transactor model takes a required instance name, po
object, configuration object, and up to four optional parameters. The model must be an AxiMonitor m
the configuration must be a dw_vip_axi_system_model_configuration. The configuration parameter
requires a valid configuration object. The transaction must be a dw_vip_axi_monitor_transaction.
function new (string sInstName, AxiMonitorPort oPort,
dw_vip_axi_system_model_configuration oVipCfg,
dw_vip_axi_monitor_transaction_channel oActivityChannel = null,
dw_vip_axi_monitor_transaction oActivityFactory = null,
dw_vip_axi_monitor_error_cov oErrorCovFactory = null,
dw_vip_axi_monitor_flow_cov oFlowCovFactory = null);
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
❖ AXI_MSGID_END_OF_WR_XACT
This results in dw_vip_axi_transaction objects being placed in the activity channel.
3.6.7.2 Extended Debugging Error Messages.

The AXI_MSGID_ADDR_CONSISTENCY_INFO message will always be issued along with the
AXI_MSGID_ADDR_CONSISTENCY message. AXI_MSGID_ADDR_CONSISTENCY_INFO provides
additional information to help in debugging the cause of the AXI_MSGID_ADDR_CONSISTENCY
message.
This message is of type VMT_REPORT and will list the top 3 closest possible matches considering the
outstanding transactions initiated on the master port in which the AID or the ADDRESS differ. Also the
of the message will provide debugging hints.
The message AXI_MSGID_ADDR_CONSISTENCY_ INFO prints extended text. The extended text of the
AXI_MSGID_ADDR_CONSISTENCY_ INFO message will be issued when the monitor has been configure
for this capability. This extended text will contain a large string of information showing address and c
information of all outstanding transactions on all master ports. This could slow down simulation and s
must be used only when absolutely necessary. For quick debugging the
AXI_MSGID_ADDR_CONSISTENCY _INFO without extended text may be sufficient.
3.6.7.3 Enabling Extended Debugging Messages

The capability of extended debug messages from AXI_MSGID_ADDR_CONSISTENCY_INFO is available
to testbenches using the AXI VMM or RVM interfaces using one of the following methods:
1. By passing the runtime switch +rvm_log_default=debug or +vmm_log_default=debug.
2. Issue the following call:
monitor_rvm.log.set_verbosity(monitor_rvm.log.DEBUG_SEV);
3.6.7.4 Extended Message Format

With the AXI_MSGID_ADDR_CONSISTENCY _INFO message, brief information will be printed with
minimal formatting, and will show only the address and AID.
The outstanding transactions pending on master ports which are possible matches to the inconsisten
port transfer are:
Master Port# 2 AID = a ADDR = f0000
Master Port# 2 AID = b ADDR = f0000
Master Port# 2 AID = e ADDR = f0000
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
--------------------------------------------------------------------------------------------------
3.6.7.5 Port Monitor Transactor

The transactor for the Port Monitor is called dw_vip_axi_port_monitor_rvm. The constructor for the
dw_vip_axi_port_monitor_rvm transactor takes a required instance name, port object, a configuration
object and up to four optional parameters. The model must be a dw_vip_axi_port_monitor_rvm model
the configuration must be a dw_vip_axi_port_model_configuration. The configuration parameter requi
valid configuration object. The transaction must be a dw_vip_axi_port_monitor_transaction.
Following is an example of the transactor’s constructor:
function new (string sInstName, AxiPortMonitorPort oPort,
dw_vip_axi_port_monitor_transaction_channel oActivityChannel = null,
dw_vip_axi_port_monitor_transaction oActivityFactory = null,
dw_vip_axi_port_monitor_error_cov oErrorCovFactory = null,
dw_vip_axi_port_monitor_flow_cov oFlowCovFactory = null);
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
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
3.6.7.6 Configuring the Port Monitor

The Port Monitor transactor is configured by providing a dw_vip_axi_port_model_configuration object
the model's constructor. To construct a configuration object for the Port Monitor, first create a
dw_vip_axi_system_model_configuration object, and then initialize and configure any m_ovMstrCfgs[]
m_ovSlvCfgs[] objects for the individual masters and slaves.
Next create a dw_vip_axi_port_configuration object for each desired Port Monitor instance by making
copy of the m_ovMstrCfgs[] or m_ovSlvCfgs[] entry corresponding to the AXI bus to which the Port
Monitor instance will be connected. These objects are placed in the m_ovPortCfgs[] array of the syste
configuration object. Next, set the m_nPortId attribute of the m_ovPortCfgs[] object to the value of the
index where it was placed. Finally, create a dw_vip_axi_port_model_configuration object for each Port
Monitor by calling the createPortMdlCfg method of the system config object with a nPortType of
DW_VIP_AXI_MONITOR_PORT_CFG and an nIdx of the desired m_ovPortCfgs[] array index.
The createPortMdlCfg method is used to create the port model configuration.
SolvNet
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;
// Create configuration objects for the Port Monitor transactors.

dw_vip_axi_port_model_configuration oPortMonCfg0;
oPortMonCfg0=oSysCfg.createPortMdlCfg(DW_VIP_AXI_MONITOR_PORT_CFG,0);
// Create the Port Monitor model instances

dw_vip_axi_port_monitor_rvm oPortMonitorRvm0;
AxiPortMonitorPort oMonitorPort0 = new();
oPortMonitorRvm0 = new("PortMon0", oMonitorPort0, oPortMonCfg0);
.
The configuration object for the Port Monitor can also be created without first creating the master and
configuration objects. In this case, after creating and configuring the system configuration object, use
new() method to populate the m_ovPortCfgs[] array for the desired number of Port Monitor instances.
then configure each array object as required. Follow the remaining steps above to create the model
SolvNet
configuration objects using the createPortMdlCfg() method, and then use the configuration objects to
instantiate the Port Monitor instances.
3.6.8 Transaction Logging

AXI bus monitor and port monitor transactors support generation of transaction logs. The logging can
done in the following two ways:
❖ Transaction-wise logging
❖ Phase-wise logging
Enabling the transaction logging may impact simulation performance.

Attention
3.6.8.1 AXI Bus Monitor Transaction Logging

Use the following methods for creating transaction logging using the Bus Monitor:
❖ task dw_vip_axi_monitor_rvm :: open_log(logType, filename, mode). Open a file and associate
with a suite specific log type.
❖ task dw_vip_axi_monitor_rvm :: close_log(logType). Close the log associated with the log type.
❖ task dw_vip_axi_monitor_rvm :: enable_log(logType). Enable logging to the log file associated w
the log type.
❖ task dw_vip_axi_monitor_rvm :: disable_log(logType). Disable logging to the log file associated
with the log type.
Where, the logType specifies the type of the log generated by the models.
3.6.8.1.1 Bus Monitor Transaction-wise Logging

Transaction-wise logging logs an entire transaction and can generate three types of logs. Following a
possible log types, which can be specified to the argument logType:
❖ DW_VIP_LOG_TYPE_AXI_MONITOR_TRANS: Used as log type by AXI Bus monitor to create
transaction log. Both read and write transactions are logged when this log type is specified.
❖ DW_VIP_LOG_TYPE_AXI_MONITOR_WRITE_TRANS: Used as log type by AXI Bus monitor to
create transaction log. Only write transactions are logged when this log type is specified.
❖ DW_VIP_LOG_TYPE_AXI_MONITOR_READ_TRANS: Used as log type by AXI Bus monitor to
create transaction log. Only read transactions are logged when this log type is specified.
The following table shows the columns of a transaction log.
Table3-9 Transaction Log Content
Column Label Meaning
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
SolvNet
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.
ADDR Indicates the address of the transaction in hexadecimal format.
AID Indicates the transaction ID in hexadecimal format.
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
ASIZE Indicates the transaction size in bytes
ABURST Indicates the transaction burst type
ALOCK Indicates the transaction lock type
ACACHE Indicates the transaction cache type
APROT Indicates the transaction protection type
WSTRB/ The WSTRB/DATA Lane column represents the WSTRB (for

Date Lane [(datawitdh in bytes-1) to 0] write 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.
RESP Indicates the transaction response RRESP or BRESP
LAST Indicates whether WLAST or RLAST signal has been asserted

for the beat
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
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:
Figure3-6 Contents of a log for read transactions
The following figure shows the log of a write transaction captured by the AXI Bus Monitor:
SolvNet
Figure3-7 Contents of a log for write transactions
3.6.8.1.2 Bus Monitor Phase-wise Logging

In phase-wise transaction logging, each of the three phases: address, data, and response, is logged w
ready-valid handshake for the phase is complete. This is useful to view the interleaved or out of orde
transactions. It is possible to generate three types of transaction logs for phase-wise transactions by
specifying the following log types:
❖ DW_VIP_LOG_TYPE_AXI_MONITOR_PHASE_TRANS: When you specify this log type, both read
and write transactions are logged.
❖ DW_VIP_LOG_TYPE_AXI_MONITOR_WRITE_PHASE_TRANS: When you specify this log type,
only the write transactions are logged.
❖ DW_VIP_LOG_TYPE_AXI_MONITOR_READ_PHASE_TRANS: When you specify this log type,
only the read transactions are logged.
The following table describes the fields of a Bus monitor transaction log.
Table3-10 Bus Monitor Phase-wise Log Fields
Field Description
ID Indicates the transaction ID in hexadecimal format.
SolvNet
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
ADDR Indicates the address of the transaction in hexadecimal format. The

first address of any transaction is captured and the subsequent
addresses are calculated based on the size length and burst type.
Xfer Num Indicates the current transfer number.

For example, the first transfer in a transaction of ALEN=15 is
represented by 1/16, the second transfer is represented by 2/16 and
so on.
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
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.
RESP Indicates the transaction response as RRESP or BRESP.
LAST Indicates whether WLAST or RLAST signal has been asserted for
the beat.
ABURST Indicates the transaction burst type.
ASIZE Indicates the transaction size in bytes.
ALOCK Indicates the transaction lock type.
ACACHE Indicates the transaction cache type.
APROT Indicates the transaction protection type.
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
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.
Figure3-8 AXI Monitor Read-Write Transaction Phase-wise Logging Format
SolvNet
3.6.8.2 AXI Port Monitor Transaction Logging

Use the following methods for creating the transaction logging using the Port Monitor:
❖ task dw_vip_axi_port_monitor_rvm :: open_log(logType, filename, mode). Open a file and assoc
it with a suite specific log type.
❖ task dw_vip_axi_port_monitor_rvm :: close_log(logType). Close the log associated with the log t
❖ task dw_vip_axi_port_monitor_rvm :: enable_log(logType). Enable logging to the log file associa
with the log type.
❖ task dw_vip_axi_port_monitor_rvm :: disable_log(logType). Disable logging to the log file
associated with the log type.
The logType specifies the type of the log generated by the models.
3.6.8.2.1 Port Monitor Transaction-wise Logging

Transaction-wise logging logs an entire transaction and generates three types of logs. Following are t
possible log types, which can be specified to the argument logType:
❖ DW_VIP_LOG_TYPE_AXI_PORT_MONITOR_TRANS: Used as log type by AXI Port monitor to
create transaction log. Both read and write transactions are logged when this log type is specif
❖ DW_VIP_LOG_TYPE_AXI_PORT_MONITOR_WRITE_TRANS: Used as log type by AXI Port
monitor to create transaction log. Only write transactions are logged when this log type is spec
❖ DW_VIP_LOG_TYPE_AXI_PORT_MONITOR_READ_TRANS: Used as log type by AXI Port
monitor to create transaction log. Only read transactions are logged when this log type is spec
The following table shows the columns of a transaction log.
Table3-11 Port Monitor Transaction Log Fields
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.
ADDR Indicates the address of the transaction in hexadecimal format.
SolvNet
Table3-11 Port Monitor Transaction Log Fields
Field Description
AID Indicates the transaction ID in hexadecimal format.
64, 128, 256, 512 or 1024
ASIZE Indicates the transaction size in bytes
ABURST Indicates the transaction burst type
ALOCK Indicates the transaction lock type
ACACHE Indicates the transaction cache type
APROT Indicates the transaction protection type
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.
RESP Indicates the transaction response RRESP or BRESP
the beat
Following figures show the typical contents of log files for read and Write transactions captured by th
Monitor:
SolvNet
Figure3-9 Contents of a Log for Read Transactions
Figure3-10 Contents of a log for write transactions
SolvNet
3.6.8.2.2 Port Monitor Phase-wise Logging

In phase-wise transaction logging, each of the three phases: address, data, and response, is logged w
ready-valid handshake for the phase is complete. This is useful to view the interleaved or out of orde
transactions. It is possible to generate three types of transaction logs for phase-wise transactions by
specifying the following log types:
❖ DW_VIP_LOG_TYPE_AXI_PORT_MONITOR_PHASE_TRANS: When you specify this log type,
both read and write transactions are logged.
❖ DW_VIP_LOG_TYPE_AXI_PORT_MONITOR_WRITE_PHASE_TRANS: When you specify this log
type, only the write transactions are logged.
❖ DW_VIP_LOG_TYPE_AXI_PORT_MONITOR_READ_PHASE_TRANS: When you specify this log
type, only the read transactions are logged.
The following table describes the fields of a Bus Monitor transaction log.
Table3-12 Port Monitor Phase-wise Log Fields
Field Description
ID Indicates the transaction ID in hexadecimal format.
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
ADDR Indicates the address of the transaction in hexadecimal format. The

first address of any transaction is captured and the subsequent
addresses are calculated based on the size length and burst type.
Xfer Num Indicates the current transfer number.

For example, the first transfer in a transaction of ALEN=15 is
represented by 1/16, the second transfer is represented by 2/16 and
so on.
64, 128, 256, 512 or 1024.
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.
RESP Indicates the transaction response RRESP or BRESP.
SolvNet
Table3-12 Port Monitor Phase-wise Log Fields
Field Description
the beat.
ABURST Indicates the transaction burst type.
ASIZE Indicates the transaction size in bytes.
ALOCK Indicates the transaction lock type.
ACACHE Indicates the transaction cache type.
APROT Indicates the transaction protection type.
The following figure shows the log contents for a read/write phase-wise transaction captured by the A
Port Monitor.
Figure3-11 AXI Port Monitor Read/Write Transaction Phase-wise Logging Format
SolvNet
3.6.9 Interconnect Transactor and Bus Architectures

The transactor model for the interconnect model is called dw_vip_axi_interconnect_rvm. The construc
for the dw_vip_axi_interconnect_rvm transactor model takes an instance name, port object and a
configuration object. The constructor arguments must be of the types indicated below. The configura
parameter requires a valid configuration object.
function new (string sInstName, AxiInterconnectPort oPort,
dw_vip_axi_system_model_configuration oVipCfg);
3.6.9.1 Bus Architecture Configuration

The Interconnect transactor model supports the setting of user defined bus architecture. This is done
through the dw_vip_axi_bus_architecture_configuration class. The class supports the creation of pred
SASD, SAMD, and MAMD bus architectures. If you use a predefined bus architecture, the transactor m
will ensure the routing between the master and the default slave is correct. In addition, users can cre
customized bus architectures.
If a master is not attached to an address channel, then the master is not able to see the slave on this
channel. The read address and write address channels are independent to each other. The bus archit
a static configuration; that is, it can only be changed before start_xactor.
All masters and slaves are properly attached to predefined buses architectures (SASD, SAMD, and MA
after the member function allocate_buses is invoked. A user can use the detach_from_bus function to
remove given ports from certain buses, For example, you can make a given slave invisible to a maste
default bus architecture when using the dw_vip_axi_bus_architecture_configuration object is of type
DW_VIP_AXI_PREDEFINED_SASD. In this case, there is only one bus on each channel. The constructor
function new must pass in a valid master and slave count into this predefined architecture.
If a master generates an address that falls into a slave’s “invisible” address region, then the intercon
transactor model will route this request to the transactor model’s default slave, which in turn will issu
DECERR response. The interconnect uses the bus architecture to determine the visibility of master. T
Monitor transactor model uses the m_bvVisibleSlavesOnWriteCh and m_bvVisibleSlavesOnReadCh
members in the class dw_vip_axi_port_configuration to determine visibility.
Class dw_vip_axi_bus_architecture_configuration is derived from vmm_data type and supports the
following vmm_data calls:
❖ new
❖ psdisplay
❖ compare
❖ allocate
❖ copy
The byte_pack and byte_unpack are not supported.
The dw_vip_axi_bus_architecture_configuration object has the following member functions for creatin
predefined bus architectures or for creating fully customizable bus architectures:
❖ allocate_buses
❖ attach_to_bus
❖ detach_from_bus
❖ validate_bus_configuration
❖ getChannelBusesCfg
SolvNet
❖ 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
3.6.10 Setting a Bus Architecture Example

Following is an short example run-through of using bus architecture features of the transactor showin
creation of a MAMD architecture.
1. Create a system configuration object:
dw_vip_axi_system_model_configuration oSysCfg = new(log, nNumMaster, nNumSlave);
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:
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

DW_VIP_AXI_PREDEFINED_MAMD)== 1)
{ // User code. }
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.11 Bus Architectures and Arbitration

While the two classes dw_vip_axi_port_configuration and AxiArbSchemeCfg are constructed separate
they must be synchronized before the system configuration is sent to any transactor model. After you
bus architecture, then construct the arbitration scheme using the update function of
updateArbCfgFromBusArchCfg. The call will put all requesters on one bus into a low priority tier using
round robin arbitration. If the round-robin selection does not match the user’s preference, then the us
move the requester id to medium, or even the high priority tier.The is_valid member function will che
consistency between the bus architecture and the arbitration tier configuration.
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
❖ 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
Master Yes (optional) Yes (required) No
Monitor No No Yes (optional)
Slave Yes (required) Yes (required) Yes (optional)
Port Monitor No No Yes (optional)
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.
3.6.14 Support for Channel Pre/Post Actions

The transactor models support the definition of channel 'pre' and 'post' functions by the user. The de
methods are empty, but the user can extend the classes to provide their own definitions. Each transa
model provides methods only for the channels it supports. The transactor models use the 'pre' functio
prior to doing a channel put. It uses the 'post' functions after doing a channel get. The functions apply
different channels and are therefore named to identify the channels they apply to. They are:
❖ post_input_channel_get - called after transaction pulled from input channel, provided with hand
to transaction gotten from the channel
❖ pre_output_channel_put - called prior to sending transaction out on output channel, provided w
handle to transaction being put
❖ pre_activity_channel_put - called prior to sending transaction out on activity channel, provided
handle to transaction being put
SolvNet
3.6.15 Transactor Model Callbacks

In addition to the 'pre' and 'post' functions, the model transactor supports callbacks. The callback cla
model specific and require model specific argument types. Callback objects are registered with an int
using the interface’s append_callback() method. The default callback methods are empty, but the use
extend the callback classes to provide their own definitions for each model. Each callback class provi
methods only for the channels its model supports. The registered callback methods are called after th
interface’s 'pre' and 'post' methods are called.
The model specific callback classes are as follows:
class dw_vip_axi_master_rvm_callbacks extends vmm_xactor_callbacks {

virtual task post_input_channel_get(
dw_vip_axi_master_rvm oRvmModel,
dw_vip_axi_master_transaction oVipXact,
var bit drop );
virtual task pre_output_channel_put(
dw_vip_axi_master_rvm oRvmModel,
dw_vip_axi_master_transaction oVipXact,
var bit drop );
}endclass
class dw_vip_axi_slave_rvm_callbacks extends vmm_xactor_callbacks {

virtual task post_input_channel_get(
dw_vip_axi_slave_rvm oRvmModel,
dw_vip_axi_slave_resp_transaction oVipXact,
var bit drop );
virtual task pre_output_channel_put(
var bit drop );
virtual task pre_activity_channel_put(
var bit drop );
}endclass
class dw_vip_axi_monitor_rvm_callbacks extends vmm_xactor_callbacks {

dw_vip_axi_monitor_rvm oRvmModel,
dw_vip_axi_monitor_transaction oVipXact,
var bit drop );
}
class dw_vip_axi_interconnect_rvm_callbacks extends

vmm_xactor_callbacks {
// There are no basic in,out,activity channels for this model.
}endclass
class dw_vip_axi_master_rvm extends dw_vip_transactor_rvm {

protected task post_input_channel_get (
dw_vip_axi_master_transaction oVipXact, var bit drop );
protected task pre_output_channel_put (
SolvNet
dw_vip_axi_master_transaction oVipXact, var bit drop );

...
}endclass
class dw_vip_axi_slave_rvm extends dw_vip_transactor_rvm {

protected task post_input_channel_get (
dw_vip_axi_slave_resp_transaction oVipXact, var bit drop );
protected task pre_output_channel_put (
protected task pre_activity_channel_put (
...
}endclass
class dw_vip_axi_monitor_rvm extends dw_vip_transactor_rvm {

dw_vip_axi_monitor_transaction oVipXact, var bit drop );
...
}
class dw_vip_axi_port_monitor_rvm_callbacks extends rvm_xactor_callbacks {

dw_vip_axi_port_monitor_rvm oRvmModel,
dw_vip_axi_port_monitor_transaction oVipXact,
var bit drop )endclass;
...
}
class dw_vip_axi_port_monitor_rvm extends dw_vip_transactor_rvm {

dw_vip_axi_port_monitor_transaction oVipXact, var bit drop );
...
}endclass
class dw_vip_axi_interconnect_rvm extends dw_vip_transactor_rvm {

// There are no basic in,out,activity channels for this model.
}endclass
3.6.16 VMM Configuration Classes

Configuration objects convey to the VMM transactor model configuration information for the verificati
models. They can be controlled via randomization, and can be sent to the models at startup, or after
reset. They can be sent at anytime prior to start; that is, between the constructor call and the start, o
between a hard reset and the start.
The first opportunity for submitting a configuration is in the constructor for the transactor model. The
configuration object is just another parameter to the 'new' for the model.
Once the model is constructed, the configuration is provided to the model via the 'change_xactor_con
command on the model. This takes one parameter, the configuration object. The testbench can retrie
current configuration via the 'get_xactor_config_t' command. Note, this are VIP commands.
The previous interaction, and the commands supporting it, are described in more detail in the VMM
documentation. The VMM methodology requires that the configuration parameter passed to the comm
SolvNet
configuration commands is an vmm_data object. The models require that these vmm_data objects ar
AMBA 3 AXI specific configuration objects.
3.6.16.1 Configuration Classes

The VMM model interface’s system configuration is described via a small number of port and system
configuration classes. Once constructed, this system configuration can be distributed to the various V
model interfaces to insure a consistent interpretation of the system by the models.
Configuration objects also support randomization. The user is free to add their own constraints, but th
configuration classes also include valid_ranges constraints which limit the generated values to ones
acceptable to the models. The valid_ranges constraints are described later for the individual configur
Several configuration parameters play a role in single port models, as well as multiple port models. S
these are defined for every port in the multiple port models and require that the port be identified in
parameter name when applied to these multiple port models (for example,
DW_VIP_AXI_MASTER_0_ID_WIDTH_PARAM).
The single port model VMM verification IP transactor models, dw_vip_axi_master_rvm and
dw_vip_axi_slave_rvm, both support dw_vip_axi_port_model_configuration objects. They can be provid
in the dw_vip_axi_master_rvm and dw_vip_axi_slave_rvm constructors, or they can be sent into (or
retrieved from) these models using the change_xactor_config (or get_xactor_config_t) commands.
The multiple port model VMM transactor models, dw_vip_axi_interconnect_rvm and
dw_vip_axi_monitor_rvm, both support dw_vip_axi_system_model_configuration configuration objects
They can be provided in the dw_vip_axi_interconnect_rvm and dw_vip_axi_monitor_rvm constructors,
they can be sent into (or retrieved from) these models using the change_xactor_config (or
get_xactor_config_t) commands.
If a configuration object is not passed to interconnect and monitor VMM transactor models when VMM
interface is started, then the transactor model will check to see if the model has the necessary inform
operate: for example, master count, slave count, and memory map. If either of them has a count of z
a fatal error message will be generated by interface as follows:
"%s does not have necessary configurations, i.e. master count= %0d, slave count = %0d
and mem region count = %0d\n"
The first parameter is the model instance name.

Configuration objects use the vmm_log variable:
public vmm_log log
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 configu
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_port_model_configuration",
"class");
Access is through the public vmm_log log member of the class instance.
The remainder of this section provides an overview of the AXI configuration classes All of the configu
fields have corresponding configuration parameters described in the chapters on the master, slave, m
and interconnect. This document provides a mapping of the configuration fields to the corresponding
configuration parameters. Refer to the appropriate sections for explanations of the parameters.
SolvNet
3.6.16.2 Consistent Usage of Configuration Objects

The dw_vip_axi_system_model_configuration object is randomized first and then constructs the
dw_vip_axi_port_model_configuration. To insure the consistency, the
dw_vip_axi_port_model_configuration, the member m_oSysCfg the same reference a consistent syste
configuration.
If user changes or creates the dw_vip_axi_port_model_configuration for a model interface, then the
interconnect and monitor VMM interfaces will be aware of the change. This could result in lost data o
protocol errors. For example, changing the ID width could cause problems.
3.6.16.3 Configuration Enumerated types

The configuration object uses several enumerated types to hold configuration information. Types tha
used to specify bus configuration fields provide values that correspond to legal values allowed by the
AMBA 3 AXI Specification.
In addition to enumerated type specified by these tables, the global Boolean enumerated type declar
VMT is used. The Boolean enumerated type is
enum { VMT_BOOLEAN_FALSE, VMT_BOOLEAN_FALSE } VmtBooleanEnum
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;
Table13 shows a listing of the enumerated types.
Table3-14 Configuration Class dw_vip_axi_configuration Enumerated Types
Enumerated Type Name
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
Table3-14 Configuration Class dw_vip_axi_configuration Enumerated Types (Continued)
Enumerated Type Name
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
3.6.16.4 Port Configuration

Each port of the overall system is described via a dw_vip_axi_port_configuration object. All public
members in the configuration are randomizable except m_sName and log.
For complete reference on VMM model class libraries, refer to:
The dw_vip_axi_port_configuration object is a contained object, and is not sent to any models directly
included in a dw_vip_axi_system_model_configuration object, or a dw_vip_axi_port_model_configurati
object.
If the m_blNotifyXact attribute default changes to VMT_BOOLEAN_TRUE, a note message will be sent
the transactor model log file: Since activity channel is not null, m_blNotifyXact of AXI monitor's each p
configuration is turned VMT_BOOLEAN_TRUE automatically to let channel get object.
If the m_blNotifyXact attribute default changes to VMT_TRUE, a note message will be sent to the VMM
model log file. The AxiMonitor message is "Since activity channel is not null, m_blNotifyXact of AXI
monitor's each port configuration is turned VMT_TRUE automatically to let channel get object". The
AxiPortMonitor message is "Since activity channel is not null, m_blNotifyXact of AXI port monitor's po
configuration is turned VMT_TRUE automatically to let channel get object".
constructor log object is null, then a default vmm_log object is used which is shared among all config
local static vmm_log m_oSharedLog = new ("dw_vip_axi_port_configuration", "class");
SolvNet
3.6.16.5 reasonable_constraint_mode Method

This class provides a method for turning ON or OFF in one call all of the “reasonable” randomize
constraints. Note that “valid_ranges” constraint is not disabled.
Following is the method declaration:
virtual public function integer reasonable_constraint_mode(integer nOnOff);
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
3.6.16.6 System and Model Configuration

The overall system is described using a dw_vip_axi_system_model_configuration object. It includes
information on all of the ports, a memory map for all of the slave ports, and individual configuration
settings for the system as a whole.
new ( vmm_log log = null, integer nMstrCnt, integer nSlvCnt, VmtBooleanEnum
blUseDefaultMemmap = VMT_BOOLEAN_TRUE );
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.
constructor log object is null, then a default vmm_log object is used which is shared among all config
local static vmm_log m_oSharedLog = new ("dw_vip_axi_system_model_configuration",
"class");

constraints listed in. Note that “valid_ranges” constraint is not disabled.
For further details, refer to HTML-based help system at:
Following is the method declaration:
SolvNet
Example usage:
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.
3.6.16.8 Configuration Sub-Classes for Arbitration and Slave Memory

The configuration object has two classes for setting up arbitration and for setting up memory address
AxiArbSchemeCfg contains the information for arbitration. Each bus has three configurable tiers.
class AxiArbSchemeCfg
{
public AxiArbThreeTierCfg m_ovWriteAddrBusArbCfg[*];
public AxiArbThreeTierCfg m_ovReadAddrBusArbCfg[*];
public AxiArbThreeTierCfg m_ovWriteDataBusArbCfg[*];
funtion new(integer nMstrCnt, integer nSlvCnt, integer nBusArch);
} endclass
For SASD, the number of bus for each channel type is 1, so only an index value of 0 is valid. Only Wri
Address bus, Read Address Bus, and Write Data bus support the configuration.
class AxiArbThreeTierCfg
{
local integer m_nDevCnt;
public integer m_nvLowPriTier[*];
public integer m_nvMedPriTier[*];
public integer m_nvHighPriTier[*];
funtion new(integer nDevCnt);
}
Each tier element must be between 0 up to (m_nDevCnt-1) or DW_VIP_AXI_NO_REQ. By default, only
m_nvLowPriTier has the 0 to (m_nDevCnt-1) values in it
The following header defines the AxiAddressRange and AxiSlaveRange which you use to setup addre
ranges for the slave.
class AxiAddressRange {
public bit [DW_VIP_AXI_ADDR_PORT_WIDTH-1:0] m_bvStartAddr;

public bit [DW_VIP_AXI_ADDR_PORT_WIDTH-1:0] m_bvEndAddr;
public funtion new (

bit [DW_VIP_AXI_ADDR_PORT_WIDTH-1:0] bvStartAddr,
bit [DW_VIP_AXI_ADDR_PORT_WIDTH-1:0] bvEndAddr);
}
class AxiSlaveRange extends AxiAddressRange {
public integer m_nSlvIdx;
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
}endclass
3.6.17 VMM Transaction Classes

Transaction objects are passed through a mode’s RMV interface channels and can be used to hold th
following:
❖ A transaction request:
✦ Master VMM interface gets dw_vip_axi_master_transaction
✦ Master VMM interface makes master transaction request
✦ Master initiates transaction on bus
❖ An “in progress” transaction:
✦ Slave sees transaction on the bus
✦ Slave notifies VMM interface of transaction
✦ Slave VMM interface sends dw_vip_axi_slave_resp_transaction to testbench
❖ A transaction response:
✦ Testbench gets dw_vip_axi_slave_resp_transaction from slave VMM interface
✦ Testbench provides dw_vip_axi_slave_resp_transaction response to slave VMM interface
✦ Slave VMM interface provides response to slave
✦ Slave generates response on the bus
✦ Slave notifies VMM interface of completed response
✦ Slave VMM interface outputs dw_vip_axi_slave_resp_transaction to Activity channel for
completed response.
❖ A completed transaction:
✦ Monitor notifies monitor VMM interface
✦ Monitor VMM interface sends dw_vip_axi_transaction to testbench
✦ Master VMM interface triggers notify at end of transaction.
✦ Master VMM interface sends dw_vip_axi_transaction result to Output channel.
There are six transaction objects:
❖ dw_vip_axi_transaction - Contains basic data relevant to AXI transaction
❖ dw_vip_axi_master_transaction - Contains basic data plus information to describe transaction
request to master (e.g., delays, address, data, etc.)
❖ dw_vip_axi_slave_resp_transaction - Contains basic data plus information to describe response
preferences to slave (e.g., delays, order, interleaving)
❖ dw_vip_axi_master_extended_transaction is an extension of axi_vip_master_transaction class.
class implements features which are not part of the AMBA 3 AXI bus protocol specification but
which do not fundamentally change the behavior of the protocol. These features are extension
the existing protocol.
SolvNet
❖ dw_vip_axi_slave_extended_transaction is an extension of axi_vip_slaver_transaction class. Thi

class implements features which are not part of the AMBA 3 AXI bus protocol specification but
which do not fundamentally change the behavior of the protocol. These features are extension
the existing protocol.
❖ dw_vip_axi_port_monitor_transaction. Has the same features of the Bus Monitor except it is on
connected to one port.
The attributes of the transaction classes are public and are accessed directly for setting and getting v
The transaction objects also support randomization. The user is free to add their own constraints, but
transaction classes also include valid_ranges constraints which limit the generated values to ones ac
to the models and reasonable_* constraints which limit the generated values to ones acceptable to th
protocol. The reasonable_* constraints also help to increase the bus activity and avoid dangerous sys
memory issues. The user may want to disable some of the reasonable_* constraints and replace them
ones more specific to their system.
The bus monitor and port monitor transaction classes disable all constraints and turn off the rand_mo
all rand attributes since the attributes are only used to report observed values.
The valid_ranges constraints should only be disabled if 'rand_mode' for any of the parameters covere
them are turned off. If these are turned off without the constraints being turned off, then it can lead t
problems during randomization.
The individual reasonable_* constraints map to individual fields, and as such can be disabled individu
to control those fields.
Note that the valid_ranges constraints have unique names on the different objects. This is to insure th
base class (i.e., dw_vip_axi_transaction) valid_ranges constraints are not overridden by the derived c
(i.e., dw_vip_axi_master_transaction::master_valid_ranges and
dw_vip_axi_slave_resp_transaction::slave_resp_valid_ranges).
Transaction objects use the vmm_log variable:
public vmm_log log
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.
3.6.19 Extended Burst Lengths Greater Than 16

The AMBA 3AXI protocol specifies that the maximum number of transfer for a transaction is 16 (AWLE
ARLEN). You can configure the system to go beyond 16 transfers.
To use this capability, do the following: set the m_enMaxBurstLength configuration member to the
maximum number of transfers you expect the system to have.
The maximum transaction length applies to both read and write transactions. For the system to proce
longer transfer lengths, all components in the system must be able to process the extended length. A
result, Master, Slave, or Interconnect device must also be configured for the proper transfer length.
SolvNet
3.6.20 Sideband Signals

Sideband signals can be used to carry additional information for each transfer when the transfer is ac
within a channel. The Master provides the following set of sideband signals:
❖ AWSIDEBAND. Sideband signals on the write address channel.
❖ ARSIDEBAND. Sideband signals on the read address channel.
❖ RSIDEBAND. Sideband signals on the read data channel
❖ WSIDEBAND. Sideband signal on write data channel.
❖ BSIDEBAND. Sideband signal on write response channel.
To enable the use of sideband signals, set the m_enSidebandEnable configuration member.
Note the following about the use of sideband signals:
❖ The sideband signals are always 64-bits wide.
❖ Any X or Z bits set in the buffer will be allowed, but will produce a warning message.
❖ The master drives the sideband signals for the read/write address bus and the write data bus.
master receives sideband signals from the read data bus and the write response bus.
3.6.21 Support for vmm_data

The following vmm_data methods are fully implemented by the AXI transaction classes:
❖ display
❖ psdisplay
❖ allocate
❖ copy
❖ compare
❖ byte_size
❖ byte_pack
❖ byte_unpack
Each transaction class contains several randomizable data members of type bit vector, integer, or en
specific transaction data members are listed in the sections describing the individual transaction clas
These data members are initialized to the values listed in the corresponding tables that follow. These
members are public and can be accessed directly.
The “kind” parameter to the methods compare, byte_size, byte_pack and byte_unpack only supports
DW_VIP_VMT_LOGICAL which is the default if “kind” is not specified. If kind is specified as physical (-1
the compare method will ignore it as if logical had been specified; however, the byte_size, byte_pack
byte_unpack methods will send an vmm_error message “<method>: does not support Physical type
kind arg”.
3.6.22 Transaction Object Enumerated Types

The transaction object uses several enumerated types to hold some of the transaction information. T
that are used to specify bus transaction fields provide values that correspond to legal values allowed
ARM AXI Specification.
SolvNet
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
3.6.22.1 Randomizable Fields in Transaction Object

The vmm_log log object for each instance of a transaction class can be provided via the constructor.
local static vmm_log m_oSharedLog = new ("dw_vip_axi_transaction", "class");
For complete reference on VMM model class libraries there is a HTML-based help system. The help sy
is located at:
Most of these defaults are based on the AMBA 3 AXI protocol, and are present to generate traffic con
with the protocol. The reasonable_bvAsize and reasonable_bvAid are also provided to help generate t
consistent with the protocol. Since the transaction has no knowledge of design specifics, however, th
constraints also make some assumptions about the user design. Based on this the user should under
these assumptions and consider replacing these defaults with more appropriate reasonable constrain
To make a reasonable m_bvAsize constraint the transaction needs to know the data bus width. Since
not, it defines a size that works with all bus widths. This can be overly restrictive, making very poor u
wide data buses.
To make a reasonable m_bvAid constraint, the transaction needs to know the ID bus widths. Since it d
not, the size is assumed to be the same as the ID width default implemented in the models. For narro
buses t some higher bits are dropped. For wide ID buses, the full ID bus will not get used.
SolvNet
3.6.22.2 Transaction Sequences

The user must provide control over the randomization of atomic sequences. The AXI protocol support
atomic accesses that put constraints on sequences of transactions. Since the randomization of a tran
object does not have access to the randomization of other transaction objects or information about th
sequence of transactions, it is not possible to provide constraints within the transaction object to con
randomization. As a result, the user must generate the proper sequence of transactions that meet th
3 AXI atomic access requirements.
The two types of atomic access are “exclusive” and “locked”. “Exclusive” allows a master to receive
that a read-modify-write sequence was successful while allowing other transfers to take place betwee
exclusive read and write. “Locked” access ensures that a sequence of accesses is exclusive by lockin
any other transfers and requiring all transfers of the locked sequence to be consecutive. See the ARM
3 AXI Specification (Revision 1.0, Issued 19 March 2004) for more details about atomic access.
The value of m_enXactLock during randomize is restricted to NORMAL by the reasonable_enXactLock
constraint. There is a high probability that randomly producing EXCLUSIVE or LOCKED transactions w
create failed atomic access sequences. As a result, the user is required to create atomic sequences b
disabling the reasonable_enXactLock constraint, by randomizing the m_enXactLock attribute accordin
the user's constraints, and by providing control over the sequence and content of transactions to mee
AXI restrictions for atomic accesses. The post_randomize() method of the dw_vip_axi_transaction clas
constrain the non-sequence related restrictions for an exclusive access. The user may extend the
post_randomize method to replace or supplement the existing support. If supplementing the exiting
support, call the super.post_randomize() routine.
3.6.22.3 Exclusive Access Sequence

A summary of the AXI exclusive access restrictions is:
1. A master must not commence the write portion of an exclusive access until the read portion is
complete.
2. The size and length of an exclusive write with a given ID must be the same as the size and len
the preceding exclusive read with the same ID.
3. The address of an exclusive access must be aligned to the total number of bytes in the transac
4. The address for the exclusive read and the exclusive write must be identical.
5. The ARID field of the read portion of the exclusive access must match the AWID of the write
portion.
6. The control signals for the read and write portions of the exclusive access must be identical.
7. The number of bytes to be transferred in an exclusive access burst must be a power of 2: that
4, 8, 16, 32, 64, or 128 bytes.
8. The maximum number of bytes that can be transferred in an exclusive burst is 128.
9. The value of the ARCACHE or AWCACHE signals must guarantee that the slave that is monitori
the exclusive access sees the transaction.
The dw_vip_axi_transaction object's post_randomize() method checks for m_enXactLock == EXCLUSI
and forces the transaction to meet the AXI restrictions that do not involve the sequence of transactio
exclusive access restrictions 3, 7, 8 above). The user may extend the post_randomize method to eith
replace The post_randomize() method uses the following steps to force compliance for restrictions 3,
8:
1. Reduce the value of m_enXactLength if necessary until restrictions 7 and 8 are met.
SolvNet
2. Zero out the lower address bits until restriction 3 is met.

The reasonable_enXactCache constraint ensures that restriction 9 is met.
The user's sequence generator is responsible for meeting restrictions 1, 2, 4, 5, and 6.
3.6.22.4 Locked Sequences

A summary of the AMBA 3 AXI locked access restrictions is as follows:
1. The master must ensure that all transactions within a locked sequence have the same ARID or
value.
2. When a master starts a locked sequence of either read or write transactions it must ensure tha
no other outstanding transactions waiting to complete.
3. A locked sequence must always complete with a final transaction that does not have ARLOCK o
AWLOCK set to indicate a locked access.
4. A master must complete all previous locked transactions before sending the final unlocking
transaction. The unlocking transaction must then complete before any additional transactions
sent.
Recommended, but not mandatory restrictions are:
❖ Keep all locked transactions sequences within the same 4Kbyte address region.
❖ Only do two transactions in a locked sequence.
❖ Only use locked access to support legacy devices.
All of the locked access restrictions are sequence related, so the user must provide all support for me
the AMBA 3 AXI restrictions. Note that the locked sequence comes from a single master and there are
other transactions from the master during the locked sequence. The main issue for a sequence gene
be to meet the completion restrictions. The ID restriction can be enforced without much problems.
3.6.22.5 Master VMM Transaction Class

The dw_vip_axi_master_transaction is derived from the dw_vip_axi_transaction. The default values fo
dw_vip_axi_transaction are also valid for the dw_vip_axi_master_transaction. In addition, the
dw_vip_axi_master_transaction contains several additional attributes. Some of these are not randomi
Refer to HTML-based help system for the details of the attributes.
The vmm_log log object for each instance of a master transactor can be provided via the constructor
local static vmm_log m_oSharedLog = new ("dw_vip_axi_master_transaction", "class");
For complete reference on VMM model class libraries, a HTML-based help system is available. Refer
Note to this help system at:

constraints. Note that “valid_ranges” and “master_valid_ranges” constraints are not disabled. Follow
a declaration:
SolvNet

Example usage:
void’(oMasterXact.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}. When turning OFF constraints, then this function prod
the following vmm_warning message:
3.6.22.7 Timing Diagrams for Delay Parameters in dw_vip_axi_master_transaction

This section shows the waveforms which illustrate how setting the following delay parameters change
response of the master transactor:
❖ m_nAvalidWvalidDelay
❖ m_nNextAvalidDelay
❖ m_nBvalidBreadyDelay
❖ m_nBreadyDelay
❖ m_nvRreadyDelay
❖ m_nvNextWvalidDelay
❖ m_nvRvalidRreadyDelay
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
❖ m_nAvalidWvalidDelay=-3
❖ m_bvAddr=0020
SolvNet
Figure3-12 m_nAvalidWvalidDelay Waveform
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
Figure3-13 m_nNextAvalidDelay Waveform
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
For transaction 1, m_nBvalidBreadyDelay is 6 and for transaction 2 m_nBvalidBreadyDelay is 5.
Figure3-14 m_nBvalidBreadyDelay Waveform
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.
SolvNet
❖ m_nvRreadyDelay[0]=4
❖ m_nvRreadyDelay[2]=2
Figure3-16 m_nvRreadyDelay Waveform
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.
❖ m_nvNextWvalidDelay[0]=4
❖ m_nvNextWvalidDelay[1]=6
SolvNet
Figure3-17 m_nvNextWvalidDelay Waveform
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.
❖ m_nvRvalidRreadyDelay[0]=6
❖ m_nvRvalidRreadyDelay[2]=4
Figure3-18 m_nvRvalidRreadyDelay Waveform
SolvNet
3.6.22.8 Extended Master Transaction Class for Protocol Enhancements

The object dw_vip_axi_master_extended_transaction is an extension of axi_vip_master_transaction
class.This class implements extended features which are not part of the AMBA 3AXI bus protocol
specification. This class supports more than 16 transfers per transaction and sideband signals on all
Table14 lists the randomizable members of the dw_vip_master_extended_transaction class.
Table3-15 Randomizable Attributes of dw_vip_master_extended_transaction
Field name Data type Default values
m_bvXactLength bit [9:0] uninitialized
m_bvAddrSideband bit [63:0] uninitialized
m_bvDataSideband bit [63:0] [m_bvXactLength] uninitialized
m_bvBrespSideband bit [63:0] uninitialized
Notes about the randomizable attributes of dw_vip_master_extended_transaction:

❖ The sideband attributes carry valid information only when the m_enSidebandEnable attribute i
configuration object is set to VMT_BOOLEAN_TRUE.
❖ The m_bvAddrSideband attribute contains the data to be driven on the write or read address
sideband buses, depending on whether the transaction is a write or a read.
❖ The m_bvDataSideband attribute needs to be specified for each write beat of the transaction w
the transaction is of type write.
❖ The m_bvBrespSideband attribute specifies the data to be driven on to the BRESP sideband bu
❖ The m_bvXactLength attribute holds the transaction length which will never be more than the
configured maximum (16, 32, 64, 128, 256, 512 or 1024). For this to happen the m_enMaxBurs
attribute of the configuration object needs to be set to an appropriate value.
❖ You must constrain the m_bvXactLength attribute as there exists no link between the configura
object and the transaction object.
❖ In summary, all the sideband attributes are dependent on m_enSidebandEnable configuration
member being enabled, while the m_bvXactLength attribute depends on m_enMaxBurstLength
being set to an appropriate value.
3.6.22.9 Extended Slave Transaction Class for Protocol Enhancements

The dw_vip_axi_slave_extended_resp_transaction class extends from dw_vip_axi_slave_resp_transact
This class implements extended features which are not part of the AMBA 3AXI bus protocol specificat
This class supports more than 16 transfers per transaction and sideband signals on all buses for slav
devices.
dw_vip_axi_slave_extended_resp_transaction
Table15 lists the randomizable members of the dw_vip_slave_extended_transaction class.
Table3-16 Randomizable Members of dw_vip_slave_extended_transaction
m_bvXactLength bit [9:0] uninitialized
SolvNet
Table3-16 Randomizable Members of dw_vip_slave_extended_transaction
m_bvAddrSideband bit [63:0] uninitialized
m_bvDataSideband bit [63:0] [m_bvXactLength] uninitialized
m_bvBrespSideband bit [63:0] uninitialized
Notes about the randomizable attributes of dw_vip_slave_extended_transaction:

❖ The sideband attributes carry valid information only when the m_enSidebandEnable attribute i
configuration object is set to VMT_BOOLEAN_TRUE.
❖ The m_bvAddrSideband attribute contains the data collected from the write or read address
sideband buses depending on whether the transaction is a write or a read.
❖ The m_bvDataSideband attribute needs to be specified for each read beat of the transaction w
transaction is of type read. In the case of a write transaction, then the same attribute will conta
collected from the bus.
❖ The m_bvBrespSideband attribute specifies the data to be driven on to the BRESP sideband bu
❖ The m_bvXactLength attribute holds the transaction length, which will never be more than the
configured maximum (16, 32, 64, 128, 256, 512 or 1024), as set in the configuration object. Th
m_enMaxBurstLength attribute of the configuration object must be set to an appropriate value
❖ In summary, all sideband signal attributes are dependent on m_enSidebandEnable being enab
while m_bvXactLength depends on m_enMaxBurstLength being set to an appropriate value.
3.6.22.10 Master VMM Interface Transaction Status Class

The dw_vip_axi_master_status class provides the VMM master with a way to indicate why a transactio
has ended. The status is provided as a return value from the tr.notify.wait_for(tr.ENDED) notification.
While this class is derived from rvm data, there are no methods that are supported for the user. The
only access the public m_enStatus attribute. None of the new, copy, compare, allocate, psdisplay or a
other methods should be called on this class.
class dw_vip_axi_master_status extends vmm_data
{
enum status_enum =
MASTER_SEND_XACT_COMPLETE = 0,
MASTER_FLUSH_XACT_IN_PROTOCOL_RESET = 1,
MISMATCH_XACCESS_CTRL = 2,
UNMATCHED_XACCESS_WR = 3;
public status_enum m_enStatus;
3.6.22.11 Slave VMM Interface Transaction Class dw_vip_axi_slave_resp_transaction

The transaction object interface for the slave is called dw_vip_axi_slave_resp_transaction, and is defin
<axi_root>/include/AxiSlaveTransaction_rvm.vri.
The attributes of dw_vip_axi_transaction along with m_enWriteBeforeAddr are referred to as the signa
of the requested transaction. In addition the dw_vip_axi_slave_resp_transaction contains several addi
attributes. One of these is not randomizable.
SolvNet
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");
3.6.22.12 Transaction Time Outs

The slave has a data member for time outs called m_nXactTimeOut. The purpose of this timeout is to
prevent the slave from holding a transaction request for a long time without processing it. A transact
be held up in the slave due to long delay settings, or due to an unsatisfied out-of-order requirement.
meant to force a transaction to complete immediately, although it may result in the immediate comp
of the transaction.
If a timeout occurs on a transaction, then the slave terminates any further OutOfOrder counting and d
counting.
However, it does not undo the OutOfOrder or delay effects that have already taken place prior to the
timeout. When the OutOfOrder count reaches zero or is forced to zero by the timeout, the OutOfOrde
count for all transactions in earlier processing positions are also zeroed out to prevent any deadlock.
However, the processing order is not altered. The transaction that timed out must still wait for transa
ahead of it in the processing queue to finish their timeouts and collect their wlast data if it is a write
transaction.
3.6.22.12.1 reasonable_constraint_mode Method

constraints. The “slave_valid_ranges” constraint is not disabled.
Following is its declaration:
Example usage:
SolvNet
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:
3.6.22.13 Timing Diagrams for Delay Parameters in dw_vip_axi_slave_resp_transaction

This section shows waveforms which illustrate how setting the following delay parameters change the
response of the slave transactor:
❖ m_nvNextRvalidDelay[*]
❖ m_nWriteBvalidDelay
❖ m_nAddressRvalidDelay
❖ m_nAvalidAreadyDelay
❖ m_nDefaultAreadyDelay
❖ m_nAvalidAreadyDelay and m_nDefaultAreadyDelay
❖ m_nvWvalidWreadyDelay[*]
❖ m_nDefaultWreadyDelay
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_enXactLength = LENGTH_3
SolvNet
Figure3-19 m_nvNextRvalidDelay Waveform
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_nWriteBvalidDelay = 5
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.
❖ m_nWriteBvalidDelay = 5
The delay begins after handshake when the 7th (last) data phase completes. After the delay expires,
bvalid signal is asserted by the slave.
SolvNet
Figure3-20 m_nWriteBvalidDelay Waveform
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_nAddressRvalidDelay = 10
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_nAddressRvalidDelay = 10
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
Figure3-21 m_nAddressRvalidDelay Waveform
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_nAvalidAreadyDelay = 6
Transaction 2 values:
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
Figure3-22 m_nAvalidAreadyDelay Waveform
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_nDefaultAreadyDelay = 6
❖ m_enDefaultAwready =1
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
Figure3-23 m_nDefaultAreadyDelay Waveform
3.6.22.13.6 m_nAvalidAreadyDelay and m_nDefaultAreadyDelay

3.6.22.13.7 shows how the delay members m_nAvalidAreadyDelay and m_nDefaultAreadyDelay work
Refer to the figure for the following values and explanation. Values for Transaction 1:
Values for Transaction 2:
If the AVALID signal has gone high, the AREADY will remain low until both the m_nAvalidAreadyDelay
and m_nDefaultAreadyDelay timing constraints have been satisfied.
SolvNet
Figure3-24 m_nAvalidAreadyDelay and m_nDefaultAreadyDelay Waveform
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_nvWvalidWreadyDelay = 4
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
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_nDefaultWreadyDelay = 7
❖ m_enDefaultWready = 1
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
Figure3-26 m_nDefaultWreadyDelay
3.6.22.14 Monitor VMMTransaction Class

The dw_vip_axi_monitor_transaction is derived from the dw_vip_axi_transaction. The default values
indicated above for the dw_vip_axi_transaction are also valid for the dw_vip_axi_monitor_transaction.
In addition, the dw_vip_axi_monitor_transaction contains several additional local attributes. None of t
are randomizable. The non-randomizable dw_vip_axi_monitor_transaction specific attribute are listed
Table16.
The dw_vip_axi_monitor_transaction provides the following methods to access these local attributes.
virtual function integer getSource();
virtual task setSource(integer nSource);
virtual function integer getDestination();

virtual task setDestination(integer nDestination);
virtual function integer getInterfaceId();

virtual task setInterfaceId(integer nInterfaceId);
The vmm_log log object for each instance of a monitor transaction class can be provided via the cons
If 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_monitor_transaction", "class");
SolvNet
Table3-17 dw_vip_monitor_transaction Non-Randomizable Attributes
Data
Field name type Default value Description
m_nSource integer DW_VIP_AXI_UNSPECIFIED. Indicate from which master this transaction

starts. Valid value range in [0… 31]
m_nDestinatio integer DW_VIP_AXI_UNSPECIFIED. Indicate from which slave this transaction ends.
n Valid value range in [-1… 31]
m_nInterfaceId integer DW_VIP_AXI_UNSPECIFIED. Indicates on which interface the transaction is

finished. From 0 up 31, indicates the
transaction finishes on interface between
masters and interconnect. From 32 to 63
indicates the transaction finishes on interface
between interconnect and slaves.
Note that the dw_vip_axi_monitor_transaction turns rand_mode and constraint_mode OFF for all of th
dw_vip_axi_transaction attributes.
3.6.22.15 Port Monitor Transaction Class

The transaction class for the Port Monitor is called dw_vip_axi_port_monitor_transaction. The
dw_vip_axi_port_monitor_transaction is derived from the dw_vip_axi_transaction.
The rvm_log log object for each instance of a port monitor transaction class can be provided via the
constructor. If the constructor log object is null, then a default rvm_log object is used which is shared
all configuration objects that were not provided a log in the constructor. The following code example
the declaration of the shared log object.
local static rvm_log m_oSharedLog = new ("dw_vip_axi_port_monitor_transaction",
"class");
Access is through the public rvm_log log member of the class instance. The
dw_vip_axi_port_monitor_transaction class does not contain any additional class specific attributes. N
that the dw_vip_axi_port_monitor_transaction turns rand_mode and constraint_mode OFF for all of the
dw_vip_axi_transaction attributes.
3.6.23 VMM Monitor Interface Coverage

In general, VMM coverage is accomplished via callback class instance registered with the VMM Monit
interface. The VMM Monitor interface by default does not have any coverage callback class instance
registered; therefore, by default no coverage is reported. The user either extends the monitor base c
callback class and registers it, or the user registers one instance of the default coverage callback cla
is provided by the VMM Monitor interface. The VMM Monitor interface base callback class defines a se
callback methods for the coverage purpose. When VMM monitor interface has detected a transaction
received a significant event, then it will create the proper data, and then scan through the callback o
and make the call. Once the callback objects implement any virtual coverage calls, then the callback
sees the effect. When the VMM Monitor interface creates the event data object before the callback, th
will call the “allocate” method of the factory object if it is passed in the VMM interface constructor.
For the AMBA 3 AXI VMM monitor interface, there are three events which trigger coverage:
1. When transaction is put to the activity channel
SolvNet
2. When hen a flow event happens

3. When a protocol error message happens
3.6.23.1 VMM Monitor Interface Callbacks

The base VMM Monitor callback class dw_vip_axi_monitor_rvm_callbacks defines three virtual callbac
methods for coverage:
❖ activity_channel_cov
❖ error_significant_event_cov
❖ flow_significant_event_cov
Each “cov method” has specific data as the parameter. For the activity_channel_cov method, the dat
of dw_vip_axi_monitor_transaction. Example:
class dw_vip_axi_monitor_rvm_callbacks extends vmm_xactor_callbacks
{
dw_vip_axi_monitor_transaction oVipXact,
var bit drop ); // channel pre put callback
virtual task activity_channel_cov(
dw_vip_axi_monitor_transaction oVipXact );
virtual task error_significant_event_cov(
dw_vip_axi_monitor_error_cov oCovData);
virtual task flow_significant_event_cov(
dw_vip_axi_monitor_flow_cov oCovData);
}
3.6.23.2 Using VMM Monitor Interface Coverage Callbacks

You can extend the base callback class, add coverage groups, and implement virtual callbacks using
VMM Monitor interface. The default coverage group callback is good example showed in Appendix.
Following are a few examples:
❖ A user could derive their class from dw_vip_axi_monitor_rvm_callbacks to get their own groups
and then register them.
❖ A user could derive their class from dw_vip_axi_monitor_def_cov_callbacks so get their groups
along with the default groups. For example:
dw_vip_axi_monitor_def_cov_callbacks myDefCovCB = new();
myRvmMonitor.append_callback(myDefCovCB);
3.6.23.3 VMM Monitor Interface Significant Event Data Classes

There are two significant data class who are used by the callback methods:
❖ dw_vip_axi_monitor_error_cov for the method error_significant_event_cov
❖ dw_vip_axi_monitor_flow_cov for the method flow_significant_event_cov.
They are both derived from vmm_data, and therefore support the following common methods:
❖ display
SolvNet
❖ psdisplay
❖ allocate
❖ copy
❖ compare
❖ byte_size
❖ byte_pack
❖ byte_unpack
3.6.24 Port Monitor Coverage

Using general VMM guidelines, coverage is accomplished via a callback class instance which is regist
with the Port Monitor transactor. The Port Monitor by default does not have any coverage callback cla
instance registered; therefore, no coverage is reported by default. For coverage, the user either exte
port monitor base coverage callback class, and registers it, or registers an instance of the default cov
callback.
The VMM Port Monitor base callback class defines a set of callback methods for coverage purposes. W
the VMM port monitor detects a transaction or receives a significant event, it will create a data object
then scan through the list of registered callback objects, and make the call with the data object. Once
user's callback class implements a virtual coverage call, then the callback object processes the data
When the Port Monitor creates the event data object for the callback, it will call the “allocate” method
factory object. If a factory object was passed into the VMM port monitor constructor, then the data ob
created from that object’s allocate method. Otherwise, the data object is created from the default fac
object class.
3.6.24.1 Coverage Information for the Port Monitor

For VMM port monitor, there are three events along with data that can be used to provide coverage:
❖ when a transaction is put to the activity channel.
❖ when a flow event occurs.
❖ when a protocol error message occurs.
Based on the above events, the callback class dw_vip_axi_port_monitor_rvm_callbacks defines three
callback methods for coverage:
❖ activity_channel_cov,
❖ error_significant_event_cov
❖ flow_significant_event_cov.
Each cov method has specific data as the parameter. For activity_channel_cov, the data type is of
dw_vip_axi_port_monitor_transaction. See the following example:
class dw_vip_axi_port_monitor_rvm_callbacks extends rvm_xactor_callbacks
{
dw_vip_axi_port_monitor_transaction oVipXact,
var bit drop ); // channel pre put callback
SolvNet
dw_vip_axi_port_monitor_transaction oVipXact );
dw_vip_axi_port_monitor_error_cov oCovData);
dw_vip_axi_port_monitor_flow_cov oCovData);
}
3.6.24.2 Using Port Monitor Coverage Callbacks

Users can extend base callback class, add coverage groups, and implement the virtual callback. User
have few options how to get the coverage:
❖ Users derive a class from dw_vip_axi_port_monitor_rvm_callbacks to obtain their own groups (a
register it).
❖ Users derive a class from dw_vip_axi_port_monitor_def_cov_callbacks so they get their groups
the default groups).
dw_vip_axi_port_monitor_def_cov_callbacks myDefCovCB = new();
myRvmPortMonitor.register_callback(myDefCovCB);
❖ Users instantiate the default object, plus create their own derived class from
dw_vip_axi_port_monitor_rvm_callbacks to keep the groups separate
3.6.24.3 Port Monitor Significant Event Data Classes

There are two significant data classes which are used by the callback methods:
1. dw_vip_axi_port_monitor_error_cov for the method error_significant_event_cov
2. dw_vip_axi_port_monitor_flow_cov for the method flow_significant_event_cov.
They are both derived from rvm_data, and therefore support the following common methods:
❖ display
❖ psdisplay
❖ allocate
❖ copy
❖ compare
❖ byte_size
❖ byte_pack
❖ byte_unpack
3.6.24.4 Port Monitor Coverage Examples

The following code is an example implementation of the dw_vip_axi_port_monitor_def_cov_data_callb
class.
//--------------------------------------------------------
// Class dw_vip_axi_port_monitor_def_cov_data_callbacks
//--------------------------------------------------------
dw_vip_axi_port_monitor_def_cov_data_callbacks extends
dw_vip_axi_port_monitor_rvm_callbacks
SolvNet
protected dw_vip_axi_port_monitor_transaction m_oActivityXact;

protected dw_vip_axi_port_monitor_error_cov m_oErrorCovData;
protected dw_vip_axi_port_monitor_flow_cov m_oFlowCovData;
protected integer m_nPortIdx;

protected dw_vip_axi_port_monitor_transaction::resp_type_enum m_envResp;
protected event m_evAddrWrChReady;

protected event m_evAddrRdChReady;
protected event m_evRdChReady;
protected event m_evRespChReady;
protected event m_evProtoErrMsg;
protected event m_evRdHsChange;
protected event m_evWrHsChange;
protected event m_evRdXactComplete;
protected event m_evWrXactComplete;
protected event m_evRdDepthChange;
protected event m_evWrDepthChange;

dw_vip_axi_port_monitor_transaction oVipXact );
dw_vip_axi_port_monitor_error_cov oCovData);
dw_vip_axi_port_monitor_flow_cov oCovData);
task dw_vip_axi_port_monitor_def_cov_data_callbacks :: activity_channel_cov(

dw_vip_axi_port_monitor_transaction oVipXact )
{
integer i;
integer nExtededMode,nSideEnable,nMaxNumberOfBeats;
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
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_error_cov oCovData)
{
if (oCovData != null) {
m_oErrorCovData = oCovData;
trigger(m_evProtoErrMsg);
}
}
task dw_vip_axi_port_monitor_def_cov_data_callbacks :: flow_significant_event_cov(

dw_vip_axi_port_monitor_flow_cov oCovData)
{
if (oCovData != null) {
m_oFlowCovData = oCovData;
case(oCovData.m_enKind)
{
dw_vip_axi_port_monitor_flow_cov::RD_HS : trigger(m_evRdHsChange);
dw_vip_axi_port_monitor_flow_cov::WR_HS : trigger(m_evWrHsChange);
dw_vip_axi_port_monitor_flow_cov::RD_XACT : trigger(m_evRdXactComplete);
dw_vip_axi_port_monitor_flow_cov::WR_XACT : trigger(m_evWrXactComplete);
dw_vip_axi_port_monitor_flow_cov::RD_DEPTH : trigger(m_evRdDepthChange);
dw_vip_axi_port_monitor_flow_cov::WR_DEPTH : trigger(m_evWrDepthChange);
}
}
}
SolvNet
3.6.25 Default Coverage Class Declaration and Defines

This section presents coverage declarations and defines. Table17 provides a summary of the
dw_vip_axi_monitor_rvm_callback class. Later tables define the coverage groups with their bins.
Table3-18 Default Coverage Class
class dw_vip_axi_monitor_def_cov_callbacks extends

dw_vip_axi_monitor_rvm_callbacks
Local Variables
Type Name
dw_vip_axi_monitor_transaction m_oActivityXact m_oActivityXact
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
Table3-18 Default Coverage Class (Continued)
class dw_vip_axi_monitor_def_cov_callbacks extends

dw_vip_axi_monitor_rvm_callbacks
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
The following table shows the coverage for ERROR_MSGID:

.
Table3-19 ERROR_MSGID Coverage Group
State Name State Value
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
Table3-19 ERROR_MSGID Coverage Group (Continued)
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
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
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
UNKNOWN not state
The following table shows coverage for PROTO_ERROR_MSGID:.

Table3-20 PROTO_ERROR_MSGID Coverage
State Name StateValue
sample_event = m_evErrMsg (
SolvNet
Table3-20 PROTO_ERROR_MSGID Coverage (Continued)
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
Table3-20 PROTO_ERROR_MSGID Coverage (Continued)
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
Table3-21 BURST_ADDR_WRITE Coverage Group
sample_event = m_evAddrWrChReady
sample m_nMstrIdx
SRC_0 0
SRC_1 1
SolvNet
Table3-21 BURST_ADDR_WRITE Coverage Group (Continued)
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
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
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
sample m_oActivityXact.m_enXferSize
SolvNet
SIZE_8BITS dw_vip_axi_monitor_transaction::SIZE_8BIT
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
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
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
Table3-22 BURST_ADDR_READ Coverage Group (Continued)
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
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
SolvNet
sample m_oActivityXact.m_enXferSize
State Name stateValue
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
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
m_oActivityXact.m_enXferSize
m_oActivityXact.m_enXactBurst
m_oActivityXact.m_enXactLock
m_oActivityXact.m_enXactCache
m_oActivityXact.m_enXactProt
The following table defines the BURST_RRESP coverage group.:

Table3-23 BURST_RRESP cov group
State Name State Value)
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
The following table shows the BURST_BRESP coverage group:

Table3-24 BURST_BRESP Coverage Group
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
The following table shows the FLOW_RD_HSORDER coverage group:

Table3-25 FLOW_RD_HSORDER
sample_event = m_evRdHsChange
SolvNet
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
The following table shows the FLOW_WR_HSORDER coverage group:

Table3-26 FLOW_WR_HSORDER Coverage Group
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
The following table shows the FLOW_RD_XACT coverage group:

Table3-27 FLOW_RD_XACT Coverage Group
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
Table3-27 FLOW_RD_XACT Coverage Group (Continued)
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
The following table shows the FLOW_WR_XACT coverage group:

Table3-28 FLOW_WR_XACT Coverage Group
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
Table3-28 FLOW_WR_XACT Coverage Group (Continued)
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
The following shows the FLOW_RD_INTRLV_DEPTH coverage group:

Table3-29 FLOW_RD_INTRLV_DEPTH Coverage Group
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
Table3-29 FLOW_RD_INTRLV_DEPTH Coverage Group (Continued)
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
DEPTH_INVALID not a state
The following shows the FLOW_WR_INTRLV_DEPTH coverage group:

Table3-30 FLOW_WR_INTRLV_DEPTH Coverage Group
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
Table3-30 FLOW_WR_INTRLV_DEPTH Coverage Group (Continued)
State
State Name Value
DEPTH_13 13
DEPTH_14 14
DEPTH_15 15
DEPTH_16 16
DEPTH_INVALID not state
3.6.26 VMM Messages

This section describes the messaging features for the AMBA 3 AXI VMM interfaces, and consists of the
following:
❖ “Messaging Overview”
❖ “Mapping Protocol-Specific Messages to VMM Messages”
❖ “VMM Notifications”
✦ “VmtNotifyMsgData Class”
❖ “Message Callbacks”
3.6.26.1 Messaging Overview

The VMM interface models generate messages that are compatible with the vmm_log base class. The
messages originate in two different scopes:
❖ General-purpose VMM messages
❖ Protocol-specific messages.
This section describes how protocol-specific messages are handled. For general information about VM
messages, see “Common Message Service” in the Reference Verification Methodology User Guide
When certain predefined simulation conditions occur, Synopsys Vera Modeling Technology (VMT) serv
create protocol-specific messages and notification events. The VMM interface captures each message
notification and translates it to an vmm_log style message.
3.6.26.2 Mapping Protocol-Specific Messages to VMM Messages

Source for a typical VMT-level message includes the following in the order listed:
❖ Message ID
❖ Message Text
❖ Message type
SolvNet
❖ Message fields (including data type)
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
VMT Message Type VMM Message Type VMM Message Severity
VMT_MSG_FATAL FAILURE_TYP FATAL_SEV
VMT_MSG_ERROR FAILURE_TYP ERROR_SEV
VMT_MSG_WARNING FAILURE_TYPE WARNING_SEV
VMT_MSG_TIMING TIMING_TYP WARNING_SEV
VMT_MSG_XHANDLING XHANDLING_TYP WARNING_SEV
VMT_MSG_NOTE NOTE_TYP NORMAL_SEV
VMT_MSG_PROTO_ERROR PROTOCOL_TYP ERROR_SEV
VMT_MSG_PROTO_CYCLE CYCLE_TYP DEBUG_SEV
VMT_MSG_PROTO_TRANS TRANSACTION_TYP TRACE_SEV
VMT_MSG_REPORT REPORT_TYP DEBUG_SEV
VMT_MSG_CMD COMMAND_TYP VERBOSE_SEV
VMT_MSG_NOTIFY NOTIFY_TYP HIDDEN_SEV
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
3.6.26.3 VMM Notifications

Each VMT message and notification has an associated VMM notify identifier member that is based on
name of the message ID. The name of the notify ID is the original message ID appended with
“_NOTIFY_ID”. Note that the original VMT message ID is a fixed value, represented by a macro. For
example:
#define VMT_MSGID_BLOCKED_STREAM 505
The corresponding VMM notification identifier is an integer typed member variable that is assigned b
VMM library, so its value may change from one design to another:
integer VMT_MSGID_BLOCKED_STREAM_NOTIFY_ID = notify.configure();
Given the relationship that the notify ID is <MSGID>_NOTIFY_ID, waiting on the message event in an
VMM environment can be performed as follows:
// Wait for AXI_MSGID_MASTER_SEND_XACT_COMPLETE
void’(u1.notify.wait_for(
u1.AXI_MSGID_MASTER_SEND_XACT_COMPLETE_NOTIFY_ID));
// … got the notification event, now do something …
3.6.26.3.1 VmtNotifyMsgData Class

For each message or notification event, a VmtNotifyMsgData message notification data object is crea
This object is returned from the wait_for() that provides access to the message ID, type, and message
text. Here are the public members of VmtNotifyMsgData:
class VmtNotifyMsgData extends VmtData //extends vmm_data
{
integer id; // vmt message id
integer type; // vmt message type
string msg; // message body text
VmtData dataObj; // reserved for future optional data
}
Note that the dataObj member is generally unused and only contains valid model-specific data for se
messages. It should be ignored unless specifically documented for a model message.
Here is an example of code that uses the return data of wait_for:
vmm_data data;
VmtNotifyMsgData msg;
// Wait for the notification
data = device_rvm.notify.wait_for( \
device_rvm.AXI_MSGID_MASTER_SEND_XACT_COMPLETE_NOTIFY_ID);
// Try to convert to vmt msg data type
if ($cast(msg,data,CHECK))
{
if (! msg.msg.match("Invalid buffer"))
{
$display("Error : bad msg text value, expected ");
$display("\"Invalid \
buffer\" but got \"%s\"\n", msg.msg);
errorCount++;
}
}
else
SolvNet
{
printf("Error : bad notification data type\n");
errorCount++;}
3.6.26.4 Message Callbacks

VMM transactor models provide an VMM callback that triggers immediately before a message is issue
The callback method allows the testbench to capture every message, along with its message ID and
message type (note that these are different from VMM message types).
The callback pre_notify_send_msg receives a data object of type VmtNotifyMsgData, which can be us
check the underlying VMT message type, ID, and text.
The following is an example of how this callback can be extended and registered:
class my_callback extends VmtModelCallbacks
{
integer msg1_done = 0;
integer msg2_done = 0;
funtion new()
{
}
// here's the method that's called before the msg is sent
task pre_notify_send_msg(VmtNotifyMsgData msg)
{
// just check for some ids
if (msg.id == AXI_MSGID_MASTER_SEND_XACT_COMPLETE)
{
{ msg1_done++; }
}
}
}
program test {
// create and register the callback{

my_callback cbk;
cbk = new();
u1.append_callback(cbk);
}
}
The callbacks are registered directly with the VMM interface.
In the previous example, the my_callback implementation of pre_notify_send_msg is called prior to ea
message being sent.
3.7 Interconnect Arbitration

By default, a simple round-robin arbitration is used on each bus. A clash is defined when at least two
sources are talking to one target through the Interconnect model. Therefore, there are four scenarios
which the Interconnect needs arbitration:
❖ Scenario 1 is that of multiple address requests at the same time.
❖ Scenario 2 is that of multiple read data with a different ARID destined to the same Master port.
❖ Scenario 3 is that of multiple write data with a different AWID destined to the same Slave port,
which are interleaved.
SolvNet
❖ 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.
Figure3-27 Three Tier, Round Robin Arbitration Scheme
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
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.
Figure3-28 Arbitration as “Pure Rotation”
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
Figure3-29 “Weighted Reverse Rotation without Index 3” Arbitration
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.
3.8 Bidirectional Transaction Support

The AXI VIP Bus Monitor supports bidirectional command feature. This feature is not supported by the
Port Monitor. Also note that the AXI Interconnect VIP as of release 5.40a does not support this feature
Bidirectional transactions can be achieved by cascading interconnects, which is also known as interc
tiling. In general, the interconnect is bi-directional. Masters local to it can access slaves on non-local
interconnects, and the masters non-local to it can access local slaves.
Following figure is an example of cascaded interconnects:
SolvNet
Figure3-30 Cascading Interconnects
ICM1
SP1 Slave 1
(MP1)
DW_axi_1
System MP2 SP2

Master 1
ICM1
SP1 Slave 2
(MP1)
DW_axi_2
System MP2 SP2

Master 2
AXI_MIDW
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
The AXI bus monitor VIP master ports can be configured as either ICM ports or system master ports.
3.8.1 Interconnecting Master (ICM) Ports

Interconnecting master (ICM) ports on the interconnect device refer to ports which are connected to s
ports of other interconnects.
In the AXI VIP Bus monitor, the number of ICM ports can be configured using the configuration param
m_nNumIcm. The minimum value of this configuration parameter is 1, and the maximum is 4. The low
numbered master ports are configured as ICM ports. For example, assume the master count configur
and the member m_nNumIcm is configured as 2. In this case, master ports 0 and 1 will be configured
ICM ports. Master ports 2, 3, 4 will be considered system master ports.
ICM ports have no system numbers because they forward the ID received from the slave port of
interconnect to which they are connected; they do not append any ID bits to transactions that pass th
them.
Users can specify the system master numbers which are allowed to pass transactions through a spec
port, using the configuration parameter m_bvAllowMstIcm. This configuration parameter specifies wh
system masters in the system are allowed to pass transactions through the ICM port. If an ICM port re
a transaction from a system master which is not allowed to pass transactions through that ICM port, t
the error message AXI_MSGID_INVALID_SYSTEM_MASTER_ON_ICM_PORT is issued.
Note that one system master can pass transactions through only one ICM per interconnect.
3.8.2 System Master Ports

Master ports on any cascaded interconnect that are directly connected to a master, rather than to a s
of another interconnect, are referred to system master ports. The masters connected to these ports a
referred as system masters.
In the AXI Bus monitor VIP, the lowest m_nNumIcm count of master ports are ICM ports. The remainin
ports are considered system master ports.
You should specify a unique system master number to each system master port using the configurati
parameter m_nSysMstrNum. Note the following:
❖ The system master number specified for the system master port must be unique, and should n
have been specified as one of the allowed system masters through any ICM ports, nor as syste
master number for any other system master ports.
❖ If a system master number is repeated for another master port, the error message
AXI_MSGID_SAME_SYSTEM_MASTER_NUMBER_FOR_MULTIPLE_MASTER_PORTS is issued,
with the bidirectional command feature then being disabled.
❖ If a system master number is not specified for any system master port, the error message
AXI_MSGID_SYSTEM_MASTER_NUMBER_NOT_SPECIFIED is issued, and the bidirectional
command feature is disabled.
❖ The user should specify the total number of system masters across all interconnects using the
configuration parameter m_nNumSysMasters. Up to 64 system masters are supported.
❖ If the number of system masters configured through the configuration parameter
m_nNumSysMasters do not match with the actual number of system masters specified for ICM
ports and system master ports, then the error message AXI_MSGID_
SYSTEM_MASTERS_NUM_MISMATCH is issued, and the bidirectional command feature then
disabled.
SolvNet
3.8.3 ID Width and Bidirectional Transactions

The ID width of all master ports of the AXI monitor VIP can be configured through the configuration
parameter m_nIdWidth. All system master ports should have the same ID width.
For ICM ports, even though the configured ID width is the value of the m_nIdWidth configuration
parameter, the number of bits driven on ID port should be:
ceil(log2 (m_nNumSysMasters))+ m_nIdWidth
The slave port ID width must be configured as:
ceil(log2 (m_nNumSysMasters))+ m_nIdWidth
The AXI monitor VIP considers the lower m_nIdWidth bits of the slave ID port as the transaction ID. Th
upperceil(log2 (m_nNumSysMasters)) number of bits of the slave ID port are considered as the system
master number.
If slave port receives a transaction with a system master which has not been specified in the system,
message AXI_MSGID_INVALID_SYSTEM_MASTER_ON_SLV_PORT is issued.
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
3.9.1 Shared Interface Loader

The shared loader file is located at <axi_root>/include/Axi.pkg. This file takes care of loading the suit
classes which are shared across all model interfaces. This loader file is included by the individual mo
interface loaders.
3.9.2 Loaders for Individual Model Interfaces

There are four individual loaders, one for each of the AXI model interfaces. They are:
❖ AxiInterconnect_rvm.pkg
❖ AxiMaster_rvm.pkg
❖ AxiMonitor_rvm.pkg
❖ AxiSlave_rvm.pkg
3.9.3 Testbench Code

When writing your testbench code, consider following the coding style recommended by VMM. This
includes building any new classes as extensions to the VMM base classes and using VMM logging. Th
keeps the testbench VMM-compliant so that the VMM methodology can be applied consistently to all
pieces of the testbench, and not just the verification models. VMM compliant code can also leverage
functionality that is already included in the VMM base classes, and the pieces of the test environmen
SolvNet
be portable to other uses. In the VMM example testbench, the user_sink class is an example of buildin
upon the VMM infrastructure.
3.10 VMM Class Reference for AMBA 3 AXI VIP

For complete reference on VMM model class libraries there is a HTML-based help system. The help sy
is located at:
$DESIGNWARE_HOME/vip/amba/latest/doc/axi_vmm_html/index.html
3.10.1 Class and Variable Naming Conventions

This section describes the significance of portions of class and variable names.
❖ Constant identifiers, such as macros and enumerated values, are all caps, with words separate
underscores:
#define VMT_MAX_MESSAGE_COUNT 2
enum VmtMessageLevel = VMT_MSG_ERROR,
VMT_MSG_WARNING,
VMT_MSG_NOTE;
❖ Variable and procedural identifiers are constructed using the Proper naming style, in which the
letter of the identifier is in lowercase, and the first letter of each following word is in uppercase
example:
function bit iosValidName();
task displayMessage();
❖ Variable names include Hungarian notation, in which the prefix indicates the type of the variab
integer nInstanceCount;
bit bValidData;
The following table provides the conventions that were used when naming variables.
Table3-32 Prefix Conventions for Variables
Type Prefix Example
Integer i or n iCount, m_nInstances
Integer vector nv m_nvRvalidRreadyDelay
Bit b bEnabled, m_bSelected
Bit vector bv bvAddress, m_bvData
Vector of bit vector bvv bvvResp, m_bvvData
String s sName, m_sTitle
Boolean bl m_blStartNewInterleave
Event ev evSynchronize, m_evSuspend
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
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.
4.2 dw_vip_axi_port_configuration Configuration Members

For detailed descriptions, view the online HTML-based help at:
$DESIGNWARE_HOME/vip/amba/latest/doc/axi_vmm_html
Table4-1 Summary of dw_vip_axi_port_configuration Members
dw_vip_axi_port_configuration
VMT_BOOL m_blLogXact = VMT_TRUE [protected]
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.
VMT_BOOL m_blNotifyXact = VMT_FALSE [protected]
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.
rand bit [31:0] m_bvVisibleSlavesOnReadCh = 32hFFFFFFFF
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.
rand VMT_BOOL m_blSlaveAutoResponse = VMT_FALSE
SolvNet
Configuration Member Summary Verification IP for AMBA AXI VMM User Guide
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.
rand bit [31:0] m_bvVisibleSlavesOnWriteCh = 32hFFFFFFFF
BUS MONITOR
Defines the write visibility of a slave port to a given master port.
rand VmtBooleanEnum m_enDefaultArready = VMT_BOOLEAN_TRUE
INTERCONNECT
Sets the default value of output pin ARREADY_M<n>.
SLAVE.
Sets the default value of output pin ARREADY_M<n>.
rand VmtBooleanEnum m_enDefaultAwready = VMT_BOOLEAN_TRUE
INTERCONNECT
Sets the default value of output pin AWREADY_M<n>.
SLAVE:
Specifies the default value the Slave drives on the AWREADY signal:
rand VmtBooleanEnum m_enDefaultBready = VMT_BOOLEAN_TRUE
MASTER
Specifies the default value of BREADY that AXI master would drive.
rand VmtBooleanEnum m_enDefaultRready = VMT_BOOLEAN_TRUE
INTERCONNECT
Sets the default value of output pin RREADY_S<n>.
MASTER.
Specifies the default value of RREADY that Master would drive.
rand VmtBooleanEnum m_enDefaultWready = VMT_BOOLEAN_TRUE
INTERCONNECT
Sets the default value of output pin WREADY_M<n>.
SLAVE.
Specifies the default value the Slave drives on the WREADY signal.
SolvNet
rand VmtBooleanEnum m_enExclAccSupp = VMT_BOOLEAN_FALSE
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.
rand memory_default_pattern_enum m_enMemoryDefaultPattern = PATTERN_X
SLAVE
Specifies the default pattern of values that memory locations contain prior to any specific
write operation from bus transactions or memory commands.
rand wstrb_value_enum m_enWrStrbIdle = INACTIVE_LOW
MASTER
When WVALID is low, the WSTRB signals are inactive.
rand integer m_nAlias
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.
rand integer m_nDelayCycles = 0
INTERCONNECT
Helps to set the thresholds for counting the number of transactions.
rand integer m_nHighThreshold = 0
INTERCONNECT
rand integer m_nIdWidth = 4
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.
rand integer m_nLowThreshold = 0
INTERCONNECT
SolvNet
rand integer m_nMaxExclAcc = 4
SLAVE
Specifies the max number of active exclusive access monitors supported by the slave.
rand integer m_nNumOutstandingXact = 4
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.
rand integer m_nRdIntrlvDepth = 1
SLAVE
Specifies the maximum number of read transactions that can have interleaved
responses at the same time. Each transaction ID must be unique.
rand integer m_nValidToArreadyDelay = 0
INTERCONNECT
SETS the delay cycles for READY signals after their respective VALID signals are
asserted.
rand integer m_nValidToAwreadyDelay = 0
INTERCONNECT
Sets the delay cycles for READY signals after their respective VALID signals are
asserted.
rand integer m_nValidToBreadyDelay = 0
INTERCONNECT
asserted.
rand integer m_nValidToRreadyDelay = 0
INTERCONNECT
asserted.
rand integer m_nValidToWreadyDelay = 0
INTERCONNECT
asserted.
rand integer m_nWrIntrlvDepth = 1
SolvNet
SLAVE
Specifies the number of write transactions that can be interleaved.
MASTER
Specifies the number of write transactions that can be interleaved.
4.3 dw_vip_axi_system_model_configuration Configuration Members
Table4-2 Summary of dw_vip_axi_System_Model_configuration Members
dw_vip_axi_system_model_configuration
VMT_BOOL m_blChkProt = VMT_TRUE [protected]
BUS AND PORT MONITOR

When set to 1, this parameter enables protocol checking.
Enable or disable the strict interpretation of the start of a transaction for
coverage. This affects the interpretation of the FLOW Interrupt bins (bin names
ending in "_INT").
VMT_BOOL m_blCovStrictInterleave = VMT_FALSE [protected]
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.
VMT_BOOL m_blCovStrictStart = VMT_FALSE [protected]

Enable or disable the strict interpretation of the start of a transaction for
coverage. This parameter cannot be modified after the start command is issued.
VMT_BOOL m_blSysLogXact = VMT_TRUE [protected]
BUS MONITOR
When set to 1, this parameter enables transaction logging for the system.
rand addr_bus_width_enum m_enAddrWidth = ADDR_BUS_WIDTH_32
ALL MODELS
Defines the width of both the AWADDR and ARADDR address buses.
rand data_bus_width_enum m_enDataWidth = DATA_BUS_WIDTH_32
SolvNet
ALL MODELS
Specifies the data bus width of the Master.
rand VmtBooleanEnum m_enEnforceCompliant = VMT_BOOLEAN_TRUE
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.
rand interconnect_bus_architecture_enum m_enIcBusArch =

INTERCONNECT_BUS_ARCH_SASD
INTERCONNECT
Defines the bus architecture. It can only be a shared-address, shared-data bus
(SASD).
rand max_burst_length_enum m_enMaxBurstLength =

MAX_BURST_LENGTH_16
ALL MODELS
By default, the protocol allows up to 16 transfers in one burst.
rand VmtBooleanEnum m_enRcmndDev = VMT_BOOLEAN_TRUE
Defines whether the system may contain non AMBA 3 AXI interface-compliant
devices.
VmtBooleanEnum m_enSidebandEnable = VMT_BOOLEAN_FALSE
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.
integer m_nAccWatchdogTimeout = 0 [protected]

At the end of a locked or exclusive access transaction this watchdog timer looks
for the next transaction in the sequence (for example: the write after the read in
an exclusive access, the unlock or next lock in a locked access).
integer m_nDefaultSlvPortIdx = -1 [protected]
Default port slave index.
integer m_nMstrCnt [protected]
SolvNet
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.
integer m_nRdyWatchdogTimeout = 16 [protected]

When the VALID signal for a channel goes high, this watchdog timer looks at the
READY signal for the channel.
integer m_nSlvCnt [protected]
BUS MONITOR
Defines the number of slaves hooked to monitor. r only' system).
INTERCONNECT
Defines the number of Slaves connected to the Interconnect.
rand integer m_nSlvIdWidth
BUS MONITOR
Internal width required for all slave ID buses (i.e., ARID, AWID, RID, WID, BID)
seen by the interconnect.
integer m_nVldWatchdogTimeout = 0 [protected]

When the READY signal for one stage of the transaction goes high, this
watchdog timer looks at the VALID signal for the next stage of the transaction.
AxiArbSchemeCfg m_oArbSchemeCfg
Round robin with a SASD architecture.
dw_vip_axi_bus_architecture_configuration m_oBusArchCfg
INTERCONNECT
Defines the bust architecture configuration.
rand dw_vip_axi_port_configuration m_ovMstrCfgs[32]
An array holding port configuration objects for masters in the system.
rand dw_vip_axi_port_configuration m_ovSlvCfgs[32]
An array holding port configuration objects for slaves in the system.
SolvNet
SolvNet
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.
A.1 Creating MCD Files

To create the MCD files, create a file called vmt_mcd.cfg in the directory where you run the simulatio
design directory). If this file exists, its contents determine which instances to dump.
❖ To dump all instances of VIP:
Create an empty file named vmt_mcd.cfg in the design directory. Then, during the simulation:
✦ Each instance of VIP in the testbench dumps debug activity into a file called instance_name
✦ Also, for VMM/RVM testbenches, each instance of VIP dumps VMM/RVM-level debug activity
into a file called instance_name_rvm.mcd.
❖ To dump specific instances of VIP:
Specify the instance names in the vmt_mcd.cfg file. (To identify VIP instance names, see “Iden
an Instance” on page180.) Then, during the simulation:
✦ Each specified instance of VIP dumps debug activity into a file called instance_name.mcd.
✦ For VMM/RVM testbenches, each specified instance of VIP also dumps VMM/RVM-level
debug activity into a file called instance_name_rvm.mcd.
For example, assume the contents of vmt_mcd.cfg as follows:
top.u1
top.u2.u1
During the simulation, each specified instance creates an MCD file. In this example, the files ar
✧ top.u1.mcd
✧ top.u2.u1.mcd
Also, for VMM/RVM testbenches, VMM/RVM-level debug activity is dumped into files named:
✧ top.u1_rvm.mcd
✧ top.u2.u1_rvm.mcd
SolvNet
Reporting Problems Verification IP for AMBA AXI VMM User Guide
A.2 Identifying an Instance

Each model instance has a unique name, this instance name is different depending on if the model is
driven from an HDL testbench or from a testbench.
A.2.1 HDL Testbench Users

In this case the instance name is the full HDL path to the instance.
A.2.1.0.1 Verilog Example

top.u1
Here the name of the Verilog module is “top” and it has an instance of the VMT model called “u1.”
A.2.1.0.2 VHDL Example

/top/u1
Again, the name of the VHDL entity is “top” and this it has an instance of the VMT model called “u1.”
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 OpenVera Testbench Users

In this case the instance name is the full HDL path to the instance plus the name passed to the const
the models instance.
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
A.2.3 Naming VIP Instances in an OpenVera Testbench

When using a Verification IP model in an OpenVera testbench, the names of all model instances must
unique.
When using a VIP model in an OpenVera testbench, the models are instantiated and each one must b
constructed by calling its new() task. One of the arguments to the new() task is a string which is used
identify the instance. One such use of the string is to create MCD filenames so that each model instan
a unique file associated with it. Since two instances cannot share the same MCD file, the filenames m
unique. This requires that the names passed to the new() task are also unique.
Following shows an OpenVera testbench that instantiates six VIP models. All six have a unique string
first argument to the new()
Following shows a general OpenVera testbench, which instantiates six VIP models. All six have a uniq
string in the first argument to the new()
task.
program AxiSystemTest
SolvNet
Verification IP for AMBA AXI VMM User Guide Reporting Problems
AxiMaster master[TEST_MAX_MASTERS]; // active master are 1 and 2 ;

AxiSlave slave[TEST_MAX_SLAVES]; // active slaves are 1 and 2
AxiMonitor monitor;
DemoTests demo;
// reset signal
driveReset();
@(posedge CLOCK);
master[1] = new("axiMaster1", axiMasterBind1);

master[2] = new("axiMaster2", axiMasterBind2);
slave[1] = new("axiSlave1" , axiSlaveBind1);
slave[2] = new("axiSlave2" , axiSlaveBind2);
monitor = new("axiMonitor", axiMonitorBind);
......
A.3 Checking if MCD has been Enabled

When MCD has been turned on for a model instance, a message with Warning severity will be printed
the model instance. For example:
DesignWare Model Warning from test_top.u1.u1 at 0:
Model Change Dump turned on, mcd file is 'test_top.u1.u1.mcd',
simulation performance will be degraded.
For VMM/RVM testbenches, an additional message is generated to note the MCD file that contains
VMM/RVM-level debug activity:
DesignWare Model Warning from test_top.u1.u1 at 0:
Model Change Dump turned on, mcd file is 'test_top.u1.u1_rvm.mcd',
simulation performance will be degraded.
A.4 Impact of Turning MCD On

When MCD has been turned on for a model, the model prints debug information to a file. As a result,
simulation performance is degraded.
SolvNet
Reporting Problems Verification IP for AMBA AXI VMM User Guide
SolvNet
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
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

Axi SV Amba

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Axi SV Amba

Caricato da

Copyright:

Formati disponibili

Synopsys Verification IP for

2.6Setting Up the AXI VIP Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.6.22Transaction Object Enumerated Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Table 1-1: AMBA 3 AXI Verification IP Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

About This Guide

1.1 Product Suite Overview

axi_master_rvm_vera_vmt The Master transactor model supports configurable transactions, unaligned

axi_slave_rvm_vera_vmt The Slave transactor model supports configurable transactions, unaligned

axi_interconnect_rvm_vera_vmt The Interconnect transactor model supports up to 32 Masters and 32 Slaves,

Table1-1 AMBA 3 AXI Verification IP Models

1.1.1 AMBATM 3 Assured

1.2 Online Reference Documentation

1.3 Master Transactor Overview

1.4 Slave Transactor Overview

1.5 Monitor Transactor Overview

1.6 Interconnect Transactor Overview

Figure1-1 Interconnect and System Block Diagram

1.6.1 Supported Features Summary

❖ Supports all types of burst transactions and atomic accesses

2.1 Installation and Setup

2.2 System Requirements

2.2.1 Hardware Requirements

2.2.2 Software Requirements

2.2.2.1 Your Version of VMT

2.2.2.2 Platform/OS and Simulator Software

2.2.2.3 Synopsys Common Licensing (SCL) Software

2.2.2.4 Other Third Party Software

2.2.3 Preparing for Installation of the VIP Image

2.2.4 Downloading and Installing

2. In the IP table, click Verification IP.

2.2.5 Setting Up an Example Testbench Design Directory

2.2.6 Running the Example Testbenches

2.2.7 QuickStart for the SystemVerilog/VMM Testbenches

2.2.7.1 Basic SV/VMM Examples

2.2.7.1.1 Installing and Running a Basic SV/VMM Example

2.2.7.2 Intermediate SV/VMM Example

2.2.7.3 Advanced SV/VMM Example

2.2.8 The Example Testbenches

Testbench Name and Details

Install/setup: $DESIGNWARE_HOME/bin/dw_vip_setup -p design_dir -e axi_rvm_sys -svtb

Sim script location: design_dir/examples/axi_rvm_sys/ (select the command from below)

Testbench Languages: Simulator: Sim Script Command

SVTB VCS: sim_axi_rvm_sys vcsvlog svtb

Install/setup: $DESIGNWARE_HOME/bin/dw_vip_setup -e amba/tb_axi_vmm_10_basic_sys -path ./design_dir

Sim script location: design_dir/examples/svtb/amba/tb_axi_vmm_10_basic (select the command from below)

Testbench Languages: Simulator: Sim Script Command

SVTB VCS: run_axi_vmm_10_basic_sys example vcsvlog

Table2-1 Example Testbenches for AXI VIP

Testbench Name and Details

Install/setup: $DESIGNWARE_HOME/bin/dw_vip_setup -e amba/tb_axi_vmm_10_intermediate_sys -path

Sim script location: design_dir/examples/svtb/amba/tb_axi_vmm_10_intermediate (select the command from

Testbench Languages: Simulator: Sim Script Command

SVTB VCS: run_axi_vmm_10_intermediate_sys example

Install/setup: $DESIGNWARE_HOME/bin/dw_vip_setup -e amba/tb_axi_vmm_10_advanced_sys -path

Sim script location: design_dir/examples/svtb/amba/tb_axi_vmm_10_advanced (select the command from

Testbench Languages: Simulator: Sim Script Command

SVTB VCS: run_axi_vmm_10_advanced_sys example vcsvlog

2.3 Licensing Information

3. DesignWare license, if available

2.3.1 Specifying License Files

2.3.2 License Features for VIP

2.3.3 Controlling License Usage

2.3.4 License Polling