AMBA Transactors User and Reference Guide: Product Version 5.4 May 2005

AMBA Transactors User and Reference
Guide
Product Version 5.4
May 2005
2004 Cadence Design Systems, Inc. All rights reserved.

Printed in the United States of America.
Cadence Design Systems, Inc., 555 River Oaks Parkway, San Jose, CA 95134, USA
Trademarks: Trademarks and service marks of Cadence Design Systems, Inc. (Cadence) contained in
this document are attributed to Cadence with the appropriate symbol. For queries regarding Cadences
trademarks, contact the corporate legal department at the address shown above or call 800.862.4522.
Open SystemC, Open SystemC Initiative, OSCI, SystemC, and SystemC Initiative are trademarks or
registered trademarks of Open SystemC Initiative, Inc. in the United States and other countries and are
used with permission.
All other trademarks are the property of their respective holders.
Restricted Print Permission: This publication is protected by copyright and any unauthorized use of this
publication may violate copyright, trademark, and other laws. Except as specified in this permission
statement, this publication may not be copied, reproduced, modified, published, uploaded, posted,
transmitted, or distributed in any way, without prior written permission from Cadence. This statement grants
you permission to print one (1) hard copy of this publication subject to the following conditions:
1. The publication may be used solely for personal, informational, and noncommercial purposes;
2. The publication may not be modified in any way;
3. Any copy of the publication or portion thereof must include all original copyright, trademark, and other
proprietary notices and this permission statement; and
4. Cadence reserves the right to revoke this authorization at any time, and any such use shall be
discontinued immediately upon written notice from Cadence.
Disclaimer: Information in this publication is subject to change without notice and does not represent a
commitment on the part of Cadence. The information contained herein is the proprietary and confidential
information of Cadence or its licensors, and is supplied subject to, and may be used only by Cadences
customer in accordance with, a written agreement between Cadence and its customer. Except as may be
explicitly set forth in such agreement, Cadence does not make, and expressly disclaims, any
representations or warranties as to the completeness, accuracy or usefulness of the information contained
in this document. Cadence does not warrant that use of such information will not infringe any third party
rights, nor does Cadence assume any liability for damages or costs of any kind that may result from use of
such information.
Restricted Rights: Use, duplication, or disclosure by the Government is subject to restrictions as set forth
in FAR52.227-14 and DFAR252.227-7013 et seq. or its successor.
AMBA Transactors User and Reference Guide
Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
How to Use This Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Platform Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1
Transaction-Based Verification Overview . . . . . . . . . . . . . . . . . . . . . . . 5
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Transaction-Based Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Non-Transaction-Based Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Transaction-Based Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Why move to Transaction Based Verification? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Other Sources of Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
6
6
7
7
8
2
Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Installation and Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
AMBA Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Running the Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
AMBA Transactor Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Construction and Instantiation of the Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Construction and Instantiation of the Slave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Construction and Instantiation of the Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Verilog System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
VHDL System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3
Introduction to the AHB Transactors Family . . . . . . . . . . . . . . . . . . . 31
Introduction
May 2005
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Product Version 5.4
Verification of AHB Peripherals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Single-master Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Single-slave Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Multi-Master DUV Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Multi-slave DUV Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Additional information on the verification configurations . . . . . . . . . . . . . . . . . . . . . .
Transactor Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Transactor Configuration Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Transactor Transaction-Level Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Transactor Pin-Level Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Transactor Transaction View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Transaction Searches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Stimulus Generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Device Emulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
38
38
38
39
39
40
40
40
40
41
41
42
42
4
AHB Transactor Reference Information . . . . . . . . . . . . . . . . . . . . . . . . 43
AHB Master Transactor Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
AHB Master Transactor Overall Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Master Configuration Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Master Transaction-level Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Pull Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Push Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The ahb_arg_t Public Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The ahb_arg_t static public methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating and using transaction handles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
AHB Master Pin-Level Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
AHB Master Transaction Recording . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Endian Format of the Data Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Start Delay Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Bus Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Transfer Lock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Insertion of BUSY cycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Retried bursts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Early terminated bursts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
May 2005
45
45
47
49
50
52
59
72
75
75
77
84
85
85
85
87
88
88
Product Version 5.4
AHB 1K Line Burst Protection Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

