IJCST Vol. 6, ISSue 2, AprIl - June 2015 ISSN : 0976-8491 (Online) | ISSN : 2229-4333 (Print)

w w w . i j c s t . c o m 120 InternatIonal Journal of Computer SCIenCe and teChnology

SystemVerilog Based Verification Environment for Wishbone Interface of AHB-Wishbone Bridge

1Bhankhar Dhvani, 2Samir Shroff1Dept. of Electronics Engineering, Gujarat Technological University, Ahmedabad, Gujarat, INDIA

2Director, Dept. of Electronics Engineering, Pronesis Technologies, Ahmedabad, Gujarat, INDIA

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

KeywordsAHB2WB Bridge, SystemVerilog, DUT, Verification Environment, Testbench

I. IntroductionVerification 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.

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 ArchitectureThe 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 EnvironmentThe 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 testbenchNowadays, 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].

IJCST Vol. 6, ISSue 2, AprIl - June 2015

w w w . i j c s t . c o m InternatIonal Journal of Computer SCIenCe and teChnology 121

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

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_testBridge_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; ……..

IJCST Vol. 6, ISSue 2, AprIl - June 2015 ISSN : 0976-8491 (Online) | ISSN : 2229-4333 (Print)

w w w . i j c s t . c o m 122 InternatIonal Journal of Computer SCIenCe and teChnology

H. Bridge_interface 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 BlocksA 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). ModportModports 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 certain modules. Modports do not contain vector sizes or data types (common error) – only whether the connecting module sees a signal as input, output, inout or ref port.

IV. Testcases ImplementationTest cases are identified from the design specification: a simple task for simple cases. Normally requirement in test cases becomes a test case. Anything that specification mentions with “Can do”, “will have” becomes a test case. Corner test cases normally take a lot of thinking to be identified.

Fig. 4: AHB2WB Verification Testcase Environment

Fig. 4. shows developed testcase environment to implement all testcases for verification.

A. Testplan for Verification of Wishbone InterfaceTestcases are written to verify functionality of the DUT.

Table 1: Verification Testplan of Wishbone Interface for Bridge

B. Testplan for Generating Error Scenario Table 2: Error Scenario

no Functionality Signal condition Expected outcome

1

System reset

If Hresetn = 0 applies for less than one cycle period of Hclk

System should not reset

2

If Hresetn = 0 applies during the cycle operation or in between the operations

System should reset

3Data transmit or receive successfully

If Hready should pull low forcefully

Master should not transmit or receive data before Hready pull high

4Sampling address synchronously

If WISHBONE slave should not sample address synchronously

Operation should not complete in specific clock cycle

5 Cycle initialization

If Hready should pull low forcefully

Master should not able to receive or broadcast data6

6

Write cycle

If Hwrite should pull low forcefully

Write operation should not perform

7 If ack_i should pull low forcefully

Write operation should not terminate

8

Read cycle

If Hwrite should pull high forcefully

Read operation should not perform

9 If ack_i should pull low forcefully

Read operation should not terminate

Similarly, I implemented error scenario for all functionality of AHB2WB Bridge.

IJCST Vol. 6, ISSue 2, AprIl - June 2015

w w w . i j c s t . c o m InternatIonal Journal of Computer SCIenCe and teChnology 123

ISSN : 0976-8491 (Online) | ISSN : 2229-4333 (Print)

V. Simulation ResultThe 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. ConclusionIn 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.

[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 TechnologiesSamir 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.