ahb_sv

Version 6.35aJanuary 2012

DesignWare AMBA AHB Verification IP

VMM User Manual

ahb_master_rvm_vera_vmtahb_slave_rvm_vera_vmt

ahb_bus_rvm_vera_vmtahb_monitor_rvm_vera_vmt

Included in the VCS Verification Libraryand the DesignWare Library

http://synopsys.com

http://synopsys.com

Copyright Notice and Proprietary InformationCopyright © 2012 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 StatementAll 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.

DisclaimerSYNOPSYS, 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.

Registered Trademarks (®)Synopsys, AEON, AMPS, Astro, Behavior Extracting Synthesis Technology, Cadabra, CATS, CRITIC, Certify, CHIPit, Confirma, CODE V, Design Compiler, DesignWare, EMBED-IT!, Formality, Global Synthesis, HDL Analyst, HSIM, HSPICE, Identify, Leda, LightTools, MAST, ModelTools, NanoSim, NOVeA, OpenVera, ORA, PathMill, Physical Compiler, PrimeTime, SCOPE, Simply Better Results, SiVL, SNUG, SolvNet, Sonic Focus, STAR Memory System, Syndicated, Synplicity, the Synplicity Logo, Synplify, Synplify Pro, Synthesis Constraints Optimization Environment, TetraMAX, UMRBus, VCS, Vera, and YIELDirector are registered trademarks of Synopsys, Inc.

Trademarks (™)AFGen, Apollo, ARC, ASAP, Astro, Astro-Rail, Astro-Xtalk, Aurora, AvanWaves, BEST, Columbia, Columbia-CE, Cosmos, CosmosLE, CosmosScope, CRITIC, CustomExplorer, CustomSim, DC Expert, DC Professional, DC Ultra, Design Analyzer, Design Vision, DesignerHDL, DesignPower, DFTMAX, Direct Silicon Access, Discovery, Eclypse, Encore, EPIC, Galaxy, Galaxy Custom Designer, HANEX, HAPS, HapsTrak, HDL Compiler, Hercules, Hierarchical Optimization Technology, High-performance ASIC Prototyping System, HSIMplus, i-Virtual Stepper, IICE, in-Sync, iN-Tandem, Intelli, Jupiter, Jupiter-DP, JupiterXT, JupiterXT-ASIC, Liberty, Libra-Passport, Library Compiler, Macro-PLUS, Magellan, Mars, Mars-Rail, Mars-Xtalk, Milkyway, ModelSource, Module Compiler, MultiPoint, ORAengineering, Physical Analyst, Planet, Planet-PL, Polaris, Power Compiler, Raphael, RippledMixer, Saturn, Scirocco, Scirocco-i, SiWare, Star-RCXT, Star-SimXT, StarRC, Taurus, TotalRecall, TSUPREM-4, VCSi, VHDL Compiler, VMC, and Worksheet Buffer are trademarks of Synopsys, Inc.

Service Marks (SM)MAP-in, SVP Café, and TAP-in are service marks of Synopsys, Inc.

SystemC is a trademark of the Open SystemC Initiative and is used under license.

ARM and AMBA are registered trademarks of ARM Limited.Saber is a registered trademark of SabreMark Limited Partnership and is used under license.

PCI Express is a trademark of PCI-SIG.

All other product or company names may be trademarks of their respective owners.

Synopsys, Inc. 700 E. Middlefield Road Mountain View, CA 94043

www.synopsys.com

2 Synopsys, Inc. January 2012

AMBA AHB Verification IP VMM User Manual

SolvNet DesignWare.com

www.synopsys.com

http://solvnet.synopsys.com

www.designware.com

January 2012 Synopsys, Inc. 3

AMBA AHB Verification IP VMM User Manual


Contents

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

About This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Related Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Manual Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Web Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Customer Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Chapter 1 Introduction to AHB Verification IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11

1.1 Overview of AHB VIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111.1.1 Features of AHB Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131.1.2 Features of AHB Slave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131.1.3 Features of the AHB Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131.1.4 Features of the AHB Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14

Chapter 2 Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15

2.1 Installation and Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .152.2 System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16

2.2.1 Hardware Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .162.2.2 Verifying the Software Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .162.2.3 Preparing for Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .172.2.4 Downloading and Installing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .172.2.5 Setting Up an Example Testbench Design Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .182.2.6 Running the Example Testbenches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .182.2.7 QuickStart for the SystemVerilog/VMM Testbenches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .192.2.8 The Example Testbenches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .202.2.9 Examining the Example Testbenches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .222.2.10 What’s Next? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23

2.3 Licensing Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .232.3.1 Specifying License Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .242.3.2 License Features for DesignWare VIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .242.3.3 Controlling License Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .242.3.4 If Licensing Fails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .252.3.5 License Polling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .252.3.6 Simulation License Suspension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .252.3.7 URG License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25

2.4 Environment Variable and Path Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .252.4.1 Simulator Specific Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26

https://solvnet.synopsys.com

www.designware.com


Contents AMBA AHB Verification IP VMM User Manual


2.5 Determining Your Model Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .262.6 Integrating DesignWare VIP into Your Testbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26

2.6.1 Creating a Design Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .262.6.2 Running dw_vip_setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .272.6.3 Using Verification IP in Your Testbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32

Chapter 3 Integration with VMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39

3.1 Overview of VMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .393.1.1 Base Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40

3.2 Benefits of DesignWare VIP and VMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .413.2.1 Improved modularity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .413.2.2 Efficiency of Abstraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .413.2.3 Rapid creation of complex tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .413.2.4 Increased Reuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41

3.3 DesignWare VIP in a VMM Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .423.3.1 Sample Test Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .433.3.2 VMM Support in DesignWare Verification IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .443.3.3 DesignWare VIP Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .443.3.4 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .493.3.5 Generators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .513.3.6 Factories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .523.3.7 Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .533.3.8 Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55

3.4 VMM Features Provided by AHB DesignWare VIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .563.4.1 Online Documentation for RVM Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57

3.5 Class and Variable Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .573.6 Base Classes for AHB DesignWare VIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58

3.6.1 Transaction Base Class: dw_vip_ahb_transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .583.6.2 Configuration Base Class: dw_vip_amba_configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .603.6.3 AHB System Configuration Class: dw_vip_ahb_system_configuration . . . . . . . . . . . . . . . . . . .60

3.7 Using the AHB Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .643.7.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .643.7.2 AHB Master Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .653.7.3 ARM11 Master Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .663.7.4 Testbench Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .673.7.5 Configuration Class: dw_vip_ahb_master_configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .723.7.6 Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .733.7.7 Master Transactor Class: dw_vip_ahb_master_rvm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .733.7.8 Master Transaction Class: dw_vip_ahb_master_transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . .743.7.9 Callbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75

3.8 Using the AHB Slave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .763.8.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .763.8.2 AHB Slave Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .763.8.3 ARM11 Slave Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .783.8.4 Testbench Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .793.8.5 Slave Configuration Class: dw_vip_ahb_slave_configuration . . . . . . . . . . . . . . . . . . . . . . . . . . .833.8.6 Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .853.8.7 AHB Slave Transaction Class: dw_vip_ahb_slave_transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . .873.8.8 Callbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88


www.designware.com


AMBA AHB Verification IP VMM User Manual Contents


3.9 Using the AHB Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .883.9.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .883.9.2 AHB Monitor Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .893.9.3 ARM11 Monitor Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .913.9.4 Testbench Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .923.9.5 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .963.9.6 Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .963.9.7 Monitor Transactor Class: dw_vip_ahb_monitor_rvm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .963.9.8 Monitor Transaction Class: dw_vip_ahb_monitor_transaction . . . . . . . . . . . . . . . . . . . . . . . . . .963.9.9 Coverage and Coverage Data Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .983.9.10 Callbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

3.10 Using the AHB Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1003.10.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1003.10.2 AHB Bus Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1013.10.3 Testbench Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1043.10.4 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1063.10.5 Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1063.10.6 Bus Transactor Class: dw_vip_ahb_bus_rvm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1063.10.7 Callbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Appendix A Reporting Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

A.1 Creating MCD Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109A.2 Identifying an Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

A.2.1 HDL Testbench Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110A.3 Checking if MCD is Enabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110A.4 Impact of Turning MCD On . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Appendix B Updating a DesignWare Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

B.1 Are Your Components and Tools Current? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111B.1.1 MyDesignWare Subscriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111B.1.2 dwh_update Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111B.1.3 coreTools Automatic Update Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .112

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115


www.designware.com


Tables AMBA AHB Verification IP VMM User Manual


Tables

Table 1-1: AMBA 2.0 AHB Verification IP Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Table 2-1: Example Testbenches for AHB VIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Table 2-2: Setup Program Switch Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Table 3-1: Summary of Channels Used by Model Transactors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Table 3-2: Display Bases for Numeric Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49Table 3-3: Prefix Conventions for Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Table 3-4: Transaction Class dw_vip_ahb_transaction Enumerated Types . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Table 3-5: Configuration Class dw_vip_amba_configuration Enumerated Types . . . . . . . . . . . . . . . . . . . . . 60Table 3-6: AHB Master Port Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65Table 3-7: ARM11 Master Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67Table 3-8: AHB Slave Port Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Table 3-9: ARM11 Slave Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78Table 3-10: AHB Monitor Port Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89Table 3-11: ARM11 Monitor Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91Table 3-12: dw_vip_ahb_monitor_error_cov Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99Table 3-13: AHB Bus Port Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101


www.designware.com


AMBA AHB Verification IP VMM User Manual Preface


Preface

About This ManualThis manual contains introductory, usage, and reference material about the DesignWare AHB Verification IP and using it in a SystemVerilog environment.

Related DocumentsThis manual is part of the AMBA/AXI IP document set. The AHB Verification IP Suite documentation set includes the following:

For Release Notes for all AMBA/AXI Verification IP, see:

❖ DesignWare AMBA/AXI Verification IP Suite Release Notes

For descriptions and access to any of the documents in the set, see:

❖ Guide to DesignWare AMBA/AXI Verification IP Suite

In addition to the features documented here, common VMT features that apply to the models are documented in:

❖ VMT Release Notes– Contains new features, fixed problems, and known problems and limitations common to all VMT models.

In addition to the features documented here, the following documents contain information about functional coverage, Verification Methodology, and other related topics:

❖ For the IEEE SystemVerilog standard, see:

IEEE Standard for SystemVerilog—Unified Hardware Design, Specification, and Verification Language

❖ For a reference guide describing the 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

AttentionThis document describes how to use the object-based interface of the DesignWare AMBA Verification IP. A separate user manual is available for the command-based interface. For more information about command-based usage, see DesignWare AMBA AHB Verification IP VMT User Manual.

solvnet.synopsys.com

www.designware.com


Preface AMBA AHB Verification IP VMM User Manual


Manual OverviewThis manual contains the following chapters and appendixes:

❖ Chapter 1, “Introduction to AHB Verification IP”, contains an overview of the DesignWare AMBA AHB Verification IP and its components.

❖ Chapter 2, “Getting Started”, contains an overview of the DesignWare AHB Verification IP and its components.

❖ Chapter 3, “Integration with VMM”, describes the Verification Methodology Manual classes that are specific to the AHB Verification IP.

❖ Appendix A, “Reporting Problems”, provides procedures for creating detailed Customer Support information when reporting problems.

❖ Appendix B, “Updating a DesignWare Library”, describes ways to update your DesignWare Library and provides details of the dwh_update utility.

Web Resources❖ DesignWare IP product information: http://www.designware.com

❖ Your custom DesignWare IP page: http://www.mydesignware.com

❖ 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 page 109.

❖ 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 below, your issue is automatically routed to a support engineer who is experienced with your product. 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: DesignWare Verification IP✧ Sub Product: amba ahb✧ Tool Version: 6.35a✧ Problem Type: ✧ Priority: ✧ Fill in the remaining fields according to your environment, the DesignWare DesignWare

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.


www.designware.com

http://www.designware.com/

http://www.mydesignware.com


http://www.synopsys.com/keys

http://solvnet.synopsys.com/EnterACall


AMBA AHB Verification IP VMM User Manual Preface


✦ Or, send an e-mail message to [email protected] (your email will be queued and 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 (as identified above) so it can be routed correctly.

✧ For simulation issues, include the timestamp of any signals or locations in waveforms that 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 For up to date information about the latest implementation IP and verification models, visit the IP Directory:

http://www.synopsys.com/products/designware/ipdir

http://www.synopsys.com/products/designware/ipdir


www.designware.com

mailto:[email protected]

http://www.synopsys.com/Support/GlobalSupportCenters


Preface AMBA AHB Verification IP VMM User Manual



www.designware.com


AMBA AHB Verification IP VMM User Manual Introduction to AHB Verification IP


1Introduction to AHB Verification IP

1.1 Overview of AHB VIPThe DesignWare AHB Verification IP described in this document provides models that verify features of the AMBA version 2.0-compliant Advanced High-performance Bus (AHB). This manual describes how the elements of the DesignWare AHB Verification IP work in a SystemVerilog environment.

Figure 1-1 shows how an AHB subsystem is connected using multiple (one to 16) AHB Masters and multiple (1 to 16) AHB Slaves. Verification IP subsystems also can contain a Monitor, which generates reports on states, transactions, and model messages.

There are two sets of models for verifying the AMBA 2.0 AHB Interface, as listed in Table 1-1. Table 1-1 AMBA 2.0 AHB Verification IP Models

Models Description

Object-based Models These models have an object-based interface for use with the Reference Verification Methodology (RVM) in SystemVerilog VMM testbenches.

ahb_master_rvm_vera_vmt The AHB Master transactor initiates transfers and bursts onto the AHB, and includes support for automatic transfer rebuilds, and automatic bus request and release. For features, see “Features of AHB Master” on page 13.

ahb_slave_rvm_vera_vmt The AHB Slave transactor responds to transactions on the AHB. Internal memory elements store and supply data on demand from the master. For features, see “Features of AHB Slave” on page 13.

ahb_monitor_rvm_vera_vmt The AHB Monitor transactor supports up to 16 masters and 16 slaves with protocol checking, transaction logging and functional coverage monitoring. All AHB transaction types are supported transaction logging and functional coverage monitoring. For features, see “Features of the AHB Monitor” on page 13.

ahb_bus_rvm_vera_vmt AHB Bus transactor supports verification in a system context by providing the arbiter, decoder and read/write muxes for interconnecting up to 15 masters and slaves. For features, see “Features of the AHB Bus” on page 14.


www.designware.com


Introduction to AHB Verification IP AMBA AHB Verification IP VMM User Manual


Figure 1-1 A Typical AHB Verification IP Subsystem

All system components shown in Figure 1-1 are available as DesignWare Verification IP components. The arbiter, muxes, and decoder are available as part of the AHB Bus model. The AHB system is also available as a DesignWare synthesizable component.

HSEL is a bus of signals from the decoder to each Slave, which has its own HSEL(n) line.

Command-based Models: These models have a command-based interface for the directed test methodology.

ahb_master_vmtahb_slave_vmtahb_monitor_vmtahb_bus_rvm_vera_vmt

For information about using these command-based models, see DesignWare AHB Verification IP Databook.

Table 1-1 AMBA 2.0 AHB Verification IP Models

Models Description

AHBMaster 1

AHBMaster n

AHBSlave 1

AHBSlave n

also:HCLK

HRESETn

HMASTERHMASTLOCKHSPLIT (from each

slave)

HMASTER

HBUSREQxHGRANTx

HLOCKx

HSEL

HRDATAHREADYHRESP

HADDRHWDATAHBURSTHTRANSHWRITE

HSIZEHPROT

AHBDecoder*

AHBArbiter*

AHB Monitor

Mux*

Mux*

HSEL1

HSELn

* The decoder, arbiter, data and control muxes are part of the AHB Bus model.


www.designware.com


AMBA AHB Verification IP VMM User Manual Introduction to AHB Verification IP


1.1.1 Features of AHB Master

The AHB Master has two operating modes: protocol-related and buffer access. Protocol-related features generate bus cycles and transfer responses to slave response types. Buffer access features allow you to create burst transfers in advance and reuse the burst information.

The protocol-related features of the AHB Master include the following:

❖ All data widths

❖ All address widths

❖ All transfer types

❖ Locked transfers

❖ All protection types

❖ Automatic transfer rebuilds

❖ Automatic bus request and release

❖ ARM11 Feature support (Systems IP ARM11 AMBA-Rev2.0 AHB Extensions-v1.0)

1.1.2 Features of AHB Slave

The AHB Slave model can generate responses to all types of burst read and write cycles, as well as non-burst reads and writes. The model also supports split cycle functionality, where the model requests the bus after specified number of clock cycles. The Slave model also supports FIFO memory arrays, constrained random test transactions, AHB Lite requirements, and ARM11 features (Systems IP ARM11 AMBA-Rev2.0 AHB Extensions-v1.0).

1.1.3 Features of the AHB Monitor

The AHB Monitor has the following features:

❖ Protocol checking

❖ Transaction logging

❖ AHB monitor buffers

❖ Coverage monitoring

❖ Incremental coverage


The Monitor can be configured for any valid AHB bus configuration from 8 to 1024 bits. All AHB transaction types are supported.

The monitor connects to the actual AHB signals, as defined in the AMBA specification. There is one monitor per AHB bus, which is capable of supporting up to 16 masters and 16 slaves.

The monitor can control protocol checkers, which can be stopped and started using configuration parameters.

Functional coverage is used to monitor particular states on the bus. Errors, logged by the monitor, are also tracked by the coverage object. Statistical reports are available for both valid and error states. This allows

NoteNoteNoteNote For information about the buffer access mode, see DesignWare AHB Verification IP VMT User Manual.


www.designware.com


Introduction to AHB Verification IP AMBA AHB Verification IP VMM User Manual


the monitor to be used to help ensure that the verification tests are covering the complete functionality. Functional coverage data can be saved and restored for incremental coverage reporting.

1.1.4 Features of the AHB Bus

The AHB Bus model provides a means of easily interconnecting AHB Masters and Slaves to form a standard AHB system as part of an on-chip bus solution. The AHB Bus model contains an Arbiter, Decoder, a Write Data Multiplexer, a Read Data/Response Multiplexer, a Control Signals Multiplexer, a dummy Master, and a default Slave.

The AHB Bus model supports these features:

❖ Supports up to 15 Masters and 15 Slaves.

❖ Data Bus widths up to 1024 bits.

❖ All types of responses.

❖ System Address width of 32 or 64 bits.

❖ Priority-based arbitration algorithm.

❖ All types of burst and locked transfers.

❖ Configurable early burst termination.

❖ Unlimited memory map for each Slave.

❖ Configurable termination of undefined length burst.

❖ Arbiter ensures that only one Master is granted bus access at any time.

NoteNoteNoteNote The AHB Bus model does not support AHB-Lite and ARM11 features.


www.designware.com


AMBA AHB Verification IP VMM User Manual Getting Started


2Getting Started

2.1 Installation and SetupThis section leads you through installing and setting up the AHB Verification IP for use with the Verification Methodology Manual (VMM) for SystemVerilog. When you complete this checklist, the provided example testbench will be operational and the AHB Verification IP will be ready to use.

If you want to update the components in your DesignWare Library to the current versions, see “Updating a DesignWare Library”.

The installation and setup consists of the following major steps:

❖ System Requirements

❖ Verifying the Software Requirements

❖ Preparing for Installation

❖ Downloading and Installing

❖ Setting Up an Example Testbench Design Directory

❖ Running the Example Testbenches

❖ Examining the Example Testbenches

❖ What’s Next?

NoteNoteNoteNote For a complete matrix of using the AHB models with Synopsys and third party vendor simulator products, testbench control languages, methodology, and VIP execution engines, refer to Chapter 2 of the VMT Installation Guide.


www.designware.com


Getting Started AMBA AHB Verification IP VMM User Manual


2.2 System RequirementsBefore 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 page 16.

Disk Space

❖ Approximately 400 MB available disk space for installation and basic use, broken down as follows:

✦ Approximately 200 MB to install a DesignWare VIP product in DESIGNWARE_HOME.

✦ Approximately 200 MB when Vera engine executable files (.vro) files are created. These .vro files 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 are the same for each set.

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.

2.2.2 Verifying the Software Requirements

2.2.2.1 Your Version of VMTThe Vera Modeling Technology (VMT) is an internal portion of the DesignWare VIP, as illustrated below. It provides base 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 DesignWare AMBA Verification IP Release Notes,

❖ For release notes information about VMT, see the DesignWare Verification IP Vera Modeling Technology (VMT) Release Notes.

2.2.2.2 Platform/OS and Simulator SoftwareYou 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 qualified with your version of VMT, see the following document:

Qualified Tools Matrix for DesignWare VIP:

http://www.synopsys.com/dw/doc.php/vip/vmt/latest/doc/vmt_update.pdf

NoteNoteNoteNote For a list of supported platform, operating system versions, and simulators, see the Web-based DesignWare Verification IP Vera Modeling Technology (VMT) Qualified Tools Matrix document at: http://www.synopsys.com/dw/doc.php/vip/vmt/latest/doc/vmt_update.pdf


www.designware.com

http://www.synopsys.com/dw/doc.php/vip/vmt/latest/doc/vmt_update.pdf

https://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 DesignWare Verification IP. Acquiring the

SCL software is covered here in “Licensing Information” on page 23.

2.2.2.4 Other Third Party Software❖ Adobe Acrobat: DesignWare DesignWare Verification IP documents are available in Acrobat PDF

files. You can get Adobe Acrobat Reader for free from http://www.adobe.com.

❖ HTML browser: DesignWare DesignWare DesignWare Verification IP includes class reference in HTML. 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)

❖ Adobe Acrobat: All AHB Verification IP documents are Acrobat PDF files. You can download Adobe Acrobat Reader from http://www.adobe.com.

2.2.3 Preparing for Installation

1. Ensure that the Synopsys Common Licensing (SCL) software and the necessary licensing structure is established. For detailed instructions, refer to “Licensing Information” on page 23.

2. Set DESIGNWARE_HOME to the absolute path where DesignWare 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 DesignWare VIP, set either the DW_LICENSE_FILE, SNPSLMD_LICENSE_FILE, or LM_LICENSE_FILE variable as described in “Licensing Information” on page 23.