AHB Slave Transactor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
AHB Slave Transactor Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
AHB Slave Transactor Configuration Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
AHB Slave Device Emulator Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Configuration Argument Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
AHB Slave Device Emulator Transaction-Level Interface . . . . . . . . . . . . . . . . . . . . . 113
Push Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
AHB Slave Port Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
AHB Slave Transaction Recording . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Slave Burst Pipelined Stream Parent-Child relationship . . . . . . . . . . . . . . . . . . . . . . 127
AHB Monitor Transactor ( ahb_monitor_t ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
AHB Monitor Configuration Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
AHB Monitor Pin-Level Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
AHB Monitor Transaction Recording . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Compliance Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
A
Appendix A - References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Glossary
May 2005
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Product Version 5.4
May 2005
Product Version 5.4
Preface
The purpose of this document is to describe the Cadence AMBA-AHB transactors developed
in SystemC. The Transactors are used to test design that are compliant with the AMBA AHB
protocol. Cadence Transactors are behavioral models intended to support the functional
verification of ASIC and system designs. These models are written in C++ using the
TestBuilder-SystemC libraries provided in the Cadence LDV package.
How to Use This Document

This document is organized in the following manner:
Chapter 1, Transaction-Based Verification Overview, gives you an overview of transactionbased verification.
Chapter 2, Getting Started, provides you with an overview of each of the Transactors.
Chapter 3, Introduction to the AHB Transactors Family, gives you instructions on the
procedures required to set up and run the Transactors. This chapter also provides information
on the creation of stimulus.
Chapter 4, AHB Transactor Reference Information, gives you reference information about
each of the Transactors. They include the AHB Master Transactor, the AHB Slave Transactor,
and the AHB Monitor Transactor.
Appendix A - References includes references to topics related to tools used with the
Transactors that are not described in this document.
Prerequisites
A verification team using this document should have the following set of knowledge and skills:
C++ (Required)
Verilog, VHDL, NC-Sim or other HDL

See the NC-Verilog Simulator Help and the NC-VHDL Simulator Help for
information on the Cadence simulators.
May 2005
Product Version 5.4

Preface
SystemC (Recommended)
See the NC-SC Simulator User Guide for information on Cadence SystemC.
Simvision Waveform Window (Recommended)

See the SimVision User Guide for information on the Simvision Waveform Window.
TxE (Transaction Explorer) (Recommended)

See the Transaction Explorer User Guide for infomation on TxE. Also see the
Transaction-Based Verification User Guide for infomation on transactors.
Knowledge of AMBA AHB Protocol Specifications - (Recommended)
Note: Skills indicated as Recommended are not required, but knowledge of those skills will
contribute to a better understanding of the tasks.
Platform Support
The AMBA-AHB Transactors have been tested and are supported on the following platforms:
Sun-Solaris 8
Linux Red-Hat 7.1
HP-UX11.0
May 2005
Product Version 5.4

Preface
Contact Information
For answers to your sales questions please send an e-mail to avs@cadence.com or contact
your sales representative.
Additional information can be found on the web at:
www.cadence.com/methodology_services.
The table below lists the Worldwide Cadence Support contact information:
Table 1-1
Region
E-mail
Phone
Fax
North America
support@cadence.com
1(877)CDS-4911 or
1(877)237-4911
(512)349-7131
Japan
crc_japan@cadence.com
+81-45-475-2223
+81-45-475-2224
(from other countries) (from other
countries)
0120-194-655 (from
Japan)
Central Europe
germany_crc@cadence.co +49-89-4563-1900
m
Northern Europe ukhelp@cadence.com
0120-667-281
(from Japan)
+49-89-4563-1919
+31-4020-89211
(Benelux)
+44-1344-865444
(UK)
+44-1344-869660
(UK)
+46-8-56612390
(Sweden)
+46-8-7520250
(Sweden)
+972-995-11799
(Israel)
Southern Europe france_crc@cadence.com +33-1-34-88-53-32
+33-1-34-88-53-51
(from other countries)
0800-32-32-31
(from France)
Hong Kong
hk_crc@cadence.com
+852-2377-7111
+852-2377-2802
Korea
korea_crc@cadence.com
+82-2-3770-0770
+82-2-3770-0771
May 2005
Product Version 5.4

Preface
Table 1-1
Region
E-mail
Phone
P.R. of China
china_support@cadence. +8610-6848196[3]-[6] +8610-68481971

com
(Beijing
(Beijing)
Representative
Office)
+8621-63850850
(Shanghai
Representative
Office)
Fax
+8621-63850977
(Shanghai)
Singapore
singapore_crc@cadence. +65-895-5151
com
+65-569-0688
Taiwan
taiwan_crc@cadence.com +886-35-778-951
+886-35-780-422
May 2005
Product Version 5.4
1
Transaction-Based Verification Overview
This chapter gives you an overview of transaction-based verification. The chapter tells you
about the benefits of transaction-based verification and how a transaction-based verification
methodology can help your verification effort.
This chapter contains the following topics:
Introduction on page 5
Transaction-Based Verification on page 6
Why move to Transaction Based Verification? on page 7
Introduction
Transaction-based verification lets you develop simulation test benches and analyze and
debug simulations at a higher level of abstraction than simply using an HDL.
Transaction-based verification consists of transactions and transactors.
A transaction is a high-level transfer of data from one device to another over a well-defined
interface. Transactions can be as simple as a read or write, or as complex as passing a data
packet through a design.
A transactor is a device that executes a transaction. The transactor connects to a design
under verification (DUV) at a design interface and serves as an abstraction layer between the
test program and the design.
Cadence has developed key transactors like the AMBA AHB transactor, the USB transactor,
and the PCI family of transactors. These transactors are written in C++/SystemC. To use a
transactor, a test engineer writes tests in C++/SystemC, calling tasks and functions, which
are implemented in the transactor.
May 2005
Product Version 5.4

Transaction-Based Verification
Transaction-based verification raises the level of abstraction from signals to transactions. This
means that a test engineer can concentrate on writing tests and improving the overall
verification effort rather than being concerned with low-level signal-based tasks. A
transaction-based verification methodology also encourages the re-use of test components
and transforms components like transactors into intellectual property (IP).
Non-Transaction-Based Verification
An example of a typical setup for the verification of a block- and chip-level digital register
transfer level (RTL) design is illustrated in Figure 1-1 on page 6. As shown in the figure, the
verification setup consists of the design under verification and a stimuli and response
generator.
Figure 1-1 Non-Transaction-Based Verification Architecture
Stimuli/Response
Generator
Design Under Verification

(RTL code)
In operation, the DUV is provided with test stimuli from a stimuli/response generator, which
also checks the results of the test. The interface between the testbench module (which is the
stimuli/response generator) and the DUV are at the signal level. Therefore, the test engineer
writes signal-level tests, which include the details of the communication of the tests with the
DUV interface.
For example, assume that the interface between the stimuli generator and the DUV is a bus
with typical signal-level elements such as a data bus, an address bus, and control signals
(such as read/no_write, chip_select, and so on). A test engineer needs to write tests
toggling all of these signals, in the correct sequence, in order to generate the correct interface
protocol.
May 2005
Product Version 5.4

Transaction-Based Verification
Figure 1-2 on page 7 shows a transaction-based verification architecture. In the
transaction-based architecture an extra layer, the transactor, is introduced between the
stimuli/response generator and the design under verification.
The test engineer writes tests using transactions. A simple example of a possible transaction
is as follows:
write(data, address)
The details of how the write transaction is translated into signal accurate values and
protocol specific sequence activating the data, address and the control signals is taken care
of by the transactor.
Figure 1-2 Transaction-Based Verification Architecture
Stimuli/Response
Generator
Transactor
Design Under Verification

(RTL code)
Why move to Transaction Based Verification?

Working at the transaction level lets a test engineer create tests, debug the design, and
measure functional coverage without the need for dealing with the details of low-level signals
and bus protocols.
A transaction-based verification methodology supports and facilitates several verification
concepts including:
Self-checking tests
Bus monitors
Random tests
Constrained random tests
The result is a more complete, more efficient verification of the design.

May 2005
Product Version 5.4

Other Sources of Information

For more information on transactions see the Transaction Based Verification Guide and
the subsequent chapters in this user guide. The Transaction Based Verification Guide is
available in the CDSDoc online documentation library from your CVE installation or from
Source Link. See the Whats New for instructions on accessing documents from Source Link.
For an introduction to the transaction based verification methodology adopted by Cadence
see A Tutorial Introduction on the New SystemC Verification Standard, by C. Norris
and Stuart Swan, in the Technical Papers section at http://www.systemc.org and at
http://www.testbuilder.net/whitepapers/sc_tut.pdf.
May 2005
Product Version 5.4
2
Getting Started
This chapter defines the procedures you use to prepare and use the AMBA family of
transactors and contains the following topics:
Installation and Licensing on page 5
AMBA Configuration on Page 6
AMBA Transactor Construction on page 7
Installation and Licensing

The following software should be installed on your system prior to installing and using the
transactors:
The Cadence Verification Extensions (Formerly known as TestBuilder-SC)
NC-SC
NC-Verilog, NC-VHDL, or the Cadence mixed-language simulator
C++ Compiler
SimVision Waves (Recommended/Optional)
Transaction Explorer (TxE) (Recommended/Optional)
Note: Check the Whats New for specific versions of each of the tools that are supported for
a specific release.
Installation
The AMBA transactors are installed using Cadences SoftLoad utility. For instructions on
using SoftLoad see the Cadence Installation Guide. The installation guide takes you
through the complete installation procedure through testing the validity of your installation.
May 2005
Product Version 5.4

Getting Started
Installation Directory
Installing the transactor creates the following directory:
tools.platform/tvmsc/amba20
Where platform is sun4v for Solaris, hppa for HP-UX, lnx86 for Linux. For example the
following path is for the Solaris platform:
tools.sun4v/tvmsc/amba20
SoftLoad installs all component files in subdirectories as follows:
examplesContains an example testbench, example test case, and a run script

that can be used for incoming inspection of the installation. Refer to the README
document at this location.
includeContains header files required to link in the components shared object

file.
libContains the required library files for the components shared object file.
verilogContains the Verilog wrappers for master, slave, and monitor

transactors.
vhdlContains the VHDL wrappers for master, slave, and monitor transactors.
scriptsContains the perl script for setting the configuration.
AMBA Configuration
The library for AMBA transactors is available in the lib subdirectory. This subdirectory
contains a library compiled with GNU and NATIVE compilers on different platforms. To set
up the correct configuration following steps are required:
Source the IUS5.3 environment
Type the following line to define the required environment variable:

setenv AMBA_TVM_TOP tools.platform/tvmsc/amba20
Change directories to the following directory:

tools.platform/tvmsc/amba20
Run the following command:

command ./setup
When you run the command, the following output appears on your screen:
./setup
May 2005
10
Product Version 5.4

Getting Started
perl: tools.<plat>/tvmsc/amba20/lib
=============================================================
The following selection of LDV Releases and Compilers are
supported in this release :
=============================================================
1. IUS 5.3 gnu
2. IUS 5.3 native
Enter Selection: 2
Installing Library for IUS 5.3 and native
... Done
Verify that the following softlinks are created in the lib subdirectory:
libahb20_32b.so -> libamba20-bw32-ius53-native.so
Running the Example

After you have setup the environment, you can run the example. To run the example do the
following:
1. Change directories to the following directory:
tools.sun4v/tvmsc/amba20/example/run_ahb_master_slave
2. Run one of the following commands:

a. make exe_push_32
b. make exe_push_32 -f Makefile.native
Note: Refer to the README file for details on the make file.
3. Type the following command to view transaction recording:
simvision txdb
AMBA Transactor Construction

The AMBA transactors are written in SystemC and are provided to you with HDL wrappers,
which you use to connect to the design under verification (DUV) and the stimulus.
Stimulus generation for the AMBA transactor is modeled by the class:
push_stimulus_generator_t
May 2005
11
Product Version 5.4

Getting Started
Members and methods of this class are responsible for the construction, instantiation, and
control of the master, slave, and monitor transactors.
The class push_stimulus_generator_t is defined as follows:
class push_stimulus_generator_t : public sc_module {
public:
//Push Interface for the Master
sc_port<uvm_push_if_t<ahb_arg_handle_t>,1> master_tx_port;
//Transaction Configuration port
sc_port<uvm_control_if_t<ahb_configuration_t>, 0> master_control_port;
sc_port<uvm_control_if_t<ahb_configuration_t>, 0> slave_control_port;
sc_port<uvm_control_if_t<ahb_configuration_t>, 0> monitor_control_port;
// control interface to the Slave Device Emulator
sc_port<uvm_control_if_t<ahb_slave_device_emulator_config_t>, 0>
device_emulator_control_port;
// Slave Device Emulator Configuration Object
ahb_slave_device_emulator_config_t emulator_config;
// Lists are used to keep a reference of all the transactions submitted to
// each master
ahb_transaction_list_t master_transaction_handles;
//structure that centralizes the transactors configuration attributes
ahb_configuration_t transactors_config;
SC_CTOR(push_stimulus_generator_t) :
master_tx_port("master_tx_port"),
master_control_port("master_control_port"),
slave_control_port("slave_control_port"),
monitor_control_port("monitor_control_port"),
device_emulator_control_port("device_emulator_control_port"),
emulator_config(device_emulator_control_port),
master_transaction_handles("master_tx_list", ahb_arg_handle_t() )
{
SC_THREAD(tb_main);
}
//Main function spawned in this stimulus
void tb_main();
//Actual stimulus function
May 2005
12
Product Version 5.4

Getting Started
void run_master_slave_demo();
private:
void info_msg_control();
void transaction_control();
};
// tb_main method
void push_stimulus_generator_t::tb_main()
{
cout << sc_time_stamp() << ": stimulus Thread Starts..." << endl;
info_msg_control();
transaction_control();
run_master_slave_demo();
tb_out << sc_time_stamp() << ": stimulus Thread is Completed..." << endl;
wait(1000, SC_NS);//To see clearly the End of the TestCase in simvision
tb_exit();
}
void push_stimulus_generator_t::run_master_slave_demo()
{
tb_out << sc_time_stamp() << name()
<< ": Single Master/Slave stimulus Test started, submitting "
<< NUM_TRANSACTIONS << " transactions to each Master... " << endl;
unsigned int startAddr;
scv_smart_ptr<sc_uint<8> > randomDataByte;//generates random data
//Clear the device emulators
emulator_config.clear_emulator();
//Set Little endianess
transactors_config.big_endian = false;
master_control_port->send_control(transactors_config);
slave_control_port->send_control(transactors_config);
monitor_control_port->send_control(transactors_config);
for( unsigned addr = MIN_SLAVE_ADDRESS;
addr <= MIN_SLAVE_ADDRESS + 528 + 16; addr++ )
{
randomDataByte->next();//randomize data byte
//Configure the device emulator with data, wait cycles and response types
emulator_config.write_emulator(addr,
May 2005
13
Product Version 5.4

Getting Started
randomDataByte->read(),
response_typeBag.peekRandom(),
responseDelayBag.peekRandom(),
0);
}
//Configure device emulators to reset responses to OKAY after a
//RETRY/SPLIT/ERROR transfer
emulator_config.set_reset_response_after_use( true );
for( int i=1; i<= NUM_TRANSACTIONS; i++) {
//create a new transaction object for each master
//and store a handle of it in the transaction handles list.
master_transaction_handles[i] = new ahb_arg_t;
unsigned int burstType = burstTypeBag.peekRandom();
randomStartAddr->next();
startAddr = randomStartAddr->read();
//Configure a Burst with incremental data value (incremented at each
// byte address).
//Transfer size: 1 byte, No data self-checking, Burst length is 10 if INCR
master_transaction_handles[i]->fill_data_burst( burstType,
startAddr,
AHB_SIZE_BYTE,
false,
INCR,
10,
0);
master_transaction_handles[i]->set_write_transaction(
readWriteBag.peekRandom() );
tb_out << " Time = " << sc_time_stamp() << ": A "
<< master_transaction_handles[i]->get_burst_string()
<< " transaction is submitted to the master " << endl;
master_tx_port->push( master_transaction_handles[i] );
//end of for(transaction) iteration loop
//Make sure that the last transaction submitted for both masters are
//complete before returning
master_transaction_handles[NUM_TRANSACTIONS]->wait_for_finish_event();
May 2005
14
Product Version 5.4

Getting Started
tb_out
<< sc_time_stamp() << name()

<< ": Single Master/Slave Demo test has completed" << endl;
Construction and Instantiation of the Master

SystemC port with a UVM interface that provides connection to the AHB Master transactor is
shown below:
sc_port<uvm_push_if_t<ahb_arg_handle_t>,1> master_tx_port;
sc_port<uvm_control_if_t<ahb_configuration_t>, 0> master_control_port;
A master object is constructed inside a special method called end_of_construction in

the top level SystemC testbench as follows:
ahb_master_t *mas =
(ahb_master_t*) (simcontext()->find_object("top.ahbMaster"));
if(mas == NULL) {
cout << "ERROR: did not find 'top.ahbMaster'\n" << endl;
return;
}
mas->puller_port(master_fifo);
The master is bound to the SystemC port inside end_of_construction as follows:

stimulus_p->master_control_port(*mas);
where stimulus_p is of type push_stimulus_generator_t *.
Construction and Instantiation of the Slave

A SystemC port with a UVM interface that provides connection to the AHB Slave transactor
is shown below:
sc_port<uvm_control_if_t<ahb_slave_device_emulator_config_t>, 0>
device_emulator_control_port;
sc_port<uvm_control_if_t<ahb_configuration_t>, 0> slave_control_port;
A slave object is constructed inside a special method called end_of_construction in the

top level SystemC testbench as follows:
ahb_slave_t *slv =
(ahb_slave_t*) (simcontext()->find_object("top.ahbSlave"));
cout << "find_object() has been called" << endl;
May 2005
15
Product Version 5.4

Getting Started
if(slv == NULL) {
cout << "ERROR: did not find 'top.ahbSlave'\n" << endl;
return;
}
// Bind the 1st Response Generator to the AHB Slave Response Generator Port
slv->slave_device_emulator_port(slave_device_emulator);
The slave is bound to the SystemC port inside end_of_construction as follows:

stimulus_p->slave_control_port(*slv);
Construction and Instantiation of the Monitor

A SystemC port with a UVM interface that provides connection to the AHB Slave transactor
is shown below:
sc_port<uvm_control_if_t<ahb_configuration_t>, 0> monitor_control_port;
A monitor object is constructed inside a special method called end_of_construction in

the top level SystemC testbench as follows:
ahb_standalone_monitor_t *mon =
(ahb_standalone_monitor_t*) (simcontext()->find_object("top.ahbMonitor"));
cout << "find_object() has been called" << endl;
if(mon == NULL) {
cout << "ERROR: did not find 'top.ahbMonitor'\n" << endl;
return;
}
The monitor is bound to SystemC port inside end_of_construction as follows:

stimulus_p->monitor_control_port(*mon);
Verilog System
At the top level, there are five inter-connected components:
1. MasterahbMaster (or Host DUV)
2. SlaveahbSlave (or Device DUV)
3. MonitorahbMonitor
4. ahbBusahbBus
5. topTestbenchtopTest
May 2005
16
Product Version 5.4

Getting Started
The top-level Verilog module with the transactor trio connected to the stimulus is as follows:
timescale 1 ns/1 ps
//The testbench is empty, it is used as the top level entry point
//for a systemc netlist.
ifdef NCSC
module topTestbench (* integer foreign = "SystemC";
*);
else
module topTestbench;
initial $sc_cosim_init;
endif
endmodule
module top;
//Definition of the Data bus width parameter
ifdef DATA32
parameter data_bus_width = 32;
else
ifdef DATA64
else
ifdef DATA128
else
parameter data_bus_width = 128; //Default value if no DATAxx was passed in
the command line
endif // DATA128
endif // DATA64
endif // DATA32
// Master Specific AHB Signals
wire
ahb_gnt_M1;
wire
ahb_gnt_M2;
wire
ahb_req_M1;
wire
ahb_lock_M1;
wire [31:0]
ahb_addr_M1;
wire [1:0]
ahb_trans_M1;
wire
ahb_write_M1;
wire [2:0]
ahb_size_M1;
May 2005
17
Product Version 5.4

Getting Started
wire
wire
wire
wire
wire
wire
wire
wire
wire
wire
wire
wire
[2:0]
ahb_burst_M1;
[3:0]
ahb_prot_M1;
[data_bus_width-1:0]
ahb_w_data_M1;
ahb_req_M2;
ahb_lock_M2;
[31:0]
ahb_addr_M2;
[1:0]
ahb_trans_M2;
ahb_write_M2;
[2:0]
ahb_size_M2;
[2:0]
ahb_burst_M2;
[3:0]
ahb_prot_M2;
ahb_w_data_M2;
// Slave Specific AHB Signals

wire
ahb_sel_S1;
wire [15:0]
ahb_split_S1;
wire
ahb_ready_S1;
wire [1:0]
ahb_resp_S1;
wire [data_bus_width-1:0]
ahb_r_data_S1;
wire
ahb_sel_S2;
wire [15:0]
ahb_split_S2;
wire
ahb_ready_S2;
wire [1:0]
ahb_resp_S2;
ahb_r_data_S2;
// Multiplexed signals
wire [31:0]
wire [1:0]
wire
wire [2:0]
wire [2:0]
wire [3:0]
wire
wire [1:0]
ahb_addr;
ahb_trans;
ahb_write;
ahb_size;
ahb_burst;
ahb_prot;
ahb_w_data;
ahb_r_data;
ahb_ready;
ahb_resp;
// System Clock and Reset

reg
resetn;
reg
clk;
May 2005
18
Product Version 5.4

Getting Started
//AHB Bus Outputs used in Split-enables Slaves
wire [3:0]
ahb_master_id;
wire
ahb_mastlock;
topTestbench topTest();
// Instance of the AHB Master TVM
ahb_master_t ahbMaster (
.ahb_clk(clk),
.ahb_resetn(resetn),
.ahb_gnt(1b1),
.ahb_lock(ahb_lock_M1),
.ahb_req(ahb_req_M1),
.ahb_resp(ahb_resp),
.ahb_ready(ahb_ready),
.ahb_r_data(ahb_r_data),
.ahb_w_data(ahb_w_data_M1),
.ahb_prot(ahb_prot_M1),
.ahb_burst(ahb_burst_M1),
.ahb_size(ahb_size_M1),
.ahb_write(ahb_write_M1),
.ahb_trans(ahb_trans_M1),
.ahb_addr(ahb_addr_M1)
);
// Instance of the AHB Slave TVM
ahb_slave_t ahbSlave (
.ahb_clk(clk),
.ahb_sel(ahb_sel_S1),
.ahb_addr(ahb_addr),
.ahb_write(ahb_write),
.ahb_trans(ahb_trans),
.ahb_size(ahb_size),
.ahb_burst(ahb_burst),
.ahb_w_data(ahb_w_data),
.ahb_master(ahb_master_id),
.ahb_mastlock(ahb_mastlock),
.ahb_prot(ahb_prot),
.ahb_ready_out(ahb_ready_S1),
.ahb_resp(ahb_resp_S1),
.ahb_r_data(ahb_r_data_S1),
May 2005
19
Product Version 5.4

Getting Started
.ahb_split(ahb_split_S1)
);
// Instance of the AHB Monitor TVM
ahb_standalone_monitor_t ahbMonitor (
.ahb_clk(clk),
.ahb_gnt({15b0,1b1}),
.ahb_lock({15b0,ahb_lock_M1}),
.ahb_req({15b0,ahb_req_M1}),
.ahb_sel({15b0,ahb_sel_S1}),
.ahb_mastlock(ahb_mastlock),
.ahb_split(ahb_split_S1)
);
.............
.............
.............
// Propagate the data bus width
defparam ahbBus.data_bus_width = data_bus_width,
ahbMaster.data_bus_width = data_bus_width,
ahbSlave.data_bus_width = data_bus_width,
ahbMonitor.data_bus_width = data_bus_width;
//
// assert Reset for 10 clocks
//
initial begin
clk = 0;
resetn = 0;
repeat (10) @(posedge clk);
May 2005
20
Product Version 5.4

Getting Started
resetn = 1;
end // initial begin
//
// a 50% duty cycle clock with period 20
//
always begin
#10;
clk = ~clk;
end
endmodule.
Master Verilog Wrapper

The Verilog wrapper for the master transactor is as follows (excerpted):
timescale 1 ns / 100 ps
//Verilog Wrapper of the Master transactor that is implemented in SystemC.
module ahb_master_t (ahb_clk,
ahb_resetn,
ahb_gnt,
ahb_lock,
ahb_req,
ahb_resp,
ahb_ready,
ahb_r_data,
ahb_w_data,
ahb_prot,
ahb_burst,
ahb_size,
ahb_write,
ahb_trans,
ahb_addr )
ifdef NCSC
// Note that the foreign attribute string value must be "SystemC".
(* integer foreign
= "SystemC"; *)
endif
;
// Note that port names must match exactly port names as they appear in
May 2005
21
Product Version 5.4

Getting Started
//
//
//
sc_module class in SystemC; they must also match in order, mode and type.
PARAMETERS
parameter
big_endian
= 1,
data_bus_width = 32,
addr_hold = 1;
// Ports
input
ahb_clk;
input
ahb_resetn;
input
ahb_gnt;
output
ahb_lock;
output
ahb_req;
input [1:0]
ahb_resp;
input
ahb_ready;
input [data_bus_width-1:0] ahb_r_data;
output [data_bus_width-1:0] ahb_w_data;
output [3:0] ahb_prot;
output [2:0] ahb_burst;
output [2:0] ahb_size;
output
ahb_write;
output [1:0] ahb_trans;
output [31:0] ahb_addr;
ifdef SCHDL
Dynamic Parameters
reg big_endian_dp;
reg
reg
reg
reg
reg
reg
reg
reg
reg
[31:0] ahb_addr;
[1:0] ahb_trans;
ahb_write;
[2:0] ahb_size;
[2:0] ahb_burst;
[3:0] ahb_prot;
[data_bus_width-1:0] ahb_w_data;
ahb_req;
ahb_lock;
initial begin
ahb_addr = 32hFEFFE000;
ahb_trans = 0;
ahb_write = 0;
ahb_size = 0;
May 2005
22
Product Version 5.4

Getting Started
ahb_burst = 0;
ahb_prot = 0;
ahb_w_data = 0;
ahb_req = 0;
ahb_lock = 0;
//Initialize dynamic parameters.
big_endian_dp = big_endian;
end
endif // ifdef SCHDL
endmodule
Slave Verilog Wrapper

The Verilog wrapper for the slave is as follows:
timescale 1ns / 100 ps
//Verilog Wrapper of the Slave transactor that is implemented in SystemC.
module ahb_slave_t (ahb_clk, ahb_resetn, ahb_ready, ahb_sel, ahb_addr, ahb_write,
ahb_trans, ahb_size, ahb_burst, ahb_w_data, ahb_master, ahb_mastlock, ahb_prot,
ahb_ready_out, ahb_resp, ahb_r_data, ahb_split)
ifdef NCSC
(* integer foreign = "SystemC"; *)
endif
;
// PARAMETERS
parameter big_endian
= 1;
parameter data_bus_width
= 32;
parameter split_capable
= 1;
parameter reset_response_after_use = 1;
// Ports
input
input
input
input
input[31:0]
input
input[1:0]
input[2:0]
input[2:0]
input[data_bus_width-1:0]
May 2005
ahb_clk;
ahb_resetn;
ahb_ready;
ahb_sel;
ahb_addr;
ahb_write;
ahb_trans;
ahb_size;
ahb_burst;
ahb_w_data;
23
Product Version 5.4

Getting Started
input[3:0]
input
input[3:0]
output
output[1:0]
output[data_bus_width-1:0]
output[15:0]
ifdef SCHDL
//Dynamic Parameters
reg
reg
reg
reg [9:0]
reg
reg
reg [1:0]
reg [data_bus_width-1:0]
reg [15:0]
ahb_master;
ahb_mastlock;
ahb_prot;
ahb_ready_out;
ahb_resp;
ahb_r_data;
ahb_split;
split_capable_dp;
enable_memory_dp;
big_endian_dp;
data_bus_width_dp;
reset_response_after_use_dp;
ahb_ready_out;
ahb_resp;
ahb_r_data;
ahb_split;
initial begin
ahb_r_data = 0;
ahb_ready_out = 0;
ahb_resp = 0;
ahb_split = 0;
split_capable_dp
big_endian_dp
enable_memory_dp
data_bus_width_dp
reset_response_after_use_dp
end
endmodule
=
=
=
=
=
split_capable;
big_endian;
enable_memory;
data_bus_width;
reset_response_after_use;
Monitor Verilog Wrapper

Verilog wrapper for monitor is as follows:
timescale 1 ns / 100 ps
//Verilog Wrapper of the Monitor transactor that is implemented in SystemC.
May 2005
24
Product Version 5.4

Getting Started
module ahb_standalone_monitor_t(
ahb_clk,
ahb_resetn,
ahb_gnt,
ahb_lock,
ahb_req,
ahb_resp,
ahb_ready,
ahb_r_data,
ahb_w_data,
ahb_prot,
ahb_burst,
ahb_size,
ahb_write,
ahb_trans,
ahb_addr,
ahb_sel,
ahb_master,
ahb_mastlock,
ahb_split
)
ifdef NCSC
// Note that the foreign attribute string value must be "SystemC".
(* integer foreign = "SystemC"; *)
endif
;
// Note that port names must match exactly port names as they appear in
// sc_module class in SystemC; they must also match in order, mode and type.
// PARAMETERS DEFAULT VALUES
// width of the data bus
parameter data_bus_width
= 128;
input
input
input
input
input
input
input
input
May 2005
[15:0]
[15:0]
[15:0]
[1:0]
ahb_clk;
ahb_resetn;
ahb_gnt;
ahb_lock;
ahb_req;
ahb_resp;
ahb_ready;
ahb_r_data;
25
Product Version 5.4

Getting Started
input
input
input
input
input
input
input
input
input
input
input
[3:0]
[2:0]
[2:0]
[1:0]
[31:0]
[15:0]
[3:0]
[15:0]
ahb_w_data;
ahb_prot;
ahb_burst;
ahb_size;
ahb_write;
ahb_trans;
ahb_addr;
ahb_sel;
ahb_master;
ahb_mastlock;
ahb_split;
ifdef SCHDL
// connect this TVM to Testbuilder
initial begin
end // initial begin
endmodule
VHDL System
At the top level, there are five inter-connected components:
1. MasterahbMaster (or Host DUV)
2. SlaveahbSlave (or Device DUV)
3. MonitorahbMonitor
4. ahbBusahbBus
5. topTestbenchtopTest
The monitor component can exist in a standalone mode.
The top-level VHDL code, instantiating the three transactors and the SystemC testbench that
drives the transactors, is shown below. Note that the monitor is configured in the SystemC
stimulus and is not standalone.
library ieee;
use ieee.numeric_std.all;
use ieee.std_logic_1164.all;
entity top is
May 2005
26
Product Version 5.4

Getting Started
generic (bus_width : integer );
end top;
library ieee;
use ieee.numeric_std.all;
use ieee.std_logic_1164.all;
architecture a1 of top is
component ahb_master_t
generic
( data_bus_width
: integer := 32;
big_endian
: integer := 1;
addr_hold
: integer := 0);
port
( ahb_clk
: in std_ulogic;
ahb_resetn : in std_ulogic;
ahb_gnt
: in std_ulogic;
ahb_lock
: out std_ulogic;
ahb_req
: out std_ulogic;
ahb_resp
: in std_ulogic_vector(1 downto 0);
ahb_ready
: in std_ulogic;
ahb_r_data : in std_ulogic_vector((data_bus_width -1) downto 0);
ahb_w_data : out std_ulogic_vector((data_bus_width -1) downto 0);
ahb_prot
: out std_ulogic_vector(3 downto 0);
ahb_burst : out std_ulogic_vector(2 downto 0);
ahb_size
ahb_write : out std_ulogic;
ahb_trans : out std_ulogic_vector(1 downto 0);
ahb_addr
: out std_ulogic_vector(31 downto 0));
end component;
component ahb_slave_t
generic
( big_endian
: integer
data_bus_width
: integer
enable_memory
: integer
split_capable
: integer
port
(
ahb_clk
: in std_ulogic;
May 2005
:=
:=
:=
:=
1;
32;
1;
1);
27
Product Version 5.4

Getting Started
ahb_resetn
: in std_ulogic;
ahb_ready
: in std_ulogic;
ahb_sel
: in std_ulogic;
ahb_addr
ahb_write
: in std_ulogic;
ahb_trans
ahb_size
ahb_burst
ahb_w_data
: in std_ulogic_vector((data_bus_width -1) downto 0);
ahb_master
ahb_mastlock : in std_ulogic;
ahb_prot
ahb_ready_out
: out std_ulogic;
ahb_resp
ahb_r_data
: out std_ulogic_vector((data_bus_width -1) downto 0);
ahb_split
: out std_ulogic_vector(15 downto 0)
);
end component;
......
......
ahbMaster : ahb_master_t
generic map (data_bus_width => bus_width)
port map(
ahb_clk
=> clk,
ahb_resetn
=> resetn,
ahb_gnt
=> mon_gnt(0),
ahb_lock
=> ahbLock_1,
ahb_req
=> ahbReq_1,
ahb_resp
=> ahbResp,
ahb_ready
=> ahbReady,
ahb_r_data
=> ahbRData,
ahb_w_data
=> ahbWData_1,
ahb_prot
=> ahbProt_1,
ahb_burst
=> ahbBurst_1,
ahb_size
=> ahbSize_1,
ahb_write
=> ahbWrite_1,
ahb_trans
=> ahbTrans_1,
ahb_addr
=> ahbAddr_1 );
May 2005
28
Product Version 5.4

Getting Started
ahbSlave : ahb_slave_t
port map(
ahb_sel
=> ahbSel1,
ahb_addr
=> ahbAddr,
ahb_ready
=> ahbReady,
ahb_write
=> ahbWrite,
ahb_trans
=> ahbTrans,
ahb_size
=> ahbSize,
ahb_burst
=> ahbBurst,
ahb_w_data
=> ahbWData,
ahb_resetn => resetn,
ahb_clk
=> clk,
ahb_master => ahbMasterID,
ahb_mastlock => ahbMastLock,
ahb_prot
=> ahbProt,
ahb_ready_out => ahbReady_S1,
ahb_resp
=> ahbResp_S1,
ahb_r_data
=> ahbRData_S1,
ahb_split
=> ahbSplit_S1);
ahbMonitor : ahb_standalone_monitor_t
port map(
ahb_clk
=> clk,
ahb_resetn
=> resetn,
ahb_gnt
=> mon_gnt,
ahb_lock
=> mon_lock,
ahb_req
=> mon_req,
ahb_resp
=> ahbResp,
ahb_ready
=> ahbReady,
ahb_r_data
=> ahbRData,
ahb_w_data
=> ahbWData,
ahb_prot
=> ahbProt,
ahb_burst
=> ahbBurst,
ahb_size
=> ahbSize,
ahb_write
=> ahbWrite,
ahb_trans
=> ahbTrans,
ahb_addr
=> ahbAddr,
ahb_sel
=> mon_sel,
May 2005
29
Product Version 5.4

Getting Started
ahb_master
=>
ahb_mastlock =>
ahb_split
=>
ahbMasterID,
ahbMastLock,
ahbSplit_S1 );
.......
.......
topTest: topTestbench;
end a1;
Note: The shells for the transactors are not shown here. Please refer to the following
directory for the definitions of these shells.
your_amba_install_dir/vhdl
The definitions follow the shell construction described in Verilog System on page 16.
May 2005
30
Product Version 5.4
3
Introduction to the AHB Transactors
Family
The Cadence AMBA SystemC Transactors support the AHB bus protocols. The AMBA
Master Transactors, Slave Transactors, and Monitor Transactors constitute a complete AMBA
AHB verification environment.
This chapter contains the following topics:
Introduction on page 31
Verification of AHB Peripherals on page 32
Transactor Interfaces on page 40
Stimulus Generator on page 42
Device Emulator on page 42
Introduction
An AHB Master Transactor is used to emulate an AHB Master bus interface, which initiates
transactions on the bus, whereas the AHB Slave Transactors respond to those transactions.
Some of the supported features of the Cadence AHB include:
A 32-bit address width
32-bit, 64-bit, or 128-bit data width
Big or little endian bit ordering scheme
All transfer types and sizes (up to the data bus width)
All burst types
Locked transactions and sequences of transactions
May 2005
31
Product Version 5.4

Introduction to the AHB Transactors Family
Automatic bus request and bus lock assertion and release
Automatic burst rebuild after a retry or a split
Automatic burst early termination and continuation when the master looses the bus and
owns it back again later
Supports multi-master configurations, master hand-over operations
Recording of overlapping bursts, address phases, and data phases in the Simvision
database
The AHB Monitor Transactor is responsible for compliance checking, as well as transaction
recording for transfers on the AHB bus. See Compliance Checks on page 152 for a list of
compliance checks Cadence offers.
The AHB Master, Slave, and Monitor Transactors handle all the AMBA-AHB interface
protocol, independently from the design, the test sequence, or coverage goals, thus making
the Transactors reusable for any AMBA bus design configuration.
Verification of AHB Peripherals

This section describes examples of configurations supported by the AMBA Transactors.
Multi-Master/Slave as well as Single-Master/Slave configurations are supported.
The configurations of the AHB bus that are included are:
Single-Master Single-Slave AMBA AHB bus configuration shown in Figure 3-1 on

page 33
Single-Master Multi-Slave AMBA AHB bus configuration shown in Figure 3-2 on page 34
Multi-Master Single-Slave AMBA AHB bus configuration shown in Figure 3-2 on page 34
Multi-Master Multi-Slave AMBA AHB bus configuration shown in Figure 3-4 on page 36
The illustrations show all of the Transactor connections

In any of the illustrations, any block labeled AHB Master + FIFO + Stimulus Generator or
AHB Slave + Device Emulator can also be a DUV (Design Under Verification).
The Stimulus Generator submits transactions to the Master transactor, and the Device
Emulator indicates what response the Slave transactor should give to the transaction on the
AHB bus. These components are not part of the Transactors and are user specific.
May 2005
32
Product Version 5.4

Single-Master Single-Slave
The Single-Master Single-Slave configuration, shown in Figure 3-1 on page 33, does not
require any arbiter or multiplexer to manage the bus (provided that the Grant and Sel
signals are each tied to the correct values). Any green block around the AHB Master or the
AHB Slave can be replaced by a DUV.
Figure 3-1 Single-Master Single-Slave AMBA AHB Bus configuration
May 2005
33
Product Version 5.4

Single-Master Multi-Slave
The Single-Master Multi-Slave configuration, shown in Figure 3-2 on page 34, only requires
an address decoder to select the correct slave addressed by the Master and a multiplexer to
drive the correct Slave signals back to the Master. Any of these blocks around Master or Slave
can be replaced by a DUV. The AMBA Decoder and Multiplexer managing the bus can also
be DUVs.
Figure 3-2 Single-Master Multi-Slave AMBA AHB Bus Configuration
May 2005
34
Product Version 5.4

Multi-Master Single-Slave
The Multi-Master Single-Slave configuration, shown in Figure 3-2 on page 34, needs an
arbiter to grant the bus to only one Master at a time, and a multiplexer to drive the signals of
the correct Master to the Slave. Here again, any of the block around the Master or Slave can
be replaced by a DUV. Arbiter or Multiplexer blocks can be DUVs as well.
Figure 3-3 Multi-Master Single-Slave AMBA AHB Bus Configuration
May 2005
35
Product Version 5.4

Multi-Master Multi-Slave
The Multi-Master Multi-Slave configuration, shown in Figure 3-4 on page 36, represents the
most general case of an AMBA Bus, with all its components. Once again, any of these
components can be a DUV, as detailed before in all the specific configurations.
Figure 3-4 Multi-Master Multi-Slave AMBA AHB Bus Configuration
May 2005
36
Product Version 5.4

Verification Process
This chapter gives an overview of the different configurations that can be used during a
verification process. The verification of a single-master/single-slave AHB configuration and a
multi-master/multi-slave AHB configuration will be covered. Figure 3-5 on page 37 lists the
verification process flow.
Figure 3-5 Verification Process Flow
Create a top level HDL testbench instantiating
the Transactor modules and the DUV.
Create a C++/SystemC testbench.

In this testbench do the following:
1. Instantiate the necessary AHB Master, Slave and Monitor transactors.
2. Bind the Transactors Configuration Interfaces to the testbench through sc_ports.
3. Select the appropriate configurations for each Transactor (if different from default
options).
4. Bind the Stimulus Generator port to the Master and the Device Emulator port to the Slave.
Create Stimulus Generator and Device Emulator files.
Compile and link the testbench

(Stimulus Generator, Transactors, DUV, and so on).
Run the simulation using Testbuilder SC.
Debug the DUV using Signalscan, Transaction

Explorer, and the log file generated by the
simulation until all the tests go as expected.
Refine the Test suite until the

functional coverage goals are met.
May 2005
37
Product Version 5.4

Single-master Verification
When verifying a single-master AHB configuration, the test writer must instantiate one or
several AHB Slave Transactors, within the HDL netlist. A single AHB Monitor Transactor can
be connected to all the Master and Slave Transactors on the bus to cover the whole AHB bus
activity.
In the example files top_with_monitor.v for Verilog or top_with_monitor.vhd for
VHDL, located in the following directory.
install_dir/tools.<platform>/tvmsc/examples run_ahb_master_slave
Note: There is only one instance of a AHB Slave Transactor in the directory.
In the example, three Transactors are instantiated, a Master, a Slave, and a Monitor. When
verifying a single-master configuration, substitute the Master Transactor with the actual DUV.
Single-slave Verification
When verifying a single-slave AHB configuration, the test writer must instantiate one or
several AHB Master Transactors, within the HDL netlist. A single AHB Monitor Transactor can
activity.
In the example files top_with_monitor.v for Verilog or top_with_monitor.vhd for
VHDL, located in the following directory.
install_dir/tools.<platform>/tvmsc/examples run_ahb_master_slave
Note: There is only one instance of a AHB Slave Transactor in the directory.
In the example three Transactors are instantiated, a Master, a Slave, and a Monitor. When
verifying a single-slave configuration, substitute the Slave Transactor with the actual DUV.
Multi-Master DUV Verification

When verifying a multi-master AHB configuration, the test writer must instantiate one or
several AHB Slave Transactors within the HDL netlist. A single AHB Monitor Transactor can
activity.
In top_with_monitor.v for Verilog or top_with_monitor.vhd for VHDL, located in the
following directory:
install_dir/tools.<platform>/tvmsc/amba20/examples/run_ahb_multi_masters_slaves
May 2005
38
Product Version 5.4

There are two instances of AHB Master Transactors, two instances of AHB Slave Transactors,
and one instance of a AHB Monitor Transactor in the directory. When verifying a multi-master
configuration, substitute the Master Transactors with DUVs.
Multi-slave DUV Verification

When verifying a multi-slave AHB configuration, the test writer must instantiate one or several
AHB Master Transactors within the HDL netlist. A single AHB Monitor Transactor can be
connected to all the Master and Slave Transactors on the bus to cover the whole AHB bus
activity.
In top_with_monitor.v for Verilog or top_with_monitor.vhd for VHDL, located in the
following directory:
install_dir/tools.<platform>/tvmsc/amba20/examples/run_ahb_multi_masters_slaves
There are two instances of AHB Master Transactors, two instances of AHB Slave Transactors,
and one instance of AHB Monitor Transactor in the directory. When verifying a multi-slave
configuration, substitute the Slave Transactors with DUVs.
Additional information on the verification configurations

Information about creating your testbench configuration, instantiating the transactors in the
design, and connecting the transactors to the testbench is located in Chapter 2, Getting
Started. Information about the writing stimulus tests is given in Stimulus Generator on
page 42.
In the multi-master verification configuration, it is not necessary to substitute all the Master
Transactors with DUVs. For example, your goal can be to test DUVs as masters in an
environment where the bus is shared with other masters. In this case only some of the Master
Transactors can be substituted with DUVs and the others left as is. All the Master Transactors
that are left on the bus will then have to be driven/configured by the testbench/stimulus.
In the multi-slave verification configuration, it is not necessary to substitute all the Slave
Transactors with DUVs. For example, your goal can be to test DUVs as slaves in an
environment where the bus is shared with other slaves. In this case, only some of the Slave
Transactors can be substituted with DUVs, and the others left as is. All the Slave Transactors
that are left on the bus will then have to be configured by the testbench/stimulus.
May 2005
39
Product Version 5.4

Transactor Interfaces
Transactor interfaces provide mechanisms for you to interact with Transactor objects created
during simulation. They provide for initial setup (mode of operation), allow you to generate
protocol operations (transaction-level interface) and abstract the operation being executed
into a graphical representation (transaction recording). They also allow you to modify the
setup during simulation (configuration interface) and allow for status checking (configuration
interface).
Transactor Configuration Interface

The Configuration Interface is a C++ interface providing a mechanism to configure
component operations. Some examples of the operations that can be configured for a
component are:
Error checking (for the Monitor)
Endianess (for the Master and Slave)
The general usage of the configuration interface is to set a mode of operation. For a full
description, refer toMaster Configuration Interface on page 47, AHB Transactor Reference
Information on page 43 and AHB Monitor Configuration Interface on page 129.
Transactor Transaction-Level Interface

Master and Slave transactors connect to higher level components (such as a stimulus
generator) through a Transaction-Level interface. This interface doesnt exist for the Monitor
transactor. These interfaces are described on Master Transaction-level Interface on page 49
for the Master transactor and on for the Slave transactor.
Transactor Pin-Level Interface

All Transactors provide a pin-level interface. This HDL interface is used to establish
connectivity between the C++ layer of a Transactor and the DUV interface. Each Transactor
has an HDL wrapper that is used to instantiate the Transactor into the HDL netlist and connect
it to the DUV instance using HDL wires. See examples in AHB Master Pin-Level Interface
on page 75, AHB Slave Port Interface on page 120 and AHB Monitor Pin-Level Interface
on page 138 for pin-level interface descriptions.
May 2005
40
Product Version 5.4

Transactor Transaction View

Every Transactor records transactions using TestBuilder's transaction recording facilities.
Transactions are recorded to an SST2 waveform database and can subsequently be viewed
as transaction boxes with duration in the Signalscan Waveform Viewer. The transaction view
is a pictorial representation of the operations that can be executed on the interface. Refer to
AHB Master Transaction Recording on page 77, AHB Slave Transaction Recording on
page 123 and AHB Monitor Transaction Recording on page 143 for detailed descriptions of
the recorded transactions.
Transaction Searches
Searches are used on a simulation database to quickly determine the current functional
coverage. When a simulation is executed, the transactions are automatically stored into the
simulation database by the Transactor. After successful completion of a simulation, you can
create searches to determine the functional coverage of the particular simulation run using
the Transaction Explorer (TxE) in Signalscan.
The transactions that are recorded contain attributes. Searches may be performed using the
attribute names. Their values can be checked, temporal relationships of transactions
(operations) can be analyzed, and operation types can be counted.
The data available for a search is dependent upon the data that the Transactor is recording
to the simulation database. Searches might include for example:
Read cycle counts
Write cycle counts
Data transfer sizes
Burst Type
Response Type
Addresses accessed
Note: See the Transaction Explorer User Guide for infomation on creating TxE searches.
Also see the README file located at install_dir/tools.<platform>/txe/examples
for examples of TxE searches.
May 2005
41
Product Version 5.4

Stimulus Generator
A stimulus generator is a C++ object that implements transaction sequences according to a
predefined test plan. Stimulus generators use the Transactors transaction-level interface to
inject test sequences onto the DUV interface as defined in Transactor Transaction-Level
Interface on page 40.
Refer to Chapter 2, Getting Started, for more information about how to connect your
stimulus generator with the transactor(s) instantiated in the design under verification.
Device Emulator
A Device Emulator is a C++ object that implements response sequences according to a
predefined model or test plan. It can behave as a basic memory (pre configured with data and
response delays), or deliver more elaborate responses following a complex model reacting to
the transactions occurring on the AHB bus.
May 2005
42
Product Version 5.4
4
AHB Transactor Reference Information
This chapter provides the reference information about each of the AMBA Transactors. The
reference information includes:
Transaction-level description (classes and public methods).
Pin-Level Interface description
Visual Transaction Recording description
The following Transactors are referenced in this chapter:
AHB Master Transactor Class on page 45
AHB Slave Transactor on page 89
AHB Monitor Transactor ( ahb_monitor_t ) on page 128
An illustration of an AHB design, consisting of several masters, several slaves, and a monitor,
is provided in Figure 4-1 on page 44. This example is used as a reference example
throughout this document.
May 2005
43
Product Version 5.4

Figure 4-1 Example of AHB Design
May 2005
44
Product Version 5.4

AHB Master Transactor Class

The master transactor class: ahb_master_t is used to emulate an AHB Master bus
interface. It is used to test designs based on the AHB interface.
See Chapter 3, Introduction to the AHB Transactors Family, for a summary of the AMBA
protocol features that the AHB Master transactor supports.
AHB Master Transactor Overall Structure

The function of an AHB Master transactor is captured in the ahb_master_t SystemC
module (see Figure 4-2 on page 46), which offers three SystemC interfaces:
1. An AHB Master transactor connecting to a device under verification through a
signal-level interface, as described in AHB Master Pin-Level Interface on page 75.
2. An AHB Master transactor connecting to a higher level component (such as a stimulus
generator) through a transaction-level interface. This interface is based on call backs of
methods in an a SystemC sc_interface object and is called a Pull interface. This
interface is described in Master Transaction-level Interface on page 49. A layer can be
added on top of a Pull interface making it a Push interface. Chapter C, Glossary gives
a general definition of the Pull and Push interfaces.
The pull interface is described in Pull Interface on page 50.
The push interface is described in Push Interface on page 52.
3. An AHB Master configured dynamically through a configuration interface, as described
in Master Configuration Interface on page 47.
Figure 4-2 on page 46, shows a class diagram of the master transactor and its three
interfaces.
May 2005
45
Product Version 5.4

Figure 4-2 AHB Master Transactor Structure
Connecting a Master Transactor to a Stimulus Generator

A master transactor is connected to a stimulus generator through a SystemC sc_port that
declares a virtual interface called uvm_pull_if_t (see Master Transaction-level
Interface on page 49).
The sc_port can be seen as the transaction-level port used by a master transactor to pull a
new transaction from the stimulus generator when it is ready to accept one.
When the Pull interface is used alone the stimulus generator is implemented as methods
called by the master transactor. The Push interface is layered on top of the Pull interface.
A FIFO queue is placed between the stimulus generator and the master transactors callback
methods. Figure 4-3 on page 57, illustrates such configuration.
May 2005
46
Product Version 5.4

Figure 4-3 Testbench Configuration
Master Configuration Interface

The AHB Master can be congured through a virtual interface called uvm_control_if_t
that is not protocol-specic. This is implemented by a variety of transactors (AHB, PCI, USB,
and so on). The denition of this class is shown in the following code listing.
Example Class Definition
The following code listing shows the class definition.
template <typename CONTROL_T>
class uvm_control_if_t
: virtual public sc_interface {
public:
uvm_control_if_t() : debug(0), enable(1) {}
virtual bool send_control(const CONTROL_T &) = 0;//protocol specific configuration
virtual void enable_on() {enable = 1;} //enables the transactor (default)
virtual void enable_off() {enable = 0;} //disable the transactor
virtual void debug_on() { debug = 1;}//displays the debug information
virtual void debug_off() { debug = 0;}//hides the the debug info (default)
virtual bool get_debug() { return debug;}
virtual bool get_enable() { return enable;}
protected:
bool debug;
bool enable;
};
The CONTROL_T template structure of this class is protocol-specific. A common structure

called ahb_configuration_t is used to configure all the AHB Transactors. Table 4-1 on
page 48, shows the attributes of this structure used to configure an AHB Master Transactor.
May 2005
47
Product Version 5.4

Table 4-1 Attributes of the ahb_configuration_t Structure Relevant for an AHB
Master Transactor
Attributes
Description
bool big_endian
Endianess mode of the Master

transactor:
false- Little Endian data bus
(default)
true- Big Endian data bus
bool addr_hold
if addr_hold is true, the address bus

(HADDR) is held to the current value
during IDLE cycles, else the value
0xffffffff is driven on the address
bus.
Default value : true
bool info_msg
if info_msg is set to true,

information messages are displayed
and logged in the tb_log file (default
is false).
bool debug_fsm
if debug_fsm is set to true, the

state of the master transactor state
machine are recorded in Simvision
(default is false).
bool transaction_record
if transaction_record is set to
true, transactions are recorded in
Simvision.
Note: The data bus width is a compilation time constant dened in the ahb.h header le, as
shown in the following lines:
//Data Bus width value defined in the ahb.h header file
const int DATA_BUS_WIDTH = 32;//Default value = 32
As presented in AHB Master Pin-Level Interface on page 75, the data bus pins,
ahb_w_data and ahb_r_data are declared respectively of type
sc_in<sc_bv<DATA_BUS_WIDTH> > and sc_out<sc_bv<DATA_BUS_WIDTH> >.
May 2005
48
Product Version 5.4

The consequence of this limitation is that, a specic library of AHB transactors must be used
for each possible data bus width (32, 64 or128 bits).
Example of Using the Configuration Interface in a Stimulus Generator
If you want to configure a transactor with some non-default values, the stimulus generator
must contain a sc_port<ahb_configuration_t> and declare a structure of type
ahb_configuration_t as shown in the following example.
Example
public:
sc_port<ahb_configuration_t> master_control_port;//Master configuration port
void my_test();
SC_CTOR(push_stimulus_generator_t)
: master_control_port(master_control_port),..,..
{
SC_THREAD(my_test);
}
};
void push_stimulus_generator_t::my_test() {
//Configure the transactors before starting the stimulus.
transactors_config.transaction_record = false;
transactors_config.big_endian = true;
master_control_port->send_control(transactors_config);
/...
}
Master Transaction-level Interface

The main features of the master transaction-level interface are:
Transactions are represented as objects of a class called ahb_arg_handle_t. These

objects are created by a stimulus generator and contain all the conguration information
May 2005
49
Product Version 5.4

that a stimulus generator can set before submitting a transaction to the master. In this
document, a transaction is dened as any kind of burst, even a single transfer. The
master transactor is responsible for queuing and pipelining the submitted transactions.
A virtual pull method is used by the master transactor to get a transaction object of
class ahb_arg_handle_t each time it is ready to accept a new one. If the pull
method is directly implemented by the stimulus generator, it must not contain any
blocking call (for example, any wait for any event) and therefore must execute in 0 unit
simulation time.
If a stimulus generator uses a push interface, the ahb_arg_handle_t objects offer the
ability to wait until a specic event happens during the transaction (retry, split, lose of
grant, reset, completion). This offers some reactivity to events that may happen during
the transaction and allows you to keep track of the status and the information related to
a previously submitted transaction.
Pull Interface
As specified in the Cadence UVM (Unified Verification Methodology), a Pull interface consists
of the following five basic parts:
1. A SystemC interface definition, as illustrated in the following code listing:
template <typename T> class uvm_pull_if_t : virtual public sc_interface {
public:
virtual T pull() = 0;
};
Note: The above code shows T being returned by value. It is expected that the template
argument will be a shared pointer to a transaction object.
UVM transaction interface classes are template classes. The pull method returns an
object (of type T in the above code). This class type of the returned object will change for
a different type of transactor. For AHB Master transactors, the template type is
ahb_arg_handle_t, which is dened as:
typedef ahb_arg_handle_t scv_shared_ptr<ahb_arg_t>;
A shared pointer can be used exactly like a pointer (by using the -> operator to access
the transaction attributes and methods) but is safer because it frees the test writer from
the burden of memory management, especially when the transaction is used by several
threads (see the scv_shared_ptr class description in the TestBuilder-SystemC
Reference manual).
2. The declaration of a SystemC port in the transactor as follows:
class ahb_master_t :
May 2005
50
Product Version 5.4

public uvm_control_if<ahb_configuration_t>, public ahb_master_port_if {
public:
sc_port<uvm_pull_if_t<ahb_arg_handle_t>,1> puller;
}
The port connects an AHB master transactor to a stimulus generator through a

transaction-level interface.The port has a template type that is the name of the interface
class. In this case the template type is: uvm_pull_if_t. That type in turn has its own
template parameter which specifies the template class handled by this generator, which
is ahb_arg_handle_t. The second argument in the ports template is the number of
objects attached to the port. A value of 0 means any number of objects.
3. The definition of a stimulus generator class which inherits the SystemC interface
definition (as defined in item 1) This class contains the callback function (pull()),
which is a virtual function in the interface class.
class ahb_stimulus_generator_t : public uvm_pull_if_t<ahb_arg_handle_t>
{
public:
ahb_stimulus_generator_t() {}
~ahb_stimulus_generator_t() {}
virtual ahb_arg_handle_t pull();
};
4. The definition of the interface member function, where stimulus transactions are created
as follows:
ahb_ahb_arg_handle_t ahb_stimulus_generator_t::pull()
{
ahb_ahb_arg_handle_t arg_p = new ahb_arg_t;//create new transaction
arg_p->set_address(0x100);
/**....Configure the transaction using the methods defined in Transaction
Argument Class on page 54)...**/
return arg_p;
}
5. The declaration of the interface class, usually in the same module that declares (in other
words, instantiates) the transactor, as follows:
class top_testbench_t : public sc_module
{
public:
ahb_stimulus_generator_t stim_gen;
}
May 2005
51
Product Version 5.4

Push Interface
The Push interface includes a queue which decouples the thread of the caller (which is the
stimulus generator) from the transactor thread. This queue is placed in the function that the
transactor calls back. An implementation is shown in the following code listing.
template <typename T>
class uvm_push_pull_fifo_t
: public sc_prim_channel,
public uvm_push_if_t<T>,
public uvm_pull_if_t<T>
{
public:
virtual bool push(const T &arg) {
bool return_value = fifo.empty();
fifo.push(arg);
push_event.notify();
return return_value;
}
virtual void push_wait(const T &arg) {
fifo.push(arg);
push_event.notify();
wait(pull_event);
}
virtual T pull() {
//T should be a scv_shared_ptr or scv_smart_ptr.
//If the fifo queue is empty, return a dummy transaction which is null by default
if (fifo.empty()) {
T dummy_transaction_h;//null scv_shared_ptr
return dummy_transaction_h;
}
else
{
T arg = fifo.front();
fifo.pop();
pull_event.notify();
return arg;
}
}
May 2005
52
Product Version 5.4

private:
sc_event push_event, pull_event;
};
If the transaction queue is empty, the pull function returns a null shared pointer to the master
transactor. If the queue is not empty, then the last transaction put into the queue is popped
and sent to the master transactor.
The following listing shows what the Push interface looks like to the user of the transactor:
//non-blocking push, returns after 0-simulation time
void push(ahb_arg_handle_t &arg);
//blocking push, returns when a transaction is pulled by the transactor
void push_wait(ahb_arg_handle_t &arg);
Since these functions are members of a class that inherits from a SystemC interface class,
they are bound to a port and are called through the port pointer, which is as follows:
//UVM Push Interface Declaration
template <typename TX_T>
class uvm_push_if_t : virtual public sc_interface {
public:
virtual void push(ahb_arg_handle_t &arg)= 0;
virtual void push_wait(ahb_arg_handle_t &arg)= 0;
};
//Example of Push stimulus generator
public: sc_port<uvm_push_if_t<ahb_arg_handle_t> > master_tx_port;
SC_CTOR(push_stimulus_generator_t) {
SC_THREAD(my_test);
}
void my_test();
};
void push_stimulus_generator_t::my_test() {
ahb_arg_handle_t tx1_h = new ahb_arg_t;
tx1_h->set_address(0x100);
/**..configure a transaction as specified in Transaction Argument Class on
page 54**/
master_port->push(tx_h);
May 2005
53
Product Version 5.4

/**..configure another transaction**/

master_port->push_wait(tx2_h);
}
Transaction Argument Class

The ahb_arg_handle_t class is the return type of the pull method defined in the
uvm_pull_if_t interface class. The stimulus generator is responsible for creating and
configuring transactions before submitting them to the master transactor in the follwing ways:
By way of the return value of the pull method if the stimulus generator implements a
pull interface (Pull Interface on page 50).
By way of the argument value of the push method if the stimulus generator uses a push
interface (Push Interface on page 52).
ahb_arg_handle_t is a shared pointer on a ahb_arg_t object, whose attributes and

methods are defined in this section.
The way you create a new transaction and store it in a shared pointer handle is shown in the
following line:
ahb_arg_handle_t transaction_h = new ahb_arg_t;
Once the transaction is created, the associated transaction handle (transaction_h in the
example above) can be used to keep track of the transaction during its entire duration. for
example, from the moment it is queued in the master transactor until the completion of the
last transfer of the burst or the burst cancellation due to a bus reset or an ERROR response.
See Creating and using transaction handles on page 75, for information on the properties
of the transaction handles.
Table 4-2 on page 54, gives a short description of the most important transaction public
methods and attributes. Please, refer to Table 4-3 on page 57, and Table 4-4 on page 59, for
a detailed description and usage explanations of all the methods and attributes.
Table 4-2 Brief description of the ahb_arg_t public methods and attributes
Attributes and Methods
Brief Description
void wait_for_start_event()
Wait until the transaction

starts.
May 2005
54
Product Version 5.4

Brief Description
void wait_for_finish_event()
Wait until the transaction

finishes.
bool wait_for_retry_event()
Wait for a retry response.
bool
wait_for_loss_of_grant_event()
Wait for a loss of bus grant.
data_array
Data storage array.
expected_data_array
Expected data storage array.
beat_delay_array
BUSY cycles array.
check_mask_array
Check bit masks array
void set_address(sc_uint<32>
start_addr);
Transaction address
void
set_write_transaction(bool
flag)
Read/Write
void set_null_transaction(bool
null_arg = false)
Null Transaction.
void
Burst Type
set_burst_type(
sc_uint<3> burst)
void
Transfer size
set_transfer_size(sc_uint<3>
size)
void
Protection Mode
set_prot(
sc_uint<4> prot)
May 2005
55
Product Version 5.4

Brief Description
void
IDLE cycles inserted before

starting the transaction.
set_start_delay
(unsigned int num)
void
Transfer lock.
set_lock( bool )
void
Continue after an ERROR.
set_continue_after_error( bool
flag)
void set_burst_length()
number of beats in an INCR

burst.
void set_check_data(bool flag)
Automatic data checking.
set_check_masked_data(bool
flag)
Automatic data checking

with bit masks.
void set_num_Idle_after_retry
IDLE cycles before retrying.
(unsigned int )
void
set_hold_req_after_last_transf
er( bool flag = true)
Hold bus request after the

last transfer.
void
set_hold_lock_after_last_trans
fer( bool flag = true)
Hold bus lock after the last

transfer.
void release_req()
Low level action: release the

HREQ pin.
void release_lock()
Low level action: release the

HLOCK pin.
May 2005
56
Product Version 5.4

Brief Description
sc_uint
<DATA_BUS_WIDTH>
read_integer_data_array(..)
Read a data transfer value

from data_array (refer to
Table 4-4 on page 59,for
details on the parameters of
this method)
void
write_integer_data_array(..)
Write a data transfer value

(refer to Table 4-4 on
page 59,for details on the
parameters of this method)
void fill_burst(..)
Configure a burst transaction

(refer to Table 4-4 on
page 59,for details on the
parameters of this method)
void initialise()
initialize the transaction

object.
The attributes of the ahb_arg_t class

Table 4-3 on page 57, lists and describes all the arrays attributes of the ahb_arg_t class.
These arrays use the scv_sparse_array type described in the TestBuilder-SystemC User
and reference guide. This class allows access to any element within an array without
pre-defining the size of the array and allows setting a default value for all the elements.
Table 4-3 ahb_arg_t Sparse Arrays Public Attributes
Array
Description
scv_sparse_array
This array contains the data to be written into the slave

memory space. This array is also used to store the read data.
Each location is indexed by the byte address and holds a
byte of data.
< int, sc_uint<8> >

data_array
The default byte value is 0.
May 2005
57
Product Version 5.4

Array
Description
scv_sparse_array
This array contains the data to be checked by the master

transactor against the actual data read on the bus during a
Read transaction. This checking is done automatically if the
set_check_data() method has been called prior to
submitting the transaction.
< int, sc_uint<8> >

expected_data_array
Each location in the sparse array is sized to 8 bits and

indexed by the byte address exactly like the data_array.
The default byte value for this array is 0.
scv_sparse_array
< int, int >
beat_delay_array
This array contains a specified number of BUSY cycles to

insert before any SEQuential transfer in a burst. Each
location of this array is indexed with the transfer (or beat) to
assign a busy delay. The index starts with 1, which
corresponds to the first beat.
No BUSY cycles can be inserted before a NONSEQuential
transfer, therefore beatDelayArray[1] will be ignored. In
any other transfer in the burst, a specified number of BUSY
cycles can be inserted.
Example:
beat_delay_array[2] =1;
//1 BUSY cycle will be inserted before the 2nd Transfer
beat_delay_array[4]=3;
//3 BUSY cycles will be inserted before the 4th
transfer.
The default integer value stored in all locations is 0.
May 2005
58
Product Version 5.4

Array
Description
scv_sparse_array
This array contains a bit mask used to compare the expected

data with the actual data during a read transaction. Each
location of this array is indexed by a byte address and holds a
byte of data.
< int, sc_uint<8> >

check_mask_array
Each bit within a byte specifies if the corresponding bit of

data must be checked against the expected data.
1: Compare
0: Do not care.
The default byte value stored in all locations is 0xff (All the
bits are compared).
The ahb_arg_t Public Methods

Table 4-4 on page 59 describes the ahb_arg_t public methods.
Table 4-4 Table of ahb_arg_t Public Methods
Method
Description
void set_address(sc_uint<32>
start_addr);
Sets the start (byte) address of the burst or

the single transfer.
It is the responsability of the user to provide
an address that is aligned with the transfer
size (byte, half-word, word, 2-words).
An unaligned address will be automatically
masked internally in the master transactor
and correctly aligned. An internal Error
Exception will be thrown and inform the
user if such correction occurs.
A corresponding get_address()
method returns the start address
(sc_uint<32> type)
May 2005
59
Product Version 5.4

void set_write_transaction(bool
flag)
Sets the transaction direction: Write (flag =

true) or Read (flag = false).
The default value is true (Write)
set_burst_type(
This sets the burst type. Here are the valid

values for this argument:
sc_uint<3> burst)
0 - SINGLE
void
1 - INCR (Unspecified Length)

(the user must specify a value using
set_burst_length(int))
2 - WRAP4
3 -INCR4
4 - WRAP8
5 - INCR8
6 - WRAP16
7 - INCR16
Instead of using integer values, the
following predefined constants can be used
in the testbench:
AHB_BURST_SINGLE
AHB_BURST_INCR
AHB_BURST_WRAP4
AHB_BURST_INCR4
AHB_BURST_WRAP8
AHB_BURST_INCR8
AHB_BURST_WRAP16
AHB_BURST_INCR16
The default burst type is SINGLE ( 0 ).
A corresponding get_burst_type()
method returns the Burst type
(sc_uint<3> value).
May 2005
60
Product Version 5.4

void
set_transfer_size(sc_uint<3>
size)
Sets the transfer size for the burst. The valid

values for this argument:
0 - BYTE (8 bits)
1 - HALF-WORD (16 bits)
2 - WORD (32 bits)
3 - 2 WORDS (64 bits).
Instead of using integer values, the
following predefined constants can be used
in the testbench:
const
const
const
const
unsigned
unsigned
unsigned
unsigned
int
int
int
int
AHB_SIZE_BYTE = 0;
AHB_SIZE_HALF = 1;
AHB_SIZE_WORD = 2;
AHB_SIZE_2WORD = 3;
A corresponding get_transfer_size()
method returns the Burst type
(sc_uint<3> value)
void
set_prot(
sc_uint<4> prot)
void
set_start_delay
(unsigned int num)
Sets the value to drive on the HPROT pins of

the transactor for the duration of the burst.
The default value is 0.
A corresponding get_prot() method
returns the protection type (sc_uint<4>
value)
Sets a number of IDLE cycles to be
inserted before the NONSEQ transfer starts
(First transfer of the burst). The default
number is 0. More details are given about
this feature is detailed in Start Delay
Specifications on page 85.
a corresponding get_start_delay()
method returns the start delay value (int)
May 2005
61
Product Version 5.4

void
set_lock( bool )
Indicates to the transactor that the

corresponding transaction must be locked.
true = locked, false = not locked, default
value = false.
HLOCK will be automatically asserted and
released by the transactor.
The way HLOCK is asserted and released by
the master transactor are described in
Transfer Lock on page 85.
A corresponding get_lock() method
returns the Lock value (bool)
void
set_continue_after_error( bool
flag)
Sets a flag that tells the master transactor

whether to complete the current burst or to
terminate the burst when the Slave issues
an ERROR response.
0 - Terminate the burst and cancel the
following transfers default
1 - Complete the remaining transfers.
A corresponding
get_continue_after_error() method
returns the value of this boolean flag.
void set_burst_length()
Specifies burst length for INCR bursts (of

unspecified length) Valid values are any
values from 1 and higher.
This method should be used only when the
burst type is INCR (undetermined length).
If the set_burst_type method was used
with any other burst type of specified length
passed as an argument (for example,
INCR4 ), the length will be automatically
set.
A corresponding get_burst_length()
method returns the value of the burst
length.
May 2005
62
Product Version 5.4

void set_check_data(bool flag)
Sets a flag that when set to one (1) will

compare supplied data in
expectedDataArray against the actual
data read during a read transaction.
An internal scv error exceptions
(AHB_DATA_CHECK_EXCEPTION) will be
thrown during the transaction if data does
not match expectations stored in the
expectedDataArray.
The default state of this flag is false.
A corresponding get_check_data()
method returns the value of this flag (bool)
set_check_masked_data(bool
flag)
Sets a flag that when set to one (1) will

compare supplied data in
expectedDataArray against the actual
data read during a read transaction. During
the comparison, each byte of data will be
masked with a corresponding byte supplied
in the check_mask_array.
This masked comparison will be done
automatically in the transactor only if
set_check_data and
set_check_masked_data have been
called with a true flag argument.
An internal scv error exception
(AHB_DATA_CHECK_EXCEPTION) will be
thrown during the transaction if the masked
data does not match expectations stored in
the expectedDataArray.
The default state of this flag is false.
A corresponding get_masked_data()
method returns the value of this flag (bool)
May 2005
63
Product Version 5.4

void set_num_Idle_after_retry
(unsigned int )
Configures the number of IDLE cycles that

the master transactor will insert before
retransmitting a burst if a RETRY or a SPLIT
response is received.
By default, if a RETRY response is received,
the master will try to re-transmit the
remaining transfers just after inserting an
IDLE cycle.
If a value of n was set using this method,
the master transactor will insert n IDLE
cycles after the compulsory IDLE cycle.
The master transactor behavior after a
RETRY/SPLIT is specified in more details
in Retried bursts on page 88.
A corresponding
get_num_Idle_after_retry() method
returns the value of this number.
void set_null_transaction()
Indicates to the transactor that no Read or

Write transaction must be done, but that
some special signals must be set. For
example, this method is used when the
stimulus generator wants to explicitly
release HLOCK or HREQ after a locked
sequence ( see Example of a
Read-Modify-Write locked sequence on
page 86)
void
set_hold_req_after_last_transfe
r( bool flag = true)
If the flag is set to true, it tells the

transactor to hold the bus request (HREQ
pin) even after the last address phase of the
transaction has started.
By default, HREQ is released when the last
address phase of the burst starts.
A more precise description of the bus
request assertion and release conditions is
given in Bus Request on page 85.
May 2005
64
Product Version 5.4

void
set_hold_lock_after_last_transf
er( bool flag = true)
If the flag is set to true, it tells the

transactor to hold HLOCK even after the last
address phase of the locked transaction has
started.
By default, HLOCK is released when the last
address phase of the burst starts.
A more precise description of the HLOCK
assertion and release conditions is given in
Transfer Lock on page 85. A test case
which uses this method is given in Example
of a Read-Modify-Write locked sequence
on page 86
void release_req()
Low level action on the HREQ pin. This

method is useful if
set_null_transaction() has been
used. It tells the transactor to explicitely
release the bus request. A test case which
uses this method is given in Example of a
page 86
void release_lock()
Low level action on the HLOCK pin. This

method can be used if
set_null_transaction() has been
used. It tells the transactor to explicitely
release the bus lock. A test case which uses
this method is given in Example of a
page 86
May 2005
65
Product Version 5.4

sc_uint
<DATA_BUS_WIDTH>
read_integer_data_array(
sc_uint<32> address,
sc_uint<3> size,
bool bigEndian = false)
This method will read an integer value, that

corresponds to the bytes stored in the
data_array. DATA_BUS_WIDTH is an
integer constant that species the biggest
transfer size allowed on the bus (32 or 64).
The valid values for the size parameters
are the same as in the
set_transfer_size() method. Unless
specied otherwise, the endianness is
always little.
Example:
If the storage in data_array is:
dataArray[0x1000] = 0x11;
For read_integer_data_array:
(0x1000, AHB_SIZE_WORD) will return
0x44332211 (Little Endian order by
default).
read_integer_data_array
(0x1000, AHB_SIZE_HALF, true) will
return 0x1122 (Half-Word in Big Endian
order)
sc_uint
<DATA_BUS_WIDTH>
read_integer_expected_data_arra
y(
sc_uint<3> size,
The description of the

read_integer_data_array method
applies here.
The array read accessed by this method is
the expected_data_array.Unless
specied otherwise, the endianness is
always little.
bool bigEndian = false)
May 2005
66
Product Version 5.4

void write_integer_data_array(
sc_uint<3>
size ,
bool bigEndian = false,

sc_bv<DATA_BUS_WIDTH>
data_value = 0)
This method will store an integer data value

corresponding to a bus transfer into the
data_array. DATA_BUS_WIDTH is a
constant that species the biggest transfer
size allowed on the bus.
Transfer size, an address, and an endianess
mode are taken into account to set the byte
addresses where the data value is stored.
The valid values for the size argument are
the same as in the set_transfer_size
method
Example 1
write_integer_data_array
(0x1000, AHB_SIZE_WORD,false
0x11223344) will store as shown below:
/* Storage of a word
order */
dataArray[0x1000] =
dataArray[0x1001] =
dataArray[0x1002] =
dataArray[0x1003] =
in a Little Endian
0x44;
0x33;
0x22;
0x11;
Example 2
write_integer_data_array
(0x1002, AHB_SIZE_HALF,
true,0x1122) will store the value as
shown below:
/* Storage of a half-word in a Big
Endian order, at the address 0x1002 */
May 2005
67
Product Version 5.4

void
write_integer_expected_data_arr
ay(
The description of the

write_integer_data_array method
applies here.
The array accessed by this method is the

expected_data_array.
sc_uint<3>
size ,
bool big_endian = false,

data_value = 0)
unsigned int get_next_addr(

sc_uint<32> addr,
sc_uint<3> burst,
sc_uint<3> size)
Calculates and returns the address of the

next transfer, given a specified address,
burst type and a transfer size.
The address argument should be aligned
with the specified transfer size.
The valid values for the burst and size
arguments are the same as in the
set_burst_type() and
set_transfer_size() methods.
May 2005
68
Product Version 5.4

void fill_burst(
bool write_trans,
sc_uint<3> burst_type,
sc_uint<32> start_addr,
sc_uint<3>
size ,
Configures automatically a burst transaction

and fills the data_array before submitting
a transaction.
write_trans:write or read.
burst_type: specifies the burst type as
in the set_burst_type() method.
bool big_endian = false,
start_addr: start address of the burst
data_type type = INCR,
size: specifies the transfer size for the

burst as in the set_transfer_size()
method.
bool check_data = false,

unsigned int burst_length = 1,
data_value = 0)
big_endian: species the endianess

order, used to store the data in
data_array if the user supplies a data
value (data_type is DATA).
This method fills automatically the
data_array according to a pattern
specied by the data_type parameter.
data_type is an enumerated type, which
can take one of the following three values:
INCR: Each byte address is filled with

an incrementing value starting from 0:
data_array[start_addr] = 0x00;
data_array[start_addr+1] = 0x01;
and so on ...
RANDOM: Each transfer of data in the

burst is a random value.
DATA: Each data transfer has the same

value supplied by data_value.
check_data: specifies that an automatic

checking must be done. If it is set to true,
the expected_data_array is filled using
the pattern defined by data_type.
burst_length: species the burst
length if the burst is an INCRemental burst
of undetermined length. It is ignored if the
burst has a fixed length.
data_value is the value of all data
transfer if data_type is DATA..
May 2005
69
Product Version 5.4

void initialise()
Initializes the transaction object to be

re-used again in the same simulation. This
method must be used only if the transaction
is complete. It clears all the memory space
occupied by all the sparse arrays (data
array, expected_data_array,
beat_delay_array,
check_mask_array) and resets the
transaction status information.
Example:
ahb_arg_handle_t tx_h = new ahb_arg_t;
tx_h->set_address(..);
//..configure the transaction
master_tx_port->push( tx_h );
tx_h->wait_for_finish_event();
tx_h->initialise();
/**reconfigure a new transaction using
the same object**/
May 2005
70
Product Version 5.4

unsigned int
get_operation_status()
Returns the status of the burst transaction

at any time after the transaction has been
submitted. The operations status possible
values are:
0 - AHB_OP_STATUS_NOT_STARTED: the
transaction is still queued in the transactor
and did not yet start.
1 - AHB_OP_STATUS_REGISTERED: the
transaction is in the 2nd position in the
queue, i.e is waiting for the completion of
the current transaction in order to start.
2 - AHB_OP_STATUS_TX: The first NONSEQ
transfer has already started. The is the
normal status. It holds the same value until
the burst completion unless a specific event
occurs (see the other status values below).
3 - AHB_OP_STATUS_COMPLETED: The
transaction is complete, for example, the
last data phase of the burst has completed.
4 - AHB_OP_STATUS_SPLIT_RETRY: a
RETRY or a SPLIT response has been
received. The status holds this value until
the transactor retries the transfer later, the
status gets back to AHB_OP_STATUS_TX.
6 - AHB_OP_STATUS_LOSS_OF_GRANT
The Master has lost the data bus and did
not complete all the transfers within the
burst. When the transactor owns the bus
back again, the remaining transfers resume
and the status reverts to
AHB_OP_STATUS_TX.
7 - AHB_OP_STATUS_CANCELED The Burst
was canceled due to a Bus Reset or due to
a Slave ERROR response.
After an ERROR response, the status can
get this value only if
set_continue_after_error(false)
was set (see Table 4-4 on page 59).
Otherwise, the status stays at
AHB_OP_STATUS_TX.
May 2005
71
Product Version 5.4

Non blocking call: returns the number of

completed transfers at any time during the
transaction.
unsigned int
get_num_completed_transfers()
The following methods are blocking. They should be used only if the stimulus generator
uses the push interface (Push Interface on page 52) .They should NOT be used in the
case where the stimulus generator directly implements the pull interface (see Pull
Interface on page 50).
void wait_for_start_event()
Blocking call: wait until the transaction

starts. The start time is the clock edge when
the first NONSEQ transfer starts.
void wait_for_finish_event()
Blocking call: wait until the transaction is

either completed or cancelled (e.g by a bus
reset)
bool wait_for_retry_event()
Blocking call: wait to expect a RETRY

response during the transaction. It returns
true when the master samples a RETRY
response (i.e, at the first cycle of the 2 cycle
RETRY response).
If no RETRY occurs during the burst
transaction, returns false when the
transaction completes.
Blocking call: wait to expect a loss of bus
grant during the transaction. It returns true
when the master looses the data bus, i.e.
when it samples HGRANT at 0 and 2
consecutive HREADY at 0.
bool
wait_for_loss_of_grant_event()
returns false when the burst transaction

completes without any loss of grant.
The ahb_arg_t static public methods

Table 4-5 on page 73, lists and describes the ahb_arg_t static public methods.
May 2005
72
Product Version 5.4

Table 4-5 Table of ahb_arg_t Static Public Methods
Static Method
Description
static
sc_uint<32>
get_good_addr
(sc_uint<32>
address,
sc_uint<3> size)
If the address is not aligned with the transfer size, it returns a

masked address aligned with the specified transfer size.The
size parameter valid values are the same as for the
set_transfer_size method.
Examples of using the ahb_arg_t class

A SINGLE transfer or a burst can be congured in two ways:
1. An automatic configuration, using the write_integer_data_array,
fill_data_burst(), fill_burst() methods.
2. A more manual configuration, which directly writes into the sparse arrays:
Examples of both approaches are given below,:
/***Configuring and submitting a SINGLE, Write,1-Word transfer***/
ahb_arg_handle_t tx_h = new ahb_arg_t;
tx_h->set_burst_type(AHB_BURST_SINGLE);
tx_h->set_transfer_size(AHB_SIZE_WORD);
tx_h->set_address(0xff010044);
tx_h->set_write_transaction(true);
// 0x11223344 value is stored in a bigEndian way in data_array.
tx_h->write_integer_data_array(0xff010045,AHB_SIZE_WORD,true,0x11223344);
master_tx_port->push( tx_h );//submit the transaction through the push interface
tx_h->wait_for_finish_event();//wait until the transaction is finished
/**Configure a WRAP4 Read burst and fill the expected data array with an
incrementing data for each byte of the burst**/
tx_h->initialise();//initialise() is necessary before re-using a transaction
handle
tx_h->fill_burst(AHB_BURST_WRAP4,0xff010044,AHB_SIZE_WORD,true,INCR,true,00);
May 2005
73
Product Version 5.4

/**Configuring a SINGLE write manually**/
handle
tx_h->set_burst_type(AHB_BURST_SINGLE);
tx_h->data_array[0xff010044] = 0x00;
/**Configure a WRAP4 Write burst and fill manually the data array with values stored
in an external sparse array called memory_array**/
handle
tx_h->set_burst_type(AHB_BURST_WRAP4);
sc_uint<32> address = 0xff010044;
for (unsigned int i=0; i< 4 ; i++) //For each WORD transfer in the burst
{
//Fill each data byte of the transfer with values stored in memory_array
tx_h->dataArray[address + i*4] = memory_array[address + i*4];
tx_h->dataArray[address + 1 + i*4] = memory_array[address + 1 +i*4];
tx_h->dataArray[address + 2 + i*4] = memory_array[address + 2 +i*4];
tx_h->dataArray[address + 3 + i*4] = memory_array[address + 3+ i*4];
//calculates automatically the address of the next transfer
address = tx_h->get_next_addr(address, AHB_BURST_WRAP4, AHB_SIZE_WORD);
}
May 2005
74
Product Version 5.4

Creating and using transaction handles

The way to create a new transaction and store it in a shared pointer (or handle) is shown in
the following line:
ahb_arg_handle_t transaction_h = new ahb_arg_t;
Using a shared pointer to store a transaction frees the stimulus writer from the burden of
memory management. The transaction object will be automatically deleted when no
reference of its handle exists.
Once a transaction is created, the associated transaction handle (transaction_h in the
example above) can be used to keep track of the transaction during its entire duration, that
is, from the moment it is queued in the master transactor until the completion of the last
transfer of the burst or the burst cancellation due to a Bus reset or an ERROR response.
The same handle can be used to keep track of a burst transaction after a RETRY/SPLIT
response is received or if a Loss of Bus grant occurs in the middle of a burst. If any of these
events happen, the master transactor will automatically build a new burst and try to continue
the burst transaction until it is complete.
Once a transaction has been created and submitted to the transactor, the same transaction
handle can not be used to configure an other transaction until the transaction finishes. After
that, the stimulus writer must use the initialise() method to be able to use the same
handle to submit a new transaction.
In addition to returning a transaction handle to the transactor, if the stimulus generator writer
wants to keep a reference of any transaction submitted, Cadence recommends to store that
handle on an STL list or an array. Later, the stimulus generator will be informed that a
transaction is complete (e.g. using the wait_for_finish_event() or
get_operation_status()). The stimulus generator will then locate the corresponding
handle on the list of outstanding transactions and remove it. The handle of a completed
transaction can also be recycled after using the initialise() method.
AHB Master Pin-Level Interface

The ahb_master_port_if class denes the master transactor pin-level interface. This
class is made of sc_in<> and sc_out<> SystemC signals that connect the transactor to the
AHB design under verification (Verilog/VHDL or SystemC).
If the transactor is being used in a Verilog/VHDL system verification testbench, a
corresponding Verilog/VHDL transactor wrapper must be instantiated in the Verilog/VHDL
design. In this case, the binding between the SystemC transactor signals and the
May 2005
75
Product Version 5.4

Verilog/VHDL signals of the transactor wrapper is done just after the construction of the
transactor object and before the simulation starts.
Table 4-6 on page 76 lsts and describes the ahb_master_port_if ports.
Table 4-6 Table Describing the ahb_master_port_if Ports
Ports
Description
sc_out<sc_uint<32> > ahb_addr
Address used in read/write

transaction: HADDR
sc_in<bool> ahb_clk
System wide clk: HCLK
sc_in<bool> ahb_resetn
System wide reset : HRESETN
sc_in<bool> ahb_gnt
Indicates Master has been granted

access to bus: HGRANTx
sc_out<bool> ahb_lock
Indicates Master requires a lock on the

bus: HLOCKx
sc_out<bool> ahb_req
Indicates Master requires use of the

bus : HBUSREQx
sc_in<sc_uint<2> > ahb_resp
Indicates response from the Slave:

HRESP
sc_in<bool> ahb_ready
Indicates when transfer has been

completed : HREADY
sc_in<sc_bv<AHB_DATA_BUS_WIDTH> >
ahb_r_data
Read data bu: RDATA
sc_out<sc_bv<AHB_DATA_BUS_WIDTH> >
ahb_w_data[31:0]
Write data bus: HWDATA
sc_out<sc_uint<4> >
ahb_prot
Protection control for bus access :

HPROT
sc_out<sc_uint<3> >ahb_size
Indicates size of transfer: HSIZE
May 2005
76
Product Version 5.4

sc_out<sc_uint<3> > ahb_burst
Indicates the type of burst: HBURST
sc_out<sc_uint<2> > ahb_trans
Indicates type of current burst :

HTRANS
sc_out<bool> ahb_write
Indicates if write or read is occurring:

HWRITE
AHB Master Transaction Recording

Each AHB Master transactor is able to record three types of transactions on three different
streams. Each of these streams will appear under the master transactor scope they belong
to, in the Simvision Design Browser (Fro example, top$ahb_master_1,
top$ahb_master_2, and so on.).
Important
The definition of a transaction that applies in this section is the one defined in AHB
Master Transactor Class on page 45. However, the result of the transaction
recording process (which is the visual object seen in simvision), is also called a
transaction in this section. Please be aware of this situation.
Each stream represents the time line and transactions are recorded as rectangles overwriting
the time line. A transaction rectangle defines the start time and the end time of a transaction.
Each transaction contains a title label and attributes recorded inside their rectangles.
If the master transactor does not generate any transactions on the bus or if the transaction
recording has been switched off, a continuous time line will be seen on each stream line.
This section discusses the following topis:
What is recorded on the burst pipelined stream is described in The Burst Pipelined
Stream on page 78.
What is recorded on the address phase stream is described in The Address Phase
Stream on page 79.
What is recorded on the data phase stream is described in The Data Phase Stream on
page 81).
May 2005
77
Product Version 5.4

