IJCST Vol.
6, Issue 2, April - June 2015
SystemVerilog Based Verification Environment
for Wishbone Interface of AHB-Wishbone Bridge
1
Bhankhar Dhvani, 2Samir Shroff
1
Dept. of Electronics Engineering, Gujarat Technological University, Ahmedabad, Gujarat, INDIA
2
Director, Dept. of Electronics Engineering, Pronesis Technologies, Ahmedabad, Gujarat, INDIA
Abstract
System Verilog is the industry’s first unified Hardware Description
and Verification Language (HDVL). It became an official IEEE
standard (IEEE 1800™) in 2005 under the development of
Accellera [1]. This is the first time that constructs have been
made available to both digital design and verification engineers.
A verification environment which is based on a constrained
random layered testbench using SystemVerilog is implemented
in this paper to verify the functionality of DUT designed with
synthesizable constructors of SystemVerilog. This new verification
constructs can be easily reused for the objected-oriented feature of
SystemVerilog. In this paper, a uniform verification environment
for AHB2WB Bridge is developed using SystemVerilog after a
comprehensive analysis of the verification plan. The proposed
multi-layer testbench is comprised of generator, bridge driver,
agent, scoreboard, checker, testcases and assertions, which are
implemented with different properties of SystemVerilog.
Keywords
AHB2WB Bridge, SystemVerilog, DUT, Verification Environment,
Testbench
I. Introduction
Verification is the process used to demonstrate the functional
correctness of a design prior to its fabrication. ASIC design projects
keep the verification cost very high because of lack of flexible
verification environments that allow verification components
reuse. Design engineers have made design reuse central in
bringing the design effort’s complexity back to a manageable
size and to reduce development time and effort. Considering the
fact that verification consumes more resources than design does
in a typical design project, it would be of great value to build
verification components that are modular and reusable. One goal
of verification tool designers is in reducing the complexity of the
test bench environment.
Verilog, VHDL Hardware Description Languages (HDL) are is not
efficient enough for verification. So, System-level verification with
scalable and reusable components has been paid much attention
these days. EDA tool vendors have proposed verification language
with methodologies like SystemVerilog with VMM (Verification
Methodology Manual), AVM (Advanced Verification Manual) and
the emerging OVM (Open Verification Manual) [1].
SystemVerilog is a hardware verification language to be used
in function verification. SystemVerilog with object-oriented
programming (OOP) is considered as one of the most promising
techniques for high level function verification for current ASIC
Design. SystemVerilog has characteristics of both hardware
description languages and hardware verification language.
SystemVerilog can be used to simulate the HDL design and verify
them by high level test case. The complexity of design can be
handling by concept of a layered testbench.
120 International Journal of Computer Science And Technology
ISSN : 0976-8491 (Online) | ISSN : 2229-4333 (Print)
In this paper, the verification environment of AHB2WB Bridge
using SystemVerilog with technique is developed.
The remaining part of the paper is organized into the following
sections. In section II, a brief introduction of SystemVerilog
verification environment development of the AHB2WB Bridge
is described, while section III addresses the requirement of
constrained random layered testbench in details. The test plan
and error scenario are mentioned in section IV. The verification
results are presented and discussed in section V and conclusions
are drawn in section VI.
II. System Verilog Verification Environment Architecture
The main purpose of the verification environment is to generate
stimulus, apply that stimulus to the DUT (design under test),
and check results to verify functionality is correct or not. Then
test cases may be modified or added referring to the coverage
reports. By using SystemVerilog we can easily do this work with
developing the verification environment.
SystemVerilog is a solution to decrease the gap between design
and verification language. SystemVerilog is a Hardware design and
Verification language having features inherited from Verilog and
C++. SystemVerilog provides a complete verification environment,
employing  Constraint Random Generation, Assertion Based
Verification and Coverage Driven Verification. These methods
improve dramatically the verification process. SystemVerilog also
provides enhanced hardware modeling features, which improve
the RTL design productivity and simplify the design process.
A. Hierarchy of System Verilog Verification Environment
The SystemVerilog code generated has the following components.
The hierarchy of the code is as shown in fig. 1.
Fig. 1: Hierarchy of Developed System Verilog Environment
B. System Verilog Based Constrained Random Layered
testbench
Nowadays, the highly integrated circuit designs become
complicated. A complicated design requires a sophisticated
testbench. So, layered testbench is a key concept of modern
verification [3].
w w w. i j c s t. c o m
ISSN : 0976-8491 (Online) | ISSN : 2229-4333 (Print)
Fig. 2: Structure of the Layered Testbench
The testbench becomes more efficient and maintainable with
some dedicated different functional full-fledged components. The
layered architecture enhances the independence of the testbench
because it makes no assumption about the DUT model. Verification
environment which verifies the functionality of DUT consists of
generator, driver, agent, monitor, scoreboard, etc. Test is program
block which calls methods of environment class out sequentially
for starting simulation after creating an object of environment
class.
Besides the different functional layers, the communication and
interconnection between different layers are big concerns to
make the testbench to be interoperable system. Virtual interface
is required for communication between the testbench components.
SystemVerilog interface can be used to encapsulate the data
connecting modules as well as to define the communication
protocols between the modules. IPC constructors also can be
used for communication. There are event, event control, and
wait statement in Verilog IPC constructors. Plus, semaphore and
mailbox are added in SystemVerilog IPC constructors.
III. Development of Verification Environment
The architecture of verification environment developed for
AHB2WB Bridge is shown in the Fig.3. The different modules
of environment are explained.
The classes of environment has instance of each others. A proposed
classic testbench, which is comprised of scenario layer, functional
layer, command layer, and signal layer [4]. Accordingly, a layered
testbench for AHB2WB Bridge verification is proposed as shown
in fig. 3. Based on the functional verification requirements and
verification environment requirements along with the layered
testbench in fig. 3.
Fig. 3: The Implementation of the Proposed Testbench
w w w. i j c s t. c o m
IJCST Vol. 6, Issue 2, April - June 2015
A. Top
Top module works as the entrance of the simulation, in which
test, interface and DUT are instantiated and connected with
each other with signals. This is the top layer of the verification
environment.
B. Bridge_test
Bridge_test is a program block, which controls the overall
verification flow. As shown in Fig.3, Bridge_test starts from
constrained random testing vector generation and ends at
automatic comparison between the actual data and the expected
data. Another important functionality of Bridge_test is scheduling
the corresponding tasks of bridge to imitate the real application
environment.
C. Bridge_env
This is AHB2WB Bridge component, containing Agent. In addition,
agent should be configurable for passive/active. All checkers and
coverage are configurable to disable/enable.
D. Bridge_agent
Agent is configurable either as a active or as a passive. Active
contains Driver, Sequencer and monitor, while passive component
contains only Monitor. Agent will also pass the interface of the
DUT to each of the sub-sequent component.
E. Generator and Stimulus
Stimulus is the name given to various fields those may be randomized
with required constraints. Random Stimulus makes the packet. The
generator generates the random stimulus from random stimulus
packet class and sends this stimulus to Driver using mailbox.
Class pckt;
rand logic [15:0] Haddr;
rand logic [31:0] Hwdata;
……..
assert (p_t.randomize);
F. Driver
Driver first unpacks the packet and translates the operations
produced by the generator into the actual inputs for the DUT.
The Driver sends these signals using Virtual Interface to reset and
configure DUT. Driver also sends this stimulus to the Scoreboard
using Mailbox or Callback.
Class drive;
virtual bridge_interface
mailbox drvr2sb;
pckt gpkt;
……..
bridge_intf.Haddr <= p_t.Haddr;
bridge_intf.Hwdata <= p_t.Hwdata;
G. Monitor
Monitor will keep displays various messages according to the
operations being performed like whether it is read or write operation.
Similarly it also shows start, stop and transfer of data operations.
In the monitor code Task ‘run’ is calling start, stop, data tasks.
Task run;
Fork
Catch_start;
Catch_stop;
……..
International Journal of Computer Science And Technology   121
IJCST Vol. 6, Issue 2, April - June 2015 ISSN : 0976-8491 (Online) | ISSN : 2229-4333 (Print)