✦ 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 variable.

2.2.4 Downloading and Installing

If you have not yet downloaded and installed the DesignWare Verification IP image, follow this procedure.

1. In your internet browser, navigate to the Synopsys IP Directory:

http://www.synopsys.com/products/designware/ipdir/

2. From the IP Showcase in the DesignWare Library Verification IP table, click on the link for the product you want in the VIP column. This brings up a Verification IP model page showing multiple AHB VIP models. Click on the link text in the “Download” row for the model you want to download.

NoteNoteNoteNote Clicking on the ‘Download’ link takes you to the SolvNet login page. If you have not previously registered as a SolvNet user, click on the “Register Today” link and provide the required information.

http://www.synopsys.com/products/designware/ipdir/


www.designware.com

http://www.adobe.com

http://www.adobe.com




3. After logging in to SolvNet secure server, your browser displays the DesignWare Download page. Follow the instructions on that page.

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 programming support called as include files, and example testbenches. You can specify the path of the design 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 current working directory.

Invoke the following command to create the design directory, add the models and example testbench, build the models, and generate the testbench simulation script:

% $DESIGNWARE_HOME/bin/dw_vip_setup -path design_dir -e ahb_rvm_sys -svtb

This command creates a design directory that contains a directory named include and a directory named examples. It also creates a simulation script named “sim_ahb_rvm_sys”, which is located at:

design_dir/examples/ahb_rvm_sys/sim_ahb_rvm_sys

For the full description of the dw_vip_setup script, refer to “Running dw_vip_setup” on page 27.

2.2.6 Running the Example Testbenches

The example testbenches are provided as part of the AHB Verification IP to demonstrate key model usage and serves as a starting point for you to develop your own testbenches. Successfully running an example testbench validates your installation. The remainder of this section shows how to set up and run an example provided with DesignWare VIP. The example described here also serves as a starting point to help you begin building your own testbench.

To run an example testbench, you use the simulation script created in the previous step.

Invoke the simulation script below that fits your simulation environment. If your simulation environment is not listed here, see “Creating and Running a Simulation Script for the Example Testbench” on page 30 for more examples.

To simulate the SystemVerilog example testbench using VCS, use the following command:

NoteNoteNoteNote The simulator run scripts use “cc” as the default compiler for any C modules that need to be compiled. 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.

NoteNoteNoteNote For a walk-through example that demonstrates basic VMM concepts, see “QuickStart for the SystemVerilog/VMM Testbenches” on page 26.


www.designware.com




% design_dir/examples/ahb_rvm_sys/sim_ahb_rvm_sys vcsvlog svtb

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 DesignWare AMBA/AXI Verification IP. These examples demonstrate how to use DesignWare VIP in a SystemVerilog/VMM testbench.

After the DesignWare 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 ExamplesThe basic example (tb_ahb_vmm_10_basic_sys) is fully explained in the QuickStart. It demonstrates the following:

❖ Instantiation

❖ Interconnection at the HDL level

❖ 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 ExampleThis 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_ahb_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 DesignWare AMBA VIP is installed, it is located at:


3. Navigate to the ‘design_dir’ directory you created and use either of the following methods to run the example:

a. Use the provided make file:

NoteNoteNoteNote Files generated as a result of the simulation may be placed in the current working directory where the simulation script is called.


www.designware.com




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_ahb_vmm_10_basic_sys -w example vcsvlog

To show more options, invoke ‘./run_ahb_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 ExampleThe intermediate example (tb_ahb_vmm_10_intermediate_sys) is fully explained in the QuickStart. It builds on the basic example to demonstrate the following:

❖ Scenario generators

❖ Responder transactions

❖ Scoreboard

❖ Functional coverage

2.2.7.3 Advanced SV/VMM ExampleThe advanced example (tb_ahb_vmm_10_advanced_sys) builds on the intermediate example to demonstrate the following:

✦ Master and slave subenvs

✦ Ending simulation with consensus

For information on installing and running an advanced example, see the ‘Running Examples’ section of the QuickStart. After DesignWare AMBA VIP is installed, the QuickStart is located at:


2.2.8 The Example Testbenches

Table 2-1 lists and describes the AHB object-based example testbenches that are included with the DesignWare DesignWare Verification IP. For each object-based testbench, Table 2-1 provides the dw_vip_setup command that creates a design directory, installs and sets up the testbench, and creates the sim script command. It also provides the specific simulation script commands you use to run the example testbench for any supported simulation environment.

Table 2-1 Example Testbenches for AHB VIP

Testbench Name and Details

ahb_rvm_sys

Description: Object-based interface testbench that uses two masters, two slaves, one bus, and one monitor. It makes use of atomic and scenario generators to generate the read and write transactions from different masters. The bus is responsible for controlling the grant between the two masters and routing the traffic to correct slave.

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

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


www.designware.com




Testbench Languages: Simulator: Sim Script Command

SVTB VCS: sim_ahb_rvm_sys vcsvlog svtb VCS MX: sim_ahb_rvm_sys vcsmxvlog svtb

sim_ahb_rvm_sys vcsvhdl svtb

ahb_vmm_simple_example

Description: Object-based interface testbench that uses two masters, two slaves, one bus, and one monitor. It makes use of atomic and scenario generators to generate the read and write transactions from different masters. The bus is responsible for controlling the grant between the two masters and routing the traffic to correct slave.

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

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


SVTB VCS: sim_ahb_vmm_simple_example vcsvlog svtb VCS MX: sim_ahb_vmm_simple_example vcsmxvlog svtb

sim_ahb_vmm_simple_example vcsvhdl svtb

amba/tb_ahb_vmm_10_basic_sys

Description: Object-based interface testbench which uses one master, one slave, and one monitor VIP. The testbench illustrates how to use the VIP and integrate it into your testbench. The environment makes use of simple atomic generator and also shows how to generate the directed transactions from the Master side.

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

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


SVTB VCS: run_ahb_vmm_10_basic_sys example vcsvlog run_ahb_vmm_10_basic_sys all vcsvlog

VCS MX: run_ahb_vmm_10_basic_sys example vcsmxvlog

run_ahb_vmm_10_basic_sys all vcsmxvlog

amba/tb_ahb_vmm_10_intermediate_sys

Description: Object-based interface testbench which uses one master, one slave, and one monitor VIP. The example illustrates scoreboarding using the VMM datastream scoreboard and how to use the predefined coverage and develop custom coverage.

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

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




www.designware.com




2.2.9 Examining the Example Testbenches

The example testbench is commented to show you how they are structured and how they function. The testbenches are is in the following locations (using “design_dir” as your user-created DesignWare Verification IP directory):

design_dir/examples/ahb_rvm_sys/svtb/ahb_rvm_sys_tst.sv

2.2.9.1 Example Testbench ContentsThe example testbench demonstrates how to integrate the DesignWare VIP into an VMM testbench, and consists of two masters, two slaves, and a monitor:

❖ Dummy master is referred as master 0.

❖ Master 2 has higher priority over master 1.

❖ Master 0 is the default master.

❖ Slave 0 is default slave.

❖ Slave 1 and Slave 2 have 1Mbyte memory.

The testbench shows how to:

❖ Integrate the DesignWare VIP into testbench


SVTB VCS: run_ahb_vmm_10_intermediate_sys example

vcsvlog run_ahb_vmm_10_intermediate_sys all vcsvlog

VCS MX: run_ahb_vmm_10_intermediate_sys example

vcsmxvlog

run_ahb_vmm_10_intermediate_sys all vcsmxvlog

amba/tb_ahb_vmm_10_advanced_sys

Description: Object-based interface testbench that makes use of one master, one slave, and 2 monitor VIP. The testbench consists of two sub env components - master/monitor and slave/monitor pairs. There is a scoreboard class to do end to end checking of the data. The scenario generator generates the transactions from the master side. The testbench also uses the VMM consensus class to arrive at the end of simulation.

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

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


SVTB VCS: run_ahb_vmm_10_advanced_sys example vcsvlog run_ahb_vmm_10_advanced_sys all vcsvlog

VCS MX: run_ahb_vmm_10_advanced_sys example vcsmxvlog

run_ahb_vmm_10_advanced_sys all vcsmxvlog




www.designware.com




❖ Use channels to communicate with the testbench

❖ Use channel and configuration object handles, with their constructor calls

The testbench includes the following:

❖ Constraints that define the transaction, configuration, and error injection data objects

❖ Testbench objects such as a transaction generator, traffic sink, and scoreboard

❖ Testbench techniques that comply with the VMM coding style

2.2.10 What’s Next?

If you successfully simulated the example testbench using the simulation scripts, you have proven that the AHB Verification IP is correctly installed and ready to use in your own testbench.

To learn more about using AHB Verification IP with VMM, refer to “Integration with VMM” on page 39.

The remainder of this section describes the details of the different steps you performed during installation and setup.

2.3 Licensing InformationThe DesignWare Verification IP uses the Synopsys Common Licensing (SCL) software to control its usage. You can find general SCL information at:


The AHB Verification IP uses a licensing mechanism that is enabled by one of several license features. The default order for a DesignWare ASIC Regression Library model is:

1. DesignWare-AMBA-VIP, if available

2. DesignWare-Regression license or VCS-Verification-Library license, if available

3. DesignWare license, if available

Only one license is consumed per simulation session, no matter how many VIP models are instantiated in the design.

The licensing keys must reside in files that are indicated by specific environment variables. For information about setting these licensing environment variables, refer to “Environment Variable and Path Settings” on page 25.

2.3.1 Specifying License Files

Synopsys license keys must be in a file location defined by one of the following environment variables. These variables are listed in order of precedence for DesignWare VIP.

1. DW_LICENSE_FILE If set, DesignWare VIP ignores all other license file variables in this list. To improve the performance of license checkout for DesignWare VIP, use this variable and set it only to snpslmd license servers that contain DesignWare VIP licenses.

2. SNPSLMD_LICENSE_FILE If set, it overrides the LM_LICENSE_FILE variable, if also set.

AttentionFor information on checking the license versions, see the DesignWare AMBA/AXI Verification IP Release Notes.



www.designware.com




3. LM_LICENSE_FILE Used only when the other variables in this list are unset.

2.3.2 License Features for DesignWare VIP

All DesignWare VIP suites have a common licensing mechanism, which is enabled by one of several license features. The order for acquiring a license during a run is:

1. DESIGNWARE-suite-VIP, if available (for example, DESIGNWARE-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 DesignWare VIP models are instantiated in the design.

2.3.3 Controlling License Usage

To limit the type of licenses that DesignWare VIP uses, define the DW_LICENSE_OVERRIDE environment variable. The general form is:

% setenv DW_LICENSE_OVERRIDE “feature1 feature2 ...”

When this variable is set, DesignWare VIP licensing behavior is as follows:

❖ Only the features specified in this list are used for licensing DesignWare 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 DesignWare VIP”. Ranking features or changing the checkout request order is not supported.

❖ If none of the features in the list are available, authorization for DesignWare VIP is denied.

❖ If a specified license feature is not available, a license error message is issued.

Examples:

❖ To use only a DesignWare Library license:

% setenv DW_LICENSE_OVERRIDE “DESIGNWARE”

❖ To exclude DesignWare Library licenses from being used to authorize DesignWare 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 DesignWare AMBA VIP suite license:

% setenv DW_LICENSE_OVERRIDE “DESIGNWARE-AMBA-VIP”

With this final example, authorization for DesignWare VIP suites other than AMBA is denied.

If DW_LICENSE_OVERRIDE is set to any value and the corresponding feature is not available, a license error message is issued.


www.designware.com




2.3.4 If Licensing Fails

By default, simulations exit with an error when a DesignWare VIP license cannot be secured. Alternatively, the DW_NOAUTH_CONTINUE environment variable can be set to allow simulations to continue when one or more VIP models fail to authorize. Unauthorized DesignWare VIP models essentially become disabled when DW_NOAUTH_CONTINUE is set to any value.

% setenv DW_NOAUTH_CONTINUE

Also, some simulation environments allow license polling, which pauses the simulation until a license is

available. License polling is described next.

2.3.5 License Polling

If you request a license and none are available, license polling allows your request to exist until a license 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, license polling is disabled.

2.3.6 Simulation License Suspension

All DesignWare/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 the license token back out when the simulation is resumed.

2.3.7 URG License

DesignWare VIP products include a license for URG, the tool you can use for viewing Vera coverage reports (Vera 2005.12 and later). The license key is as follows:

VT_CoverageURG

This key should be located with the other DesignWare VIP license keys.

2.4 Environment Variable and Path SettingsThe following are environment variables and path settings required by the DesignWare 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 and 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 variable.

2.4.1 Simulator Specific Settings

Your simulation environment and PATH variables must be set up as required to support your simulator.

Additionally, if you use NC-Verilog or NC-VHDL, make the following additional settings:

❖ CDS_INST_DIR: Set this variable to the NC-Verilog or NC-VHDL installation directory.


www.designware.com




❖ Include the following in your PATH environment variable:

$CDS_INST_DIR/tools/bin

2.5 Determining Your Model VersionThe following steps tell you how to check the version of the models you are using.

❖ 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 -p design_dir_path -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 AHB Verification IP that is available from Synopsys, navigate to your product beginning at the following web page:

http://www.synopsys.com/products/designware/

2.6 Integrating DesignWare VIP into Your TestbenchAfter installing DesignWare VIP, perform the procedures in the following subsections to set up the models for use in testbenches:

❖ Creating a Design Directory

❖ Running dw_vip_setup

❖ Using Verification IP in Your Testbench

2.6.1 Creating a Design Directory

You use dw_vip_setup to copy all necessary files to a user-specified design directory, or to the current working directory when no design directory is specified. The design directory has a testbench configuration and contains example testbenches provided by Synopsys.

The design directory includes:

❖ A design configuration file (.dw_vip.cfg) – A database of all models being used for this testbench configuration. This file also tracks the VMT library. The dw_vip_setup program can read this database to rebuild or recreate a design setup.

❖ An “include” directory – Contains all files and directories required to use the models in your testbench.

NoteNoteNoteNote Verification IP products are released and versioned by the suite and not by individual model. The version number of a model indicates the suite version.

AttentionDo not modify the design configuration file because the dw_vip_setup script depends on the original contents.

http://www.synopsys.com/products/designware/


www.designware.com




❖ An “examples” directory – If an example was requested on the command line, this directory contains all files required for model, suite, or system testbenches. This is where generated simulation scripts from dw_vip_setup are stored.

Following are the design directory characteristics:

❖ You must use dw_vip_setup to add the models to your design directory.

❖ You must use the supported Vera, OS, and simulator versions, as identified in the release notes.

❖ If you move the design directory, the paths to the include files in your testbenches must be revised. Also, any simulation scripts in the examples directory will need to be recreated.

2.6.2 Running dw_vip_setup

Before using the AHB Verification IP, you must run dw_vip_setup to set up the models or system testbenches, and to get information about your installation or design directory.

The setup program performs the following operations:

❖ Adds or removes models from a design

❖ Builds all required library files

❖ Retrieves model or system testbenches

The remainder of this section includes the following topics:

❖ “Setting Environment Variables”

❖ “The dw_vip_setup Command”

❖ “Examples of dw_vip_setup”

2.6.2.1 Setting Environment Variables

Before running dw_vip_setup, the following environment variables must be set:

DESIGNWARE_HOME – Points to where the model is installed.

2.6.2.2 The dw_vip_setup CommandYou invoke dw_vip_setup from the command prompt. The dw_vip_setup program checks command line argument syntax and makes sure that the requested input files exist. The general form of the command is either:

% 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.

switch The switch argument defines dw_vip_setup operation. Table 2-2 lists the switches and their applicable sub-switches.

model The model argument specifies 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.

The names of the VMM models are: ahb_master_rvm_vera_vmt


www.designware.com




ahb_slave_rvm_vera_vmt ahb_monitor_rvm_vera_vmt ahb_bus_rvm_vera_vmt

You may specify a version for each listed model, using the -version option. If 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 to 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 file contains:

_model_name_vmt [-v version] –or– # Comments

NoteNoteNoteNote The dw_vip_setup program treats all lines beginning with “#” as comments.

Table 2-2 Setup Program Switch Descriptions

Switch Description

-a[dd] (model [-v[ersion] version]) …

Adds the specified models to the design directory or current working directory. If you do not specify a version, the latest version is assumed.The names of the VMM models are: ahb_master_rvm_vera_vmt ahb_slave_rvm_vera_vmt ahb_monitor_rvm_vera_vmt ahb_bus_rvm_vera_vmt 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.The names of the VMM models are: ahb_master_rvm_vera_vmt ahb_slave_rvm_vera_vmt ahb_monitor_rvm_vera_vmt ahb_bus_rvm_vera_vmt


www.designware.com




-u[pdate] (model [-v[ersion] version]) …

Updates to the specified model version for the specified model or models. The dw_vip_setup program updates to the latest models when you do not specify a version. The names of the VMM models are: ahb_master_rvm_vera_vmt ahb_slave_rvm_vera_vmt ahb_monitor_rvm_vera_vmt ahb_bus_rvm_vera_vmt 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/scenerio} [-v[ersion] version]

The dw_vip_setup program configures a testbench example for a single model or a system testbench of a group of models. The program creates a simulator run program for all supported simulators.The scenario option of the -example switch configures an entire system testbench; dw_vip_setup automatically gets all of the models needed for that scenario.To configure a system testbench for the DesignWare Verification IP, issue the following command:

dw_vip_setup -e ahb_rvm_sysNote: The DesignWare Verification IP only allows you to configure a scenario. The model/scenario option of the -example switch is not available and returns an error.Note: Use the -info switch to list all available examples.

-svtb Use this switch when using SystemVerilog. The resulting design directory is streamlined, but can only be used with SystemVerilog simulations.

-c[lean] {scenario | model/scenerio} 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.

Table 2-2 Setup Program Switch Descriptions (Continued)

Switch Description


www.designware.com




2.6.2.3 Examples of dw_vip_setupThis section contains examples that show common usage scenarios.

2.6.2.3.1 Getting Installation or Design InformationThe following example lists the individual model and multi-model system and stand-alone testbenches that are available:

% $DESIGNWARE_HOME/bin/dw_vip_setup -i home

2.6.2.3.2 Adding ModelsThe following example shows how to add or update the ahb_master_rvm_vera_vmt model to your design directory:

% $DESIGNWARE_HOME/bin/dw_vip_setup -a ahb_master_rvm_vera_vmt -svtb

The setup program does the following:

1. Creates an include directory under the current directory and copies all files in the ahb_master_rvm_vera_vmt model include directory, all include files in the VIP suite, and the latest VMT library include files into the include directory.

2. Creates the ahb_master_rvm_vera_vmt vro file, DesignWare Verification IP suite libraries and VMT libraries.

2.6.2.3.3 Removing ModelsThis example shows how to remove all listed models in the design directory at “/d/test2/daily” using the model list in the file “del_list” in the scratch directory under your home directory. The dw_vip_setup program command line is:

% $DESIGNWARE_HOME/bin/dw_vip_setup -p /d/test2/daily -r -m ~/scratch/del_list

The setup program removes the models in the del_list file, but does not remove any Vera object (.vro) files or include files.

2.6.2.3.4 Creating and Running a Simulation Script for the Example TestbenchThe dw_vip_setup utility can create a simulation script to run an example testbench. The following example shows how to create the simulation script for the VMM system testbench.

% $DESIGNWARE_HOME/bin/dw_vip_setup -path my_design_dir -example ahb_rvm_sys -svtb

Given this example, the simulation script would be located at:

my_design/examples/ahb_rvm_sys/sim_ahb_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[-execution] [control_language]svtb

The arguments are as follows (only the supported arguments are shown here):

-h[elp] Returns a list of valid dw_vip_setup switches and the correct syntax for each.

Table 2-2 Setup Program Switch Descriptions (Continued)

Switch Description


www.designware.com




❖ -64 – Optional. When using either VCS (or VCS MX) with NTB or Pioneer NTB on a 64-bit platform, specify this argument to achieve a full 64-bit run. The default is a 32-bit run. (For other simulators, the VERA_HOME variable determines the platform bit size.)

❖ -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

-execution – Optional. Engine that executes the VIP code. Choices are:

✦ none (default) – The VIP is compiled and executed by Vera software unless the control_language is ntb or svtb

✦ svtb – The controlling testbench is in SystemVerilog and it runs in VCS with NTB

For VCS and VCS MX, simulation scripts generate a compile log file (compile.log) and a simulation log file (simulate.log) in the current working directory (except when the top level is VHDL, and then the output is sent only to the transcript window).

The following examples show you how to run the example testbench using my_design as your design directory.

❖ To run the SystemVerilog VMM example with a Verilog top-level in:

VCS:

% my_design/examples/ahb_rvm_sys/sim_ahb_rvm_sys vcsvlog svtb

VCS MX:

% my_design/examples/ahb_rvm_sys/sim_ahb_rvm_sys vcsmxvlog svtb

❖ To run the SystemVerilog VMM example with a VHDL top-level in:

VCS MX:

% my_design/examples/ahb_rvm_sys/sim_ahb_rvm_sys vcsvhdl svtb

2.6.2.4 Viewing Qualified Simulator SwitchesThis section describes how to view the set of simulation switches used during product qualification. The 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 a DesignWare VIP example testbench. Make sure that the command matches your simulation environment.

The following command is appropriate when running DesignWare VIP in VCS using OpenVera Native Testbench capability. Specify an example testbench that is included in your DesignWare VIP. Here, the axi_rvm_sys example is used:

% dw_vip_setup -path <design_dir> -example ahb_rvm_sys -ntb


www.designware.com




For a full description of the dw_vip_setup command, see “The dw_vip_setup Command” on page 27

2. Change directory to the example:

% cd <design_dir>/examples/ahb_rvm_sys

3. Run the simulation script that fits your simulation environment, and make sure to include the -n switch (described in “Creating and Running a Simulation Script for the Example Testbench”).

For this example, the command is:

% ./sim_ahb_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/ahb_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 DesignWare Verification IP release can be used in SystemVerilog VMM testbenches. After running dw_vip_setup, follow the procedure below.