The Burst Pipelined Stream
The burst_pipelined_stream can record burst transactions. Another recording stream
named as burst_pipelined_stream_1 automatically appears in simvision in case two
burst transactions overlap with each other. If no burst overlapping occurs during the
simulation, the transactions will be recorded only in a single recording stream.
A burst transaction starts when the first address phase starts. It finishes when the last data
phase of the burst completes. SINGLE transfers are considered as burst transactions and
are recorded as such in this stream.
If a burst transaction is recorded in burst_pipelined_stream and a new burst starts
before the completion of the data phase belonging to the previous burst, the second burst will
be recorded on burst_pipelined_stream_1. Figure 4-4 on page 78 shows the
transactions recorded in simvision in this specic case.
Burst transaction are held if BUSY cycles are inserted within a burst.
If a RETRY/SPLIT response is received during a burst transaction, the recording of the burst
transaction that owns the retried transfer and the burst transaction that owns the following
transfer (possibly the same one),will both be interrupted at the first cycle of the RETRY/SPLIT
response. A new burst transaction will be recorded when the master transactor resumes the
transfer.
If an ERROR response is received during a burst transaction, the burst transaction recording
can either be cancelled at the first cycle of the ERROR response, or be continued until its
completion. Choosing between these two possible behaviors is controlled by the
set_continue_after_error method used to congure a transaction (see Table 4-4 on
page 59).
Burst transactions are automatically terminated if a bus reset is detected.
Figure 4-4 Burst Transactions recorded in the burst_pipelined_stream
May 2005
78
Product Version 5.4