H. Bridge_interface Table 1: Verification Testplan of Wishbone Interface for Bridge

It is the mechanism to connect Testbench to the DUT just named
as bundle of wires (e.g. connecting two hardware unit blocks with
the help of physical wires). With the help of interface block, we
can add new connections easily; no missed connections and port
lists are compact. It also carries the directional information in the
form of Modport and clocking blocks.

1. Synchronization for Different Modules of Environ-

ment

(i). Clocking Blocks

A clocking block (CB) specifies clock signals and the timing and
synchronization requirements of various blocks. A CB assembles
all the signals that are sampled or synchronized by a common clock
and defines the timing behaviors with respect to the clock.
clocking cb @ (posedge clk)
default input #1ns output #1ns;
……….
………..
endclocking: cb

(ii). Modport
Modports allow a module to easily tap a subset of signals form
an interface. This provides direction information for module
interface ports and controls the use of tasks and functions within B. Testplan for Generating Error Scenario
certain modules. Modports do not contain vector sizes or data Table 2: Error Scenario
types (common error) – only whether the connecting module sees Expected
a signal as input, output, inout or ref port. no Functionality Signal condition
outcome
If Hresetn = 0 applies
IV. Testcases Implementation System should
1 for less than one cycle
not reset
Test cases are identified from the design specification: a simple period of Hclk
task for simple cases. Normally requirement in test cases becomes System reset If Hresetn = 0 applies
a test case. Anything that specification mentions with “Can do”, during the cycle System should
2
“will have” becomes a test case. Corner test cases normally take operation or in between reset
a lot of thinking to be identified. the operations
Master should
Data transmit not transmit
If Hready should pull
3 or receive or receive data
low forcefully
successfully before Hready
pull high
Operation should
Sampling If WISHBONE slave
not complete in
4 address should not sample
specific clock
synchronously address synchronously
cycle
Master should not
Cycle If Hready should pull
5 able to receive or
initialization low forcefully
broadcast data6
Write operation
If Hwrite should pull
6 should not
low forcefully
perform
Write cycle
Write operation
If ack_i should pull low
7 should not
forcefully
terminate
Read operation
If Hwrite should pull
Fig. 4: AHB2WB Verification Testcase Environment 8 should not
high forcefully
perform
Read cycle
Fig. 4. shows developed testcase environment to implement all Read operation
If ack_i should pull low
testcases for verification. 9
forcefully
should not
terminate
A. Testplan for Verification of Wishbone Interface Similarly, I implemented error scenario for all functionality of
Testcases are written to verify functionality of the DUT. AHB2WB Bridge.