2.6.3.1 SystemVerilog UsersFollow these steps to use the VMM transactor models in a SystemVerilog environment:

1. Create a SystemVerilog program that will control the model. For each AHB transactor that you are using, include the appropriate files in the testbench:

design_dir/include/svtb/AhbMasterInterface.svi design_dir/include/svtb/AhbSlaveInterface.svi design_dir/include/svtb/AhbMonitorInterface.svi design_dir/include/svtb/AhbBusInterface.svi

These files define the interface modports that the AHB transactors require for proper connections.

2. Do the following things in your SystemVerilog testbench:

a. Pass a reference to the desired modport to connect to the transactor. Do this for each instance of each transactor you are using. For example, the bold portion refers to the Master modport of the AhbMasterInterface interface:

program automatic AhbSystemTest( AhbMasterInterface.Master AhbMasterBind1, ... );

b. Import the entire contents of the model package for the each AHB transactor you are using. This step gives you access to all the elements of the AHB transactor. For example:

// import the AHB transactor elementsimport AhbMaster_rvm::*;...

c. Connect to the interface when you instantiate and construct the transactor, as shown next:

dw_vip_ahb_master_rvm master; ...master = new("AHB MASTER1",AhbMasterBind1,cfg_m1,gen1.out_chan,master_outchan1);


www.designware.com




...

d. Within your program's initial block, include a call to the setSystemClock method, as shown next:

initial begin setSystemClock(test_top.SystemClock);

The setSystemClock method needs to be provided with the clock that will be the "system clock" 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 are using only one VIP, it is easiest to use the same clock that is driving your transactors. If you are verifying a particular portion of a system, you can use the main clock for that portion. If you are simulating with several VIPs, choose a top-level clock that has a known relationship with each VIP.

3. For a Verilog top testbench, continue with the following steps. (For a VHDL top testbench, see the next step)

a. Instantiate the required instances of the interface, and then complete the connection:

...ìnclude "AhbMasterInterface.svi"ìnclude "AhbSlaveInterface.svi"ìnclude "AhbMonitorInterface.svi"ìnclude "AhbBusInterface.svi"

module test_top; parameter simulation_cycle = 100 ; wire hresetn; wire hclk;

wire [ÀHB_HADDR_WIDTH-1:0] haddr_m1; wire [ÀHB_HBURST_WIDTH-1:0] hburst_m1; wire hbusreq_m1;...AhbMasterInterface intf_m1( .hclk ( hclk ), .hresetn ( hresetn ), .hgrant (hgrant_m1), .hrdata ( hrdata ), .hready ( hready ), .hresp ( hresp ),

... );...

AhbSystemTest tb(intf_m1.Master, ...);initial begin @(posedge TestDone); $finish; end initial begin SystemClock = 0 ;ìfdef WAVES $dumpvars;èndif

forever begin #(simulation_cycle/2)


www.designware.com




SystemClock = ~SystemClock ; end end

assign hclk = SystemClock ; assign hresetn = resetReg;endmodule

b. Build the simulator executable and run the test:

For VCS, use the following commands:

Figure 2-1 Compilation for VCS with SystemVerilog

In the example above, the “-ntb_incdir” lines specify several include directories that DesignWare VIP models require. In the order of appearance, they specify the following:

✧ OpenVera include (one per executable)✧ VMT include (one per executable)✧ VIP suite includes (one per VIP suite of models in the design)✧ AHB protocol model includes (one per transactor model in the design)✧ AHB 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 be specified, accomplished by $DESIGN_DIR/include/vera in the sample below. The NTB testbench is specified via the hdl_files option.

ii. Second, issue the vcs compile command. The following sample shows the vlogan and vcs commands for the ahb_rvm_sys example testbench:

${VCS_HOME}/bin/vcs -sverilog ${vcsflags} -ntb_define NTB -ntb_opts rvm -ntb_opts use_ntbpp -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/ahb_master_vmt/vera/src -ntb_incdir ${DESIGNWARE_HOME}/vip/amba/latest/ahb_master_rvm_vera_vmt/vera/src ahb_master_rvm.pkg ahb_master_vmt_tst.sv ahb_master_vmt_tst_svtb.v -ntb_incdir ${DESIGNWARE_HOME}/vip/amba/latest/ahb_slave_vmt/vera/src -ntb_incdir ${DESIGNWARE_HOME}/vip/amba/latest/ahb_slave_rvm_vera_vmt/vera/src ahb_slave_rvm.pkg ahb_slave_vmt_tst.sv ahb_slave_vmt_tst_svtb.v -ntb_incdir ${DESIGNWARE_HOME}/vip/amba/latest/ahb_monitor_vmt/vera/src -ntb_incdir ${DESIGNWARE_HOME}/vip/amba/latest/ahb_monitor_rvm_vera_vmt/vera/src ahb_monitor_rvm.pkg ahb_monitor_vmt_tst.sv ahb_monitor_vmt_tst_svtb.v -ntb_incdir ${DESIGNWARE_HOME}/vip/amba/latest/ahb_bus_vmt/vera/src -ntb_incdir ${DESIGNWARE_HOME}/vip/amba/latest/ahb_bus_rvm_vera_vmt/vera/src ahb_bus_rvm.pkg ahb_bus_vmt_tst.sv ahb_bus_vmt_tst_svtb.v simvcssvtb run


www.designware.com




Figure 2-2 VCS MX Command for SystemVerilog Testbench with Verilog 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 ahb_rvm_sys_tst_svtb_wrap.v:

ìnclude "AhbMasterInterface.svi"ìnclude "AhbSlaveInterface.svi"ìnclude "AhbMonitorInterface.svi"ìnclude "AhbBusInterface.svi"

module test_top( hresetn, hclk, haddr_m1, ... ); inout hresetn; input hclk; inout [ÀHB_HADDR_WIDTH-1:0] haddr_m1; inout [ÀHB_HADDR_WIDTH-1:0] haddr_m2;...AhbMasterInterface intf_m1( .hclk ( hclk ), .hresetn ( hresetn ), .hgrant (hgrant_m1),

... );...AhbSlaveInterface intf_s1( .hclk ( hclk ), .hresetn ( hresetn ), .haddr ( haddr ),

... );...AhbMonitorInterface intf_mon( .haddr ( haddr ), .hburst ( hburst ), .hclk ( hclk ),

... );AhbBusInterface intf_bus(

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 +define+NTB +incdir+$DESIGN_DIR/include/verilog+$DESIGN_DIR/include/svtb+$DESIGN_DIR/examples/ahb_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+$DESIGNWARE_HOME/vip/amba/latest/ahb_master_vmt/vera/src+$DESIGNWARE_HOME/vip/amba/latest/ahb_slave_vmt/vera/src+/$DESIGNWARE_HOME/vip/amba/latest/ahb_monitor_vmt/vera/src+/$DESIGNWARE_HOME/vip/amba/latest/ahb_bus_vmt/vera/src+$DESIGNWARE_HOME/vip/amba/latest/ahb_master_rvm_vera_vmt/vera/src+$DESIGNWARE_HOME/vip/amba/latest/ahb_slave_rvm_vera_vmt/vera/src+$DESIGNWARE_HOME/vip/amba/latest/ahb_monitor_rvm_vera_vmt/vera/src+$DESIGNWARE_HOME/vip/amba/latest/ahb_bus_rvm_vera_vmt/vera/src

vcs -ntb_opts use_sigprop -o simvcssvtb test_top


www.designware.com




.hresetn (hresetn), .hclk (hclk), .haddr_m1 (haddr_m1),

... );AhbSystemTest tb( intf_m1.Master, ..., intf_s1.Slave, ..., intf_mon.Monitor, intf_bus.Bus); always @ (hclk) SystemClock <= hclk;endmodule

b. Instantiate and connect the module from the Verilog wrapper in a VHDL top-level testbench:

LIBRARY IEEE;...USE work.dw_vip_amba_ahb_common_pkg.all;USE work.all;ENTITY test_top_vhdl ISEND test_top_vhdl;

ARCHITECTURE cfgtest OF test_top_vhdl IS CONSTANT AHB_CLOCK_PERIOD : time := 100 ns; ... SIGNAL hresetn : std_logic; SIGNAL hclk : std_logic; ... COMPONENT test_top PORT (

hresetn : inout std_logic; hclk : in std_logic;

... );END COMPONENT;BEGIN u1 : test_top port map (

hresetn=> hresetn hclk=> hclk,

... ); clkgen : PROCESS BEGIN if(testDone /= '1') then

hclk <= '0'; wait for AHB_CLOCK_PERIOD/2; hclk <= '1'; wait for AHB_CLOCK_PERIOD/2; else wait; end if;

... END PROCESS clkgen;

...

AttentionNote the special treatment of the system clock above. It has to be a register in the Verilog wrapper testbench and connected by the SystemVerilog program with a call to setSystemClock().


www.designware.com




c. Compile the simulation using the VCS MX Unified Usage Model, as follows:

i. First, 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_files option.

Figure 2-3 Vlogan Command for SystemVerilog Testbench with VHDL Top

ii. Second, analyze the VHDL code. This includes all of the model and suite packages in addition to the VHDL top-level design:

Figure 2-4 Vhdlan Command for SystemVerilog Testbench with VHDL Top

iii. Last, 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:

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 dw_vip -ntb +incdir+{$DESIGN_DIR}/include/verilog+{$DESIGN_DIR}/include/svtb+{$DESIGN_DIR}/examples/ahb_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/latest/vera/src+{$DESIGNWARE_HOME}/vip/amba/latest/ahb_monitor_vmt/vera/src+{$DESIGNWARE_HOME}/vip/amba/latest/ahb_master_vmt/vera/src+{$DESIGNWARE_HOME}/vip/amba/latest/ahb_slave_vmt/vera/src+{$DESIGNWARE_HOME}/vip/amba/latest/ahb_bus_vmt/vera/src+{$DESIGNWARE_HOME}/vip/amba/latest/ahb_monitor_rvm_vera_vmt/vera/src+{$DESIGNWARE_HOME}/vip/amba/latest/ahb_master_rvm_vera_vmt/vera/src+{$DESIGNWARE_HOME}/vip/amba/latest/ahb_slave_rvm_vera_vmt/vera/src+{$DESIGNWARE_HOME}/vip/amba/latest/ahb_slave_rvm_vera_vmt/vera/src

vhdlan $design_dir/include/vhdl/vmt_pkg.vhd $DESIGN_DIR/include/vhdl/AmbaCommonDefines.vhd $DESIGN_DIR/include/vhdl/AhbCommonDefines.vhd $DESIGN_DIR/include/vhdl/AhbMonitorDefines.vhd $DESIGN_DIR/include/vhdl/AhbMasterDefines.vhd $DESIGN_DIR/include/vhdl/AhbSlaveDefines.vhd $DESIGN_DIR/include/vhdl/AhbBusDefines.vhd $DESIGN_DIR/examples/ahb_rvm_sys/ntb/ahb_rvm_sys_tst.vhd


www.designware.com





www.designware.com


AMBA AHB Verification IP VMM User Manual Integration with VMM


3Integration with VMM

This chapter contains the following sections:

❖ “Overview of VMM”

❖ “DesignWare VIP in a VMM Environment” on page 42

❖ “VMM Features Provided by AHB DesignWare VIP” on page 56

❖ “Class and Variable Naming Conventions” on page 57

❖ “Base Classes for AHB DesignWare VIP” on page 58

❖ “Using the AHB Master” on page 64

❖ “Using the AHB Slave” on page 76

❖ “Using the AHB Monitor” on page 88

❖ “Using the AHB Bus” on page 100

3.1 Overview of VMMThe Verification Methodology Manual (VMM) for SystemVerilog is an object-oriented approach. It provides a blueprint methodology so that testbench code is effectively organized for constrained random testing. The resulting structure also supports directed testing, so it serves all verification needs. VMM consists of three 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 testing, and the need to develop code efficiently are all encapsulated in the VMM approach. To achieve its goals, VMM prescribes an overall testbench organization that impacts the way testbench code is written.


www.designware.com


Integration with VMM AMBA AHB Verification IP VMM User Manual


Here are some highlights of the VMM approach:

❖ Most of the code is dedicated to setting up dynamic processes in advance. Everything is already programmed by the time the test is started.

❖ Test conditions are controlled by constraints instead of procedural code.

❖ Tests dynamically react to significant events. For example, a testbench must be able to detect the end 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 in order to maximize reuse and guarantee interoperability.

❖ A standard testbench sequence template is used (build-configure-execute-report). Each testbench uses the template and fills in the details according to its needs.

❖ Orientation shifts from procedures and directed tests to objects, randomization, and constraints.

3.1.1 Base Classes

In an object-oriented programming environment, a set of base classes form the foundation for the entire system. Base classes provide common functionality and structure. Because most objects will be derived from them, a well-architected set of base classes is essential to the end goal of an effective programming environment.

The SystemVerilog verification methodology (VMM) base classes are specifically designed for the VMM approach to verification. They provide common functionality and structure needed for simulation (such as logging), and they support any sort of verification task.

The DesignWare 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 writing your own logging routine, you can reuse the vmm_log class. With inheritance, extension, and polymorphism, many opportunities exist for customization.

Important VMM base classes used by the DesignWare 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

This chapter assumes that you are familiar with OpenVera (OV), SystemVerilog and VMM. For more information:

❖ For the IEEE SystemVerilog standard, refer to 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, refer toVerification 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, refer to SystemVerilog Testbench Constructs, at $VCS_HOME/doc/UserGuide/svtb.pdf


www.designware.com




3.2 Benefits of DesignWare VIP and VMM

3.2.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 an object-oriented language, improved modularity is a key element in any VMM system. Better modularity simplifies development and reduces maintenance. DesignWare VIP models provide both protocol functionality and control features in a complete, self-contained package that fully supports the modular architecture of VMM and simplifies the development of VMM testbenches. This gives you a modular foundation layer over which you can quickly build a robust testbench.

3.2.2 Efficiency of Abstraction

VMM is based on object-oriented programming (OOP). DesignWare VIP abstracts protocol transactions into objects and provides an object-based interface allowing the engineer to work in logical protocol terms without worrying about implementation details. With protocols becoming more complex, this abstraction is a big boost as 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 create complex systems. For example, a typical webcam transports video data stacked on top of the Ethernet protocol.

3.2.3 Rapid creation of complex tests

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

3.2.4 Increased Reuse

Opportunities for reuse are extensive when using DesignWare VIP and VMM. DesignWare VIP models are inherently reusable blocks 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 reusable components. VMM even provides a template for a standard testbench flow that can be customized to suit specific needs. The base classes provide reuse through inheritance. Reuse is a central theme for DesignWare VIP with VMM, enabling maximum leverage of this critical design concept.


www.designware.com




3.3 DesignWare VIP in a VMM Environment Figure 3-1 shows where the DesignWare VIP fits into the VMM methodology. In the layered approach that is typical for VMM, the DesignWare VIP (light green) fits into the lower levels, which allows you to focus on higher levels of abstraction.

Figure 3-1 DesignWare VIP in VMM Architecture

Channels provide the interface between verification components. Channels provide a consistent yet flexible way to connect the elements within the verification environment. They enhance modularity, layering, and scalability. This allows the pieces to be stacked on top of each other or interchanged.

Tests

Generators

Transactor Self Check Checker

MonitorDriver

DUT

DesignWare VIP Fu

nct

ion

al C

ove

rag

e

Note: dashed lines ( - - - -) represent VMM channels

Scenario Layer

Functional Layer

Command Layer

Signal Layer

Test Layer


www.designware.com




3.3.1 Sample Test Environment

The elements 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 testbench. From these elements, you can create a VMM-based test environment that might resemble Figure 3-2 below.

Figure 3-2 Sample VMM Test Environment

Instead of defining many individual directed tests, as with traditional verification, the VMM flow is based on defining several objects that reflect the requirements of the design under test (DUT) and the test environment. These objects perform fundamental test operations such as configuring the DesignWare VIP (to match the DUT) and generating transactions. These objects contain randomizable attributes that vary within the constraints that are defined. DesignWare VIP provides valid range constraints that keep them within operating limits, and a set of reasonable 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 configuration 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 random transactions are performed.

As shown above in Figure 3-2, a source generator creates transaction objects and puts them into a channel that connects with the transactor. You can define your own generator or you can use the atomic or scenario 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 AHB transaction objects and submits them to the transactor input channel. The transactor then creates the transaction bus protocol. You can define your own generator or you can call 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 length. Randomizing the transaction objects is the primary way to take advantage of the VMM approach.

Channel

Channel

DesignWare VIP Transactor

In

Out

Source Generator

Sink

Scoreboard

Sink

SourceLog

Port Model

System Configuration

Port Model Configuration

DUT

Out

In


www.designware.com




3.3.2 VMM Support in DesignWare Verification IP

In DesignWare VIP, VMM-compliant classes and attributes (members) are provided to represent protocol activity and the characteristics of that activity. For example, a transaction object has members that might define a requestor ID, the payload size, routing, and so on. The definitions of these transaction objects, along with the channels that handle them, form the interface between testbench and DesignWare VIP. To create traffic, a user simply generates an object of the appropriate type and calls the put_t() task of the corresponding input channel.

DesignWare VIP includes transactor models that interact with a VMM testbench.

Figure 3-3 Verification IP for VMM

❖ VMM Testbench: User created; puts objects into and gets objects out of an channel. Typical objects define the test configuration and transactions.

❖ Channels: Provide a conduit for passing data between the testbench and the VIP transactor. For more information about channels, see “Channels” on page 44.

❖ VIP transactor: Puts transaction objects into and gets transaction objects out of VMM channels. Internally, it translates objects into terms that the base protocol model understands. The VIP transactor model is fully compliant to fit into your VMM test environment.

❖ Base protocol model: Internally provides protocol functionality. Base protocol models are not directly accessible to the user.

3.3.3 DesignWare VIP Objects

The DesignWare VIP defines several classes that were designed for a VMM environment. This section introduces the major DesignWare VIP objects, which define channels, configurations, transactions, and callbacks.

3.3.3.1 ChannelsChannels provide a standard interface for passing data objects between components in a VMM testbench. Channels natively handle objects of type vmm_data. To define a channel, the DesignWare VIP extends the vmm_channel base class to support a data object that was derived from vmm_data. The data objects, which typically represent protocol transactions, can be pushed into or pulled out of a channel. So, to interface two 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 between components can be standardized.

Testbench

VIP Transactor

Channels

Protocol Pins

transactor provides compliance

DUT


www.designware.com




Given the definition of the data object class that a channel was created for, any component that can generate that type of data object can put one into the channel, and any component that can operate on that type of data object can get one out of the channel. Modularity is achieved because each side of the channel needs no 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 channels pass transaction objects from the testbench to a transactor in order to create stimulus to be driven on a bus.

❖ Output: Channels can pass objects from a transactor to the testbench. Typically, these objects are 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.

Within each transactor class, the channels are named as follows:

❖ AhbMaster_rvm

✦ m_oTransactionInputChan

✦ m_oTransactionOutputChan

✦ m_oTransactionActivityChan

❖ AhbSlave_rvm

✦ m_oTransferInputChan

✦ m_oTransferOutputChan

✦ m_oAutoResponseInputChan

❖ AhbMonitor_rvm

✦ m_oTransactionActivityChan

Channels do not have to be used and can be left unconnected. In the new() method for each transactor, the channel arguments are optional. If a channel is not specified, a channel object is neither created nor connected. For channels that are unused, this allows the simulation to run more efficiently.

Table 3-1 summarizes the use of channels by the various interfaces.

3.3.3.2 Configuration Objects You configure the DesignWare VIP to fit your application. For this purpose, predefined configuration objects (extended from the vmm_data base class) are provided for use by transactors. The configuration objects support randomization and constraints, as described in “Constraints” on page 49.

Table 3-1 Summary of Channels Used by Model Transactors

AHB VMM Interface Output Channel Input Channel Activity Channel

Bus No No No

Master Yes (optional) Yes (required) No

Monitor No No Yes (optional)

Slave Yes (required in reactive mode, otherwise, No)

Yes (required) No


www.designware.com




You specify a configuration object in the constructor for a transactor. The configuration object must not be null and must be valid. If the configuration object is null, the simulation is halted. If the object is not null, the constructor calls the is_valid method of the configuration object. If this method returns true(1), then the transactor continues the construction; otherwise, it gives the following message and halts:

Invalid configuration provided to dw_vip_ahb_[master|slave|bus|monitor]_rvm :: new, unable to continue

To retrieve 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 used, the is_valid method ensures that the configuration object is valid. If it is not valid, the configuration is not changed.

The AHB transactors require that the configuration argument passed to change_xactor_config and get_xactor_config_t are AHB-specific configuration objects.

For AHB transactors, there are several levels of configuration, each defined by a class. As represented in Figure 3-4, the levels and corresponding classes are as follows:

AMBA configuration The dw_vip_amba_configuration is a base class that defines global AMBA bus features, such as data and address width. All AHB configuration classes extend this class. (Note that the configuration classes for the APB Verification IP also extend this class).

AHB system configuration The dw_vip_ahb_system_configuration class describes the overall system, such as the number of masters and slaves, as well as the memory map. This class contains two arrays for holding configurations describing the different masters and slaves in the system. The monitor and bus transactors use this configuration object.

AHB master configuration The dw_vip_ahb_master_configuration class describes a specific master in the system. This class includes randomizable members. To ensure consistency, the ‘new’ for this class includes a reference to the AHB system configuration, as indicated by an arrow in Figure 3-4.

AHB slave configuration The dw_vip_ahb_slave_configuration class describes a specific slave in the system. This class includes randomizable members. To ensure consistency, the ‘new’ for this class includes a reference to the AHB system configuration, as indicated by an arrow in Figure 3-4.


www.designware.com




Figure 3-4 AHB Configuration for Transactors

The first opportunity for submitting a configuration is in the constructor for the transactor. When a master or slave transactor is constructed, one of the arguments is a reference to the corresponding master or slave configuration, as indicated by arrows in Figure 3-4.

When a monitor or bus transactor is constructed, one of the arguments is a reference to the AHB system configuration (shown by arrows in Figure 3-4), which provides all the configuration information they require.