Top Level Burst Transaction Attributes
Table 4-7 on page 79 describes the attributes recorded in a burst transaction.
Table 4-7 Table of Top Level Burst Transaction Attributes
Attribute
Value Range
Radix
Description
Start Address
0x0-0xffffffff
hex
This value remains unchanged

during the entire length of the
burst. Its value represents the
32-bit start address of the burst.
Burst Type
SINGLE, INCR,
WRAP4, INCR4,
WRAP8, INCR8,
WRAP16, INCR16
alpha-num
eirc
Represents the HBURST value

of the burst.
Transfer Size
BYTE,
HALF-WORD,
2WORD
alpha-num
eirc
Represents the value of HSIZE

during the burst.
R/W
Read, Write
alpha-num
eirc
Represents the value of

HWRITE during the burst
The Address Phase Stream

The address_phase_stream can record the address phases of each transfer generated
by a master transactor.
An address phase starts to be recorded as soon as the master transactor starts a
NONSEQuential or a SEQuential transfer.
An address phase recording is ended when the previous transfer is successfully completed
(HREADY = 1 and HRESP = OKAY, see Figure 4-5 on page 80) or at the first cycle of a
RETRY/SPLIT Response (see Figure 4-6 on page 82).
If an ERROR response is received while an address phase recording is being done (see
Figure 4-7 on page 82), the address phase recording will normally end when HREADY is 1,
for example. at the second cycle of the ERROR response, unless
set_continue_after_error has been used to tell the transactor to cancel the following
May 2005
79
Product Version 5.4

transfer after an ERROR (see Table 4-4 on page 59). In this case, the address phase recording
will end at the rst cycle of the ERROR response.
An address phase is automatically terminated if a bus reset is detected.
Figure 4-5 Address Phase and Data Phase Transactions
Address Phase Transaction Attributes

Table 4-8 on page 80 describes the attributes recorded in an address phase.
Table 4-8 Table of Address Phase Transaction Attributes
Attribute
Value Range
Radix
Description
Start Address
0x0-0xffffffff
hex
This is the 32-bit address value

that is currently being driven on
the bus. This value represents
the address of the transaction.
Hburst
SINGLE, INCR,
WRAP4, INCR4,
WRAP8, INCR8,
WRAP16, INCR16
alpha-num
eric

of the burst.
Hsize
BYTE,
HALF-WORD,
2WORD
alpha-num
eric

during the burst.
May 2005
80
Product Version 5.4

Attribute
Value Range
Radix
Description
R/W
Read, Write
alpha-num
eric

The Data Phase Stream

The data_phase_stream can record the data phase of each transfer generated by a
master transactor (see Figure 4-5 on page 80).
A data phase starts to be recorded as soon its corresponding address phase has started and
the previous transfer is successfully completed (HRESP = OKAY and HREADY = 1).
If an address phase has started and a RETRY/SPLIT response is received for the previous
transfer, the corresponding data phase will not start until the previous transfer is retried later
(see Figure 4-6 on page 82).
If an address phase has started and an ERROR response is received for the previous transfer,
the corresponding data phase will start unless set_continue_after_error has been
used to tell the transactor to cancel the following transfer after an ERROR (see Table 4-4 on
page 59). Figure 4-7 on page 82, illustrates this specic case.
A data phase recording is ended when the transfer is successfully completed (HREADY = 1
and HRESP = OKAY) or at the first cycle of a RETRY/SPLIT Response.
If an ERROR response is received while a data phase recording is being done, the data phase
recording will normally end when HREADY is 1, for example, at the second cycle of the ERROR
response, unless set_continue_after_error has been used to tell the transactor to
cancel all the following transfer after an ERROR (see Table 4-4 on page 59). In this case, the
data phase recording will end at the rst cycle of the ERROR response.
Any started data phase is automatically terminated if a bus reset is detected.
Figure 4-6 on page 82 shows an address phase started and a RETRY/SPLIT response
received for the previous transfer.
May 2005
81
Product Version 5.4