122 International Journal of Computer Science And Technology w w w. i j c s t. c o m

ISSN : 0976-8491 (Online) | ISSN : 2229-4333 (Print)
V. Simulation Result
The proposed verification environment applies constrained random
technique to fulfill the configuration of verification environment
and DUT, and functional coverage is employed to make sure
that DUT has realized all the expected functional requirements.
And the automaticity of the proposed verification environment
improves efficiency of verification largely.
Fig. 5 (a) shows part of the simulation result of AHB2WB
reset functionality. Fig. 5 (b) shows write- read functionality of
AHB2WB Bridge.
Fig. 5(a): AHB2WB Reset Functionality
Fig. 5(b): AHB2WB Write-Read Functionality
Similarly, I obtained simulation result for all functionality of
AHB2WB Bridge correctly.
VI. Conclusion
In this paper, how to put up the simulation environment using
SystemVerilog is introduced. The simulation environment using
by SystemVerilog is efficient and high-performance with higher
reusability. The proposed multi-layer testbench is comprised of
driver, scoreboard, monitor and agent, which are implemented
with OOP. By using this verification environment the DUT
has been verified for its functionality. In addition, constrained
random technique is applied for higher functional coverage. The
verification result provides good evidence for the effectiveness
of the proposed verification environment.
References
[1] IEEE Standard for System Verilog, IEEE Std 1800tm 500
University Science, 1989.
[2] Martin Keavency, Anthony McMahon, et al.,“The
development of advanced verification environments using
systemverilog”, Proceedings of ISSC2008, pp. 325-330,
2008.
w w w. i j c s t. c o m
IJCST Vol. 6, Issue 2, April - June 2015
[3] Yong-Jim Oh, Gi-Yong Song,“Simple hardware verification
platform using systemverilog”. IEEE TENCON2011, pp.
1414-1417, 2011.
[4] Chris Spear,"SystemVerilog for Verification", A Guide to
Learning the Testbench, MA, Springer, pp. 15 (2006).
[5] Opencore organization,“AHB-WISHBONE BRIDGE”,
Released: July 13, 2007.
Dhvani received her B.E. degree
in Electronics and communication
engineering from Gujarat Technological
University, Ahmedabad, Gujarat, in
2013. She is pursuing her M.E. in
VLSI from Gujarat Technological
University, Ahmedabad, Gujarat,
2013-2015 batch.
Founder of Pronesis Technologies
Samir is Silicon Valley veteran with
20+ years of experience in technology
industry. Prior to founding Pronesis,
he was founder and VP Engineering
with Sibridge Technologies. He there
built teams in ASIC and Embedded
engineering and delivered engineering
solutions to customers’ world over.
Before that Samir led the ASIC team
at eInfochips and held various technical
and management positions at Broadcom, Silicon-Spice (acquired
by Broadcom), National Semiconductor and LSI Logic.
Samir’s strength lies in building large engineering teams,
developing them on technical and non-technical front and helping
them deliver world class engineering products and solutions. He
has successfully accomplished this in areas of ASIC/FPGA design
and verification, Physical design, System design, Embedded
Software development, etc.
He is very passionate about mentoring and guiding students
and young entrepreneurs. He is foodie to core and marathon
enthusiast.
He holds Masters in Electrical Engineering from California State
University, Northridge, USA and Bachelors from SP University,
India.
International Journal of Computer Science And Technology   123