3.3.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 accessed 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 types of transaction objects, such as for different protocol layers.

The transaction objects support randomization and constraints, as described in “Constraints” on page 49.

Transaction objects support the use of generators and factories (for more information, see “Generators” on page 51 and “Factories” on page 52).

The AHB transaction objects are passed through the transactor channels and can be used to hold:

❖ A transaction request; for example:

✦ Master transactor gets dw_vip_ahb_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_ahb_monitor_transaction to the testbench

AMBA Configuration

AHB System Configuration

AHB Master_n AHB Master_2 AHB Master_1

AHB Bus TransactorAHB Master_n

AHB Master_2 AHB Master_1 Transactor

AHB Slave_n AHB Slave_2 AHB Slave_1

AHB Monitor Transactor

AHB Slave_n Transactor

AHB Slave_2 Transactor

AHB Slave_1 Transactor


www.designware.com




❖ A completed transaction, trapped by the master transactor; for example:

✦ Transaction completed on the bus

✦ Master transactor triggers notify at end of transaction

✦ Master transactor sends dw_vip_ahb_master_transaction result to output channel

The payload for all transaction types are stored in byte arrays. All transaction payloads are stored in little endian. If the system is configured as big endian, the transaction data is byte swapped by the model.

3.3.3.4 CallbacksCallbacks are an important part of the VMM and DesignWare VIP architecture, and they can be used for several applications. At their root, callbacks are an access mechanism. Among other uses, they enable the insertion of user-defined code and allow access to objects for scoreboarding and functional coverage.

For each transactor, DesignWare VIP includes a class that contains a set of callback methods. These methods are called as 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 unless they are extended. The exception to this rule is that some of the callback methods for functional coverage already contain a default implementation of a coverage model.

❖ The callback class is accessible to DesignWare VIP users so that the class can be extended and user code inserted.

❖ Callbacks are called within the sequential flow at places where external access would be useful. Additionally, the arguments to the methods include references to relevant data objects. For example, just before a transactor puts a transaction object into an output channel is a good place to sample for functional coverage, since the object reflects the activity that just happened on the pins. A callback at 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 loss of performance, callbacks are not executed by default. In order to use them, they must be registered using the append_callback() method of the transactor.

DesignWare 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 the DesignWare VIP:

❖ post-channel get callbacks: called after a transaction is pulled from the input channel; provided with a handle to the transaction gotten from the channel

❖ pre-channel put callbacks: called prior to putting a transaction out on output channel, provided 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 processing.

❖ channel coverage callbacks: called after the channel pre/post methods, providing a mechanism for producing VMM transaction coverage.


www.designware.com




❖ significant event coverage callbacks - called in response to significant events, such as a protocol error, providing a mechanism for producing significant event coverage.

3.3.3.5 Displaying DesignWare VIP Objects You can access a formatted presentation of the contents of a DesignWare VIP transaction or configuration object. Access is provided by the display() or psdisplay methods, which are provided with VMM base classes.

For some DesignWare VIP objects that are extended from rvm_data, the formatting follows a mapping convention for numeric values. The resulting numerical base that is used relates to the data type. These relationships are shown in Table 3-2.

3.3.4 Constraints

DesignWare VIP uses objects with constraints for transactions and configurations. The constraints define the range of randomized values that are used to create each object during the simulation. Tests in a VMM flow are primarily defined by constraints.

Classes that provide random attributes allow you to define the contents of the resulting object. When you call the randomize() method (defined in the vmm_data base class), all random attributes are randomized using all constraints that are enabled. Because dependencies exist between some attributes, some transactions use only a subset of the constraints.

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. Randomization is an additional way for the user to assign class members, and there are several ways to control the process. The follow techniques apply when working with randomization:

❖ Randomization only occurs when an object's randomize() method is called, and it is completely up 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.

❖ A user can assign a value to a member at any time. Randomization does not affect the other methods of assigning class members.

Table 3-2 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>


www.designware.com




Figure 3-5 shows the scope of the constraints that are part of the VMM solution for DesignWare VIP.

Figure 3-5 Valid Ranges, Reasonable Constraints, and User-Defined Constraints

❖ Valid range constraints:

✦ Provided with DesignWare 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 DesignWare VIP

✦ Keep values within protocol limits

✦ In some cases, keep simulations to a reasonable length and size

✦ Defined to be “reasonable” by Synopsys (you can override)

✦ May result in conditions that are a subset of the protocol

✦ On by default and can be turned off or modified (you 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 conflicts.

Valid Ranges

Reasonable Constraints

Valid Ranges Valid Ranges

Reasonable Constraints

Valid Ranges

User-Defined Constraints

Default ConstraintsUser-Defined Constraints


www.designware.com




3.3.5 Generators

You use generators to create constrained random objects, typically transactions. Generators make use of the built-in randomize() method and rely on constraints to limit the scope of the randomizations. A generator 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 with no particular relationship between them. The following generic code snippet illustrates an atomic generator 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 voidint 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_assign(anyXact, randomized_tr.copy()); anyXact.object_id = gen_cnt; gen_out_chan.put_t (anyXact); // Display the transaction msg = $psprintf(msg, "Copy of Transaction #%0d has been put in the channel",

gen_cnt);rvm‘vmm_note(log, msg);anyXact.display("tbd TX In CH: "); // The ENDED notification indicates the transaction has completed on the protocol void = anyXact.notify.wait_for_t(anyXact.vmm_data::ENDED); msg = $psprintf(msg, "Transaction #%0d has ended", gen_cnt); rvm‘vmm_note(log, msg);

}end

This example shows the essential parts of a generator, which include a while loop to control how many objects are generated. Inside the loop, randomize() is called. Then, a copy of the randomized transaction is 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 “on-the-spot”. In terms of reuse, the generator does not need to know anything about the factory object that it is randomizing (except for the class name). In the code above, the definition of randomized_tr does not affect the generator code. The constraints are the only object information included, and they could be included elsewhere (in an extended class). As a result, the generator code can be independent from the testbench code; it simply needs to be given a factory object to randomize. By simply providing another factory object, the generator produces objects based on the new template. This is one of the important opportunities that VMM provides for reducing test-specific code and increasing reuse.


www.designware.com




3.3.5.1 Generator Macros in VMMThere are numerous ways to code a random generator. As a recommended alternative, VMM provides two macros (vmm_atomic_gen and vmm_scenario_gen) that you can use to define a generator class. These generator macros accept an argument that defines the class to be used as the factory object. For detailed information about these macros, see the “Class Reference” appendix in the Verification Methodology Manual For SystemVerilog.

The vmm_scenario_gen macro creates a scenario generator that generates sequences of instances of the specified factory class. The sequence is represented as an array of objects. A scenario generator can be used for protocols that define sequences of activity where the individual transactions are related. Constraints define the rules governing the sequence of objects that the generator creates. When the array of transactions is randomized, an entire sequence is generated. A VMM scenario can even generate sequences of sequences.

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 rvm‘vmm_scenario_gen (dw_vip_anymodel_transaction, "AnyModel Gen")

The vmm_scenario_gen macro creates several classes based on the factory class argument. Note that the classes that are created rely on having a predefined channel, which is similarly named and provided by the DesignWare VIP.

For detailed information about generators, see “Generator Components” in the Verification Methodology Manual For SystemVerilogReference Verification Methodology User Guide.

3.3.6 Factories

The object that is provided to a generator is referred to as a factory, or factory object. It is a blueprint for randomization and serves as the template for the generated objects. A generator uses the factory to create streams of randomized transactions. Also, DesignWare VIP transactors rely on factory objects so user-defined extensions to a transaction class can be handled for scoreboarding.


www.designware.com




Figure 3-6 illustrates how a factory object works with a generator and a DesignWare VIP transactor.

Figure 3-6 Factories with DesignWare VIP

When using DesignWare VIP, the factory object is typically a transaction. In Figure 3-6, the code excerpt extends a DesignWare VIP transaction class and then establishes two instances to use as factory objects; one for the generator and one 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 constraints, the generator creates transactions and puts them into the input channel of the transactor. The transactor 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() method is used to ensure that the resulting object is of the extended type and not of the base type. Note that, for this type of object, the extended members are only initialized because the VIP does not process the functionality of the extra members. Handling any added members must be provided by the testbench.

Constructors for VIP VMM 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. Default transaction factories are created if the user fails to provide a factory in the constructor, as long as the corresponding channel exists.

3.3.7 Messages

Messages in VMM can be controlled individually or in groups. This section describes messages and how to use them.

Messages generated by VIP VMM transactors are compatible with the vmm_log base class. The messages originate in two scopes:

❖ Methodology messages that report base class conditions and errors

❖ Protocol-specific messages that report protocol conditions, events, and errors

class my_xact extends dw_vip_any_transaction {... }...factory1 = my_xact::new( ... )...factory2 = my_xact::new( ... )

Generatorfactory1

factory2

Scoreboard

Output Channel

TransactionTransaction


Transaction



Transaction

Input Channel

PinsDW VIP Transactor


www.designware.com




Messages can have a number of attributes, such as type, severity, ID, and text. Here are some qualities of these attributes:

❖ Type: Messages are categorized into types. The possible types are listed in Appendix A of the Reference Verification Methodology User GuideVerification 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 values for severity are listed in the Verification Methodology Manual For SystemVerilog in the description of 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 VMM supports and promotes identifying messages by string matching against a regular expression, the text is especially important for messages that do 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 to react to in your testbench, but do not display any text

For registered messages, the message descriptor that is returned from a vmm_log::wait_for_msg_t() method includes the message ID in its ID field. You can use the vmm_log::wait_for_msg_t() method with the message ID to capture the message event, or you can use the wait_for_t() method as shown next in “VMM Notify for Messages”.

Note that 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.3.7.1 VMM Notify for MessagesEach registered message or notification has an additional notify identifier member. The name of the notify ID is the original message ID with a suffix of “_NOTIFY_ID”. For example:

int VMT_MSGID_BLOCKED_STREAM_NOTIFY_ID = notify.configure();


www.designware.com




Given the relationship that the notify ID is <MSG_ID>_NOTIFY_ID, waiting on a message event in a VMM environment can be performed as follows:

// Wait for a AHBMASTER_MSGID_ILLEGAL_BUSY_RESP messagevoid = u1.notify.wait_for_t( u1.AHBMASTER_MSGID_ILLEGAL_BUSY_RESP);// … 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, so its value may change from one design to another.

3.3.8 Coverage

Functional coverage is used to measure the progress of a verification effort. In general, with VMM technology, coverage is accomplished through one or more callback class instances registered with the monitor transactor. By default, the monitor transactor does not have a coverage callback class instance registered, and so no coverage is reported. To enable coverage, the user must either extend one of the monitor coverage callback classes and register it, or register an instance of the predefined default coverage callback class that 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 VMM transactors

❖ user-defined coverage relative to special events (typically provided in monitor models only, and is not present in all VMT suites)

❖ Predefined default coverage model for channels/transactions and special events (provided for monitor transactors only)

3.3.8.1 Coverage ModelThe predefined coverage model consists of numerous coverage groups. Each coverage group defines bins in terms of coverage points (signals, variables, and so on), cross coverage points (optional), and sample events, all of which are defined outside of the coverage group.

The predefined coverage model can be used without alteration or you can extend it. You can also create your own coverage model, either as an addition or as a replacement. Coverage data is provided through callbacks that are applied to the data flowing through the monitor transactor.

The coverage data comes in the form of data objects that are exposed through the transactor. This includes transaction information as well as data for “significant events”, such as protocol errors. Important data about such events may also be available, such as the type of transaction that caused an error. The data 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.

AttentionAs with all callbacks, the coverage callbacks must be registered with the transactor before they can be used. This applies for the default coverage callback (it is not registered by default) as well as any user-defined coverage callback.


www.designware.com




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

c. Coverage 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.4 VMM Features Provided by AHB DesignWare VIP To access the verification features provided by the DesignWare AHB Verification IP, you use the following transactor models:

❖ ahb_master_rvm_vera_vmt

❖ ahb_slave_rvm_vera_vmt

❖ ahb_bus_rvm_vera_vmt

❖ ahb_monitor_rvm_vera_vmt

These transactor models provide the following capabilities:

❖ Support for basic VMM control methods

✦ VMM methods: start_xactor and stop_xactor

❖ Support for VMM configuration objects

✦ A configuration object must be provided in the constructor of the VMM transactor class

✦ VMM methods to modify and get configuration object provided to transactor: change_xactor_config and get_xactor_config_t

❖ Support for VMM input through VMM transactor channels

✦ Supported by master and slave VMM transactors

✦ Support for post channel get actions through callback registered with VMM transactor

❖ Support for VMM 'ENDED' notification

✦ When input transaction request completes, VMM transactor issues transaction ENDED notification

✦ Supported by master VMM transactor

❖ Support for VMM output through VMM transactor channel

✦ Supported by master, slave, and monitor VMM transactors

✦ Support for pre channel put actions through callback registered with VMM transactor

❖ Support for the VMM factory through VMM transactor activity/output channel

✦ Factory can be provided in constructor

✦ Supported only for VMM transactors with activity and/or output channel


www.designware.com




❖ Support for functional coverage in an VMM environment, including:

✦ Predefined default coverage model

✦ User-defined coverage

3.4.1 Online Documentation for RVM Classes

For a complete listing of VMM classes and their data members, consult the online documentation at:

DESIGNWARE_HOME/vip/amba/ahb_vmm_html/index.html

This manual will discuss the use of the classes, but will not include tables or listings of their members.

3.5 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 separated by 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 first letter of the identifier is in lowercase, and the first letter of each following word is in uppercase. For example:

function bit isValidName(); task displayMessage();

❖ Variable names include Hungarian notation, in which the prefix indicates the type of the variable:

integer nInstanceCount;bit bValidData;

The following table provides the conventions that were used when naming variables.Table 3-3 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


www.designware.com




Class data members are prefixed with a leading “m_” to distinguish from variables. For example:

integer m_nInstanceCount;bit m_bValidData;

Classes are prefixed with a leading “o”, with no underscore.

3.6 Base Classes for AHB DesignWare VIP Consistent with the VMM approach, the AHB DesignWare VIP defines several base classes that extend base VMM classes and provide broad AHB functionality that more specific AHB classes can extend. This section provides descriptions of the following AHB base classes:

❖ “Transaction Base Class: dw_vip_ahb_transaction” on page 58

❖ “Configuration Base Class: dw_vip_amba_configuration” on page 60

❖ “AHB System Configuration Class: dw_vip_ahb_system_configuration” on page 60

3.6.1 Transaction Base Class: dw_vip_ahb_transaction

This AHB base class (extended from vmm_data) provides a common set of enumerated types and values for the master and monitor transaction classes.

3.6.1.1 Enumerated Types for Transaction ObjectsThe transaction objects use several enumerated types to hold some of the transaction information. These types are used to specify bus transaction fields and the possible settings that correspond to legal values allowed by the ARM AHB Specification.

First, the transaction base class includes the following global Boolean enumerated type:

enum VmtBooleanEnum = VMT_BOOLEAN_FALSE, VMT_BOOLEAN_TRUE;

In addition, the enumerated types listed in Table 3-4 are provided, and all are scoped within the dw_vip_ahb_transaction class. When setting enumerated type attributes in the transaction classes, use the scoped reference to specify the enumerated type value. For example:

m_enXactType = dw_vip_ahb_transaction::READ;

AttentionThe start_xactor() method for all transactor models should be called at the posedge of the clock signal in the transactor model's interface.


www.designware.com




Table 3-4 shows a listing of the enumerated types of the dw_vip_ahb_transaction class.

3.6.1.2 Reasonable Constraints for dw_vip_ahb_transactionThis class provides the “reasonable_constraint_mode” method for turning ON or OFF all of the “reasonable” randomize constraints. Note that the “valid_ranges” constraint is not disabled.

The method declaration is:

virtual function integer reasonable_constraint_mode(integer nOnOff);

Example usage:

voidint success = oMasterXact.reasonable_constraint_mode(OFF);

This method is a function that returns the value of nOnOff when successful, or returns -1 if it fails. Legal values for the nOnOff argument are {ON, OFF}. When turning constraints OFF, this function produces the following warning message:

"Reasonable constraints have been turned off, the system could appear hung or have memory issues if the reasonable constraints for the following fields are not replaced: m_nvBusy, m_nIdle."

This message warns that turning off these constraints without adding user-defined constraints will allow some of the attributes to take on values during randomization that could lead to extremely long simulation delays. As indicated by the message, the only attributes that have this problem are the m_nvBusy and m_nIdle attributes.

Table 3-4 Transaction Class dw_vip_ahb_transaction Enumerated Types

Enumerated Type Name Supported Values Description

xfer_size_enum XFER_SIZE_8BITXFER_SIZE_16BITXFER_SIZE_32BITXFER_SIZE_64BITXFER_SIZE_128BITXFER_SIZE_256BITXFER_SIZE_512BITXFER_SIZE_1024BIT

8-bit transfer16-bit transfer32-bit transfer64-bit transfer128-bit transfer256-bit transfer512-bit transfer1024-bit transfer

burst_type_enum SINGLEINCRWRAP4INCR4WRAP8INCR8WRAP16INCR16

Single transferIncrementing burst of unspecified length4-beat wrapping burst4-beat incrementing burst8-beat wrapping burst8-beat incrementing burst16-beat wrapping burst16-beat incrementing burst

xact_type_enum READWRITEIDLE

Read transferWrite transferIdle transfer


www.designware.com




3.6.2 Configuration Base Class: dw_vip_amba_configuration

The dw_vip_amba_configuration class extends vmm_data to form a base class that is extended by the system, master, and slave configuration classes. For detailed conceptual information about AHB configuration and configuration objects, see “Configuration Objects” on page 45.

This base class provides several enumerated types to hold some of the configuration information. Types that are used to specify bus configuration fields provide values that correspond to legal values allowed by the ARM AMBA Specification.

First, the configuration base class includes the following global Boolean enumerated type:

enum VmtBooleanEnum = VMT_BOOLEAN_FALSE, VMT_BOOLEAN_TRUE;

In addition, the enumerated types listed in Table 3-5 are provided, and all are scoped within the dw_vip_amba_configuration class. When setting enumerated type attributes of the dw_vip_amba_configuration object, use the scoped reference to specify the value.

For example:

m_enDataWidth = dw_vip_amba_configuration:: HADDR_WIDTH_32;

Table 3-5 shows a listing of the enumerated types.

3.6.3 AHB System Configuration Class: dw_vip_ahb_system_configuration

This class extends dw_vip_amba_configuration and defines the overall AHB system. It is not a base class that other AHB classes extend, but is used by all transactors. For consistency across the system, the master and slave transactors include this configuration object in addition to their specific configuration settings,

Table 3-5 Configuration Class dw_vip_amba_configuration Enumerated Types

Enumerated Type Name Supported Values Description

haddr_width_enum HADDR_WIDTH_32 HADDR_WIDTH_64

Address width

hdata_width_enum HDATA_WIDTH_8 HDATA_WIDTH_16 HDATA_WIDTH_32 HDATA_WIDTH_64 HDATA_WIDTH_128 HDATA_WIDTH_256 HDATA_WIDTH_512 HDATA_WIDTH_1024

Data width

memory_default_pattern_enum PATTERN_ZERO PATTERN_ONE PATTERN_A5 PATTERN_5A PATTERN_WALK0 PATTERN_WALK1 PATTERN_INCR PATTERN_DECR PATTERN_RANDOM PATTERN_X

Sets all bits in the region to 0 Sets all bits in the region to 1 Sets all bytes in the region to 0xA5 (1010 0101) Sets all bytes in the region to 0x5A (0101 1010) Sets all words in the region to a walking 0 pattern Sets all words in the region to a walking 1 pattern Sets all words in the region to an incrementing pattern Sets all words in the region to a decrementing pattern. Sets all words in the region to a random patternSets all bits in the region to X


www.designware.com




and the monitor and bus transactors require nothing more than what is provided by the system configuration object.

The system configuration object includes information about all of the AHB transactor models, a memory map for all of the AHB slave transactors, and individual configuration settings for the system as a whole. The information in the system configuration object is used by the transactors for the AHB monitor, bus, slave, and master. For detailed conceptual information about AHB configuration and configuration objects, see “Configuration Objects” on page 45.

The following example shows the constructor for dw_vip_ahb_system_configuration:

new (vmm_log oLog = null, integer nNumMasters, integer nNumSlaves, VmtBooleanEnum blUseDefaultMemmap = VMT_BOOLEAN_TRUE);

The arguments for this constructor include the number of masters and slaves, as well as a boolean property to enable a default memory map. These arguments are not randomizable, but other members of a system configuration are randomizable. For recommendations about randomizing configuration objects, see “Randomizing Configuration Objects” on page 62.

The memory map is used by the monitor and bus transactors. If the default memory map is used, then every slave (from 1 up to nNumSlaves-1) will have 1Mbytes region continuously allocated from address 0. If you set your own memory map, the memory map is described by adding AmbaSlaveRange objects to the dw_vip_ahb_system_configuration through a call to “addRange”. Each AmbaSlaveRange includes the slave associated with the range and the start and end addresses for the range. The ranges are stored in the dw_vip_ahb_system_configurationm_ovRanges data member. For more about address range usage, see “Memory Map Address Range Usage” on page 62.

The dw_vip_ahb_system_configuration object contains two arrays, m_ovMasterCfgs and m_ovSlaveCfgs, for holding configurations of the different masters and slaves in the system. These arrays are dynamic and the size is determined at “new” by nNumMasters and nNumSlaves, respectively. Figure 3-7 shows the arrays of master and slave configurations in the system configuration object.

Figure 3-7 AHB System Configuration and Contained Arrays

The dw_vip_ahb_master_rvm needs the dw_vip_ahb_master_configuration, and the dw_vip_ahb_slave_rvm needs the dw_vip_ahb_slave_configuration in their constructor. The user can use the getMasterCfg and getSlaveCfg methods after the system configuration is randomized.

To ensure that the configuration of the test system is consistent, the testbench should start by creating a dw_vip_ahb_system_configuration defining the system configuration, which can be fed to the