Figure 4-6 Example of data phase recording with a RETRY Response
Figure 4-7 on page 82 shows an address phase started and a ERROR response received for
the previous transfer.
Figure 4-7 Example of data phase recording with an ERROR response
Data Phase Transaction Attributes

Table 4-9 on page 83 describes the Data Phase Transaction Attributes.
May 2005
82
Product Version 5.4

Table 4-9 Table of Data Phase Transaction Attributes
Attributes
Value Range
Radix
Description
Start Address
0x0-0xffffffff
hex

Burst Type
SINGLE, INCR,
WRAP4, INCR4,
WRAP8, INCR8,
WRAP16, INCR16
alpha-num
eric

of the burst.
Transfer Size
BYTE,
HALF-WORD,
WORD, 2WORD
alpha-num
eric

during the burst.
R/W
Read, Write
alpha-num
eric

data
0x0-0xffffffff
or
0x0-0xffffffff
ffffffff (
depending on the
data bus width: 32
or 64 bits)
hex
data value read from or written

to the bus.
May 2005
83
Product Version 5.4

Attributes
Value Range
Radix
Description
Expected data
0x0-0xffffffff
or
0x0-0xffffffff
ffffffff (
depending on the
data bus width: 32
or 64 bits)
hex
Represents the expected data

value to be read for this
transfer. This attribute appears
only if the following conditions
are met:
Automatic data check has

been switched on for this
transaction (see
set_check_data method
in the ahb_arg_t class,
Table 4-4 on page 59).
This transfer is a Read.
Endian Format of the Data Bus

The relationship of the data driven or read from the data bus with regard to the how it is stored
in the data_array structure within the ahb_arg_t class is as follows:
Big endian write transaction example:
unsigned int startAddress = 0x10;
data_array[startAddress] = 0x00;
data_array[startAddress+1] = 0x11;
In the big endian example, data is driven on the AHB write data bus [31:0] as 0x00112233.
Little endian write transaction example:
startAddress = 0x10;
data_array[startAddress] =
data_array[startAddress+1]
0x00;
= 0x11;
= 0x22;
= 0x33;
In the little endian example, data will be driven on the AHB write data bus [31:0] as
0x33221100.
Data for a read transaction will follow the same mapping for a specified endian format.
May 2005
84
Product Version 5.4

Start Delay Specifications

This feature is supported by the set_start_delay method of the ahb_arg_t class (see
Table 4-4 on page 59). It allows setting a specified number of IDLE cycles before starting a
NONSEQuential transfer (SINGLE transfer or a burst). These IDLE cycles are possibly
pipelined with the data phase of the previous transaction and inserted as soon as the master
transactor owns the address bus, for example, HGRANT and Hready have been sampled at
a value of 1.
By default, the master will start the NONSEQuential transfer as soon as it owns the address
bus (null start delay).
If the master loses the bus grant prematurely during a burst, the remaining transfers of the
burst will automatically start as soon as the master owns the address bus again without any
IDLE cycles before the first NONSEQuential transfer.
If the master transactor needs to retry a transfer, the number of IDLE cycles inserted before
the retried transfer is controlled by the set_num_Idle_after_retry method (see
Table 4-4 on page 59).
Bus Request
By default, the bus request (HREQ) is asserted one clock cycle before the rst
NONSEQuential transfer starts, that is, one IDLE cycle is inserted between the HREQ
assertion and the NONSEQ transfer if no transaction was already in the transactor pipeline. A
possibly larger number of IDLE cycles can be inserted using the set_start_delay
method as specied in Start Delay Specications on page 85.
HREQ remains asserted until the last address of the last submitted transaction starts. In
other words, if two or more transactions are submitted in a row, the bus request will be held
until the last address phase of the last transaction.
In some cases, it may be required to tell the transactor to hold the bus request even after the
last address phase of a transaction has completed. This can be done by using the
set_hold_req_after_last_transfer method(see Table 4-4 on page 59 and
Example of a Read-Modify-Write locked sequence on page 86).
Transfer Lock
HLOCK is asserted by the master transactor at least one cycle before the first
NONSEQuential address phase of a locked transaction starts, which prevents the arbiter
from changing the Grant signals (Refer to the AHB specification V2.0 section 3.11.1 p
3-28).
If two or more locked transactions are submitted in a row, HLOCK is held until the last
address phase of the last locked transaction starts.
May 2005
85
Product Version 5.4

To emulate for example a locked sequence of transactions that are not submitted in a row
(because a transaction depends on the result of the preceding one), it may be required in
some cases to tell the transactor to hold the bus request even after the last locked address
phase of a transaction has completed. This can be done by using the
set_hold_lock_after_last_transfer method(see Table 4-4 on page 59). Example
of a Read-Modify-Write locked sequence on page 86, shows how to emulate
such sequences of transactions.
Example of a Read-Modify-Write locked sequence
The AHB Master Transactor supports the emulation of atomic sequences of memory
transactions. The following example shows how to emulate a read-write sequence, where the
write depends on the data read using the push interface.
To insure the atomicity of this sequence of transactions, the bus lock and the bus request
must be held until the address phase of the write. In this example, the write is done if some
condition is satisfied in the value read.
Example
/*create a transaction object and store it in a handle*/
ahb_arg_handle_t read_tx_h = new ahb_arg_t;
/*address of the memory location which must be read and written to (e.g a memory
swap)*/
read_tx_h->set_address(0x11ff7824);
/**specify the size of the transfer size, for example a byte swap*/
read_tx_h->set_transfer_size(AHB_SIZE_BYTE);
/*configure the read and the write transfers as Locked so that HLOCK is asserted
before the read starts.*/
read_tx_h->set_lock(true);
/*specify that HLOCK/HREQ must be held after the address phase of the read transfer.
If this option was not switched on (i.e. default value), the AHB Master transactor
would release HREQ/HLOCK when it starts the SINGLE Read Address phase because no
other locked transaction was submitted*/
tx_h->set_hold_lock_after_last_transfer(true);
/*submit the read transfer and wait until it is complete to do some checks*/
master_tx_port->push(read_tx_h);
read_tx_h->wait_for_finish_event();
/*In this case, the Testbench processes the write value depending on the value
loaded from memory. This example implements a test condition on the read value, the
write is done here only if the value is not null*/
if( read_tx_h->data_array[0x11ff7824] != 0)
{
/** Fill the tx_h data_array (not describe here) and submit the write transfer **/
May 2005
86
Product Version 5.4

/*create a new transaction object and store it in a handle*/
ahb_arg_handle_t write_tx_h = new ahb_arg_t;
/** except for set_hold_lock_after_last_transfer() and set_write_transaction() the
same settings can be used for the WRITE: Same address, same transfer size **/
write_tx_h->set_write_transaction( true );//WRITE
master_tx_port->push(write_tx_h);
write_tx_h->wait_for_finish_event();
/**when the run returns, the Write Transfer is complete. HLOCK and HREQ have been
automatically released when the Address Phase of the Write started**/
}
else
{
/*if the write is not done, HREQ/HLOCK must be released to prevent the master from
monopolizing the bus*/
ahb_arg_handle_t null_tx_h = new ahb_arg_t;
null_tx_h->set_null_transaction();
null_tx_h>release_lock();
null_tx_h->release_req();
}
Note: In this example, the WRITE depends on the value read and HREQ/HLOCK must be held
after the READ address phase has started. If the test wants to emulate a locked sequence of
transactions which have no dependencies with each other, there is no need to use
set_hold_lock_after_last_transfer and the sequence could be emulated by a
simple succession of push calls, as follows:
/***tells to the transactor to assert HLOCK before the 1st transfer of the
locked sequence starts.***/
tx1_h->set_lock(true);
master_tx_port->push( tx1_h);
//next transaction
tx2_h->set_lock(true);
master_tx_port->push( tx2_h);
/and so on ...
Insertion of BUSY cycles

A specified number of BUSY cycles can be inserted before any transfer within a burst except
for the first NONSEQuential transfer (see Table 4-3 on page 57).
If a burst is early terminated due to a bus grant loss, the master transactor will continue to
transmit the remaining transfers when it owns the bus again (HREADY and HGRANT are
May 2005
87
Product Version 5.4

sampled at 1). In this case, the master transactor will start the remaining transfers with a
NONSEQ without any BUSY cycles inserted before it.
Retried bursts
If a transfer within a burst must be retried due to a RETRY or a SPLIT response, the master
transactor will automatically build a new burst to retry this transfer and continue the remaining
transfers.
If the master transactor does not lose the bus after the RETRY/SPLIT response, it can insert
a specified number of IDLE cycles before re-transmitting the interrupted burst (see the
set_num_idle_after_retry method described in Table 4-4 on page 59).
If the master transactor loses the bus after the RETRY/SPLIT, it will start to re-transmit the
interrupted burst as soon as HGRANT and HREADY are sampled at 1, without any IDLE cycles
before the first NONSEQuential re-transmitted transfer according to the following:
If the retried transfer is the first transfer of the burst, the re-transmitted burst will have the
same type as the initial burst (For example, WRAP4, INCR8, and so on).
If the retried transfer is any other transfer in the burst, the re-transmitted burst will be an
incremental (INCR) burst.
Early terminated bursts

If a burst is early terminated due to a bus grant loss, the master transactor will wait until it
owns the bus again and will automatically continue the remaining transfers.
The burst containing the remaining transfers will be an incremental (INCR) burst.
AHB 1K Line Burst Protection Algorithm

The AHB Master does not protect against the crossing of a 1K-burst line boundary. This
capability allows the verification engineer to test their designs resilience to an ill-behaved
AHB Master on the interface of their design. If it is not desired that the stimulus cross this
boundary, an algorithm will have to be implemented to enforce this behavior. The following is
an algorithm that may be implemented to protect against a 1K line crossing by the AHB
Master.
May 2005
88
Product Version 5.4

For Burst of SINGLE, INCR, INCR4, INCR8 and INCR16
To determine the start address for a given burst
Calculate the last address of the last transfer.

See if address bit 10 from the start address and last address are different. If so, the
transfer will cross a 1K boundary and you will want to select a new starting address.
For Burst of WRAP4, WRAP8 and WRAP16

To determine the start address of the line:
1. Take the start address and mask the lowest bits of the start address, based on the size
and burst values to be used.
2. Add the total number of bytes to transfer, to the start address of the line, to obtain the last
address of the line.
See if the address bit 10 from the start address of the line and last address of the line
are different. If so, the transfer will cross a 1K boundary, and you will want to select a new
starting address for the WRAP burst cycle.
AHB Slave Transactor

The AHB Slave Transactor is used to imitate an AHB Slave and supports AMBA
specifications. The Transactor recognises transactions on a signal-level interface and
responds to these transactions, under the control of the verification test, by emulating a
physical device, as if the device were actually connected to the interface.
Whenever the Transactor state machine needs to get information from the component that is
emulating the behaviour of the device the slave represents, the transactor calls a callback
function which provides the required information. Since the AHB Slave Transactor is
decoupled from the device that the AHB Slave Transactor represents, it can be reused and
attached to a different emulated component, an I/O controller for example, depending on the
configuration requirements of the testbench.
In this case, the component that is emulating the behaviour of the device the slave represents
is called a AHB Slave Device Emulator, to which the Transactor has a SystemC interface to
make the necessary callback function calls. The Device Emulator supplied with the
Transactor is modeled as a memory (RAM/ROM) and provides an interface to preload the
memory with data, no. of wait cycles, no. of SPLIT delay cycles and response type. Each
address location has associated data, wait_cycles, SPLIT delay and response type.
May 2005
89
Product Version 5.4

The address is 32 bits wide and the data bus is either 32, 64 or 128 bits. The Device
Emulator may be substituted by a customer generated model if desired.
Since an AHB transfer to the Slave may result in multi-byte access to memory, the algorithm
used to determine the resultant Device Emulator number of wait cycles, is to use the address
location with the largest number of wait cycles. For example, a word access to address 0x10
actually spans locations 0x10 through 0x13. The location containing the largest number of
wait cycles will determine the HREADY wait states inserted for this access.
Similarly the Device Emulators response type, on multi-byte accesses, will have the following
precedence: ERROR followed by SPLIT, followed by RETRY, and OKAY.
For example, a word access to address 0x10 actually spans locations 0x10 through 0x13:
Location 0x10 has been configured to respond with ERROR,
Location 0x11 with RETRY,
Locations 0x12 and 0x13 to respond with OK.
The resultant response on the AHB Bus will be ERROR, for this scenario. Likewise a byte
access to 0x11 would result in a RETRY response.
Figure 4-8 on page 91 illustrates how the AHB Slave Transactor interfaces to the Device
Under Test (DUV) and also how the AHB Slave Transactor interfaces to the AHB Slave Device
Emulator.
May 2005
90
Product Version 5.4

Figure 4-8 AHB Slave Transactor Interfacing to the Device Under Test
May 2005
91
Product Version 5.4

To avoid undefined behaviour in the AHB Slave Device Emulator, the AHB Slave Transactor
will report an exception and respond with a two cycle ERROR response (and no preceding
wait states) to the following AMBA AHB protocol violations, in order of the following priority:
1. Transfer size requests greater than what the Slave can support.
2. 1K Address Boundary Crossovers.
3. Unaligned address inputs.
AHB Slave Transactor Interfaces

There are two seperate interfaces to the AHB Slave Transactor:
1. An AHB Slave Transactor connects to a device under verification through a signal level
interface described in AHB Slave Port Interface on page 120.
2. An AHB Slave Transactor can be configured dynamically through a configuration
interface as described below AHB Slave Transactor Configuration Interface.
AHB Slave Transactor Configuration Interface

The AHB Slave Transactor can be configured through a SystemC virtual interface called
uvm_control_if_t that is not protocol specific and that is implemented by various
transactors (AHB, PCI, USB etc.). The definition of this class is shown in the following
example.
Example
public:
virtual void enable_on() {enable = 1;} //enables the transactor (default)
virtual void enable_off() {enable = 0;} //disable the transactor
virtual void debug_on() { debug = 1;}//displays the debug information
virtual void debug_off() { debug = 0;}//hides the the debug info (default)
virtual bool get_debug() { return debug;}
virtual bool get_enable() { return enable;}
May 2005
92
Product Version 5.4

protected:
bool debug;
bool enable;
};
The CONTROL_T template structure of this class is protocol specific. A common structure
called ahb_configuration_t is used to configure all the AHB Transactors. Table 4-10 on
page 93 shows the attributes of this structure that are used to configure the AHB Slave
Transactor.
Table 4-10 Attributes of ahb_configuration_t used by the AHB Slave Transactor
Attributes
Description
bool big_endian
Endianess mode of the AHB Slave

Transactor:
false - Little Endian data bus
(default).
true - Big Endian data bus.
bool split_capable
This is used to enable the AHB Slave

Transactor to drive the HSPLIT output
(ahb_split[15:0]) a specified number of
clock cycles after a SPLIT response
has been generated by the AHB Slave
Transactor.
Attribute value:
true - sets the split_capable attribute
to enable driving the
ahb_split[15:0] output.
false - resets the split_capable
attribute to disable driving the
ahb_split[15:0] output.
May 2005
93
Product Version 5.4

bool info_msg
If info_msg is set to true,

information messages are displayed
and logged in the tb.log file (default is
false).
If transaction_record is set to
true, transactions are recorded in
Simvision.
Note: The data bus width is a compilation time constant dened in the ahb.h header le
thus:
//Data Bus width value defined in the ahb.h header file
const int DATA_BUS_WIDTH = 32; //Default value = 32
As presented in AHB Slave Port Interface on page 120, the data bus pins,
ahb_w_data and ahb_r_data are declared respectively of type
sc_in<sc_bv<DATA_BUS_WIDTH> > and sc_out<sc_bv<DATA_BUS_WIDTH> >.
You can override this default value specified in the ahb.h file by using a compiler
directive either on the command line or in a file used to load command line arguments
as follows:
#compilers directive for DATA_BUS_WIDTH
-DDATA128
#define data_bus_width verilog parameter
+define+DATA128
The consequence of this limitation is that, a specific library of AHB transactors must be
used for each possible data bus width (32, 64 or128 bits).
An Example of Using the Configuration Interface in a Stimulus Generator
If you want to configure the AHB Slave Transactor with some non-default values, the stimulus
generator must contain a SystemC port of type:
sc_port<uvm_control_if_t<ahb_configuration_t> >
In this case, the stimulus generator must also declare a structure of type
ahb_configuration_t, as follows:
class stimulus_generator_t : public sc_module {
public:
// Slave configuration port
sc_port< uvm_control_if_t<ahb_configuration_t> > slave_control_port;
May 2005
94
Product Version 5.4

void my_test();
SC_CTOR(stimulus_generator_t)
: slave_control_port(slave_control_port),..,..
{
SC_THREAD(my_test);
}
};
void stimulus_generator_t::my_test() {
// Configure the Slave Transactor before starting the stimulus.
transactors_config.transaction_record = false;
transactors_config.info_msg = true
transactors_config.big_endian = true;
transactors_config.split_capable = true;
slave_control_port->send_control(transactors_config);
/...
}
AHB Slave Device Emulator Interfaces

There are two seperate interfaces to the AHB Slave Device Emulator:
1. An AHB Slave Device Emulator can be configured dynamically through a configuration
interface as described below AHB Slave Device Emulator Configuration Interface on
page 95.
2. An AHB Slave Transactor can interface to an AHB Slave Device Emulator when
requesting information through a transaction-level interface as described below AHB
Slave Device Emulator Transaction-Level Interface on page 113.
AHB Slave Device Emulator Configuration Interface
The AHB Slave Device Emulator can be configured through a SystemC virtual interface called
uvm_control_if_t that is not protocol specific and that is implemented by various
transactors (AHB, PCI, USB etc.). The definition of this class follows:
May 2005
95
Product Version 5.4

public:
virtual void enable_on() {enable = 1;} //not used by AHB Slave Device Emulator
virtual void enable_off() {enable = 0;} //not used by AHB Slave Device Emulator
virtual void debug_on() { debug = 1;}//not used by AHB Slave Device Emulator
virtual void debug_off() { debug = 0;}//not used by AHB Slave Device Emulator
virtual bool get_debug() { return debug;}//not used by AHB Slave Device Emulator
virtual bool get_enable() { return enable;}//not used by AHB Slave Device Emulator
protected:
bool debug;
bool enable;
};
The CONTROL_T template structure of this class is protocol specific. A common structure
called ahb_slave_emulator_config_t is used to configure the Emulator.
Note: Only the above control interface method virtual bool send_control(const
CONTROL_T&) is implemented by the Emulator. The Emulator cannot be turned on and off
because it is a purely passive component (there is no SystemC thread running within the
module) that is, it will only be activated when requested by an AHB Slave Transactor. There
are also no debug messages associated with the Emulator.
Example of Using the Configuration Interface in a Stimulus Generator
If you want to configure the AHB Slave Device Emulator with some non-default values, the
stimulus generator must contain a SystemC control port of type:
sc_port<uvm_control_if_t<ahb_slave_emulator_config_t> >
In thi scase, the stimulus generator must also declare a class object of type
ahb_slave_emulator_config_t.
An instance of this class object must then take as a constructor argument a SystemC port. In
this case the control port to be used to configure/control the AHB Slave Device Emulator is
used as the constructor argument, for example:
public:
// Slave Device Emulator configuration/control port
sc_port< uvm_control_if_t<ahb_slave_emulator_config_t> > emulator_control_port;
May 2005
96
Product Version 5.4

// Instantiate the AHB Slave Device Emulator

ahb_slave_device_emulator_t slave_device_emulator;
// Declaration of Slave Device Emulator Configuration Object
ahb_slave_emulator_config_t emulator_config;
void my_test();
SC_CTOR(stimulus_generator_t)
: .................................................,
slave_device_emulator(slave_device_emulator),
emulator_control_port(emulator_control_port),
//Call the Instance of the Emulators configuration objects
//constructor with the control port previously created
emulator_config(emulator_control_port),
..................................................
{
SC_THREAD(my_test);
}
};
void stimulus_generator_t::end_of_construction()
{
..............
//Bind the Emulators control port to an instance of the Emulator
emulator_control_port(slave_device_emulator);
................
tb_startup();
}
void stimulus_generator_t::my_test() {
.............
// Configure address 0x0100 with a data value of 0x0500, a response value of SPLIT,
// a HREADY wait_cycle value of 4 clock cycles, a split delay value of 9 clock
cycles and a split_enable value of true.
emulator_config.write_emulator(0x0100, 0x0500, SPLIT, 4, 9, true);
.............
............
}
May 2005
97
Product Version 5.4

A more detailed description of the configuration class is given in the following sections, as well
as a more detailed explanation of the various methods available to configure the AHB Slave
Device Emulator.
Configuration Argument Class

The ahb_slave_emulator_config_t class is the argument type of the send_control
method defined in the uvm_control_if_t interface class. The testbench/stimulus
generator is responsible for configuring this class before it is sent to the AHB Slave Device
Emulator via a control port.
There are five address (location in the Emulators memory space where to write the attribute
values) dependant attributes that can be set in the Emulator, using the
ahb_slave_emulator_config_t class:
Address(32-bit) Attributes:
Data
Response
Wait Cycles
Split Delay
Split Enable
Table 4-11 on page 98 below gives a description of each of these Attributes.

Table 4-11 AHB Slave Device Emulator Address Attributes
Data
Each address holds an 8 bit byte of data. Default = 0x00.
Response
Each address can be configured with 1 of 4 responses: OKAY,

RETRY, SPLIT, ERROR. During a word access spanning
multiple address locations, the most fatal among the response
is chosen in the following order: ERROR, SPLIT, RETRY, OKAY.
Default = OKAY.
Wait Cycles
Each address can be configured with a number of wait cycles

associated with HREADY. During a word access, the highest
wait cycles value is used. Default = 0
Split Delay
If the Split Enable flag is set, the Slave changes the

HSPLIT[15:0] output to the relevant corresponding SPLIT
Master ID value (HMASTER[3:0]) a number (determined by
this attribute) of clock cycles after a SPLIT response for one
clock cycle. During a word access, the highest delay value is
used. Default = 0.
May 2005
98
Product Version 5.4

Data
Each address holds an 8 bit byte of data. Default = 0x00.
Split Enable
After a SPLIT response has been generated for a particular

address, this attribute enables the setting of the
HSPLIT[15:0] output after a number of clock cycles
determined by Split Delay. Default = FALSE.
There are many flexible methods defined in the ahb_slave_emulator_config_t class to

allow the user to set these attributes before the user sends an instance of the class object to
the AHB Slave Device Emulator. A list of these available methods are described in Table 4-12
on page 100.
Note also that this configuration argument class ahb_slave_emulator_config_t takes
as the constructor argument the control port to be used for configurationand control of the
AHB Slave Device Emulator. The methods defined in Table 4-12 on page 100 call the bool
send_control(const ahb_slave_emulator_config_t&) interface method of the
AHB Slave Device Emulator by way of this port once the specific argument values to each
method have been set. For example:
class ahb_slave_emulator_config_t {
public :
// Constructor
ahb_slave_emulator_config_t(sc_port<uvm_control_if_t<ahb_slave_emulator_config_t
>, 0 >& arg) : port_(arg) {
}
........................
void write_emulator(sc_uint<32> address, sc_uint<8> data);
..........................
private:
sc_port<uvm_control_if_t<ahb_slave_emulator_config_t>, 0 >& port_;
........................
}
void ahb_slave_emulator_config_t::write_emulator(sc_uint<32> addr, sc_uint<8>
data) {
set_device_emulator_config(WRITE);
set_address(addr);
set_data(data);
port_->send_control(*this);
}
May 2005
99
Product Version 5.4

Methods of the ahb_slave_emulator_config_t Class
Table 4-12 on page 100 list the methods that call the bool send_control(const
ahb_slave_emulator_config_t&) interface method of the AHB Slave Device Emulator.
Table 4-12 Methods of the ahb_slave_emulator_config_t Class
Method
Description
void
After the AHB Slave Transactor requests a

response value from the AHB Slave Device
Emulator for a particular address, this method
call will determine whether the Emulator should
reset the response value for an address to OKAY
or not, after the Transactor has received the
response value.
set_reset_response_after_us
e(
bool reset;
);
It is particularly useful to use this method to set