.

.

.

dw_vip_ahb_system_configuration

dw_vip_ahb_master_configuration

dw_vip_ahb_master_configuration

m_ovMasterCfgs

dw_vip_ahb_slave_configuration

dw_vip_ahb_slave_configuration

m_ovSlaveCfgs

.

.

.


www.designware.com




dw_vip_ahb_bus_rvm and dw_vip_ahb_monitor_rvm transactors directly through the constructor or the change_xactor_config command.

3.6.3.1 Memory Map Address Range UsageThe AHB system configuration object is created with a default set of address ranges. Each range defines a start address, an end address and a slave ID number indicating which slave is the target of the transactions within that address range. There are 15 default ranges with one assigned to each slave index, 1 to 15, using 1-Mbyte blocks of address space starting at address 0.

The address range is statically configured and cannot be cleared or added to after the model is started. New address ranges can be added to the existing set, or the user can clear all the existing address ranges and start over with a new set.

To clear all the current address ranges, you can use the clearRanges() method of the dw_vip_ahb_system_configuration class.

To get the current number of address ranges, which you can do at any time, you can use the getRangeCnt() function of the dw_vip_ahb_system_configuration class.

To add a new range, you can use the addRange method of the dw_vip_ahb_system_configuration class, which adds the new range to the end of the list of address ranges. New address ranges must not overlap existing address ranges. Overlapping ranges cause a fatal error.

3.6.3.2 Randomizing Configuration ObjectsConfiguration objects can be randomized, and can be sent at any time prior to start. For example, between the constructor call and the start, or between a hard reset and the start.

Ideally, the system configuration object is randomized first so it can be referenced when the master or slave configuration is constructed. To ensure this consistency, the m_oSysCfg member of dw_vip_ahb_master_configuration or dw_vip_ahb_slave_configuration object must reference the system configuration. Once constructed, the system configuration can be distributed to the various transactors to insure a consistent interpretation of the system.

Note that the configuration classes include valid_ranges constraints that limit the generated values to ones acceptable to the models. You can set your own constraints if you want.

If you replace the master or slave configuration with your own, the reference to the system configuration might not be consistent. This can lead to the bus and monitor transactors not knowing of a change to the system configuration, resulting in lost data or protocol errors.

3.6.3.3 Validating Configuration ObjectsIf you replace the master or slave configuration with your own, the reference to the system configuration might not be consistent. This can lead to the bus and monitor transactors not knowing of a change to the system configuration, resulting in lost data or protocol errors.

3.6.3.4 dw_vip_ahb_system_configuration Class Description For a complete listing of VMM classes and their data members, consult the online documentation at:


3.6.3.4.1 Reasonable Constraints for dw_vip_ahb_system_configurationThis class provides the “reasonable_constraint_mode” method for turning ON or OFF all of the “reasonable” randomize constraints listed below. Note that “valid_ranges” constraint is not disabled.

constraint reasonable_enAhblite;


www.designware.com




constraint reasonable_enHaddrWidth; constraint reasonable_enHdataWidth; constraint reasonable_enLittleEndian; constraint reasonable_nWatchDogTimeout; constraint reasonable_nDefaultMaster; constraint reasonable_nDummyMaster; constraint reasonable_nDefaultSlave; constraint reasonable_enOrHsplit; constraint reasonable_nIncrEarlyTerm;

Method declaration:


Example usage:

int success = oSystemCfg.reasonable_constraint_mode(OFF);

This method is a function that returns the value of nOnOff when successful or returns -1 if it fails. Legal values for the nOnOff argument are {ON, OFF}. When turning OFF constraints, this function produces the following vmm_warning message:

"Reasonable constraints have been turned off, the system could appear hung or have memory issues, see DesignWare AMBA User Manual reasonable_constraint_mode command reference for details."

This message warns that turning off these constraints without adding user-defined constraints will allow the following attribute to take on values during randomization that could lead to extremely large memory consumption or extremely long simulations:

m_enAhblite;

3.6.3.4.2 Class Methods for dw_vip_ahb_system_configurationThe dw_vip_ahb_system_configuration class supports the following base methods (inherited from vmm_data):

psdisplaycompareallocatecopycopy_databyte_sizebyte_packbyte_unpack (note, the len parameter is ignored)is_valid

The is_valid and compare methods support the following values for the “kind” argument:

❖ DW_VIP_VMT_LOGIC or -1—Every member in the system configuration object checked, including the contained master and slave configuration objects.

❖ DW_VIP_AMBA_RVM_CONFIG_KIND_BUS—Checks the following members:

m_nNumMastersm_nNumSlavesm_blUseDefaultMemmap m_enAhbLite m_enHaddrWidthm_enHdataWidth m_enLittleEndianm_nDefaultMasterm_ovMasterCfgs[*] m_nIncrEarlyTerm m_ovRanges[$]


www.designware.com




❖ DW_VIP_AMBA_RVM_CONFIG_KIND_MONITOR—Checks the following members:

m_nNumMastersm_nNumSlavesm_blUseDefaultMemmap m_enAhbLite m_enHaddrWidthm_enHdataWidth m_enLittleEndianm_nDefaultMasterm_nWatchDogTimeout m_enVerbose m_nDummyMasterm_enCheckProtocol m_envSplitCapable[*]m_nDefaultSlavem_enWaitForReset m_enOrHsplit

The dw_vip_ahb_system_configuration class also supports the following methods:

reasonable_constraint_modeclearclearMasterCfgclearSlaveCfggetMasterCfggetSlaveCfgaddRangegetRangeclearRangesgetRangeCntgetRangeDesc



3.7 Using the AHB Master The section describes all the elements relating to the AHB master transactor, and contains the following information:

❖ “Features”

❖ “AHB Master Ports” on page 65

❖ “Testbench Connections” on page 67

❖ “Configuration Class: dw_vip_ahb_master_configuration” on page 72

❖ “Channels” on page 73

❖ “Master Transactor Class: dw_vip_ahb_master_rvm” on page 73

❖ “Master Transaction Class: dw_vip_ahb_master_transaction” on page 74

❖ “When using the “kind” parameter, DW_VIP_VMT_LOGICAL must be replaced with a value of 9.” on page 75

3.7.1 Features

The AHB master has two operating modes: protocol-related and buffer access. Protocol-related features generate bus cycles and transfer responses to slave response types. Buffer access features allow you to create burst transfers in advance and reuse the burst information. The AHB master also supports constrained random test features, which allow you to optimize test coverage by defining sets of weighted, randomly-generated transactions.


www.designware.com




The protocol-related features of the AHB master include the following:

❖ All data widths

❖ All address widths

❖ All transfer types

❖ Locked transfers

❖ All protection types

❖ Automatic transfer rebuilds

❖ Automatic bus request and release


3.7.2 AHB Master Ports

Table 3-6 lists AHB Master ports and their direction, width, polarity, and function.

NoteNoteNoteNote For information about the buffer access mode, see DesignWare AHB Verification IP Databook.

Table 3-6 AHB Master Port Interface

Port Direction Width Polarity Description

HGRANT Input 1 High Bus Grant signal. Disabled when in AHB Lite mode, controlled by m_enAhbLite in the AHB system configuration object.

HREADY Input 1 High Slave Ready signal.

HRESP Input [1:0] [0:0]

— Slave Response bus. HRESP[1} not required and may be left unconnected in AHB Lite mode. AHB Lite mode is controlled by m_enAhbLite in the AHB system configuration object.

HRESETN Input 1 Low Reset signal. To reset the model, assert HRESETN for at least one clock cycle.

HCLK Input 1 — Clock signal.

HRDATA Input [1023:0] [511:0] [255:0] [127:0] [63:0] [31:0] [15:0] [7:0]

— Read data bus. Width is set by m_enHdataWidth in the system configuration object.

HBUSREQ Output 1 High Master Request signal. Disabled when in AHB Lite mode. AHB Lite mode is controlled by m_enAhbLite in the AHB system configuration object.

HLOCK Output 1 High Lock signal.


www.designware.com




3.7.3 ARM11 Master Features

The AHB master VIP model supports some ARM 11 features specified in Systems IP ARM11 AMBA (Rev2.0) AHB Extensions (v1.0). The ARM11 features are controlled using a system configuration parameter. You should pass the ARM11 ports as arguments to the AHB master model constructor.

To Enable the ARM11 mode:

❖ An Arm11 Port is required.

❖ The m_enAhbArm11 argument in dw_vip_ahb_system_configuration class should be enabled.

Following is the list of features supported by AHB master:

❖ Driving of HBSTRB signals is supported in Little Endian mode. HBSTRB are driven for read and write transfers.

❖ Level 2 Cache support (HPROT[4]). Only driving of HPROT[4] signal is supported.

❖ Exclusive access support (HPROT[5]). Only driving of HPROT[5] signal is supported.

Following is the list of features that are currently not supported by AHB master:

❖ The master can receive two-cycle XFAIL response from a slave model.

❖ There are no constraints to generate HBSTRB patterns.

❖ HUNALIGN signal

❖ HDOMAIN signal

HTRANS Output [1:0] — Transfer signal.

HADDR Output [63:0] [31:0]

— Address bus. The 64-bit or 32-bit system address bus.

HWRITE Output 1 High Write signal.

HSIZE Output [2:0] — Data Size bus.

HBURST Output [2:0] — Burst Type bus.

HPROT Output [3:0] — Protection bus.

HWDATA Output [1023:0] [511:0] [255:0] [127:0] [63:0] [31:0] [15:0] [7:0]

— Write data bus. Width is set by m_enHdataWidth in the system configuration object.

NoteNoteNoteNote The ARM11 features have a separate set of ports. This does not affect the default mode of operation of AHB Master VIP. Only when using the ARM11 features, you are required to connect these ports.

Table 3-6 AHB Master Port Interface (Continued)



www.designware.com




❖ Unaligned access and burst of Aligned transfers using Byte Lane strobes. Section 2.3.1 and 2.3.2 of ARM11 specification is not supported.

❖ Arm11 support in Big Endian mode.

Since any burst transaction can be optimized in many ways using HBSTRB, the model does not take a decision on optimizing a burst transaction. The master model only drives the programmed HBSTRB for a given burst transfer.

Table 3-7 ARM11 Master Ports

3.7.4 Testbench Connections

To connect and use a transactor and its channels and channel objects, it is only necessary to include the .vri files for the transactor and the transactor loader. For example, to use the master transactor, include the files AhbMaster_rvm.vri and AhbMasterLoader_rvm.vri. Those two files include all the other .vri files to load and access the AhbMaster model, transactor channels and channel objects as well as all the macro definitions related to the master.

3.7.4.1 LoaderLoading for the transactor is done using multiple files. This includes a shared loader file and loader files for the individual RVM transactors.

3.7.4.1.1 Shared RVM Transactor LoaderThe shared loader file is located at ahb_root/include/AhbLoader_rvm.vri. This file takes care of loading the suite of RVM transactor classes, which are shared across all AHB transactors. This loader file is included by the individual model RVM transactor loaders.

Port Direction Optional Config WidthWidth in Bits Description

hclk Input No No 1 Input clock signal.

hbstrb_arm11

Output No Yes. Minimum DataWidth is 8.Maximum DataWidth is 128.

128 The ARM11 HBSTRB signal identifies the strobes for read and write transfers.

hprot_arm11

Output No No 2 ARM 11 additional HPROT signals.hprot_arm11[0] is for Level2 Cache support. It represents HPROT[4] bit.hprot_arm11[1] is for exclusive access. It represents HPROT[5] bit.

hresp_arm11

Input No No 1 ARM11 AHB Exclusive response signal. It represents HRESP[2] bit.

hunalign_arm11

Output Yes No 1 Used for unaligned access. It is not supported currently.

hdomain_arm11

Output Yes No 4 Used for exclusive access. It is not supported currently.


www.designware.com




3.7.4.1.2 Loaders for Individual RVM TransactorsThis section provides an overview of how to connect the AHB master transactor in a testbench. To see a full example of the elements used to make these connections, see the example testbench located in:


Figure 3-8 shows the instantiation of the transactor model when using an SystemVerilog testbench. As shown, the design under test (DUT) is connected to the transactor in the testbench through an interface and modport definition.

Figure 3-8 Connecting a Transactor in a SystemVerilog Testbench

The major steps in connecting the in a SystemVerilog testbench are describes in the following sections:

❖ “The Interface Definition for the AHB Master”

❖ “Connecting the Transactor in the Testbench”

❖ “Connecting the Interface in the Top Testbench”

3.7.4.2 The Interface Definition for the AHB MasterTo make these connections, you use an interface definition, which includes:

❖ A list of all pins

❖ A list of clocking signals

❖ One or more clocking blocks (or domains) of related clocked signals

❖ One or more modport definitions (each modport relates clocking signals with clocking blocks)

The following interface definition file is provided for the AHB master transactor:

design_dir/verilog/include/AhbMasterInterface.svi

The interface definition for the AHB master transactor follows:

interface AhbMasterInterface ( input hclk, // Input to AHB Master input hresetn, input hgrant,

AttentionIt is recommended that you use this interface file in your testbench to ensure proper signal ordering. If you use your own interface file, the expanded order of signals in your modports must match the expanded signal order in the modports in these files.

DUT

Verilog test_top

Transactor

SystemVerilog Testbench

Interface_inst1

modport

DUT


www.designware.com




input [`DW_VIP_AMBA_AHBMASTER_HDATA_PORT_WIDTH - 1:0] hrdata, input hready, input [1:0] hresp, // Output from AHB Master output [`DW_VIP_AMBA_AHBMASTER_HADDR_PORT_WIDTH - 1:0] haddr, output [2:0] hburst, output hbusreq, output hlock, output [3:0] hprot, output [2:0] hsize, output [1:0] htrans, output [`DW_VIP_AMBA_AHBMASTER_HDATA_PORT_WIDTH - 1:0] hwdata, output hwrite ) ;

clocking Clk @(hclk); default input #0; input hclk; endclocking

clocking Cb @(posedge hclk) ; default input #1 output #1 ; // Input to AHB Master input hresetn; input hgrant; input hrdata; input hready; input hresp; // Output from AHB Master output haddr; output hburst; output hbusreq; output hlock; output hprot; output hsize; output htrans; output hwdata; output hwrite; endclocking

modport Master(import Clk.*, import Cb.*);endinterface: AhbMasterInterface

3.7.4.3 Interface Definition for Ahb Arm11 Masterinterface AhbArm11MasterInterface #(parameter setup_time=1, parameterhold_time=1) ( input hclk, // Input to Ahb Master ARM11 input hresp_arm11,

AttentionThe start_xactor() method for all transactor models should be called at the posedge of clock signal in the transactor model's interface.


www.designware.com




// Output from AHB ARM11 Master output [`DW_VIP_AMBA_AHBMASTER_HBSTRB_ARM11_PORT_WIDTH - 1:0] hbstrb_arm11, output [`DW_VIP_AMBA_AHBMASTER_HPROT_ARM11_PORT_WIDTH - 1:0] hprot_arm11, output hunalign_arm11, output [`DW_VIP_AMBA_AHBMASTER_HDOMAIN_ARM11_PORT_WIDTH - 1:0] hdomain_arm11) ;

clocking Clk @(hclk); default input #0 output #0; input hclk; endclocking

clocking Cb @(posedge hclk) ; default input #(setup_time) output #(hold_time) ;

// Output from AHB Master output hbstrb_arm11; output hprot_arm11;

// Input to AHB Master input hresp_arm11;

output hunalign_arm11; output hdomain_arm11; endclocking

modport Arm11Master(import Clk.*, import Cb.*);

endinterface: AhbArm11MasterInterface

3.7.4.4 Connecting the Transactor in the TestbenchDo the following in your SystemVerilog testbench:

1. Pass a reference to the desired modport to connect to the transactor. For example, the bold portion refers to the Master modport of the AhbMasterInterface defined above:

program automatic AhbSystemTest( AhbMasterInterface.Master AhbMasterBind1, ...);

2. Import the entire contents of the model package for the AHB master. This step gives you access to all the elements of the AHB master:

// import the AHB master elementsimport AhbMaster_rvm::*;...

3. Connect to the interface when you instantiate and construct the transactor, as shown next:

dw_vip_ahb_master_rvm master; ...master = new("AHB MASTER1",AhbMasterBind1,cfg_m1,gen1.out_chan,master_outchan1);

AttentionEnabling ARM11 mode requires the following VCS compile-time flags:+define+SYNOPSYS_ENABLE_ARM11_SV -ntb_define SYNOPSYS_ENABLE_ARM11_SV


www.designware.com




...

4. Within your program's initial block, include a call to the setSystemClock method, as shown next:

initial begin setSystemClock(test_top.SystemClock);

The setSystemClock method needs to be provided with the clock that will be the "system clock" 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 are using only one VIP, it is easiest to use the same clock that is driving your transactors. If you are verifying a particular portion of a system—for example, the USB portion—you can use the main clock for that portion. If you are simulating with several VIPs, choose a top-level clock that has a known relationship with each VIP.

3.7.4.5 Connecting the Interface in the Top TestbenchFinally, you instantiate instance(s) of the interface and complete the connection in the Verilog top testbench, as shown next:


wire [ÀHB_HADDR_WIDTH-1:0] haddr_m1; wire [ÀHB_HBURST_WIDTH-1:0] hburst_m1; wire hbusreq_m1;...reg SystemClock;...AhbMasterInterface intf_m1( .hclk ( hclk ), .hresetn ( hresetn ), .hgrant (hgrant_m1), .hrdata ( hrdata ), .hready ( hready ), .hresp ( hresp ),

.haddr ( haddr_m1 ), .hburst ( hburst_m1 ), .hbusreq (hbusreq_m1), .hlock (hlock_m1), .hprot ( hprot_m1 ), .hsize ( hsize_m1 ), .htrans ( htrans_m1 ), .hwdata ( hwdata_m1 ), .hwrite ( hwrite_m1 ) );...

AhbSystemTest tb(intf_m1.Master);endmodule


www.designware.com




3.7.5 Configuration Class: dw_vip_ahb_master_configuration

Each AHB master of the overall system is described using a dw_vip_ahb_master_configuration object. This class contains a reference to the AHB system configuration (for consistency). The dw_vip_ahb_master_configuration object is a contained object; that is, it is included in a dw_vip_ahb_system_configuration object.

For information about the AHB system configuration class, see “AHB System Configuration Class: dw_vip_ahb_system_configuration” on page 60. For detailed conceptual information about AHB configuration and configuration objects, see “Configuration Objects” on page 45.



3.7.5.1 Reasonable Constraints for dw_vip_ahb_master_configurationThe class “reasonable_constraint_mode” provides a method for turning ON or OFF all of the “reasonable” randomize constraints listed below. Note that “valid_ranges” constraint is not disabled.

constraint reasonable_nMaxRetries; constraint reasonable_enDriveZBeforeGrant; constraint reasonable_RetryAfterError;constraint reasonable_BusyIgnoreWaits;constraint reasonable_nSetEbtCycleCount; constraint reasonable_nSetEbtNumTimes; constraint reasonable_nSetEbtTimeOutCycle; constraint reasonable_nClearEbt;constraint reasonable_nGrantAfterEbtCycleCount;

Method declaration:

virtual public function integer reasonable_constraint_mode(integer nOnOff);

Example usage:

voidint success = oMasterCfg.reasonable_constraint_mode(OFF);


"Reasonable constraints have been turned off, the system could appear hung or have memory issues, see DesignWare AHB User Manual reasonable_constraint_mode command reference for details."

This message warns that turning off these constraints without adding user-defined constraints allows some of the attributes to take on values during randomization that could lead to extremely large memory consumption or extremely long simulations. The members of dw_vip_ahb_master_configuration that must be constrained to prevent these undesirable conditions are as follows:

m_nMaxRetries; m_enDriveZBeforeGrant; m_nSetEbtCycleCount; m_nSetEbtNumTimes; m_nSetEbtTimeOutCycle; m_nGrantAfterEbtCycleCount;


www.designware.com




3.7.5.2 Class Methods for dw_vip_ahb_master_configurationThe dw_vip_ahb_master_configuration class supports the following base methods (inherited from vmm_data):

psdisplaycompareallocatecopycopy_databyte_sizebyte_packbyte_unpack (note, len parameter is ignored)is_valid


❖ DW_VIP_VMT_LOGIC or -1: Every member in the master configuration object is checked

❖ DW_VIP_AMBA_RVM_CONFIG_KIND_MONITOR: Checks every member in the master configuration object, plus the following members in the system configuration:

m_enAhbLite m_enHaddrWidthm_enHdataWidth m_enLittleEndian

The dw_vip_ahb_master_configuration class supports the following additional method:

3.7.6 Channels

See “Channels” on page 44.

3.7.7 Master Transactor Class: dw_vip_ahb_master_rvm

The dw_vip_ahb_master_rvm class implements the master transactor. It is extended from vmm_xactor. The master transactor supports the basic VMM control methods along with the DesignWare VIP capabilities. It also support the input and output channels.

The usage model for the master channels is straightforward. The input channel is used to initiate transactions and expects transactions of type dw_vip_ahb_master_transaction. The output channel is used to retrieve transaction results.

reasonable_constraint_mode

Turns ON or OFF all of the “reasonable” randomize constraints for this class. Note that “valid_ranges” constraint is not disabled.

Syntax:

reasonable_constraint_mode (integer nOnOff)

Arguments:

nOnOffAn integer that turns ON or OFF all the reasonable randomize constraints.

Returned value:

An integer containing the value of nOnOff when successful. Returns -1 if it fails.


www.designware.com




The constructor for the master transactor takes six arguments. The constructor arguments must be of the types shown in the following code fragment:

task new (string instName, AhbMasterPort portConnect, dw_vip_ahb_master_configuration oVipCfg, dw_vip_ahb_master_transaction_channel oTransactionInputChan = null, dw_vip_ahb_master_transaction_channel oTransactionOutputChan = null, dw_vip_ahb_master_transaction oTransactionOutputFactory = null, AhbArm11MasterPort arm11MasterPortConnect = null);