the argument value to true when there are
addresses within the Emulators memory space
that have been configured as SPLIT or RETRY
responses.
Arguments:
reset - sets the
reset_response_after_use attribute.
True = The Emulator will modify the response
for an accessed address to be OKAY, after the
Transactor has received the previous setting.
False = response will not be modified after use.
Default value of reset = True
When this method is called an enumerated type
called SET_RESET_RESPONSE_AFTER_USE is
automatically set within the class object which
will indicate to the AHB Slave Device Emulator,
once it receives the object, to perform this
desired operation.
Once this attribute value of the class object is
set, the object is automatically sent to the AHB
Slave Device Emulator by way of the Emulators
control port.
May 2005
100
Product Version 5.4

void
clear_emulator();

called CLEAR is automatically set within the
class object which will indicate to the AHB Slave
Device Emulator, once it receives the object, to
perform this desired operation.
Once this attribute value of the class object is
set the following actions occur:
1. The object is automatically sent to the AHB
Slave Device Emulator by way of the
Emulators control port
2. The Emulator clears the state of its memory
space by doing the following:
May 2005
101
Zero out the data in memory
Set the response for all memory to be

OKAY
Set the wait_cycles and

split_delay values to 0
Set the split_enable values to

false
Product Version 5.4

void
fill_emulator(
sc_uint<32> start_addr,
sc_uint<32> end_addr,
data_type data_generation,
sc_uint<8> byte_data,
response_type response,
unsigned int wait_cycles
);

called FILL is automatically set within the class
object which will indicate to the AHB Slave
perform this fill operation.
This method is used to fill the internal memory
array contained within the Slave Device
Emulator with data, wait cycles, and response
for each address.
Arguments:
start_address - This is a 32-bit field which
contains the start address to fill with data,
wait_cycles and response.
end_address - This is a 32-bit field which
contains the end address to fill with data,
wait_cycles and response.
data_generation - This is an enumerated
type. The options are:
May 2005
102
data_type::INCR - Fills the

internal memory array from
start_address through
end_address with incrementing data
and uses the data argument as the
starting data pattern.
data_type::RAND - Fills the

internal memory array from
start_address through
end_address with random data.
data_type::DATA - Fills the

internal memory array with data
specified in the data argument at the
start_address. The argument
end_address is ignored.
Product Version 5.4

byte_data - This is an 8-bit field that supplies

a data byte to store.
response - This is an enumerated type. This
argument will configure the memory to respond
to AHB cycles to the address range specified.
The options are:
response_type::OKAY (Default if
not specified)
response_type::ERROR
response_type::RETRY
response_type::SPLIT
wait_cycles - HREADY response delay for

the addresses specified (Defaults to 0 if not
specified).
Once the attribute values of this class object is
Slave Device Emulator via the Emulators
control port.
May 2005
103
Product Version 5.4

void write_emulator(
sc_uint<8> data,

called WRITE is automatically set within the
class object which will indicate to the AHB Slave
perform this particular write operation.
unsigned int split_delay,
This method will set the address, data,

response, wait_cycles, split_delay
and split_enable attributes of this class.
bool split_enable
Arguments:
);
address - This is a 32-bit field that contains

the address for which to set the data value.
Default is 0.
unsigned int wait_cycles,
data - Data byte supplied (8 bits). Default is 0.

response - This is an enumerated type. The
options are one of: OKAY, ERROR, RETRY,
SPLIT.
Note: Configuring an address for a SPLIT
response automatically enables the AHB Slave
Transactor to drive the HSPLIT (ahb_split) bus,
provided the Transactor is configured as SPLIT
capable (The split_capable Transactor
configuration parameter is set to true (default
value)).
Default response is OKAY.
wait_cycles - Number of clock cycles (in
ns) during which time HREADYOUT
(ahb_ready_out) is held LOW. Default is 0.
May 2005
104
Product Version 5.4

split_delay - If the split enable flag is set,

the AHB Slave Transactor sets the HSPLIT
(ahb_split) bus after the number of clock
cycles determined by this attribute for one cycle.
This delay is set to 0 by default. This attribute is
subsequently only used by the AHB Slave
Transactor if the response for this address is set
to SPLIT.
split_enable - This field is a bool type
used to enable the driving of the
HSPLIT(ahb_split) bus for this address only.
The default value is true. This attribute is only
used by the AHB Slave Transactor if the
response for this address is set to SPLIT.
Once the attribute values of this class object is
Slave Device Emulator by way of the Emulators
control port.
The following additional overloaded void write_emulator(...) methods allow a
greater degree of flexibility for cases where the user only needs to set specific attributes of
the memory space contained within the AHB Slave Device Emulator. The same argument
descriptions as above for address, data, response, wait_cycles, split_delay
and split_enable apply below where applicable.
When these methods are called, an enumerated type called WRITE is automatically set
within the class object which will indicate to the AHB Slave Device Emulator, once it
receives the object, to perform that particular write operation.
Once these methods have set the attribute values of the class object, the class object is
subsequently automatically sent to the AHB Slave Device Emulator via the Emulators
control port.
5
sc_uint<8> data,
This method will set the address and data

attributes of this class and subsequently writes
the data attribute value into the AHB Slave
Device Emulators memory space.
);
6
response_type response
This method will set the address and response

the response attribute value into the AHB Slave
Device Emulators memory space.
);
May 2005
105
Product Version 5.4

);
bool split_enable
);
sc_uint<8> data,
This method will set the address and

wait_cycles attributes of this class and
subsequently writes the wait_cycles attribute
value into the AHB Slave Device Emulators
memory space.
This method will set the address,
split_delay and split_enable
the split_delay and split_enable
attribute values into the AHB Slave Device
Emulators memory space.
response and wait_cycles attributes of
this class and subsequently writes the data,
response and wait_cycles attribute values
into the AHB Slave Device Emulators memory
space.
);
10 void write_emulator(
sc_uint<8> data,
bool split_enable

the data, split_delay and
split_enable attribute values into the AHB
Slave Device Emulators memory space.
);
sc_uint<8> data,
response_type response
This method will set the address, data and

response attributes of this class and
subsequently writes the data and response
);
May 2005
106
Product Version 5.4

sc_uint<8> data,
This method will set the address, data and

wait_cycles attributes of this class and
subsequently writes the data and
wait_cycles attribute values into the AHB
);
This method will set the address, response,

wait_cycles, split_delay and
split_enable attributes of this class and
subsequently writes the response,
bool split_enable
);
unsigned int split_delay

wait_cycles and split_delay attributes
of this class and subsequently writes the
response, wait_cycles and split_delay
);
bool split_enable

the response, split_delay and
);
This method will set the address, response

and wait_cycles attributes of this class and
subsequently writes the response and
wait_cycles attribute values into the AHB
);
May 2005
107
Product Version 5.4

bool split_enable
This method will set the address,

split_enable attributes of this class and
subsequently writes the wait_cycles,
split_delay and split_enable attribute
values into the AHB Slave Device Emulators
memory space.
);
Examples of Using the Configuration Argument Class

This section shows examples of using the configuration argument class
(ahb_slave_emulator_config_t Class) to Configure the AHB Slave Device Emulator
by way of a testbench/stimulus generator.
A testbench/stimulus generator can have access to one or many AHB Slave Device
Emulators through a uvm_control_if_t interface. Table 4-13 on page 109 , gives an
example of using the ahb_slave_emulator_config_t class methods, as described in
Table 4-12 on page 100. You configure the AHB Slave Device Emulator by way of the
uvm_control_if_t interface. In these examples emulator_config is a declaration of
the Configuration Argument Class:
ahb_slave_emulator_config_t emulator_config;
An instance of this declaration emulator_config would then take the previously created
AHB Slave Device Emulator control port as the constructor argument (this control port is
subsequently binded to an instance of the AHB Slave Device Emulator). This is shown in
Example of Using the Configuration Interface in a Stimulus Generator on page 96.
May 2005
108
Product Version 5.4

Table 4-13 Examples of using the ahb_slave_emulator_config_t class methods
Method
1
Example
Set Address 0x010 with a response value of SPLIT, a

set_reset_response_ split_delay value of five clock cycles and a
split_enable value of true.
after_use(
Also set the reset_response_after_use flag to be
reset
true, so that after the response value of SPLIT has been
);
used by the AHB Slave Transactor, the Slave Device
Emulator resets the response value to OKAY so that when
the Master that has been SPLIT regains control of the
address bus 5+1 clock cycles later, it wont be SPLIT again
for the same address value of 0x010.
void
emulator_config.set_reset_response_after_use(true);
emulator_config.write_emulator(0x010, SPLIT, 5,
true);
2
3
void
clear_emulator();
Clear the Slave Device Emulator.

emulator_config.clear_emulator();
void fill_emulator( Fill the Slave Device Emulators Memory Address range
from 0x00 to 0x03F with Random data starting from a
start_address,
data value of 0x00, with OKAY responses and two wait
end_address,
cycles.
sc_uint<8> data = 0x00;
data_generation,
byte_data,
emulator_config.fill_emulator(0x00, 0x03F, RAND,

data, OKAY, 2);
response,
wait_cycles
);
May 2005
109
Product Version 5.4

void
write_emulator(
address,
data,
response,
Set address 0x034 with a data value of 0x0100, a

response value of ERROR, two wait_cycles, zero
split_delay cycles and split_enable to be true.
emulator_arg.write_emulator(0x034, data, ERROR, 2, 0,
true);
wait_cycles,
split_delay,
split_enable
);
5
void
write_emulator(
address,
Set address 0x06C with a data value of 0x0500.

emulator_config.write_emulator(0x06C, data);
data
);
6
void
write_emulator(
Set address 0x0100 with a response value of ERROR.

emulator_config.write_emulator(0x0100, ERROR);
address,
response
);
void
write_emulator(
Set address 0x0150 with four wait_cycles.

emulator_config.write_emulator(0x0150, 4);
address,
wait_cycles
);
8
void
write_emulator(
Set Address 0x017F with a split_delay value of nine

clock cycless and split_enable to be true.
address,
emulator_config.write_emulator(0x017F, 9, true);
split_delay,
split_enable
);
May 2005
110
Product Version 5.4

void
write_emulator(
Set address 0x0200 with a data value of 0x07C, a

response value of OKAY and five wait_cycles.
address,
sc_uint<8> data = 0x07C;

emulator_config.write_emulator(0x0200, data, OKAY,
5);
data,
response,
wait_cycles
)
10 void
write_emulator(
address,
data,
split_delay,
Set address 0x025A with a data value of 0x00, a

split_delay value of five clock cycles and a
emulator_config.write_emulator(0x025A, data, 5,
true);
split_enable
)
11 void
write_emulator(
address,
data,
Set address 0x025A with a data value of 0x00 and a

response value of SPLIT.
emulator_config.write_emulator(0x025A, data, SPLIT);
response
)
12 void
write_emulator(
address,
data,
Set address 0x0300 with a data value of 0x056C and a

wait_cycles value of four clock cycles.
sc_uint<8> data = 0x056C;
emulator_config.write_emulator(0x0300, data, 4);
wait_cycles
);
May 2005
111
Product Version 5.4

13 void
write_emulator(
address,
response,
wait_cycles,
Set address 0x0378 with a response value of SPLIT, a

wait_cycles value of two clock cycles, a split_delay
value of fifteen clock cycles and a split_enable value of
true.
emulator_config.write_emulator(0x0378, SPLIT, 2, 15,
true);
split_delay,
split_enable
);
14 void
write_emulator(
address,
response,
Set address 0x0400 with a response value of SPLIT, a

wait_cycles value of three clock cycles and a
split_delay of five clock cycles.
emulator_config.write_emulator(0x0400, SPLIT, 3, 5);
wait_cycles,
split_delay
);
15 void
write_emulator(
address,
response,
Set address 0x044C with a response value of SPLIT, a

split_delay value of nine clock cycles and a
emulator_config.write_emulator(0x044C, SPLIT, 9,
true);
split_delay,
split_enable
);
16 void
write_emulator(
address,
Set address 0x0512 with a response value of ERROR and a

wait_cycles value of six clock cycles.
emulator_config.write_emulator(0x0512, ERROR, 6);
response,
wait_cycles
);
May 2005
112
Product Version 5.4

17 void
write_emulator(
address,
wait_cycles,
Set address 0x0590 with a wait_cycles value of eight

clock cycles, a split_delay value of fifteen clock cycles
and a split_enable value of true.
emulator_config.write_emulator(0x0590, 8, 15, true);
split_delay,
split_enable
);
AHB Slave Device Emulator Transaction-Level Interface

The main features of the AHB Slave Device Emulator Transaction-Level Interface are as
follows:
Transactions to the AHB Slave Device Emulator are represented as objects of a class
called ahb_slave_emulator_request_t. (For a description of this class see
Transaction Argument Class (ahb_slave_emulator_request_t Class) on page 116
below). These objects can be passed to the AHB Slave Device Emulator from the AHB
Slave Transactor during normal AHB bus operations.
A virtual push method is defined within the UVM uvm_push_if_t interface class which
can be used by a SystemC port defined in the AHB Slave Transactor to push requests
into the AHB Slave Device Emulator.
Note: , In the following Transactor request description, WRITE_DATA and
UPDATE_SLAVE are the possible values of an enumerated type contained within the
ahb_slave_emulator_request_t class object, which is sent from the Transactor to
the Emulator.
The requests that the Transactor can make to the Emulator are:
WRITE_DATA requestIn this case the Transactor writes the sampled data value
(HWDATA[DATA_BUS_WIDTH]) of the data bus, during a write transfer, to the
Emulator.
UPDATE_SLAVE requestIn this case the Transactor requests the Emulator to send
to the Transactor the attribute values (data, response, wait_cycles, split_delay,
split_enable) corresponding to the address associated with the request. In the case
of data (sc_bv<DATA_BUS_WIDTH>) transfer between the Emulator and the
Transactor, the data will be aligned to the endianess of the data bus.
The push method takes a pointer to the ahb_slave_emulator_request_t class

object as an argument. No FIFO queue is required to exchange the transaction
May 2005
113
Product Version 5.4

information between the AHB Slave Transactor and the AHB Slave Device Emulator,
since the call to the Emulator occurs in zero simulation time and returns immediately.
This interface is described below on page 114 Push Interface.
Push Interface
In this case, a push interface is where the transactor calls a method to push a request into
the component communicating with the transactor and subsequently, in zero simulation time,
receives information relating to the request back from the component.
In the case of the interface between the AHB Slave Transactor and the AHB Slave Device
Emulator, the Transactor can push a read request into the Emulator and receive back the read
value. For example, when the Transactor needs to know the particular response it should give
to a transaction received on the address bus, it calls the the push method with an
UPDATE_SLAVE enumerated type request and receives back the response value it should
give.
There are five parts to the push interface:
1. A SystemC Interface Definition, as illustrated below:
template <typename T>
class uvm_push_if_t : virtual public sc_interface, virtual public
uvm_fifo_if_t<T> {
public:
virtual bool push(T) = 0;
virtual void push_wait(T) = 0; // not applicable for Slave Emulator
};
Unified Verification Methodology (UVM) transaction interface classes are template

classes. The interface member functions take as their single argument a user-defined
class (of type T in the above example). This class type of the member function argument
will change for a different type of transactor. For AHB Slave Transactors the template type
is ahb_slave_emulator_request_t.
2. The declaration of a SystemC port in the Transactor, as illustrated below:
class ahb_slave_t : public uvm_control_if<ahb_configuration_t>, public
ahb_slave_port_if {
public:
sc_port<uvm_push_if_t<ahb_slave_emulator_request_t*>, 0> pusher;
}
The port connects an AHB Slave Transactor to an AHB Slave Device Emulator through
a transaction-level interface.
May 2005
114
Product Version 5.4

The port has a template type that is the name of the interface class. In this case the
template type is uvm_push_if_t. That type has in turn its own template parameter
which specifies the template class handled by the Emulator, in this case
ahb_slave_emulator_request_t.
The second argument in the template is the number of objects attached to the port. A
value of 0 means any number of objects. If a AHB Slave Transactor needed to be
connected to more than one emulated device, to model a hardware structure where more
than one peripheral shared a single bus interface, then the AHB Slave Transactors state
machine could selectively call more than one push method by using an array subscript
other than 0.
3. The definition of a class which inherits the SystemC interface definition (as defined in the
first item of this list). This class defines the callback function (push(...)), which is a
virtual function in the interface class.
class ahb_slave_device_emulator : public
uvm_push_if_t<ahb_slave_emulator_request_t*>,
public uvm_control_if_t<ahb_slave_emulator_config_t>,
public sc_module {
public:
ahb_slave_device_emulator() {};
~ahb_slave_device_emulator() {};
bool push(ahb_slave_emulator_request_t* push_arg );
};
4. The definition of the interface member function, where the 3response type, wait cycles
number is generated in the case of the AHB Slave Device Emulator. For example:
bool ahb_slave_device_emulator::push(ahb_slave_emulator_request_t*
emulator_arg) {
switch( emulator_arg->get_device_request_type() ) {
case: UPDATE_SLAVE
emulator_arg->set_response( get_response() );
emulator_arg->set_wait_cycles( get_wait_cycles() );
emulator_arg->set_split_delay( get_split_delay() );
emulator_arg->set_data( get_data() );
break;
}
}
5. The class containing the emulator function definition is declared, usually in the same
place (such as in a high-level module in the test bench) as the class for other stimulus
generators. For example:
May 2005
115
Product Version 5.4

public:
ahb_master_stim_gen_t master_gen; // stimulus gen. for master
ahb_slave_device_emulator_t slave_emulator; // Slave Device Emul.
}
Transaction Argument Class (ahb_slave_emulator_request_t Class)

The ahb_slave_emulator_request_t class is the argument type of the push method
defined in the uvm_push_if_t interface class.
The AHB Slave Transactor is responsible for configuring an instance of this class before it is
sent to the AHB Slave Device Emulator via a push interface type port defined in the AHB
Slave Transactor.
This port must be binded in a testbench/stimulus generator to an instance of the AHB Slave
Device Emulator. For example:
void topTestbench::end_of_construction()
{
..............................
..............................
//Get a Pointer on the Slave TVM Object and bind the Testbench abstract Port ///to
this Object.
ahb_slave_t *slv = (ahb_slave_t*) (simcontext()->find_object("top.ahbSlave"));
if(slv == NULL) { cout << "ERROR: did not find 'top.ahbSlave'\n" << endl; return; }
//Bind the AHB Slave Transactors Device Emulator push interface
//type port to an instance of the AHB Slave Device Emulator
slv->slave_device_emulator_port(slave_device_emulator);
..................................
...............................
tb_startup();
}
There are methods defined in the ahb_slave_emulator_request_t class to allow an

AHB Slave Transactor to request a specific operation to the AHB Slave Device Emulator by
way of its push interface type SystemC port. A list of these available methods are described
in Table 4-14 on page 117, including methods used specifically by the AHB Slave Device
Emulator.
May 2005
116
Product Version 5.4

Table 4-14 Methods of the ahb_slave_emulator_request_t Class
Method
void
Description
write_data(
data);
This method is used by the AHB Slave Transactor during

AHB write transfers when it needs to write data
corresponding to the sampled HWDATA bus input to the
AHB Slave Device Emulator.
This method will set an sc_bv<DATA_BUS_WIDTH> data
type attribute contained within the class object with the
sampled data value corresponding to the address value
and also sets an enumerated type WRITE_DATA
contained within the object which will indicate to the AHB
Slave Device Emulator that it has to perform the required
request, once it receives the object.
void
update_slave(
sc_uint<3> size);
This method is used by the AHB Slave Transactor when

the Transactor recognises a transaction on the address
bus and it needs to know what values to update the AHB
Slave Transactor outputs with.
This method will set the address, size attribute values of
this class object and will also set an enumerated type
UPDATE_SLAVE of this class object which will indicate to
the AHB Slave Device Emulator, once the Emulator
receives the object, that it has to update the data,
response, wait_cycles, split_delay and
split_enable attribute values of this class object
which will be subsequently read by the AHB Slave
Transactor so that the Transactor can update its HRESP,
HREADY_OUT, HSPLIT and HRDATA outputs where
applicable.
May 2005
117
Product Version 5.4

void
set_aligned_data(sc_b
v<DATA_BUS_WIDTH>
aligned_data);
This method can be used by either the AHB Slave

Transactor or the AHB Slave Device Emulator to set an
sc_bv<DATA_BUS_WIDTH> data type attribute contained
within the class object.
It is used by the Transactor to set the data value attribute
of a class object before it is sent to the Emulator during
write transfers.
It is used by the Emulator after an UPDATE_SLAVE
request has been received from the Transactor, to set the
data attribute value within the argument class equal to a
data value in memory, which can subsequently be read by
the Transactor.
void
set_response(response
_type response);
This method can be used by the AHB Slave Device

Emulator to set a response type contained within the class
object, corresponding to a value in memory after the
Transactor has requested an UPDATE_SLAVE request.
void
set_wait_cycles(unsig
ned int wait_cycles);

Emulator to set a wait_cycles type contained within the
class object.
void
set_split_delay(unsig
ned int split_delay);

Emulator to set a split_delay type contained within the
class object.
void
set_split_enable(bool
split_enable);

Emulator to set a split_enable type contained within
the class object.
May 2005
118
Product Version 5.4

void
set_big_endian(bool
big_endian);
This method can be used by the AHB Slave Transactor to

set a endianess attribute type contained within the class
object, before it issues a request to the AHB Slave Device
Emulator (lets the AHB Slave Device Emulator know the
endianess of the data bus during write and read
operations between the Transactor and the Emulator).
slave_emulator_push_r
equest_type
get_device_emulator_r
equest() const;
This method is used by the AHB Slave Device Emulator.

It returns the slave_emulator_push_request_type
request operation value that the AHB Slave Device
Emulator is to perform. Can be one of the following:
WRITE_DATA: Tells the AHB Slave Device Emulator to
write the sc_bv<DATA_BUS_WIDTH> data type attribute
value specified in the class object argument via its push
interface implementation to an address/address range
specified contained within its memory.
UPDATE_SLAVE:. Tells the AHB Slave Device Emulator
that the AHB Slave Transactor needs the attribute values
(data, response, wait_cycles, split_delay,
split_enable) for a particular address range specified
and hence to change the push interface argument class
objects attributes with these values that can subsequently
be read by the Transactor.
sc_uint<32>
get_address() const;
This method is used by the AHB Slave Device Emulator to

return the address attribute value of this class object.
sc_uint<3>
get_size() const;

return the size value attribute corresponding to the
address/address range value of this class object. It can be
one of: BYTE, HALF, WORD, 2WORD, 4WORD.
bool
get_big_endian();

return the endianess attribute value corresponding to the
endianess of the data transfer between the AHB Slave
Transactor and the Emulator.
May 2005
119
Product Version 5.4

get_aligned_data();
This method can be used by the AHB Slave Transactor or

the AHB Slave Device Emulator to return the
sc_bv<DATA_BUS_WIDTH> data value attribute
corresponding to the address/address range value of this
class object.
response_type
get_response() const;
This method is used by the AHB Slave Transactor after the

AHB Slave Device Emulator has updated the response
attribute value of the class object corresponding to the
address/address range value of the object. It can be one
of: OKAY, RETRY, SPLIT, ERROR.
unsigned int
get_wait_cycles()
const;
This method is used by the AHB Slave Transactor, after

the AHB Slave Device Emulator has updated the class
object, to return the HREADY wait_cycles attribute
value corresponding to the address/address range value
of this class object.
unsigned int
get_split_delay()
const;

object, to return the split_delay attribute value
class object.
bool
get_split_enable()
const;

object, to return the split_enable attribute value
class object.
AHB Slave Port Interface

This interface defines the signal-level interface for the Slave Transactor. This is how the Slave
transactor connects to the device under verification (DUV). Note that the port interface
includes the ahb_prot (HPROT[3:0]) and the ahb_mastlock (HMASTLOCK) signals but
there is no functionality associated with these ports within the AHB Slave Transactor.
May 2005
120
Product Version 5.4

Table 4-15 Port Interface
Port
Direction
Type
Description
ahb_addr
sc_in
sc_uint<32>
System Address Bus - HADDR[31:0]
ahb_trans
sc_in
sc_uint<2>
Master indicates current sequence,

can be NONSEQUENTIAL,
SEQUENTIAL, IDLE, or BUSY HTRANS.
ahb_write
sc_in
bool
Master indicates if transaction is a

write or read, high is write, low is read
- HWRITE.
ahb_size
sc_in
sc_uint<3>
Master indicates the size of the

transfer - HSIZE, see AMBA
specifications for details.
ahb_burst
sc_in
sc_uint<3>
Master indicates if the transfer is part

of a burst - HBURST, see AMBA
specifications for details.
ahb_prot
sc_in
sc_uint<4>
Master Indicates protection type HPROT.

Note: this port is defined but is not
used by the AHB Slave Transactor.
ahb_w_data
sc_in
sc_bv<DATA_
BUS_WIDTH>
32, 64 bit or 128 write data supplied

by Master HWDATA[DATA_BUS_WIDTH:0].
ahb_sel
sc_in
bool
Indicates Slave is active, selected HSELx.
ahb_r_data
sc_out
sc_bv<DATA_
BUS_WIDTH>
32, 64 or 128 bit wide read data from

Slave to Master - HRDATA.
May 2005
121
Product Version 5.4

ahb_ready_out
sc_out
bool
Indicates transfer has completed, or

transfer is being delayed. This output
is fed via a bus multiplexor to the bus
master that is performing the transfer.
ahb_ready
sc_in
bool
A slave must have the HREADY signal

as both an input and an output. This
input signal comes from the output of
the slaves-to-master multiplexor.
When another slave is being
accessed, this signal will indicate if
that slave is inserting wait states; this
is important when a master switches
from one slave to another .
The input version of the HREADY
signal is not explicitly mentionned in
the AMBA v2.0 document but is
described the ARM AMBA FAQ as a
required signal input. Please refer to
http://www.arm.com.
Also a Slave must only sample the
address, control signals and HSEL
when this input signal is HIGH.
Please see AMBA specifications for
details(p. 3-19).
ahb_resp
sc_out
sc_uint<2>
Response of Slave during transaction.

Responses can be OKAY, ERROR,
RETRY, and SPLIT - HRESP.
ahb_master
sc_in
sc_uint<4>
Indicates which of the 16 possible

Masters are active.
ahb_mastlock
sc_in
bool
Indicates locking of bus by Master.

Note: this port is defined but is not
currently used by the AHB Slave
Transactor.
ahb_split
May 2005
sc_out
sc_uint<16>
122
Indicates which of the 16 possible

Masters is allowed to split a
transaction.
Product Version 5.4

ahb_resetn
sc_in
bool
System Reset - Active Low.
ahb_clk
sc_in
bool
System Clock
AHB Slave Transaction Recording

The AHB Slave Transactor is able to record two kinds of transactions in two different streams:
The Slave Burst Pipelined StreamThe transaction recorded on this stream is an entire
burst of transfers.
The Slave Transfer StreamThe transaction recorded in this stream is a unique transfer
processed by a specific slave.
The Slave Burst Pipelined Stream

In the slave burst pipelined stream, the slave samples the address, control (HWRITE, HTRANS,
HSIZE, HBURST) and HSEL signals only when the input HREADY (ahb_ready) signal is high,
which means that the previous transfer has completed (see the AMBA document, section 3.8,
page 3-19). The reason behind this assertion is that it is possible that another slave is
finishing a transfer while a new transfer is driven on the bus. This is assumed throughout the
following explaination.
Transaction recording for this stream starts if the Slave has been sampled HSEL as high and
the input transfer type signal HTRANS (ahb_trans) is sampled to be NONSEQ.
Burst pipelined stream transaction recording ends:
If the Slave samples HTRANS to be IDLE, indicating that the burst has been
cancelled.
If the Slave samples HTRANS to be another NONSEQ indicating a new burst transfer
is starting (Slave ends the previous burst transaction recording and starts the new
burst transaction recording at the same time).
If the Slave samples HSEL as low.
Table 4-16 on page 124 provides a list of attributes recorded for this stream.
Figure 4-11 on page 128 shows a Simvision snapshot of Slave Burst transaction recording in
progress.
May 2005
123
Product Version 5.4

Table 4-16 Slave Burst Pipelined Stream Parent Attributes
Attribute
Value Range
Radix
Description
Slave
1-16
string
Name of the currently selected

Slave which is processing
transactions.
Start Address
0x0-0xffffffff
hex

HBURST
SINGLE, INCR,
WRAP4, INCR4,
WRAP8, INCR8,
WRAP16, INCR16
alpha

of the burst.
burstLength
0x1-0xffffffff
hex
Represents the number of

beats for the transfer to
complete. For example if the
transaction was WRAP16, then
the value for burstLength would
be 0x0010.
Note: This feature is not
currently implemented
HSIZE
BYTE, Halfword,
WORD, 2WORD
alpha

during the burst.
R/W
Write or Read
alpha

HWRITE during the burst.
May 2005
124
Product Version 5.4

Figure 4-9 Slave Burst Pipelined Stream Recording
The Slave Transfer Stream

The start of a Slave transfer recording occurs when the slave samples the address and
control signals (HWRITE, HTRANS, HSIZE, HBURST), and HSEL when the input HREADY signal
(ahb_ready) is high.
The end of the transaction recording occurs when:
A new address is sampled.
An IDLE or BUSY transfer type is received on the HTRANS(ahb_trans) signal input

to the Slave.
When the Slave samples HSEL as low.
Note: The transfer transactions and the burst transactions recorded by the slave are not the
same transactions as the ones recorded in the master and the monitor transactors (see AHB
Master Transaction Recording on page 77 and AHB Monitor Transaction Recording on
page 143). This slave recording shows what is being processed by a specific slave. It allows
showing a specific slaves point of view on what is happening on the bus, and record some
specific transfer attributes which are not recorded by the other transactors (number of wait
cycles, response type).
Table 4-17 on page 126 provides a list of attributes recorded for this stream .
Figure 4-10 on page 127 shows a Simvision snapshot of Slave Transfer transaction recording
in progress.
May 2005
125
Product Version 5.4

Table 4-17 Slave Transfer Stream Child Attributes
Attribute
Value Range
Radix
Description
HADDR
0x0-0xffffffff
hex
Address of current transfer.
HBURST
SINGLE, INCR,
WRAP4, INCR4,
WRAP8, INCR8,
WRAP16, INCR16
alpha

of the burst.
HSIZE
BYTE, Halfword,
WORD, 2WORD
alpha

during the burst.
Wait Cycles
0x0-0xffffffff
hex
Delay/No. of clock wait cycles

associated with the address
being accessed.
HRESP
OKAY, ERROR,
RETRY, SPLIT
alpha
Type of response given by the

Slave.
HWRITE
Read, Write
alpha

HWRITE during the burst.
Write Data
0x0-0xffffffff
hex
Write data associated with a

write transaction.
Read Data
0x0-0xffffffff
hex
Read data associated with a

read transaction.
burstLength
0x1-0xffffffff
hex
Represents the length of burst

determined through the value
of the hburst. This value is
undefined during bursts that
have INCR for HBURST.
Note: This feature is not
currently implemented
May 2005
126
Product Version 5.4

Figure 4-10 Slave Transfer Stream Recording
Slave Burst Pipelined Stream Parent-Child relationship

The parent transaction (SlaveTopLevelBurstTransaction) is active during the complete burst,
while the child transaction (SlaveTransferTransaction) is active during individual writes and
reads. Figure 4-11 on page 128 shows a Simvision snapshot of Slave Parent-Child
(burst_pipelined_streamSlaveTransferStream) transaction recording in progress.
May 2005
127
Product Version 5.4

Figure 4-11 Slave Burst Pipelined Stream Parent-Child Transaction Recording
AHB Monitor Transactor ( ahb_monitor_t )

The AHB Monitor transactor is a passive component which observes transactions occurring
on the AHB bus. A unique Monitor can support any Multi-Master and Multi-Slave
configurations.
Bursts, Address phases, Data phases and Compliance Errors are recorded in the
Simvision database. A set of attributes is recorded for each transaction, such as addresses,
data, transaction types, read/write, and so on.
The Monitor does a number of AMBA compliance checks on the traffic of the bus and logs
Warning messages (SCV_WARNING) or Info messages (SCV_INFO) in case of a violation of
the AMBA specification.
May 2005
128
Product Version 5.4

The AHB compliance checks performed by the Monitor Transactor are as follows:
Check that the transfer type is IDLE during reset.
Check that address is correctly aligned, according to HSIZE.
Check 1KB page boundary violations for bursts.
Check that address steps appropriately for all beats of burst.
Check that bursts of all types do not burst longer than specified by HBURST.
Check that non-INCR bursts do not end prematurely.
Check that HTRANS is IDLE on the second cycle of a non-OKAY response.
Check that HTRANS never transfers from IDLE to SEQ.
Check that HTRANS never transfers from IDLE to BUSY.
Check that HSIZE remains constant during a burst.
Check that HBURST remains constant during a burst.
Check the two cycle non-OKAY responses.
AHB Monitor Configuration Interface

This section presents the methods and parameters that enable to customize the AHB Monitor
transactor and control the level of information it generates during the simulation. In general,
the parameters are:
Monitor Transactor Configuration Parameters

AHB Monitor HDL configuration parameters on page 130, describes the configuration
parameters of the Monitor transactor when it is used with the HDL wrapper in an HDL
testbench. These parameters have to be set in the HDL testbench.
The other configuration parameters are used to configure the systemC side of the
Monitor transactor.
The ahb_configuration_t structure contains all the systemC configuration
parameters for the three transactors (Master, Slave and Monitor). Among these
parameters, some are dedicated to the configuration of the Monitor transactor.
Compliance Check Parameters
May 2005
129
Product Version 5.4

AHB Monitor Compliance Checks configuration parameters on page 131, lists and
describes the AMBA compliance check parameters that are used to configure the
compliance checks performed by the Monitor.
Transaction Recordine and Information Message Parameters

AHB Monitor output configuration parameters on page 134, lists and describes the
parameters that are used to control the transaction recording and the general information
messages generated by the Monitor.
Other SystemC Configuration Parameters

A few other systemC configuration parameters are not part of the
ahb_configuration_t structure. Additional AHB Monitor configuration parameters
on page 135 lists these parameters that are used to configure some extra features of the
Monitor.
There are a number of methods you can use to modify all these parameters from the systemC
testbench. AHB Monitor Configuration Methods on page 136 lists the methods used to set
the values of all these systemC configuration parameters for the AHB Monitor transactor and
explains how to configure these parameters from the systemC testbench.
AHB Monitor HDL configuration parameters
The first set of parameters is the HDL configuration parameter group, listed on Table 4-18 on
page 130.
Table 4-18 AHB Monitor HDL Configuration Parameters
Parameter
Description
int data_bus_width
Defines the width of the data bus
The data_bus_width parameter configures the data bus width of the AHB bus used for the
simulation. This parameter must be set in the HDL testbench. The corresponding type of
transactor systemC library (32, 64 or 128 bits bus width) has to be used for the simulation so
that the systemC transactor and its HDL wrapper use the same data bus width.
This is not a dynamic parameter and its value can not be changed during a simulation.
In the HDL top testbench module, a top_data_bus_width parameter has to be defined as
follows:
May 2005
130
Product Version 5.4

parameter top_data_bus_width = 128;
When an ahb_monitor_t object is instantiated (for example with the name

monitor_hdl_instance), the value of its data_bus_width parameter is configured as
follows in the HDL testbench:
defparam monitor_hdl_instance.data_bus_width = top_data_bus_width;
This must be done for every instance of Master, Slave or Monitor declared in the HDL
testbench.
AHB Monitor Compliance Checks configuration parameters
This is the first set of dynamic systemC configuration parameters for the Monitor. They can
be configured from the systemC testbench. These parameters are illustrated on Table 4-19
on page 131 and allow the user to control which compliance checks are performed by the
Monitor during simulation, and how they are performed. The three possible values on each
compliance check parameter are Off (0), On (1) or Expect (2).
These parameters can be modified during simulation. The default value of each of these
parameters is On (1).
If an incorrect value, one that is not 0, 1 or 2, is passed by in, the corresponding parameter
will be set to On (1) by default.
An additional boolean parameter (check_address_not_aligned_if_idle) has also
been added to control wether the address alignment with HSIZE (controlled by
check_address_not_aligned_to_transfer_size) has to be checked for IDLE
transfers or not. Its defaulf value is true, which means that, by default, the alignment of the
transfer address with HSIZE is checked for every type of transfer including IDLE transfers. If
this switch is later configured to false, the checking wont be performed for IDLE transfers,
which can be useful to avoid spurious error messages from the Monitor in case the DUV
doesnt respect strictly that minor point of the AMBA specification.
Table 4-19 AHB Monitor Compliance Check Configuration Parameters
Parameter
May 2005
Description
131
Product Version 5.4

unsigned int
check_htrans_not_idle_during_reset
Turns compliance
checks on/off/expect.
Value of this flag:
0 - Off
1 - On (Default)
2 - Expect
unsigned int
check_address_not_aligned_to_transfer_size
Turns compliance
Value of this flag:
0 - Off
1 - On (Default)
2 - Expect
Turns compliance
unsigned int
check_page_address_violation
Value of this flag:

0 - Off
1 - On (Default)
2 - Expect
unsigned int
check_incorrect_address_calculation
Turns compliance
Value of this flag:
0 - Off
1 - On (Default)
2 - Expect
Turns compliance
unsigned int
check_burst_longer_than_hburst
Value of this flag:

0 - Off
1 - On (Default)
2 - Expect
May 2005
132
Product Version 5.4

unsigned int
check_premature_end_of_non_incr_normal_burst
Turns compliance
Value of this flag:
0 - Off
1 - On (Default)
2 - Expect
unsigned int
check_htrans_not_idle_after_non_okay_response
Turns compliance
Value of this flag:
0 - Off
1 - On (Default)
2 - Expect
unsigned int
check_htrans_goes_from_idle_to_seq_busy
Turns compliance
Value of this flag:
0 - Off
1 - On (Default)
2 - Expect
unsigned int
check_hsize_changes_during_burst
Turns compliance
Value of this flag:
0 - Off
1 - On (Default)
2 - Expect
unsigned int
check_hburst_changes_during_burst
Turns compliance
Value of this flag:
0 - Off
1 - On (Default)
2 - Expect
May 2005
133
Product Version 5.4

unsigned int
check_incorrect_two_cycle_non_okay_response
Turns compliance
Value of this flag:
0 - Off
1 - On (Default)
2 - Expect
bool
check_address_not_aligned_if_idle
Turns on/off the

checking of the address
alignment with HSIZE
for IDLE transfers.
Value of this switch:
true - Checking
performed for all types of
transfers.
false - Checking is not
performed for IDLE
transfers.
AHB Monitor output configuration parameters

Some of the systemC configuration parameters are implemented to allow the user to control
the outputs generated by the Monitor directly form the testbench. Information messages and
transaction recording coming from the Monitor can be turned On or Off.
These parameters are detailed on Table 4-20 on page 134. As the other configuration
parameters, they can be modified from the systemC testbench to configure dynamically the
Monitor during a simulation (to have transaction recording only on certain testcases during a
simulation for example).
Table 4-20 AHB Monitor Output Configuration Parameters
Parameter
May 2005
Description
134
Product Version 5.4

bool info_msg
Turns On/Off the info messages generated by the Monitor.

true: The Monitor generates info messages (default).
false: The Monitor doesnt generate info messages.
Turns On/Off the transaction recording performed by the Monitor.

true: The Monitor records transactions (default).
false: The Monitor doesnt record transactions.
Additional AHB Monitor configuration parameters

Two other systemC parameters that are also implemented in the Master and Slave
transactors allow the user to control extra features of the Monitor transactor. They are detailed
on Table 4-21 on page 135.
Table 4-21 Additional AHB Monitor Configuration Parameters
Parameter
Description
bool debug
Turns On/Off the debug messages generated by the Monitor.

true: The Monitor generates debug messages.
false: The Monitor doesnt generate debug messages (default).
bool
enable
Turns the monitor On/Off during the simulation. When turned Off, the Monitor is
also reset.
true: The Monitor is On (default).
false: The Monitor is Off.
Note: The debug message generated by the Monitor transactor are for development purpose
only and should not normally be used as they convey no general information.
The enable switch allows you to turn the Monitor transactor On or Off during a simulation.
This feature can be useful to improve the performances of the simulation in case of a very
long test case where the Monitor is not needed, without modifying the testbench.
When a monitor is switched Off, all its internal parameters are reset and its pending recorded
transactions are closed.
May 2005
135
Product Version 5.4

When the monitor is turned On again, the Monitor transactor will be in a state similar to the
state following a reset.
AHB Monitor Configuration Methods
As explained before, all the systemC parameters are configured from the systemC testbench.
In the testbench, an sc_port<uvm_control_if_t<ahb_configuration_t>> object
and an ahb_configuration_t object must be instantiated for each transactor.
The ahb_configuration_t object contains all the Monitor parameters detailed on
Table 4-19 on page 131 and Table 4-20 on page 134. Each monitor in the testbench can be
configured through the methods detailed on Table 4-22 on page 136.
Table 4-22 AHB Monitor configuration Methods
Methods
Description
bool send_control(const
ahb_configuration_t &)
Updates the Monitor configuration

parameters of the
ahb_configuration_t object.
void enable_on()
Turns the enable switch On
void enable_off()
Turns the enable switch Off
bool get_enable()
Returns the enable switch value
void debug_on()
Turns the debug switch On
void debug_off()
Turns the debug switch Off
bool get_debug()
Returns the debug switch value
The configuration of the Monitor is done as shown in the following steps:

1. First, you must declare an sc_port for the Monitor:
sc_port< uvm_control_if_t<ahb_configuration_t> > monitor_port;
2. Then, a pointer to the ahb_monitor_t must be found and bound to the Monitor
sc_port:
May 2005
136
Product Version 5.4

ahb_monitor_t *monitor = (ahb_monitor_t*) (simcontext()->
find_object("top_hdl_test.monitor_hdl_instance"));
monitor_port.bind(*monitor);
This gives you an access point to the Monitor from where you can call the methods listed
in Table 4-22 on page 136.
Now you can declare an ahb_configuration_t object for the Monitor:
ahb_configuration_t monitor_parameters;
Then you can modify the configuration of the Monitor by modifying any parameter in this
ahb_configuration_t object and calling the send_control() method:
monitor_parameters.info_msg = true;
monitor_parameters.transaction_record = false;
monitor_parameters.check_htrans_not_idle_during_reset = 2;
monitor_parameters.check_address_not_aligned_to_transfer_size = 0;
monitor_parameters.check_page_address_violation = 1;
monitor_parameters.check_incorrect_address_calculation = 1;
monitor_parameters.check_burst_longer_than_hburst = 1;
monitor_parameters.check_premature_end_of_non_incr_normal_burst = 1;
monitor_parameters.check_htrans_not_idle_after_non_okay_response = 1;
monitor_parameters.check_htrans_goes_from_idle_to_seq_busy = 2;
monitor_parameters.check_hsize_changes_during_burst = 1;
monitor_parameters.check_hburst_changes_during_burst = 0;
monitor_parameters.check_incorrect_two_cycle_non_okay_response = 0;
monitor_parameters.check_address_not_aligned_if_idle = false;
monitor_port->send_control(monitor_parameters);
The parameters that havent been modified since the last configuration will remain the same
after send_control() has been called. For example, if in the systemC testbench you write:
monitor_parameters.check_incorrect_two_cycle_non_okay_response = 0;
monitor_port->send_control(monitor_parameters);
It will only modify the check_incorrect_two_cycle_non_okay_response parameter.

After a Monitor reset, or after its construction, all the parameters have the default values
given in Table 4-19 on page 131 and in Table 4-20 on page 134. The
ahb_configuration_t object has these default values as well when it is declared.
May 2005
137
Product Version 5.4

The last two parameters of the monitor, enable and debug, which are detailed in Table 4-21
on page 135, can be configured from the systemC testbench directly through the methods
described in Table 4-22 on page 136 (other than send_control()). For example:
monitor_port->enable_on();
monitor_port->debug_off();
AHB Monitor Pin-Level Interface

The pin-level interface is a collection of HDL signals contained in an HDL module and
connected to the DUV. The C++ versions of the HDL signals are contained in the Transactor
and are used to interact with the DUV. The pin-level interface is detailed in Table 4-23 on
page 138.
Table 4-23 Table of AHB Monitor Pin-Level Interface Signals
Pin
Direction
Description
ahb_clk
in
System clock
ahb_resetn
in
System Reset - active low
ahb_gnt[15:0]
in
All 16 possible HGRANTx signals. The active one

indicates that the corresponding Master has been
granted access to the bus
ahb_lock[15:0]
in
All 16 possible HLOCKx. The active one indicates

that the corresponding Master requires a lock on the
bus
ahb_req[15:0]
in
All 16 possible HBUSREQx. The active one indicates

that the corresponding Master requires use of the
bus
ahb_resp[1:0]
in
Indicates the response from the Slave - HRESP
ahb_ready
in
Indicates when the transfer has been completed HREADY
ahb_r_data[data
BusWidth-1:0]
in
Read data bus - HRDATA
May 2005
138
Product Version 5.4

ahb_w_data[data
BusWidth-1:0]
in
Write data bus - HWDATA
ahb_prot[3:0]
in
Protection control for bus access - HPROT
ahb_burst[2:0]
in
Indicates the type of the burst - HBURST
ahb_size[2:0]
in
Indicates the size of the transfer - HSIZE
ahb_write
in
Indicates if a write or a read is occurring - HWRITE
ahb_trans[1:0]
in
Indicates the type of the current burst - HTRANS
ahb_addr[31:0]
in
Address used in the read/write transaction - HADDR
ahb_sel[15:0]
in
All 16 possible HSELx. The active one indicates that

the corresponding Slave is selected
ahb_master[3:0]
in
ID Indicating which Master is selected
ahb_master_lock
in
Indicates whether or not the bus is locked by the

AHB Master
ahb_split[15:0]
in
Indicates which Slave has a split burst waiting.
Multi-Master and Multi-Slave configuration

Multi-Master and Multi-Slave configurations are supported by the Monitor. A unique Monitor
transactor is needed, and can monitor a bus with up to sixteen Master and sixteen Slaves
connected (this is the maximum value allowed by the AMBA specification).
The Monitor connection in the testbench must be correctly done to support this configuration.
The following code gives an example of the instantiation of the monitor in the verilog
testbench with two Masters (M1 and M2) and two Slaves (S1 and S2). A more graphical
example is provided in Figure 4-12 on page 141.
// Instance of the AHB Monitor Transactor
ahb_monitor_t ahb_monitor_instance (
.ahb_clk(clk),
.ahb_gnt({14b0,ahb_gnt_M2,ahb_gnt_M1}),
.ahb_lock({14b0,ahb_lock_M2,ahb_lock_M1}),
May 2005
139
Product Version 5.4

.ahb_req({14b0,ahb_req_M2,ahb_req_M1}),
.ahb_sel({14b0,ahb_sel_S2,ahb_sel_S1}),
.ahb_mastLock(ahb_mast_lock),
.ahb_split(ahb_split)
);
The ahb_gnt, ahb_lock, ahb_req and ahb_sel signals are 16-bit signals and allow the
monitor to be connected to up to sixteen masters and slaves. In this specific example (two
Masters and two Slaves), fourteen bits are connected to 0 and the two bits left are connected
to the two Masters and the two Slaves instantiated in the testbench.
In a system with multiple SPLIT-capable slaves, The AMBA specification recommends that
the HSPLIT signal from each slave should be sixteen bits in width and combined by a logical
OR with all the HSPLIT bits to provide a single resultant (AMBA 2.0 specifications, paragraph
3.12 page 3-35). This resultant signal is the one that should be connected to the ahb_split
signal input of the AHB monitor transactor.
Since the AMBA specification does not explicitly require the HSPLIT signal to be sixteen bits
wide, in a user specific AHB bus design, in case the HSPLIT signal width is smaller than
sixteen bits, the unconnected bits of the ahb_split monitor input should be forced to 0. For
example, in a two Masters configuration, if ahb_split is only two bits wide. The connection
of this signal to the monitor transactor should be:
.ahb_split({14b0,ahb_split})
A graphical example of an AHB design with n Masters, m Slaves and a Monitor is illustrated
on Figure 4-12 on page 141.
May 2005
140
Product Version 5.4