❖ instName argument: This argument defines the vmm_xactor “instance” value. The oMasterPort argument provides a port interface used internally. The oVipCfg object defines the master transactor configuration information. These are all required arguments. The remaining arguments are optional.

❖ oTransactionInputChan object: This object initiates transactions on the bus. If it is not provided, the master transactor creates a default input channel that is used. The handle to the transaction input channel can be obtained through the transactor public member m_oTransactionInputChan.

❖ oTransactionOutputChan object: This object provides a mechanism for retrieving transaction results occurring from the bus. If it is not provided, the master transactor does not create a default channel. The handle to the transaction output channel can be set or obtained through the transactor public member m_oTransactionOutputChan.

❖ oTransactionOutputFactory object: This is a factory for creating objects derived from dw_vip_ahb_master_transaction prior to calling the transaction output channel 'pre' functions and prior to putting the transaction into m_oTransactionOutputChan. If the constructor includes an oTransactionOutputFactory object, the transactor calls the allocate method whenever it has an output transaction. If the factory is not in the constructor, the master transactor creates dw_vip_ahb_master_transaction based output transactions.

❖ oTransactionOutputFactory object: This object must be extended from dw_vip_ahb_master_transaction and must allocate objects of type dw_vip_ahb_master_transaction so that it can support the AHB master output channel.

❖ arm11MasterPortConnect: This is an argument in the constructor to connect ARM11 ports. By default, the arm11MasterPortConnect is set to null. The user is required to pass the port infromation when using the Ahbmaster model in Arm11 mode.

Once it has created an output transaction object, the master transactor populates the transaction with information from the original dw_vip_ahb_master_transaction request sent through the input channel, as well as transaction data coming back from the slave (for example, read data, stored in m_bvvData) and information about the transaction on the bus (for example, number of retries and number of waits).

The loaded transaction results in a call to the output channel “pre” methods as well as the output channel coverage (cov) method. It is then placed in the output channel if it is present.

The master transactor also generates an ENDED notification for transactions coming in through the input channel. The following could be used to wait for the ENDED notification on the “oMasterXact” transaction sent in through the master transactor input channel.

oMasterXact.notify.wait_for_t(oMasterXact.ENDED);

3.7.8 Master Transaction Class: dw_vip_ahb_master_transaction

The class dw_vip_ahb_master_transaction is extended from dw_vip_ahb_transaction. Several of the attributes presented in this section are defined in the dw_vip_ahb_transaction object. They can also be accessed through the dw_vip_ahb_master_transaction object.


www.designware.com




For a complete listing of VMM class members, refer to:

$DESIGNWARE_HOME/vip/amba/doc/ahb_vmm_html/index.html

All of the defaults are based on the AHB protocol and are present to generate good traffic consistent with the protocol. The user should consider replacing these with constraints-specific to their system.

3.7.8.0.1 Class Methods for dw_vip_ahb_master_transaction The following vmm_data methods are fully implemented by the AHB transaction classes:

❖ psdisplay

❖ allocate

❖ copy

❖ compare

❖ byte_size

❖ byte_pack

❖ byte_unpack (note, len parameter is ignored)

The “kind” parameter to the compare method supports two values: DW_VIP_VMT_LOGICAL and -1 (the default). Both values result in a logical compare that compares all fields in the transaction.

The byte_size, byte_pack and byte_unpack methods only support DW_VIP_VMT_LOGICAL. If kind defaults to -1 or is specified to be something other than DW_VIP_VMT_LOGICAL, these methods generate a vmm_error. The error indicates the kind that was requested and the method that encountered the failure. Note that the len parameter is ignored. For example, if a kind of -1 is passed to the byte_pack method, the following error would be generated:

Unsupported kind (-1) for 'byte_pack' on class 'dw_vip_ahb_master_transaction'.

3.7.9 Callbacksclass dw_vip_ahb_master_rvm_callbacks extends vmm_xactor_callbacks { virtual task post_transaction_input_channel_get( dw_vip_ahb_master_rvm oRvmModel, integer nChanId, dw_vip_ahb_master_transaction oVipXact, var bit drop ); virtual task pre_transaction_output_channel_put( dw_vip_ahb_master_rvm oRvmModel, , integer nChanId, dw_vip_ahb_master_transaction oVipXact, var bit drop );

// coverage callbacks virtual task transaction_input_channel_cov ( dw_vip_ahb_master_rvm oRvmModel, integer nChanId, dw_vip_ahb_master_transaction oVipXact ); virtual task transaction_output_channel_cov ( dw_vip_ahb_master_rvm oRvmModel, integer nChanId, dw_vip_ahb_master_transaction oVipXact ); virtual task error_significant_event_cov(

AttentionWhen using the “kind” parameter, DW_VIP_VMT_LOGICAL must be replaced with a value of 9.


www.designware.com




dw_vip_ahb_monitor_rvm oRvmModel, dw_vip_ahb_monitor_error_cov oCovData); virtual task activity_significant_event_cov( dw_vip_ahb_monitor_rvm oRvmModel, dw_vip_ahb_monitor_activity_cov oCovData);}endclass

3.8 Using the AHB Slave The section describes all the elements relating to the AHB slave transactor and contains the following set of information:

❖ “Features”

❖ “AHB Slave Ports”


❖ “Slave Configuration Class: dw_vip_ahb_slave_configuration” on page 83


❖ “AHB Slave Transaction Class: dw_vip_ahb_slave_transfer” on page 87

❖ “Callbacks” on page 88

3.8.1 Features

The AHB Slave model can generate responses to all types of burst read and write cycles, as well as non-burst reads and writes. The model also supports split cycle functionality, where the model requests the bus after specified number of clock cycles. The Slave also supports:

❖ FIFO memory arrays

❖ constrained random test transactions

❖ AHB Lite requirements

❖ ARM11 features

3.8.2 AHB Slave Ports

Table 3-8 lists AHB Slave ports, their direction, width, polarity and function. Table 3-8 AHB Slave Port Interface


HSEL Input 1 High Slave select. Indicates that the current transfer is intended for the selected Slave or Slaves.

HADDR Input [63:0] [31:0]


HWRITE Input 1 High Transfer direction. When asserted, indicates a Master write transfer.

HTRANS Input [1:0] — Transfer type. Indicates the type of the current transfer.

HSIZE Input [2:0] — Transfer size. Indicates the size of the transfer.


www.designware.com




HBURST Input [2:0] — Burst type. Indicates if the transfer forms part of a burst.

HWDATA Input [1023:0] [511:0] [255:0] [127:0] [63:0] [31:0] [15:0] [7:0]

— Write data bus. Transfers data from the Master to the Slaves during write operations. Width is set by m_enHdataWidth in the system configuration object.

HRESETN Input 1 Low Reset signal. To reset the model, assert HRESETN for at least one clock cycle.

HCLK Input 1 — Bus clock. All signals are sampled by the Monitor on the rising edge of HCLK.

HMASTER Input [3:0] — Master number. Indicates which bus master is currently performing a transfer. Disabled when in AHB Lite mode. AHB Lite mode is controlled by m_enAhbLite in the AHB system configuration object.

HMASTLOCK Input 1 High Locked sequence.Note: This pin is not used by the model.

HPROT Input [3:0] High Protection control.Note: These pins are not used by the model.

HREADY Input 1 High Transfer done input. Indicates that the Master has finished a bus transfer.

HREADY_RESP Output 1 High Transfer done output. Indicates that the Slave has finished a bus transfer.

HRESP Output [1:0] — Transfer response. Provides additional information on the status of a transfer.

HRDATA Output [1023:0] [511:0] [255:0] [127:0] [63:0] [31:0] [15:0] [7:0]

— Read data bus. Output of the hrdata mux. Width is set by m_enHdataWidth in the system configuration object.

HSPLIT Output [15:0] — Split completion request. Indicates to the arbiter which bus Masters should be allowed to re-attempt a split transaction. Disabled when in AHB Lite mode. AHB Lite mode is controlled by m_enAhbLite in the AHB system configuration object.

Table 3-8 AHB Slave Port Interface (Continued)



www.designware.com




3.8.3 ARM11 Slave Features

The AHB slave VIP model supports some ARM 11 features specified in Systems IP ARM11 AMBA (Rev2.0) AHB Extensions (v1.0). The ARM11 features are controlled using a system configuration parameter. You should pass the ARM11 ports as arguments to the AHB slave model constructor.




Following is the list of features supported by AHB slave:

❖ HBSTRB support for read and write transfers. Memory locations are updated based on the HBSTRB values.

❖ Level 2 Cache support (HPROT[4])

❖ Exclusive access support (HPROT[5]): Driving two-cycle XFAIL response for a valid Exclusive access transaction.

❖ Constraint randomization on slave response transaction to support XFAIL for an Exclusive Write transfer.

Following is the list of features that are currently not supported by the AHB slave:

❖ Exclusive Access monitoring is not supported for ARM11. For Exclusive access transactions, slave memory is updated based on HBSTRB, which is similar to any ARM11 transaction (Non-Exclusive). Refer to Section 2.5.1 of ARM11 specification for more details on Exclusive transfers.

❖ HUNALIGN signal

❖ HDOMAIN signal

❖ Unaligned burst transaction. Section 2.3.2 of ARM11 specification is not supported.

Since, any burst transaction can be optimized in many ways using HBSTRB, the model does not take a decision on optimizing a burst transaction. The slave model only drives the programmed HBSTRB for a given burst transfer.

Table 3-9 ARM11 Slave Ports

NoteNoteNoteNote The ARM11 features have a separate set of ports. This does not affect the default mode of operation of AHB slave VIP. Only when using the ARM11 features, you are required to connect these ports.

Port Direction OptionalConfig Width

Width in Bits Description

hclk Input No No 1 Input clock signal.

hbstrb_arm11 Input No No 128 The ARM11 HBSTRB signal identifies the strobes for read and write transfers.

hprot_arm11 Input No No 2 ARM 11 additional HPROT signals.hprot_arm11[0] is for Level2 Cache support. It represents HPROT[4] bit.hprot_arm11[1] is for exclusive access. It represents HPROT[5] bit.


www.designware.com





This section provides an overview of how to connect the AHB slave transactor in a testbench. To see a full example of the elements used to make these connections, see the example testbench located in:


Figure 3-8 shows the instantiation of the transactor model when using a SystemVerilog testbench. As shown, the design under test (DUT) is connected to the transactor in the testbench through an interface and modport definition.


3.8.4.1 The Interface DefinitionTo make these connections, you use an interface definition, which includes:





The following interface definition file is provided for the AHB slave transactor:

design_dir/verilog/include/AhbSlaveInterface.svi

hresp_arm11 Output No No 1 ARM11 AHB Exclusive response signal. It represents HRESP[2] bit.

hunalign_arm11 Input Yes No 1 This corresponds to HUNALIGN signal defined in ARM11 specification. It is not currently supported.

hdomain_arm11 Input Yes No 4 This corresponds to HDOMAIN signal defined in ARM11 specification. It is not currently supported.



DUT

Verilog test_top

Transactor


Interface_inst1

modport


www.designware.com




The interface definition for the AHB slave transactor is as follows:

interface AhbSlaveInterface ( input hclk,

// Inputs input hresetn,

input [31:0] haddr, input [2:0] hburst, input [3:0] hmaster, input hmastlock, input [3:0] hprot, input hready, input hsel, input [2:0] hsize, input [1:0] htrans, input [31:0] hwdata, input hwrite, // Outputs output [31:0]hrdata, output hready_resp, output [1:0] hresp, output [15:0] hsplit );

clocking Clk @(hclk); default input #0 ; input hclk; endclocking

clocking Cb @( posedge hclk); default input #1 output #1;

input hresetn; input haddr; input hburst; input hmaster; input hmastlock; input hprot; input hready; input hsel; input hsize; input htrans; input hwdata; input hwrite;

output hrdata;

AttentionIt is strongly recommended that you use this interface file in your testbench to ensure proper signal ordering. If you create your own interface definitions, the expanded order of signals in your modports must match the expanded signal order in the modports in these files.


www.designware.com




output hready_resp; output hresp; output hsplit;

endclocking

modport Slave(import Clk.*, import Cb.*);

endinterface: AhbSlaveInterface

3.8.4.2 Connecting the Transactor in the TestbenchDo the following in your SystemVerilog testbench:

1. Pass a reference to the desired modport to connect to the transactor. For example, the bold portion refers to the Slave modport of the AhbSlaveInterface defined above:

program automatic AhbSystemTest( AhbSlaveInterface.Slave AhbSlaveBind1, ...);

2. Import the entire contents of the model package for the AHB slave. This step gives you access to all the elements of the AHB slave:

// import the AHB slave elementsimport AhbSlave_rvm::*;

...


dw_vip_ahb_slave_rvm slave; ...slave = new("AHB SLAVE1",AhbSlaveBind1,cfg_s1,slave_activity_ch1);...

4. Within your program's initial block you need to include a call to the setSystemClock method. This method needs to be provided with the clock for your overall system. If possible, this clock should correspond to the main clock provided to your transactors. But if you have multiple transactors which are being driven with different clocks, then you need to utilize the top level clock defined for your system.

3.8.4.2.1 Arm11 Slave Interface Definitioninterface AhbArm11SlaveInterface #(parameter setup_time=1, parameterhold_time=1) ( input hclk, // Input to AHB ARM11 Slave input [`DW_VIP_AMBA_AHBSLAVE_HBSTRB_ARM11_PORT_WIDTH - 1:0] hbstrb_arm11, input [`DW_VIP_AMBA_AHBSLAVE_HPROT_ARM11_PORT_WIDTH - 1:0] hprot_arm11, input hunalign_arm11, input [`DW_VIP_AMBA_AHBSLAVE_HDOMAIN_ARM11_PORT_WIDTH - 1:0] hdomain_arm11,

// Output from Ahb ARM11 Slave



www.designware.com




output hresp_arm11) ;


clocking Cb @(posedge hclk); default input #(setup_time) output #(hold_time);

// Input to Ahb Arm11 Slave input hbstrb_arm11; input hprot_arm11;

// Output from Ahb Arm11 Slave output hresp_arm11;

input hunalign_arm11; input hdomain_arm11;

endclocking

modport Arm11Slave(import Clk.*, import Cb.*);

endinterface: AhbArm11SlaveInterface

3.8.4.3 Connecting the Interface in the Top TestbenchFinally, you instantiate instances of the interface and complete the connection in the Verilog top testbench, as shown next:


wire [ÀHB_HADDR_WIDTH-1:0] haddr_m1; wire [ÀHB_HBURST_WIDTH-1:0] hburst_m1; wire hbusreq_m1;...reg SystemClock;...AhbSlaveInterface intf_s1( .hclk ( hclk ), .hresetn ( hresetn ), .haddr ( haddr ), .hburst ( hburst ), .hmaster ( hmaster ),

AttentionEnabling the ARM11 mode requires the following VCS compile-time flags:+define+SYNOPSYS_ENABLE_ARM11_SV -ntb_define SYNOPSYS_ENABLE_ARM11_SV


www.designware.com




.hmastlock ( hmastlock ), .hprot ( hprot ), .hready ( hready ), .hsel ( hsel_s1 ), .hsize ( hsize ), .htrans ( htrans ), .hwdata ( hwdata ), .hwrite ( hwrite ), .hrdata ( hrdata_s1 ), .hready_resp ( hready_resp_s1 ), .hresp ( hresp_s1 ), .hsplit ( hsplit_s1 ));...AhbSystemTest tb(intf_s1.Slave);endmodule

3.8.4.4 Accessing Slave Transactor MemoryFor you to access slave transactor memory, you must use the command (HDL) interface. You must first obtain a handle to the underlying HDL model. Next you use the handle to issue set and get memory commands. Following is a code example of this:

// Get a hanlde to the AhbSlave model.dw_vip_ahb_slave_rvm slaveVmm;AhbSlave baseSlave;

slaveVmm = new (...);baseSlave = slaveVmm.getAhbSlave();

// Use the base set_mem command with handle to setup a memory region.baseSlave.set_mem(...);

Only memory commands can be used this way. Any use of other commands, including configure and multi-cycle commands may result in undetermined and incorrect VIP behaviors.

3.8.4.5 Updating Memory Locations in ARM11 ModeThe memory locations are written and read based on the HBSTRB values when AHB slave is configured in ARM11 mode.

For write transfers, the slave memory locations corresponding to HBSTRB=0 are not updated.

For read transfers, in the byte lanes corresponding to HBSTRB=0, the slave returns the value “x”. This helps in verifying if the master RTL incorrectly samples the data lanes corresponding to HBSTRB=0.

3.8.5 Slave Configuration Class: dw_vip_ahb_slave_configuration

Each AHB slave of the overall system is described using a dw_vip_ahb_slave_configuration object. This class contains a reference to the AHB system configuration (for consistency). The dw_vip_ahb_slave_configuration object is a contained object; that is, it is included in a dw_vip_ahb_system_configuration object.




www.designware.com




3.8.5.1 Reasonable Constraints for dw_vip_ahb_slave_configurationThe class “reasonable_constraint_mode” provides a method for turning ON or OFF all of the “reasonable” randomize constraints listed below. Note that “valid_ranges” constraint is not disabled.

constraint reasonable_nHsplitDelays; constraint reasonalbe_enDefaultMemPattern; constraint reasonable_enZpatternOutput

Method declaration:


Example usage:

voidint success = oSlaveCfg.reasonable_constraint_mode(OFF);


"Reasonable constraints have been turned off, the system could appear hung or have memory issues if the reasonable constraint for the following fields are not replaced: m_nHsplitDelays and m_enZpatternOutput."

This message warns that turning off these constraints without adding user-defined constraints will allow some of the attributes to take on values during randomization that could lead to extremely large memory consumption or extremely long simulations. The members of dw_vip_ahb_slave_configuration that must be constrained to prevent these undesirable conditions are as follows:

m_nHsplitDelays m_enZpatternOutput

3.8.5.2 Class Methods for dw_vip_ahb_slave_configurationThe dw_vip_ahb_slave_configuration class supports the following base methods (inherited from vmm_data):

psdisplaycompareallocatecopycopy_databyte_sizebyte_pack byte_unpack (note, len parameter is ignored)is_valid


❖ DW_VIP_VMT_LOGIC or -1: Every member in the slave configuration object is checked

❖ DW_VIP_AMBA_RVM_CONFIG_KIND_MONITOR: Checks every member in the slave configuration object, plus the following members in the system configuration:

m_enAhbLite m_enHaddrWidthm_enHdataWidth m_enLittleEndian


www.designware.com




The dw_vip_ahb_slave_configuration class supports the following additional method:

3.8.6 Channels


3.8.6.1 Slave Transactor: dw_vip_ahb_slave_rvmThe class that implements the slave transactor is called dw_vip_ahb_slave_rvm and is extended from rvm_xactor. The slave VMM interface supports the basic VMM control methods along with configuration capabilities.

The constructor for the dw_vip_ahb_slave_rvm VMM interface takes required arguments for the instance

The constructor for the dw_vip_ahb_slave_rvm VMM interface takes required arguments for the instance name, port interface, and configuration object; the rest are optional. The oVipCfg argument is a required argument, and a compile time error is generated if one is not supplied (see below).

// public attributes:public dw_vip_ahb_slave_auto_response_channel m_oAutoResponseInputChan = null;public dw_vip_ahb_slave_transfer_channel m_oTransferInputChan = null;public dw_vip_ahb_slave_transfer_channel m_oTransferOutputChan = null;public dw_vip_ahb_slave_transfer m_oOutputFactory = null;

task new (string instName, AhbSlavePort portConnect, dw_vip_ahb_slave_configuration oVipCfg = null, dw_vip_ahb_slave_auto_response_channel oAutoResponseInputChan = null, dw_vip_ahb_slave_transfer_channel oTransferInputChan = null, dw_vip_ahb_slave_transfer_channel oTransferOutputChan = null,

reasonable_constraint_mode

Turns ON or OFF all of the “reasonable” randomize constraints for this class. Note that “valid_ranges” constraint is not disabled.

Syntax:

reasonable_constraint_mode(integer nOnOff)

Arguments:

nOnOffAn integer that turns ON or OFF all the reasonable randomize constraints.

Returned value:

An integer containing the value of nOnOff when successful. Returns -1 if it fails.

NoteNoteNoteNote Synopsys recommends the use of the Reactive Response mode to set Slave transactor responses. New classes, channels, and configuration members have been added to support this method of Slave response. When Reactive Response mode is turned on, then the input and output Transfer channels are used instead of the AutoResponse channel to provide the slave with the response information.


www.designware.com




dw_vip_ahb_slave_transfer oOutputFactory = null, dw_vip_ahb_slave_transfer oRandomResponseFactory = null, AhbArm11SlavePort arm11SlavePortConnect = null);

If the constructor is provided with an oRespOutputFactory object, then the slave calls the allocate method that must be implemented by the extended factory class to create new objects. The slave populates the values corresponding to the dw_vip_ahb_slave_transfer attributes, and sends the object through the output channel.

The output channel is used to notify the testbench that a transaction has arrived and that the model needs to know how to respond. The testbench must submit a response, through the input channel, in 0 cycles. The model assumes this 0-cycle reply. If the response is not returned within 0 cycles, the outcome is a fatal message that will terminate the simulation.

The slave input channel requires transactions of type dw_vip_ahb_slave_transfer. The data in the transaction is transferred to a model buffer that is then passed to the model to be used for the slave response. The input channel object generates an ENDED notification when the slave base model completes the transfer. If the transfer was completed with an "OKAY" response, the read or write data for the transfer is placed in the m_bvHdata attribute of the corresponding input channel object along with the ENDED notification.

3.8.6.2 Setting and Using Slave Reactive Response ModeTo enable Reactive Response mode, set the transactor’s configuration object as follows:

m_enReactiveResponse = VMT_BOOLEAN_TRUE

The input and output Transfer channels will be used instead of the AutoResponse channel in order to provide the slave with response information.

The process of using the slave transactor in Reactive Response mode, is as follows:

❖ The slave detects a transfer request on the AHB bus.

❖ The slave sets the transfer signature information within a dw_vip_ahb_slave_transfer object, and sends it out on the m_oTransferOutputChan channel.