Figure 4-12 Connection of n Masters, m Slaves, and a Monitor, on an AHB bus
An example code listing is provided below. The listing shows an example of instance
declaration in the testbench for a Master (number i), a Slave (number j) and the Monitor
corresponding to the bus connection of Figure 4-12 on page 141. All the signal names are
detailed on this figure and the following declarations are the connections of the pin-level
interfaces for the three transactors.
// Instance of the AHB Master number i
ahb_master_t ahb_master_i_instance (
.ahb_clk(HCLK),
.ahb_resetn(HRESETn),
.ahb_gnt(HGRANTi),
.ahb_lock(HLOCKi),
May 2005
141
Product Version 5.4

.ahb_req(HBUSREQi),
.ahb_resp(HRESP),
.ahb_ready(HREADY),
.ahb_r_data(HRDATA),
.ahb_w_data(HWDATAi),
.ahb_prot(HPROTi),
.ahb_burst(HBURSTi),
.ahb_size(HSIZEi),
.ahb_write(HWRITEi),
.ahb_trans(HTRANSi),
.ahb_addr(HADDRi)
);
// Instance of the AHB Slave number j
ahb_slave_t ahb_slave_j_instance (
.ahb_clk(HCLK),
.ahb_ready(HREADY),
.ahb_sel(HSELj),
.ahb_addr(HADDR),
.ahb_write(HWRITE),
.ahb_trans(HTRANS),
.ahb_size(HSIZE),
.ahb_burst(HBURST),
.ahb_w_data(HWDATA),
.ahb_master(HMASTER),
.ahb_mastlock(HMASTLOCK),
.ahb_prot(HPROT),
.ahb_ready_out(HREADYj),
.ahb_resp(HRESPj),
.ahb_r_data(HRDATAj),
.ahb_split(HSPLITj)
);
// Instance of the AHB Monitor Transactor
ahb_monitor_t ahb_monitor_instance (
.ahb_clk(HCLK),
.ahb_gnt({(16-n)b0,HGRANTn,...,HGRANT1}),
.ahb_lock({(16-n)b0,HLOCKn,...,HLOCK1}),
.ahb_req({(16-n)b0,HBUSREQn,...,HBUSREQ1}),
May 2005
142
Product Version 5.4

.ahb_resp(HRESP),
.ahb_ready(HREADY),
.ahb_r_data(HRDATA),
.ahb_w_data(HWDATA),
.ahb_prot(HPROT),
.ahb_burst(HBURST),
.ahb_size(HSIZE),
.ahb_write(HWRITE),
.ahb_trans(HTRANS),
.ahb_addr(HADDR),
.ahb_sel({(16-m)b0,HSELm,...,HSEL1}),
.ahb_master(HMASTER),
.ahb_mastlock(HMASTLOCK),
.ahb_split(HSPLIT)
);
AHB Monitor Transaction Recording

The AHB monitor transactor is able to record four types of transactions in four different
streams.:
1. Burst transactions are recorded in the top_level_burst_stream (see Recording
Burst Transactions in the top_level_burst_stream on page 143).
2. Address phases are recorded on the address_phase_stream (see Recording
Address Phases in the address_phase_stream on page 147).
3. Data phases are recorded in the data_phase_stream (see Recording Data Phases
in the data_phase_stream on page 148).
4. Special transactions are defined as error transactions. They are recorded in a specific
stream (see Recording Special Transactions on the error_recording_stream on
page 150). An error transaction is recorded when an AMBA compliance violation has
been detected on the bus.
Recording Burst Transactions in the top_level_burst_stream
Any burst transferred on the bus, is recorded in this stream.
Burst transaction recording starts with the first address phase of a burst and ends after the
last data phase of this burst is complete. During a burst transaction, the monitor records
information related to the entire burst, such as: the start address, the burst type, and the
transfer size.
May 2005
143
Product Version 5.4

A burst transaction recording is illustrated on Figure 4-13 on page 144 where the first stream
at the top of the picture, represents the whole burst (top_level_burst_stream). The two other
streams below represent the address phase (recorded on the address_phase_stream, see
Recording Address Phases in the address_phase_stream on page 147) and the data phase
(recorded on the data_phase_stream, see Recording Data Phases in the
data_phase_stream on page 148).
Figure 4-13 Burst Transaction Recorded on the top_level_burst_stream.
Due to the pipelined structure of the AMBA AHB bus, two bursts can overlap each other,
which means that the first address phase of a new burst can start when the last data phase
of the previous burst is not yet complete. Therefore, two streams are needed to record
overlapping bursts. This is illustrated on Figure 4-14 on page 145 where a new
top_level_burst_stream_1 is automatically created and displayed in Simvision.
May 2005
144
Product Version 5.4

Figure 4-14 Two Overlapping Bursts on the Three Different Types of Stream.
The list of attributes recorded for each burst transaction, is detailed in Table 4-24 on
page 145.
Table 4-24 Table of Attributes Recorded for Each Burst Transaction
Attribute
Value Range
Radix
Description
Granted
Master ID
0 - 15
dec
ID of the Master currently

granted the bus.
May 2005
145
Product Version 5.4

Attribute
Value Range
Radix
Description
Burst Start
Address
0x0 0xffffffff
hex
Start address of the current

burst.
Burst Type
SINGLE, INCR,
WRAP4, INCR4,
WRAP8, INCR8,
WRAP16, INCR16
alpha
Type of burst in progress.
Transfer Size
BYTE, HALF, WORD,

2WORD, 4WORD,
8WORD, 16WORD,
32WORD
alpha
Size of each transfer for the

burst in progress.
R/W
READ, WRITE
alpha
Direction of the burst in

progress, read or write.
Transfer
Protection
opcode, data
alpha
Indicates the level of protection

of the burst.
/
user access,
privileged access
/
not bufferable,
bufferable
/
not cacheable,
cacheable
Number of
Beat Done
0 - 1024
decimal
The number of beats done in

this burst.
Number of
Beat Expected
0 - 1024
decimal
The number of beats that were

expected for this burst if the
transfer type is not INCR.
May 2005
146
Product Version 5.4

Recording Address Phases in the address_phase_stream
In this stream, each address phase of a burst is recorded. All the control signals are recorded
as attributes of an address phase.
In the address phase recorded transaction, the monitor records information related to the
corresponding beat (transfer). The address recorded on the transaction is the address of the
current beat. information related to the current transfer, such as: transfer type, burst type, and
size are recorded.
Address phase recording starts when a NONSEQ, SEQ or BUSY transfer begins. IDLE transfers
are not recorded. An example of address phase recording is shown in Figure 4-15 on
page 147.
Figure 4-15 An Example of address_phase_stream Recording
May 2005
147
Product Version 5.4

The list of attributes recorded for each address phase, is detailed in Table 4-25 on page 148.
Table 4-25 Table of address_phase_stream Attributes
Attribute
Value Range
Radix
Description
Beat Address
0x0 0xffffffff
hex
Address of the current transfer.
Transfer Type
NONSEQ, SEQ,
BUSY
alpha
Type of transfer being currently

performed.
Burst Type
SINGLE, INCR,
WRAP4, INCR4,
WRAP8, INCR8,
WRAP16, INCR16
alpha
Transfer Size
BYTE, HALF, WORD,

2WORD, 4WORD,
8WORD, 16WORD,
32WORD
alpha
Size of each transfer for the burst

in progress.
R/W
READ, WRITE
alpha
Direction of the burst in progress,

read or write.
Transfer
Sequence
LOCKED,
UNLOCKED
alpha
Indicates if this transfer is locked

or not.
Recording Data Phases in the data_phase_stream

The data phases of all the transfers done on the bus, are recorded in this stream. The control
signals as well as the data being currently sampled on the bus are recorded as attributes of
a data phase.
The transfer address corresponding to the data currently being sampled on the bus is also
recorded, making it easier for the user to read the pipelined transfers.
Examples of data phase recording are shown on Figure 4-16 on page 149.
May 2005
148
Product Version 5.4

Figure 4-16 An Example of data_phase_stream
.
Several attributes are recorded for each burst on this data_phase_stream. They are
detailed in Table 4-26 on page 150.
May 2005
149
Product Version 5.4

Table 4-26 Table of data_phase_stream Attributes
Attribute
Value Range
Radix
Description
Beat Address
0x0 0xffffffff
hex
Address of the data being

currently transferred (without the
pipeline effect).
Beat Data
0x0 0xffffffff
hex
Data currently being transferred

on the bus. (Read bus or Write
bus depending on the transfer
direction).
for a data bus width

of 32.
0x0 0xffffffffffff
ffff
for a data bus width
of 64.
Burst Type
SINGLE, INCR,
WRAP4, INCR4,
WRAP8, INCR8,
WRAP16, INCR16
alpha
Transfer Size
BYTE, HALF, WORD,

2WORD, 4WORD,
8WORD, 16WORD,
32WORD
alpha
Size of each transfer for the burst

in progress.
R/W
READ, WRITE
alpha
Direction of the burst in progress,

read or write.
Transfer
Sequence
LOCKED,
UNLOCKED
alpha
Indicates if this transfer is locked

or not.
Recording Special Transactions on the error_recording_stream

This stream is not directly related to the traffic on the bus and is used to record error
transactions when compliance violations are detected by the monitor (see Compliance
May 2005
150
Product Version 5.4

Checks on page 152). If no AMBA compliance violation is detected on the bus during
simulation, this stream will not appear in simvision.
As soon as a compliance violation is detected, an error transaction is recorded in the
corresponding clock cycle. Error transactions have no associated durations, which means
that they begin and end at the same simulation time. They are represented in the SimVision
GUI as vertical lines and contain a description attribute, which gives some explanations of the
error.
Examples of error transactions recorded in error_recording_stream, are shown in Figure 4-17
on page 151.
Figure 4-17 An Example of the error_recording_stream
The description message associated with an AMBA compliance error is also logged in the
tb.log file. An example of error transaction description is shown in Figure 4-18 on
page 152.
May 2005
151
Product Version 5.4

Figure 4-18 Error Message Description in the error_recording_stream
Compliance Checks
The AHB Monitor performs a number of compliance checks, related to the AHB Master and
AHB Slave protocol. These compliance checks are listed in Table 4-27 on page 152.
Table 4-27 Table of Compliance Checks
Check Parameter Name
Condition for an
Error
check_htrans_idle_during_
reset
HTRANS is not IDLE

during reset.
RESET ERROR: Master

HTRANS not IDLE during
RESET.
check_address_not_aligned
_to_transfer_size
HADDR is not correctly

aligned with the size
(HSIZE) of the
transfer. This
checking can be
disabled for the IDLE
transfers.
ADDRESS ERROR:
Invalid Address Offset - Not
aligned to Transfer Size.
check_page_address_violat
ion
1KB page violation

occurs.
PAGE ADDRESS
VIOLATION ERROR: 1K
page crossover. Address
stepped over 1K boundary.
May 2005
152
Error Message
Product Version 5.4


check_incorrect_address_c
alculation
Condition for an
Error
Error Message
HADDR does not

increment
appropriately.
ADDRESS STEPPING
ERROR: Wrong stepping
on this beat.
or
ADDRESS STEPPING
AFTER BUSY ERROR:
Wrong stepping on this
beat.
check_burst_longer_than_h
burst
Burst lasts longer

than specified, with a
given HBURST value.
BURST LENGTH
ERROR: Burst longer than
specified by HBURST.
check_premature_end_of_no
n_incr_normal_burst
non-INCR Burst ends

prematurely, given a
HBURST value.
BURST LENGTH TOO

SHORT ERROR: Burst
ended prematurely.
check_htrans_not_idle_aft
er_non_okay_response
HTRANS is not IDLE

on the second clock
of a two cycle SPLIT
or RETRY response.
ILLEGAL HTRANS
ERROR: HTRANS not set
to IDLE - RETRY or SPLIT
HRESP must cause
HTRANS to sequence to
IDLE.
check_htrans_goes_from_id
le_to_seq_busy
HTRANS transitions
from IDLE to SEQ or
BUSY.
ILLEGAL HTRANS
ERROR: Transition from
IDLE to NON NON-SEQ
state.
check_hsize_changes_durin
g_burst
HSIZE doesnt remain

constant during the
entire burst
transaction.
ILLEGAL HSIZE ERROR:

HSIZE is not stable for burst
duration.
check_hburst_changes_duri
ng_burst
HBURST doesnt
remain constant
during the entire burst
transaction.
ILLEGAL HBURST
ERROR: HBURST is not
stable for burst duration.
May 2005
153
Product Version 5.4


check_incorrect_two_cycle
_non_okay_response
Condition for an
Error
HREADY not correct
during the 2 cycle
non-OKAY response.
or
non-OKAY response is
not the same for both
cycles.
or
non-OKAY response is
not maintained for 2
cycles by the Slave.
or
Slave doesnt give an
OKAY response after
a two cycle RETRY or
a two cycle SPLIT.
Error Message
ILLEGAL NON OKAY
RESPONSE ERROR:
HREADY must be LOW on
a NON-OKAY response first
Cycle.
or
ILLEGAL NON OKAY
RESPONSE ERROR:
HREADY must be HIGH on
a NON-OKAY response
second Cycle.
or
ILLEGAL NON OKAY
RESPONSE ERROR:
Response not driven to
same NON-OKAY response
for two cycles.
or
ILLEGAL NON OKAY
RESPONSE ERROR: 1st
Cycle of response is
NON-OKAY and second
Cycle is OKAY.
or
ILLEGAL NON OKAY
RESPONSE ERROR:
Slave must give an OKAY
response after two RETRY
or two SPLIT Cycles.
May 2005
154
Product Version 5.4

When a compliance error is detected by the monitor the following action occur:
An error transaction is recorded in the error_recording_stream. The message

description message (as seen in the SimVision GUI) associated with this transaction is
the message given inTable 4-27 on page 152 for the corresponding error.
An SCV_WARNING exception is raised and a warning message of the following type,

followed by the error message of Table 4-27 on page 152 for the corresponding error,
is printed in the simulation log file (tb.log):
*** SCV_WARNING: AMBA COMPLIANCE VIOLATION : <ERROR TYPE> at time 510 ns in
process <monitor_instance>.do_observe_bus
A few more details can be added to the message in the log file depending on which
compliance error is detected. For example, in case of a wrong address stepping, the
following message is printed in the log file:
*** SCV_WARNING: AMBA COMPLIANCE VIOLATION : ADDRESS STEPPING ERROR at time
1330 ns in process topTestCC$ahbMonitor.do_observe_bus
Wrong Stepping on this Beat
--->
Expected Address = 0x0000003fd
--->
Actual Address
= 0x0000003fe
The complete list of compliance errors detected by the monitor during a simulation is printed
in the log file, whereas only the first detected error for each cycle can be read in simvision.
If the compliance check parameter has been set to ERROR_EXPECTED (see Table 4-19 on
page 131) then only an SCV_INFO is issued by the Monitor Transactor instead of an
SCV_WARNING.
May 2005
155
Product Version 5.4

May 2005
156
Product Version 5.4

Appendix A - References
A
You can obtain any of the documents listed in Table A-1 on page 157 in the CDSDoc on-ine
documentatuin system, at the URL given in the table, or by contacting the Cadence
Verification Platforms Group Program Office. To contact the Platforms Group, send an e-mail
to avs@cadence.com or contact your sales representative.
Table A-1 Table of Cadence Documents
Document
URL Address
TestBuilder User Guide
www.testbuilder.net
TestBuilder Reference Guide
www.testbuilder.net
Transaction Explorer User Guide
www.cadence.com
Cadence Installation Guide
www.cadence.com
You can obtain the AMBA standard specifications at the URL listed in Table A-2 on page 157.
Table A-2 AMBA Specification Resource
Document
AMBA 2.0 Specifications
May 2005
URL Address
www.arm.com
157
Product Version 5.4

May 2005
158
Product Version 5.4
AMBA Transaction Verification Model User/Reference Guide
Index
Numerics
1KB
BurstType 146
BUSY 121
129
Address 126, 148, 150

AHB Master 152
AHB Master TVM 31, 38, 39
AHB Master. 139
AHB Monitor 128, 152
AHB Monitor Parameter Group 130
AHB Monitor Transaction Recording 143
AHB Slave 152
AHB Slave TVM 31, 38
ahbAddr 121, 139
ahbBurst 121, 139
ahbClk 123, 138
ahbDataFiber 150
ahbGnt 138
ahbLock 138
ahbMaster 122, 139
ahbMasterDataFiber 148
ahbMasterLock 139
ahbMastLock 122
ahbMonitorAddrFiber 143
ahbProt 121, 139
ahbRData 121, 138
ahbReady 138
ahbReq 138
ahbResetn 123, 138
ahbResp 122, 138
ahbSel 121, 139
ahbSize 121, 139
ahbSlaveTransaction Fibe 123, 125
ahbSplit 122, 139
ahbTrans 121, 139
ahbWData 121, 139
ahbWrite 121, 139
APB Peripherals Verification 40
May 2005
C++ 138
compliance check 32
compliance checks 152
D
Delay 126
DUV 138
E
ERROR 122, 126, 129
F
fiber 145
flexibility Interface 40
H
HADDR 121, 139, 153
HBURST 121, 129, 139
HBUSREQx 138
HDL 38, 39, 138
HGRANTx 138
HLOCKx 138
HPROT 121, 139
HRDATA 121, 138
HREADY 122, 138
HRESP 122, 138
HSELx 121
HSIZE 121, 129, 139
HTRANS 121, 139
HWDATA 121, 139
HWRITE 121, 139
159
Product Version 5.4
AMBA Transaction Verification Model User/Reference Guide
StartAddress 146
IDLE 121, 129

INCR 146, 148, 150
INCR16 146, 148, 150
INCR4 146, 148, 150
INCR8 146, 148, 150
T
task level Interface 40
tools./vrm/examples/vrmamba/
run_ahb_demo 38, 39
TransferSize 146
TVM 31
TVM Interfaces 40
M
Master 121
Master TVM 31, 38
Monitor TVM 31, 129
Multi-Master 37
Multi-Master DUV Verification 38
Multi-Slave DUV Verification 39
V
vrmAhbMonitorT 128
W
WRAP16 146, 148, 150
WRAP4 146, 148, 150
WRAP8 146, 148, 150
WRITE 146, 148, 150
WriteData 126
N
netlist 38
NONSEQUENTIAL 121
O
OKAY
122
P
Pin Level Interface 120, 138
R
READ 146, 148, 150
ReadData 126
Response 126
RETRY 122, 126, 129
S
SEQUENTIAL 121
SINGLE 146, 148, 150
Single-Master 37
Single-Master Verification 38
Single-Slave 37
Single-Slave Verification 38
Slave 121, 126, 139
Slave TVM 31
SPLIT 122, 126, 129
May 2005
160
Product Version 5.4
Glossary
DUV
A Device Under Verification (DUV) is the design targeted for verification.
Pull Interface
The most efficient way for a transactor to communicate other verification components is
through callback functions. This method is called Pull since it allows the transactor to pull
data from another component. A transactor with a Pull (or callback) interface is able to
transfer the flow of program control to another verification component without the need
to create a new thread or incur the overhead of a thread context switch. Another benefit
to the Pull approach is data exchange with the transactor occurs as close to the time the
data is used as possible. A minimum amount of data queuing or perhaps none at all is
required. This makes it possible to build highly reactive test benches.
Push Interface
A Push transactor interface is where the component communicating with the transactor
calls a method to push data into the transactor, rather than having the transactor pull the
data out of the communicating component. It is possible to build a Push interface on top
of the standard Pull interface by inserting a FIFO queue between the stimulus generator
and the master transactors callback methods.The Push interface can be added to a
transactor, usually a master, when the transactor user wants their program to follow a
sequential pattern (for example, first do this, then do this, and this, and so on.).
Master Transactor
Connects a verification test program with a signal-level interface, which is part of a device
under verification (DUV). The master transactor takes a command or a data structure
from a stimulus generator and converts this information (known as a transaction) into the
signal-level protocol of the interface.
Monitor Transactor
Connects to a DUV interface and recognizes transactions. Unlike a slave transactor, a
monitor transactor only reports what it sees to a higher level verification component
(such as a response monitor or protocol checker).
May 2005
161
Product Version 5.4

Glossary
Response Checker
A verification component used to monitor transactors and determine if a DUV behavior
is what is expected. Response checkers report errors such as protocol violations by the
DUV or transaction outputs from the DUV that are incorrect..
Slave Transactor
Connects to a DUV interface. A slave transactor recognizes transactions on a signal-level
interface and responds to these transactions, under the control of the verification test, by
emulating a physical device, as if the device were actually connected to the interface.
Stimulus Generator
Generate transactions that are driven into the DUV through transactors.
Testbench
A group of verification components and a DUV. The testbench defines everything needed
to apply stimulus and check responses of a DUV in simulation.
Transaction
A transaction is the transfer of information from one design, or verification component, to
another. For example the movement of data or control information between the testbench
to the design under verification (DUV) is a transaction. A transaction usually occurs over
an interface, for example, a bus or a communications port connection, and therefore
involves the use of a bus or communication protocol. A transaction is an abstraction of
what actually takes place in hardware or in a model of hardware. For example, a
transaction might be write the value 0x1234 at address 0xffee0000. The transaction
only specifies what gets done and when, not how it gets done. How information is
transferredthe wiggling of signal wiresis at a level of detail below that of a
transaction.
Transaction-level Interface
A transaction-level interface is based on the abstraction of actual interface activity. It
reduces the amount of interface knowledge the transactor user must possess. This
abstraction simplifies the connection of verification components by encapsulating all the
necessary information about interface activity into a protocol-specific C++ class.
Transactor
With Transaction-Based Verification the test does not directly connect to the design
under verification. Instead, transactors represent the interface between the test and the
design. The test sends transaction requests to the transactors. The transactors translate
the transactions into detailed, signal-level activity. Likewise transactors observe signallevel interfaces and encode the activity seen there as transactions which can be reported
back to the test. This strategy lets you develop tests at a higher level of abstraction, so
May 2005
162
Product Version 5.4

Glossary
that you can easily create and maintain the many variations required to thoroughly test
a designs interaction with its environment.
May 2005
163
Product Version 5.4

Glossary
May 2005
164
Product Version 5.4

AMBA Transactors User and Reference Guide: Product Version 5.4 May 2005

Uploaded by

Copyright:

Available Formats

AMBA Transactors User and Reference Guide: Product Version 5.4 May 2005

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

AMBA Transactors User and Reference Guide: Product Version 5.4 May 2005

Uploaded by

Copyright:

Available Formats

AMBA Transactors User and Reference

2004 Cadence Design Systems, Inc. All rights reserved.

AMBA Transactors User and Reference Guide

Product Version 5.4

AMBA Transactors User and Reference Guide

Verification of AHB Peripherals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Product Version 5.4

AMBA Transactors User and Reference Guide

AHB 1K Line Burst Protection Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Product Version 5.4

AMBA Transactors User and Reference Guide

Product Version 5.4

AMBA Transactors User and Reference Guide

How to Use This Document

Verilog, VHDL, NC-Sim or other HDL

Product Version 5.4

AMBA Transactors User and Reference Guide

Simvision Waveform Window (Recommended)

TxE (Transaction Explorer) (Recommended)

Knowledge of AMBA AHB Protocol Specifications - (Recommended)

Linux Red-Hat 7.1

Product Version 5.4

AMBA Transactors User and Reference Guide

Northern Europe ukhelp@cadence.com

Product Version 5.4

AMBA Transactors User and Reference Guide

china_support@cadence. +8610-6848196[3]-[6] +8610-68481971

Product Version 5.4

AMBA Transactors User and Reference Guide

Transaction-Based Verification on page 6

Why move to Transaction Based Verification? on page 7

Product Version 5.4

AMBA Transactors User and Reference Guide

Design Under Verification

Product Version 5.4

AMBA Transactors User and Reference Guide

Design Under Verification

Why move to Transaction Based Verification?

Constrained random tests

The result is a more complete, more efficient verification of the design.

Product Version 5.4

AMBA Transactors User and Reference Guide

Other Sources of Information

Product Version 5.4

AMBA Transactors User and Reference Guide

Installation and Licensing on page 5

AMBA Configuration on Page 6

AMBA Transactor Construction on page 7

Installation and Licensing

The Cadence Verification Extensions (Formerly known as TestBuilder-SC)

NC-Verilog, NC-VHDL, or the Cadence mixed-language simulator

SimVision Waves (Recommended/Optional)

Transaction Explorer (TxE) (Recommended/Optional)

Product Version 5.4

AMBA Transactors User and Reference Guide

SoftLoad installs all component files in subdirectories as follows:

examplesContains an example testbench, example test case, and a run script

includeContains header files required to link in the components shared object

verilogContains the Verilog wrappers for master, slave, and monitor