❖ The testbench is required to get requests from that output channel and provide a response object to the m_oTransferInputChan channel in the same time step as the request was made.

❖ When the slave completes the transfer, then it provides an ENDED notification using the response object provided to the m_oTransferInputChan channel.

❖ If the transfer response is OKAY, then the m_bvHdata attribute of the input channel object will be updated with the read or write data from the resulting transfer.

❖ When generating the response, the testbench may examine the signature attributes of the request.

As an application note, the testbench can reuse the output channel request object as the input channel response object. When the ENDED notification is generated on the input object, then all the information about the transfer is contained in a single object. The testbench is not required to set any of the signature attributes of the response object since the AHB slave transactor does not use them. However, if the testbench keeps all the transfer information in the response object, then use the object's copy method prior to randomizing or setting the response attributes as in the following code fragment:

void = oRequestObject.copy(oResponseObject);void = oResponseObject.randomize();


www.designware.com




3.8.6.3 Slave Reactive Response to MessagesThe slave transactor in Reactive Response mode responds to these messages in the following way:

❖ AHBSLAVE_MSGID_REQUEST_XFER: Creates a new m_oOutputFactory object and sets signature attributes (see Table 4.12). It then puts the object into the m_oTransferOutputChan channel. The model requires a response object in the m_oTransferInputChan channel before the next rising clock edge; that is, in 0 cycles.

❖ AHBSLAVE_MSGID_END_OF_XFER: Message is received at the completion of an OKAY and ERROR response. The slave transactor sets the ENDED notification on the corresponding response object that was put into the m_oTransferInputChan channel. If m_enResp is OKAY, then the m_bvHdata attribute is set with the actual read or write data for that transfer. No other response object attributes are modified.

❖ AHBSLAVE_MSGID_RETRY_SPLIT_XFER: This message is received at the completion of RETRY and SPLIT responses. Sets the ENDED notification on the corresponding response object that was put into the m_oTransferInputChan channel. None of the response object attributes are modified.

Following is an example of how the testbench could wait for an ENDED notification generated by the slave transactor (assume that oSlave is a handle to slave object):

dw_vip_ahb_slave_transfer oXfer;void = oXfer.randomize();oSlave.m_TransferOutputChan.put_t(oXfer);oXfer = oSlave.m_oTransferOutputChan.get_t();oSlave.m_oTransferOutputChan.put_t(oXfer);void = oXfer.notify.wait_for_t(oXfer.ENDED);

3.8.7 AHB Slave Transaction Class: dw_vip_ahb_slave_transfer

The dw_vip_ahb_slave_transfer is derived from dw_vip_data. The constructor accepts one optional argument:

public task new ( rvm_log oLog = null );

The following enum type is scoped to this class.

enum response_enum = OKAY = DW_VIP_AMBA_RESPONSE_OKAY, ERROR = DW_VIP_AMBA_RESPONSE_ERROR, RETRY = DW_VIP_AMBA_RESPONSE_RETRY, SPLIT = DW_VIP_AMBA_RESPONSE_SPLIT;

As ahb_slave_transfer is derived from rvm_data, the following methods are supported:

❖ psdisplay

❖ allocate

❖ copy

❖ compare

❖ byte_size

❖ byte_pack

❖ byte_unpack



www.designware.com





3.8.8 Callbacksclass dw_vip_ahb_slave_rvm_callbacks extends vmm_xactor_callbacks { virtual task post_auto_response_input_channel_get( dw_vip_ahb_slave_rvm oRvmModel, integer nChanId, dw_vip_amba_slave_auto_response oVipXact, var bit drop );

// coverage callbacks virtual task auto_response_input_channel_cov ( dw_vip_ahb_slave_rvm oRvmModel, integer nChanId, dw_vip_amba_slave_auto_response oVipXact );}endclass

3.9 Using the AHB Monitor This section describes all the elements relating to the AHB Monitor transactor, and contains the following set of information:

❖ “Features” on page 88

❖ “AHB Monitor Ports” on page 89


❖ “Configuration” on page 96


❖ “Monitor Transactor Class: dw_vip_ahb_monitor_rvm” on page 96

❖ “Monitor Transaction Class: dw_vip_ahb_monitor_transaction” on page 96

❖ “Coverage and Coverage Data Classes” on page 98


3.9.1 Features

The AHB Monitor has the following features:

❖ Protocol checking

❖ Transaction logging

❖ AHB monitor buffers

❖ Coverage monitoring (not supported in VCS with NTB or Pioneer NTB)

❖ Incremental coverage (not supported in VCS with NTB or Pioneer NTB)

The Monitor can be configured for any valid AHB bus configuration from 8 to 1024-bits. All AHB transaction types are supported.

The monitor connects to the actual AHB signals, as defined in the AMBA Specification. There is one monitor-per-AHB bus, which is capable of supporting up to 16 masters and 16 slaves.


www.designware.com




The monitor can control protocol checkers, which can be stopped and started using configuration parameters.

Functional coverage is used to monitor particular states on the bus. Errors logged by the monitor are also tracked by the coverage object. Statistical reports are available for both valid and error states. This allows the monitor to be used to help ensure verification tests are covering the complete functionality. Functional coverage data can be saved and restored for incremental coverage reporting.

3.9.2 AHB Monitor Ports

Table 3-10 lists AHB Monitor ports and their direction, width, polarity and function.

Table 3-10 AHB Monitor Port Interface


HCLK Input 1 High Bus clock. All signals are sampled by the Monitor on the rising edge of HCLK.

HRESETN Input 1 Low Reset signal. To reset the model, assert HRESETN for at least one clock cycle.Protocol checking may occur before reset assertion, depending on how the m_enWaitForReset member is set in the system configuration object.

HRDATA Input [1023:0] [511:0] [255:0] [127:0] [63:0] [31:0] [15:0] [7:0]

— Read data bus. Output of the hrdata mux. Width is set by m_enHdataWidth in the system configuration object.

HADDR Input [63:0] [31:0]


HBURST Input 3 — Burst type. Indicates if the transfer forms part of a burst.

HMASTER Input 4 — Master number. Indicates which bus master is currently performing a transfer. Disabled when in AHB Lite mode, as set by m_enAhbLite in the AHB system configuration.

HMASTLOCK Input 1 High Locked sequence. Indicates that the current master is performing a locked sequence of transfers.

HPROT Input 4 — Protection control. Provide additional information about a bus access for data protection control.

HREADY Input 1 High Transfer done. Indicates that a bus transfer has finished.

HRESP Input [1:0] [0:0]

— Slave Response bus. HRESP[1} not required and may be left unconnected in AHB Lite modeb.

HSIZE Input 3 — Transfer size. Indicates the size of the transfer.

HTRANS Input 2 — Transfer type. Indicates the type of the current transfer.


www.designware.com




HWDATA Input [1023:0] [511:0] [255:0] [127:0] [63:0] [31:0] [15:0] [7:0]

— Write data bus. Transfers data from the Master to the Slaves during write operations. Width is set by m_enHdataWidth in the system configuration object.

HWRITE Input 1 High Transfer direction. Asserted indicates a write transfer.

HSEL Input [15:0] … [0:0]

— Slave select. Indicates that the current transfer is intended for the selected Slave or Slaves.

HSPLIT (16) Input [15:0] … [0:0]

— Split completion request. Indicates to the arbiter which bus Masters should be allowed to re-attempt a split transaction.Disabled when in AHB Lite mode, as set by m_enAhbLite in the AHB system configuration.Some pins may be disabled when m_nNumSlaves in the system configuration indicates that Slave is not present.Some pins may be disabled when m_envSplitCapable[] in the system configuration indicates that Slave is not split capable. Width set by the m_nNumMasters member in the system configuration.

HBUSREQ Input [15:0] … [0:0]

— Bus request. Indicates that the bus Master requires the bus.Disabled when in AHB Lite mode, as set by m_enAhbLite in the AHB system configuration.Width set by the m_nNumMasters member in the system configuration.

HGRANT Input [15:0] … [0:0]

— Bus grant. Indicates that the specified bus Master is currently the highest priority Master.Disabled when in AHB Lite mode, as set by m_enAhbLite in the AHB system configuration; see. Width set by the m_nNumMasters member in the system configuration.

HLOCK Input [15:0] … [0:0]

— Locked transfers. Indicates that the Master requires locked access to the bus.Width set by the m_nNumMasters member in the system configuration.



www.designware.com




3.9.3 ARM11 Monitor Features

The AHB monitor VIP model supports some ARM 11 features specified in Systems IP ARM11 AMBA (Rev2.0) AHB Extensions (v1.0). The ARM11 features are controlled using a system configuration parameter. You should pass the ARM11 ports as arguments to the AHB monitor model constructor.




Following is the list of features supported by AHB monitor:

❖ Checks on HBSTRB

❖ Exclusive access and L2 cache checks

❖ ARM11 response checks (XFAIL)

❖ Separate coverage callback class and coverage bins for ARM11 transactions

Following is the list of features that are currently not supported by the AHB monitor:

❖ Exclusive Access monitoring checks are not supported.

❖ HUNALIGN signal

❖ HDOMAIN signal

❖ Unaligned access checks are not supported. Refer to Section 2.3.2 of ARM11 specification.

Since any burst transaction can be optimized in many ways using HBSTRB, the model does not take a decision on optimizing a burst transaction. The slave model only drives the programmed HBSTRB for a given burst transfer.

Table 3-11 ARM11 Monitor Ports

NoteNoteNoteNote The ARM11 features have a separate set of ports. This does not affect the default mode of operation of AHB slave VIP. Only when using the ARM11 features, you are required to connect these ports.


Port Depth


hclk Input No No - 1 Input clock signal.

hbstrb_arm11 Input No No 1 128 The ARM11 HBSTRB signal identifies the strobes for read and write transfers.

hprot_arm11 Input No No 1 2 ARM 11 additional HPROT signals.hprot_arm11[0] is for Level2 Cache support. It represents HPROT[4] bit.hprot_arm11[1] is for exclusive access. It represents HPROT[5] bit.

hresp_arm11 Input No No 1 1 ARM11 AHB Exclusive response signal. It represents HRESP[2] bit.

hunalign_arm11 Input Yes No 1 1 This corresponds to HUNALIGN signal defined in ARM11 specification. It is not currently supported.


www.designware.com





This section provides an overview of how to connect the AHB monitor transactor in a testbench. To see a full example of the elements used to make these connections, see the example testbench located in:









The following interface definition files are provided for the AHB monitor transactor:

design_dir/verilog/include/AhbMonitorInterface.svi

A snippet of the interface definition for the AHB monitor transactor follows:

interface AhbMonitorInterface ( input [`DW_VIP_AMBA_HADDR_PORT_WIDTH-1:0] haddr, input [`DW_VIP_AMBA_HBURST_PORT_WIDTH-1:0] hburst,

hdomain_arm11 Input Yes No 1 4 This corresponds to HDOMAIN signal defined in ARM11 specification. It is not currently supported.

AttentionIt is recommended that you use this interface file in your testbench to ensure proper signal ordering. If you create your own interface definitions, the expanded order of signals in your modports must match the expanded signal order in the modports in these files.


Port Depth


DUT

Verilog test_top

Transactor


Interface_inst1

modport


www.designware.com




input hclk, input [`DW_VIP_AMBA_HMASTER_PORT_WIDTH-1:0] hmaster, input hmastlock, input [`DW_VIP_AMBA_HPROT_PORT_WIDTH-1:0] hprot, input [`DW_VIP_AMBA_HRDATA_PORT_WIDTH-1:0] hrdata, input hready, input hresetn, input [`DW_VIP_AMBA_HRESP_PORT_WIDTH-1:0] hresp, input [`DW_VIP_AMBA_HSIZE_PORT_WIDTH-1:0] hsize, input [`DW_VIP_AMBA_HTRANS_PORT_WIDTH-1:0] htrans, input [`DW_VIP_AMBA_HWDATA_PORT_WIDTH-1:0] hwdata, input hwrite, input [`DW_VIP_AMBA_HSEL_PORT_WIDTH-1:0] hsel, input [`DW_VIP_AMBA_NUM_AHB_MASTERS-1:0] hsplit_s0, ... input [`DW_VIP_AMBA_NUM_AHB_MASTERS-1:0] hsplit_s15, input [`DW_VIP_AMBA_NUM_AHB_MASTERS-1:0] hbusreq, input [`DW_VIP_AMBA_NUM_AHB_MASTERS-1:0] hgrant, input [`DW_VIP_AMBA_NUM_AHB_MASTERS-1:0] hlock ) ;



input haddr; input hburst;èndif

input hmaster; input hmastlock; input hprot; input hrdata; input hready; input hresetn; input hresp; input hsize; input htrans; input hwdata; input hwrite; input hsel; input hsplit_s0; ... input hbusreq; input hgrant; input hlock;endclocking modport Monitor(import Clk.*, import Cb.*);endinterface: AhbMonitorInterface


www.designware.com




3.9.4.2 Connecting the Transactor in the TestbenchDo the following things in your SystemVerilog testbench:

1. Pass a reference to the desired modport to connect to the transactor. For example, the bold portion refers to the Monitor modport of the AhbMonitorInterface defined above:

program automatic AhbSystemTest( AhbMonitorInterface.Monitor AhbMonitorBind, ...);

2. Import the entire contents of the model package for the AHB monitor. This step gives you access to all the elements of the AHB monitor:

// import the AHB monitor elementsimport AhbMonitor_rvm::*;

...


dw_vip_ahb_monitor_rvm monitor; ...monitor = new("AHB MONITOR",AhbMonitorBind,cfg_sys,monitor_activity_ch);...

4. Within your program's initial block you need to include a call to the setSystemClock method. This method needs to be provided with the clock for your overall system. If possible, this clock should correspond to the main clock provided to your transactors. But if you have multiple transactors that are being driven with different clocks, then you need to utilize the top level clock defined for your system.

3.9.4.2.1 Arm11 Monitor Interface Definitioninterface AhbArm11MonitorInterface #(parameter setup_time=1, parameterhold_time=1) ( input hclk, // Input to AHB ARM11 Monitor input [`DW_VIP_AMBA_AHBMONITOR_HBSTRB_ARM11_PORT_WIDTH - 1:0] hbstrb_arm11, input [`DW_VIP_AMBA_AHBMONITOR_HPROT_ARM11_PORT_WIDTH - 1:0] hprot_arm11, input hunalign_arm11, input [`DW_VIP_AMBA_AHBMONITOR_HDOMAIN_ARM11_PORT_WIDTH - 1:0] hdomain_arm11,

// Output from Ahb ARM11 Monitor input hresp_arm11) ;


clocking Cb @(posedge hclk); default input #(setup_time) output #(hold_time);



www.designware.com




// Input to Ahb Arm11 Monitor input hbstrb_arm11; input hprot_arm11; input hresp_arm11; input hunalign_arm11; input hdomain_arm11;

endclocking

modport Arm11Monitor(import Clk.*, import Cb.*);

endinterface: AhbArm11MonitorInterface

3.9.4.3 Connecting the Interface in the Top TestbenchFinally, you instantiate instance(s) of the interface and complete the connection in the Verilog top testbench, as shown in the next excerpt:


wire [ÀHB_HADDR_WIDTH-1:0] haddr_m1; wire [ÀHB_HBURST_WIDTH-1:0] hburst_m1; wire hbusreq_m1;...reg SystemClock;... AhbMonitorInterface intf_mon( .haddr ( haddr ), .hburst ( hburst ), .hclk ( hclk ), .hmaster ( hmaster ), .hmastlock ( hmastlock ), .hprot ( hprot ), .hrdata ( hrdata ), .hready ( hready ), .hresetn ( hresetn ), .hresp ( hresp ), .hsize ( hsize ), ... .hsplit_s15 ( hsplit_s15 ), .hbusreq ( hbusreq ), .hgrant ( hgrant ), .hlock ( hlock ) );...AhbSystemTest tb(intf_mon.Monitor);endmodule

Attention Enabling ARM11 mode requires the following VCS compile-time flags:+define+SYNOPSYS_ENABLE_ARM11_SV -ntb_define SYNOPSYS_ENABLE_ARM11_SV


www.designware.com




3.9.5 Configuration

See “AHB System Configuration Class: dw_vip_ahb_system_configuration” on page 60.

3.9.6 Channels


3.9.7 Monitor Transactor Class: dw_vip_ahb_monitor_rvm

The class that implements the monitor transactor is called dw_vip_ahb_monitor_rvm and is extended from vmm_xactor. The monitor transactor supports the basic VMM control methods along with the DesignWare VIP capabilities. It supports the activity channel, but it does not support the input or output channels.

The constructor for the monitor transactor takes six arguments. The configuration must be a dw_vip_ahb_system_configuration. The transaction must be a dw_vip_ahb_monitor_transaction.

public task new (string instName, AhbMonitorPort portConnect, dw_vip_ahb_system_configuration oVipCfg = null, dw_vip_ahb_monitor_transaction_channel oTransactionActivityChan = null, dw_vip_ahb_monitor_transaction oTransactionActivityFactory = null, dw_vip_ahb_monitor_error_cov oErrorCovFactory = null, dw_vip_ahb_monitor_activity_cov oActivityCovFactory = null, AhbArm11MonitorPort Arm11MonitorPortConnect = null);

The monitor transactor supports the basic VMM control methods along with the configuration capabilities.

The default implementation of functional coverage is included with the dw_vip_ahb_monitor_rvm. You can extend functional coverage if you want. For more information, see “Coverage and Coverage Data Classes” on page 98.

3.9.8 Monitor Transaction Class: dw_vip_ahb_monitor_transaction

The dw_vip_ahb_monitor_transaction class is extended from dw_vip_ahb_transaction. Several of the attributes presented in this section are defined in the dw_vip_ahb_transaction object. They can also be accessed through the dw_vip_ahb_monitor_transaction object. All attributes are not randomizable and the rand variable is turned off when the object is constructed.



3.9.8.1 Class Methods for dw_vip_ahb_monitor_transaction The following vmm_data methods are fully implemented by the AHB transaction classes:

❖ psdisplay

❖ allocate

❖ copy

❖ compare

❖ byte_size

❖ byte_pack

❖ byte_unpack (the len parameter is ignored)


www.designware.com




The “kind” parameter to the compare method supports two values: DW_VIP_VMT_LOGICAL and -1 (the default). These values both result in a logical compare, one that compares all fields in the transaction.

The byte_size, byte_pack and byte_unpack methods only support DW_VIP_VMT_LOGICAL. If kind defaults to -1 or is specified to be something other than DW_VIP_VMT_LOGICAL, these methods will generate a vmm_error. The error indicates the kind that was requested and the method that encountered the failure. Note that the len parameter is ignored. For example, if a kind of -1 is passed to the byte_pack method, the following error would be generated:


3.9.8.2 dw_vip_ahb_sequence_response_per_beat The class dw_vip_ahb_sequence_response_per_beat stores the information for each beat, and is defined as follows:

Class dw_vip_ahb_sequence_response_per_beat extends vmm_data{ bit [1:0] m_bvResponse[$]; integer m_nNumWaits[$]; bit m_bvArm11Responses[$];...}endclass

It supports the following vmm_data methods:

❖ psdisplay

❖ allocate

❖ copy

❖ compare

❖ byte_size

❖ byte_pack


The “kind” parameter to the compare method supports two values: DW_VIP_VMT_LOGICAL and -1 (the default). These values result in a logical compare, one that compares all fields in the transaction.

The byte_size, byte_pack and byte_unpack methods support only DW_VIP_VMT_LOGICAL. If kind defaults to -1 or is specified to be something other than DW_VIP_VMT_LOGICAL, these methods generate a vmm_error. The error indicates the kind that was requested and the method that encountered the failure. The len parameter is ignored. For example, if a kind of -1 is passed to the byte_pack method, the following error would be generated:


AttentionWhen using the ‘kind’ parameter, DW_VIP_VMT_LOGICAL must be replaced with a value of 9.

AttentionWhen using the ‘kind’ parameter, DW_VIP_VMT_LOGICAL must be replaced with a value of 9.


www.designware.com




3.9.9 Coverage and Coverage Data Classes

This section describes details of coverage and the coverage data classes.

The monitor callback classes define a set of callback methods for coverage purposes. When the monitor transactor detects traffic on the activity channel or detects a significant event, it calls the appropriate callback method with the data to be covered encapsulated in a coverage data class. When the monitor transactor creates the coverage data object for a callback, it calls the “allocate” method of the corresponding factory object (either oErrorCovFactory or oActivityCovFactory) if one is passed into the transactor constructor.

You can extend the base callback class to add coverage groups and bins and implement the virtual callbacks to add the data and sampling events. You can also extend the dw_vip_ahb_monitor_def_cov_data_callbacks class and add only the custom coverage groups and bins. There are several options to enable the coverage:

❖ Derive a class from dw_vip_ahb_monitor_rvm_callbacks and register it with the monitor transactor. This is a base class implementation of callbacks. This allows the user to extend its own callback class for coverage. You may need to create the following.

✦ Sampling events

✦ Coverage data structures

✦ Cover groups and bins

❖ Derive a class from dw_vip_ahb_monitor_def_cov_data_callbacks and register it with the monitor transactor. This class provides the following:

✦ Sampling events


It is possible to create your own cover groups and bins.

❖ Derive a class from _dw_vip_ahb_monitor_def_cov callbacks and register it with the monitor transactor. You can then add your own groups and bins to supplement the default coverage. This class provides the following:

✦ Sampling events


✦ Cover groups and bins

❖ Register an instance of dw_vip_ahb_monitor_def_cov callbacks, and create your own derived from dw_vip_ahb_monitor_rvm_callbacks to keep the groups separate.

3.9.9.1 Coverage Data ClassesThe data associated with significant event callbacks is encapsulated in coverage data classes that are derived from dw_vip_data. There are two coverage data classes used by the coverage callbacks.

The following vmm_data methods are fully implemented by the coverage data classes:

❖ display

❖ psdisplay

❖ allocate

❖ copy

❖ compare


www.designware.com




❖ byte_size

❖ byte_pack


The “kind” parameter to the compare method supports two values: DW_VIP_VMT_LOGICAL and -1 (the default). Both of these values result in a logical compare, one that compares all fields in the transaction.

The byte_size, byte_pack and byte_unpack methods only support DW_VIP_VMT_LOGICAL. If kind defaults to -1 or is specified to be something other than DW_VIP_VMT_LOGICAL, these methods generate a vmm_error. The error indicates the kind that was requested and the method that encountered the failure. For instance if a kind of -1 is passed to the byte_pack method the following error would be generated:


3.9.9.1.1 dw_vip_ahb_monitor_error_covWhen the monitor transactor detects a protocol error, this call is provided through the error_significant_error_cov callback. The following class scoped enum is defined for this class:

enum cov_type_enum = ERROR, PROTO_ERROR;

The following table describes the properties defined in this class.

3.9.9.1.2 dw_vip_ahb_monitor_significant_event_covThis data object is provided through the significant_event_cov callback. The following events trigger this callback:

❖ Arbitration requests

❖ Bus ownership hand-over

❖ Transitions associated with the HTrans signal

The m_enKind property defines which type of event has occurred. The following class scoped enum is defined for this class:

enum cov_type_enum = ARB_REQS, ARB_OWNS, HTRANS;



AttentionFor this release, when using the “kind” parameter, DW_VIP_VMT_LOGICAL must be replaced with a value of 9.

Table 3-12 dw_vip_ahb_monitor_error_cov Properties

Field Name Data Type Valid When m_enKind is

m_enKind cov_type_enum

m_nErrMsgId integer ERROR

m_nProtoErrMsgId integer PROTO_ERROR


www.designware.com




3.9.10 Callbacks

There are four callback classes that are provided with the monitor transactor:

❖ dw_vip_ahb_monitor_rvm_callbacks

❖ dw_vip_ahb_monitor_def_cov_data_callbacks

❖ dw_vip_ahb_monitor_def_cov callbacks

❖ dw_vip_ahb_monitor_arm11_def_cov_callbacks

For more details on callbacks and cover groups, refer to $DESIGNWARE_HOME/vip/amba/doc/ahb_vmm_html/index.html

3.10 Using the AHB Bus This section describes all the elements relating to the AHB bus transactor, and contains the following set of information:

❖ “Features” on page 100

❖ “AHB Bus Ports” on page 101


❖ “Configuration” on page 106


❖ “Bus Transactor Class: dw_vip_ahb_bus_rvm” on page 106


3.10.1 Features

The AHB Bus model provides a means of easily interconnecting AHB Masters and Slaves to form a standard AHB system as part of an on-chip bus solution. The AHB Bus model contains an Arbiter, Decoder, a Write Data Multiplexer, a Read Data/Response Multiplexer, a Control Signals Multiplexer, a dummy Master, and a default Slave.

The AHB Bus model supports these features:

❖ Supports up to 15 Masters and 15 Slaves

❖ Data Bus widths up to 1024 bits

❖ All types of responses

❖ System Address width of 32 or 64 bits

❖ Priority-based arbitration algorithm

❖ All types of burst and locked transfers

❖ Configurable early burst termination

❖ Unlimited memory map for each Slave

❖ Configurable termination of undefined length burst

❖ Arbiter ensures that only one Master is granted bus access at any time

NoteNoteNoteNote The AHB Bus model does not support AHB-Lite.


www.designware.com




3.10.2 AHB Bus Ports

Table 3-6 lists AHB Bus ports, their direction, width, polarity and function. Table 3-13 AHB Bus Port Interface


Control ports for all AHB devices a

HCLK Input 1 High System clock.

HRESETN Input 1 Low Reset. Used to reset all modules in an AHB system. During reset, the AHB Bus model issues a bus grant to the dummy Master.

Dummy Master a (Master 0) control port Note: This is the only port for the dummy Master.

HGRANT_M(0) Output 1 High Bus Master grant.

Default Slave a (Slave 0) control port Note: This is the only port for the default Slave.

HSEL_S(0) Output 1 High Slave select.

Master control ports for Masteri a (1 ≤ i ≤ 15) Note: Each Master, except Master 0, has a set of these ports.

HADDR_M(i) b Input [31:0] [63:0]

— Address bus for every Master in the AHB system.Note: All Masters should use same width as the system address width.

HBURST_M(i) Input [2:0] — Burst Type bus. Indicates if the transfer is part of a burst. The AHB Bus model supports all types of bursts.Note: Burst type is configured in each Master.

HBUSREQ_M(i) Input 1 High Master Request signal. The Master asserts this signal to request access to the system bus.

HLOCK_M(i) Input 1 High Lock signal. The Master asserts this signal when it starts a locked transaction.

HSIZE_M(i) Input [2:0] — Data Size bus. Indicates size of transfer. The AHB Bus model supports transfer sizes from 8 bits through 1024 bits.Note: Data size is configured in each Master.

HTRANS_M(i) Input [1:0] — Transfer Type signal. Indicates the type of the transfer. Can be NONSEQUENTIAL, SEQUENTIAL, IDLE, or BUSY.Note: Transfer type is configured in each Master.


www.designware.com




HWDATA_M(i) c Input [1023:0] [511:0] [255:0] [127:0] [63:0] [31:0] [15:0] [7:0]

— Write Data Bus for Master i. The AHB Bus model uses the portion of the bus that is the same width as the System Data Bus, starting from the LSB.Width is set by m_enHdataWidth in the system configuration object.

HWRITE_M(i) Input 1 High Write signal. When HIGH, indicates a write transfer; when LOW, indicates a read transfer.

HPROT_M(i) Input [3:0] — Protection Control bus.Note: Protection control is configured in each Master.

HGRANT_M(i) Output 1 High Bus Grant signal.

Slave control ports for Slavei a (1 ≤ i ≤ 15) Note: Each Slave, except Slave 0, has a set of these ports.

HSPLIT_S(j) Input [15:0] — Split Completion Request. Any split-capable Slave drives this signal to tell the Arbiter that bus Masters should be allowed to re-attempt split transactions. Each bit represents one Master: bit 0 for Master 0, bit 1 for Master 1, and so on.

HRDATA_S(j) c Input [1023:0] [511:0] [255:0] [127:0] [63:0] [31:0] [15:0] [7:0]

— Read Data Bus. The AHB Bus model uses the portion of the bus that is the same width as the System Data Bus, starting from the LSB.Width is set by m_enHdataWidth in the system configuration object.

HRESP_S(j) Input [1:0] — Transfer Response signal. Provides information on the status of a transfer. Possible responses are: OKAY (00), ERROR(01), RETRY(10), and SPLIT(11).

HREADY_ RESP_S(j)

Input 1 High Transfer Done signal. Indicates the Slave has completed a transfer.

HSEL_S(j) Output 1 High Slave Select signal. Indicates the specified Slave (j) is being selected for the current transfer.

Table 3-13 AHB Bus Port Interface (Continued)



www.designware.com




AHB System busses for all Masters a

HREADY Output 1 High Slave Ready signal. From Read Data and Response Mux.

HRESP Output [1:0] — HRESP System signals. From Read Data and Response Mux.

HRDATA c Output [1023:0] [511:0] [255:0] [127:0] [63:0] [31:0] [15:0] [7:0]

— AHB System Read Transfer Data Bus. From Read Data and Response Mux.Note: HRDATA width should be the same as HWDATA.

AHB System busses for all Slaves a d

HADDR b Output [31:0] [63:0]

— AHB System Address Bus. From Address and Control Mux.

HBURST Output [2:0] — Burst Type signals. From Address and Control Mux.

HSIZE Output [7:0] — Transfer Size signals. From Address and Control Mux.

HTRANS Output [1:0] — Transfer Type signals. From Address and Control Mux.

HPROT Output [3:0] — Protection Control signals. From Address and Control Mux.

HWRITE Output 1 High Transfer Direction. From Address and Control Mux.

HWDATA c Output [1023:0] [511:0] [255:0] [127:0] [63:0] [31:0] [15:0] [7:0]

— Write Data signals. From Write Data Mux.

HMASTER Output [3:0] — Master Number signals. Indicates which bus Master is performing a transfer. Controls Address and Control Mux. Split-capable Slaves use the value for starting a split access.

HMASTER_DATA Output [3:0] — Bus Master signals. Indicates which Master owns the Data Bus.




www.designware.com





For additional information, refer to “Testbench Connections” on page 67.

This section provides an overview of how to connect the AHB bus transactor in a testbench. To see a full example of the elements used to make these connections, see the example testbench located in:









The following interface definition files are provided for the AHB bus transactor:

design_dir/verilog/include/AhbBusInterface.svi

HMASTLOCK Output 1 High Locked Sequence signal. Indicates that the current Master is performing a locked transfer sequence.

a. All AHB Bus model input and output ports must be connected to signals.b. The number of ports on the bus that must be connected are defined by m_enHaddrWidth in the system

configuration object.c. The number of ports on the bus that must be connected are defined by m_enHdataWidth in the system

configuration object.d. Note: Not all Slaves have to support all of these ports. Support depends on each Slave’s capability. For example, a

Slave that does not allow different transfer sizes does not have an HSIZE port, so HSIZE does not need to be connected.



DUT

Verilog test_top

Transactor


Interface_inst1

modport


www.designware.com




A snippet of the interface definition for the AHB bus transactor follows:

interface AhbBusInterface ( input hresetn, input hclk,

input [`DW_VIP_AMBA_HADDR_PORT_WIDTH-1:0] haddr_m1, input [`DW_VIP_AMBA_HADDR_PORT_WIDTH-1:0] haddr_m2, ... output [`DW_VIP_AMBA_HMASTER_PORT_WIDTH-1:0] hmaster_data, output hmastlock ) ;



input hresetn; input haddr_m1; ... output hmaster; output hmaster_data; output hmastlock;

endclocking

modport Bus(import Clk.*, import Cb.*);

endinterface: AhbBusInterface

3.10.3.2 Connecting the Transactor in the TestbenchDo the following things in your SystemVerilog testbench:

1. Pass a reference to the desired modport to connect to the transactor. For example, the bold portion refers to the Bus modport of the AhbBusInterface defined above:

program automatic AhbSystemTest( AhbBusInterface.Bus AhbBusBind, ...);

2. Import the entire contents of the model package for the AHB bus. This step gives you access to all the elements of the AHB bus component:

// import the AHB bus elementsimport AhbBus_rvm::*;...

AttentionIt is recommended that you use this interface file in your testbench to ensure proper signal ordering. If you create your own interface definitions, the expanded order of signals in your modports must match the expanded signal order in the modports in these files.


www.designware.com





dw_vip_ahb_bus_rvm ahbbus; ...ahbbus = new("AHB BUS",AhbBusBind,cfg_sys);...

4. Within your program's initial block, you need to include a call to the setSystemClock method. This method needs to be provided with the clock for your overall system. If possible, this clock should correspond to the main clock provided to your transactors. However, if you have multiple transactors that are being driven with different clocks, you need to utilize the top level clock defined for your system.

3.10.3.3 Connecting the Interface in the Top TestbenchFinally, you instantiate instance(s) of the interface and complete the connection in the Verilog top testbench, as shown in the next excerpt:


wire [ÀHB_HADDR_WIDTH-1:0] haddr_m1; wire [ÀHB_HBURST_WIDTH-1:0] hburst_m1; wire hbusreq_m1;...reg SystemClock;... AhbBusInterface intf_bus( .hresetn (hresetn), .hclk (hclk), .haddr_m1 (haddr_m1), ... .hmaster_data (hmaster_data), .hmastlock (hmastlock));...AhbSystemTest tb(intf_bus.Bus);endmodule

3.10.4 Configuration

See “AHB System Configuration Class: dw_vip_ahb_system_configuration” on page 60.

3.10.5 Channels


3.10.6 Bus Transactor Class: dw_vip_ahb_bus_rvm

The class that implements the bus transactor is called dw_vip_ahb_bus_rvm and is extended from vmm_xactor. The bus transactor supports the basic RVM control methods along with the DesignWare VIP capabilities. It does not support any of the channels.

The constructor for the bus transactor takes three arguments, as shown in the following code fragment:


www.designware.com




function new (string sInstName, AhbBusInterface.Bus oPort, dw_vip_ahb_system_configuration oVipCfg = null);

The sInstName argument defines the vmm_xactor “instance” value. The oPort argument provides a port interface used internally. The oVipCfg object defines the bus transactor configuration information. The configuration must be a dw_vip_ahb_system_configuration object.

3.10.7 Callbacks

None


www.designware.com





www.designware.com


AMBA AHB Verification IP VMM User Manual Reporting Problems


AReporting Problems

If you think a VMT model is not working properly, contact a Synopsys Support Center. Before you contact the technical support, create an MCD (Model Change Dump) file for the model. The MCD file captures all activities of a model during simulation (that is, stimulus and response) in ASCII text format. Transmitting an MCD file to technical support ensures accurate diagnosis of the problem.

A.1 Creating MCD FilesTo create the MCD files, create a file called vmt_mcd.cfg in the directory where you run the simulation (the design directory). If this file exists, its contents determine which instances to dump.

❖ To dump all instances of DesignWare VIP:

Create an empty file named vmt_mcd.cfg in the design directory. Then, during the simulation:

✦ Each instance of DesignWare VIP in the testbench dumps debug activity into a file called instance_name.mcd.

✦ Also, for VMM/RVM testbenches, each instance of DesignWare VIP dumps VMM/RVM-level debug activity into a file called instance_name_rvm.mcd.

❖ To dump specific instances of DesignWare VIP:

Specify the instance names in the vmt_mcd.cfg file. (To identify DesignWare VIP instance names, see “Identifying an Instance” on page 110.) Then, during the simulation:

✦ Each specified instance of DesignWare VIP dumps debug activity into a file called instance_name.mcd.

✦ For VMM/RVM testbenches, each specified instance of DesignWare 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.u1top.u2.u1

During the simulation, each specified instance creates an MCD file. In this example, the files are:

✧ 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


www.designware.com


Reporting Problems AMBA AHB Verification IP VMM User Manual


A.2 Identifying an InstanceEach model instance has a unique name. This instance name is different depending on whether the model is being driven from an HDL testbench or from an OpenVera 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 Exampletop.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 it has an instance of the VMT model called “u1.”

A.3 Checking if MCD is EnabledWhen MCD is turned on for a model instance, a message with Warning severity is printed from 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 OnWhen MCD is turned on for a model, the model prints debug information to a file. As a result, simulation performance is degraded.

NoteNoteNoteNote Separator for most VHDL simulator is “/”, but the separator may be different for your simulator. Refer to your simulator documentation for the correct path separator.


www.designware.com


AMBA AHB Verification IP VMM User Manual Updating a DesignWare Library


BUpdating a DesignWare Library

B.1 Are Your Components and Tools Current?Synopsys provides several methods to let you know if your components and/or tools are current or out of date:

❖ You can subscribe to MyDesignWare notifications on a component basis, where you receive an email when a component is updated, or has new STAR information. See “MyDesignWare Subscriptions”.

❖ You can execute the command dwh_update (in DESIGNWARE_HOME/bin) which compares your DesignWare Library against the currently supported Synopsys components and tools. See “dwh_update Command”.

❖ You can enable automatic update checking in coreAssembler and coreConsultant, which checks the components in your design against both your DesignWare Library, and the currently supported Synopsys components. See “coreTools Automatic Update Checking”.

B.1.1 MyDesignWare Subscriptions

MyDesignWare enables you to receive product information that is of interest to you, such as product updates, technical articles, in-depth application notes and much more. You can add or remove selected subscriptions at any time. Sign-up through your SolvNet user account at:

https://www.synopsys.com/dw/mydesignware.php

B.1.1.1 DesignWare Technical Bulletin SubscriptionsSubscribe to a quarterly publication for Synopsys DesignWare customers which contains technical information regarding DesignWare products such as in-depth application notes.

B.1.1.2 DesignWare Component SubscriptionsProactive notification of new releases, STAR information availability and more. To add a component to your subscription list, locate it using the Search for IP tool on the left and select the "Subscribe" link.

B.1.2 dwh_update Command

The dwh_update command ($DESIGNWARE_HOME/bin directory) is a quick way for you to check your DesignWare Library against the latest components and tools that Synopsys provides. This command does not automatically update components, but only provides a report of what is or is not current. Links are provided to newer components to make updating easier.


www.designware.com

http://www.synopsys.com/dw/mydesignware.php


Updating a DesignWare Library AMBA AHB Verification IP VMM User Manual


If you specify the 'update' switch to check for newer versions of components and tools, you will need to provide SolvNet authentication. Reporting on the contents of DESIGNWARE_HOME, or when dwh_update updates itself to the latest version, does not require authentication.

If dwh_update is not in your DESIGNWARE_HOME tree, or the local version is less than 2.00a, you should download the latest dwh_update command from:

https://www.synopsys.com/dw/dwh_update_download.php

B.1.2.1 Example dwh_update UsageThe following generates a “delta” report showing what is out of date:

dwh_install -info u /remote/project_1/reportsdwh_update: Executing dwh_update.pl_2.02a

Access to Synopsys web server for library updateinformation requires SolvNet authentication.

SolvNet User: <your_solvnet_id>Password: <your_solvnet_password>

./dwh_delta.rpt written

An example dwh_delta.rpt report contents is shown:

## Update Report generated by dwh_update.pl_2.02a# From DESIGNWARE_HOME : /remote/project_1/DW_H-2005.04a# on Wed Aug 30 11:39:14 2006

Component : DW_memctlYour Version : 2.72aLatest Version : 2.73aPublication Date : June 08, 2006Download Size : 36359 kbDownload Link : https://www.synopsys.com/dw/dwdl.php?id=dw_iip_DW_memctl

Component : ethernet_monitor_vmt : ethernet_txrx_vmtYour Version : 1.10aLatest Version : 3.13aPublication Date : June 15, 2006Download Size : 26841 kbDownload Link : https://www.synopsys.com/dw/dwdl.php?id=dw_vip_ethernet. . . .

B.1.3 coreTools Automatic Update Checking

coreAssembler and coreConsultant provide a scheduled way for you to check for DesignWare Library synthesizable and verification component updates as well as existing STARs for the Synopsys IP used in your design workspace. When you complete the Add Subsystem Component activity in coreAssembler or the Specify Configuration activity in coreConsultant, these tools check your component versions against the most recent versions available both for download from Synopsys, and in your local DESIGNWARE_HOME

http://www.synopsys.com/dw/dwh_update_download.php


www.designware.com


AMBA AHB Verification IP VMM User Manual Updating a DesignWare Library


library. A report gives you newer version information, and lists STARs created/fixed for the components you are using.

You can perform a manual check at any time using the menu item Help > Check for IP Updates, or set an interval for coreTools to automatically generate the report.

For more information about Automatic/Manual IP update checks in coreAssembler and coreConsultant, see:

❖ “Component Update Checking” in the coreAssembler User Guide

❖ “Component Update Checking” in the coreConsultant User Guide

AttentionComponents are not automatically updated; this operation only generates a report. You must make these updates manually.


http://www.synopsys.com/products/designware/docs/doc/coretools/latest/caug.pdf

www.designware.com

http://www.synopsys.com/products/designware/docs/doc/coretools/latest/ccug.pdf


Updating a DesignWare Library AMBA AHB Verification IP VMM User Manual



www.designware.com


AMBA AHB Verification IP VMM User Manual Index


Index

AAdobe Acrobat Reader 17AHB Bus

ports 101AHB Master

ports 65AHB Slave

ports 76supported functions 13

CChannels, overview 44Class naming conventions, RVM 57DDesign directory

creating 18, 26Design information, obtaining 30DESIGNWARE_HOME variable 17, 25Documentation

overview 8related 7

Downloading VIP 17DW_LICENSE_FILE variable 24DW_LICENSE_OVERRIDE 24dw_vip_setup utility

creating simulation scripts 31determining model version 26environment variables 27examples of 30invoking 28obtaining design information 30removing models 30running 27

DW_WAIT_LICENSE 25

EEnvironment

DESIGNWARE_HOME variable 17, 25DW_LICENSE_FILE variable 24DW_LICENSE_OVERRIDE 24dw_vip_setup utility variables 27DW_WAIT_LICENSE 25library path variable 26LM_LICENSE_FILE variable 17, 24, 26simulator-specific settings 26SNPSLMD_LICENSE_FILE variable 17, 24, 26variable and path settings 25VERA_HOME variable 26

Example testbencheslocations of 22running 18

GGenerators

macros for creating 52Getting started 15HHelp, contacting Synopsys 8IInstallation

overview 15preparing for 17

LLicensing 23

DW_LICENSE_FILE variable 24keys 23licensing features 23LM_LICENSE_FILE variable 17, 24, 26polling 25


www.designware.com


Index AMBA AHB Verification IP VMM User Manual


SNPSLMD_LICENSE_FILE variable 17, 24, 26suspension 25

LM_LICENSE_FILE variable 17, 24, 26MMCD (Model Change Dump) file

and model messages 110creating 109impact of 110instance name, VERA 110instance name, Verilog or VHDL 110introduction 109

Messagesnotify 54

Model version, determining 26Models, removing 30NNotify for messages 54PPorts

AHB Bus 101AHB Master 65AHB Slave 76

Problems, reporting 109RReporting problems 109Requirements

software 16RVM

naming conventions 57sample environment 43testbench 22using 39

SSimulation script 31simulator 18Simulators

creating simulation scripts 31environment settings 26license suspension 25run scripts and C compiler 18running simulation script 31

SNPSLMD_LICENSE_FILE variable 17, 24, 26

Software requirements 16STARs checking 112Support Matrix 17Support, contacting 8Support, reporting problems 109Support, websites 8Supported functions 13Synopsys, websites 8TTestbench

RVM 22System Verilog 32using Ethernet VIP in 32

Testbench, sim script 31Troubleshooting, reporting problems 109VVera Modeling Technology (VMT), version 16VERA_HOME variable 26Version, determining 26VMT version 16WWebsites, Synopsys 8


www.designware.com

Date post:	08-Nov-2014
Category:	Documents
Upload:	kuani-lee
View:	269 times
Download:	4 times