Roles and Responsibilities of Verification Language

Journal of VLSI Design Tools & Technology ISSN: 2249-474X (online), ISSN: 2321-6492(print) Volume 5, Issue 3 www.stmjournals.com

Roles and Responsibilities of Verification Language, Verification Methodology and Verification Tool for Design Verification of a DUT Rakhi Nangia1*, Neeraj K. Shukla2 1

Xinoe Systems Pvt. Ltd., Sector 18, Electronic City, Gurgaon, Haryana, India VLSI Group, Department of Electrical, Electronics & Communication Engineering, ITM University, Gurgaon, Haryana, India

2

Abstract Verification of a design is as important as the design itself to make it work in a practical scenario. Verification phase is an important phase in system-on-chip (SoC) design cycle and used to take 70–80% of the total design time. A verification environment may be prepared simply using a hardware verification language (HVL) only without using any methodology or using a HVL with verification methodology. The question arises that if there is a core language designed specially to do verification of a design along with design then why do we need a methodology for verifying a design? Are there loop holes in the language? Does the language not suffice to write an efficient testbench? The answer lies somewhere in the middle that role and responsibilities are different for a language and a methodology. We can say that there are many advantages of using a methodology to create verification environment than a language alone, however we can not ignore the importance and role of a verification language for verification purposes. Here we will talk about different aspects of a verification language that is SystemVerilog (SV) and a methodology that is Universal Verification Methodology (UVM). We will discuss about SV and UVM only among HVL and verification methodologies because these are the latest ones being used in the industries for verification purposes. We will also discuss the role of verification tool for verification of a design. Keywords: verification, testbench, system-on-chip (SoC), base class library (BCL), domainspecific languages

*Author for Correspondence E-mail: [email protected]

INTRODUCTION SystemVerilog (SV) is the language that has been adopted widely for verification purposes. However, in the absence of libraries its use is limited without a methodology. On the other hand, we can say universal verification methodology (UVM) has enjoyed widespread adoption because of rich set of base class libraries (BCLs), and support of major tool vendors but can we think upon a methodology without a language. Thus we can say that the two are lobster for each other, i.e., one completes another. The role and responsibilities of SV and UVM are related but different for both. Actually in practical scenario, verification with SV or verification with UVM is one and the same thing for many verification engineers. A methodology is nothing but use and application of a language in an structured way to make verification an

easy task and to reduce the time to build a testbench, so that verification of a design can be done in much lesser time than 70–80% of total design cycle. The paper covers the introduction and literature review of the SV and UVM and work reported in this domain. The paper presents a small description of SV and its role and responsibilities for verification, its capabilities as a verification language and its inabilities of challenges faced as a verification language. The paper talks about a little of verification methodologies, the UVM, its role and responsibilities, benefits of using UVM to set a verification environment, and role of EDA tools for verification.

LITERATURE REVIEW SV was developed by Accellera as an extension to the Verilog Hardware Description Language-2001 IEEE standard. Standard

JoVDTT (2015) 1-8 © STM Journals 2015. All Rights Reserved

Page 1

Roles and Responsibilities of Verification Language, Methodology and Tool

1800-2012 is the latest one. UVM was developed by verification community and UVM 1.0 was released by Accellera in 2011. Latest released version is UVM 1.1 and UVM 1.2 is going to be released soon. UVM was not built from scratch but come up from other verification methodologies like advanced verification methodology (AVM), universal reuse methodology (URM), verification methodology manual (VMM), and open verification methodology (OVM). It was developed by many industry experts and EDA vendors. According to Ref. [1], SV is efficient to meet user needs but has limited macro capabilities and lacks metaprogramming facilities and BCLs, while UVM has BCLs and built-in library functions that provides a powerful toolkit to the user so that it can be applied very efficiently for all types of verification problems. SV alone does not have standard for VIP creation and use [2]. Apart from SV, many methods are there but they require expensive retraining and conversion cost. VIP creation using a methodology lowers verification costs and improves the quality of the design and meets various requirements of system-on-chip (SoC) verification [3]. The verification components as well as test scenarios can be reused from application to application as there are configurable verification components with no change in their source code [4]. A layered and modular verification environment can be built with the facilities provided in UVM. Most of the complex designs have configuration registers to do various tasks like reset the design or set any output vector etc. UVM has a very good facility to model the registers through its corresponding UVM model [5]. UVM also has phasing scheme that is needed to create the steps necessary to execute the testbench [5]. UVM 1.2 release is going to divide these phases into subphases to provide standard for time consuming reset, configuration and run phases [2]. UVM provides transaction level modeling that is very useful to build reusable verification components. A verification environment can be reused with minimal changes with configuration, constraints, checkers and coverage [6].

Nangia and Shukla

HARDWARE VERIFICATION LANGUAGES Simulation-based functional verification of hardware designs has its own dedicated languages. An hardware verification language (HVL) is a programming language used to verify a design written in hardware description language (HDL). An HVL generally has features of object oriented programming languages like C++ as well as features of HDLs. Many HVLs like System C, e and VERA had been used to verify a design. Later on part of VERA was combined with verilogHDL to give birth to SV. SystemVerilog for Verification It is possible to design ASIC using any language like very high speed integrated circuit HDL (VHDL) or Verilog HDL or any other HDL and to do its verification using SV but the difference in syntax and structure between the languages used for designing and verification makes the interaction difficult between a design engineer and a verification engineer, i.e., by using SV for design and testbench both; it is easier to connect the two and make communication between them. Role and Responsibilities of SystemVerilog SV is a unified hardware specification, design and verification language that is being supported by almost all HDL simulators without any additional overhead. It is a core language that has been designed by incorporating the features of many domainsspecific languages (like associative arrays, queues and string etc of scripting language, garbage collection of Java and Vera) and has the goods of all to aim for performance and usefulness and not the simplicity. To write a testbench, higher level of programming features are needed that SV provides and it is able to test the design at all levels of abstraction. As SV is not a domain specific but a combination of many domains so it leads to express the same concept in multiple ways to obtain the best performance [7]. Capabilities of SystemVerilog Capturing hardware features like concurrency, events, and timing, along with software features like user-defined data-type structures, dynamic arrays and queues and storage, SV is capable to support verification. Assertions,

JoVDTT (2015) 1-8 © STM Journals 2015. All Rights Reserved

Page 2

Journal of VLSI Design Tools & Technology Volume 5, Issue 3 ISSN: 2249-474X (online), ISSN: 2321-6492(print)

interfaces, modports, coverage and constraint random features make the SV unique in itself. Assertions are statements that specify the design intent that needs to be verified. Constraints are statements restricting random number generation to a legal solution space as stimulus to DUT. Because of interfaces it is easy to add and delete signals in the testbench without error possibilities. Interface construct that can have variables, tasks, functions and processes also make transaction-level modeling possible [7]. Reuse concept of object-oriented programming that is supported by SV is the base of all verification methodologies with that only one can extend the base class from the BCLs. Modularization mechanism much more than basic OOP makes SV fit for verification. However because of certain limitations, reusable verification environment is not possible with features provided by the language alone. Inabilities or Challenges of SystemVerilog Functional verification of complex designs requires dedicated programming constructs, tool set and features. Lack of libraries and toolkits has limited the application of SV for practical verification challenges, and because of this one vendor’s VIP would be unusable for other vendor. SV also does not support metaprogramming that is the ability of a language to write a program that write or manipulate other programs or themselves as their data. Reflection that is a form of metaprogramming is possible in domainspecific languages those supports real macros and do part of the work at runtime rather than at compile time is not supported by SV. The language does not offer phasing scheme that is good to have for verification. Common math functions, I/O operations and data structures manipulations that are needed to prepare fast verification environment are not supported by SV. Nature of reuse facility that is supported by SV to do verification is different from classical software application domains. So it puts a question on SV that does reuse concept serves as well for reuse in verification domain, as these techniques do not scale in accordance and results in code complexity for verification.

VERIFICATION METHODOLOGIES A methodology is simply application of tools and languages in an effective manner. There are many methodologies brought in verification market from time to time by different companies. Some of these are:  Universal Reuse Methodology (URM)  Advanced Verification Methodology (AVM)  Verification Methodology Manual (VMM)  Open Verification Methodology (OVM)  Universal Verification Methodology (UVM) A methodology makes verification very fast as most of the verification components can be reused. We can say that a methodology uses architecture to make the verification environment that increases reusability. One has to make changes according to functionality. Here we will mainly talk about UVM as it is the latest one being used in the industries. Universal Verification Methodology (UVM) UVM is a verification methodology for functional verification [4, 8]. UVM was created by Accellera based on open verification methodology (OVM) version 2.1.1. UVM mainly uses simulations to do functional verification of the digital hardware. UVM environment has reusable verification components (UVC), and is considered as a methodology of constrained random, coverage-driven, verification (CDV) [9]. CDV combines test cases generation, self-checking testbenches, and coverage metrics to reduce the time that is needed to verify a design [10]. A verification component is extended and configured as per requirement. UVM has SV BCLs which provides all the building blocks we need to quickly develop well-constructed, reusable, verification components and test environments as shown in Figure 1. The UVM library consists of base classes, many utilities, and macros [2, 10]. Components may be encapsulated and instantiated hierarchically and are controlled through an extendable set of phases to initialize, run, and complete each test.

JoVDTT (2015) 1-8 © STM Journals 2015. All Rights Reserved

Page 3

Roles and Responsibilities of Verification Language, Methodology and Tool

UVM Classes UVM library has the following classes:  Component classes for building testbench components like generator/driver/monitor etc.  Reporting classes for logging.  Factory for object substitution.  Synchronization classes for managing concurrent process.  Policy classes for printing, copying, recording, packing, and unpacking of uvm_object based classes.  TLM classes for transaction level interface.  Sequencer and sequence classes for generating realistic stimulus.  Macros which can be used for shorthand notation of complex implement. UVM Features UVM provides a method of testbench, i.e., how to use the SV tools to create effective, reusable and scalable testbenches. UVM provides BCLs and macros that are open source and are supported by many vendors. UVM provides many features to develop a reusable test environment. The component hierarchy provides a basic skeleton for the testbench. UVM testbench has a number of class objects that are connected hierarchically. The top is a component that is created by UVM. Top module consists of test and DUT. The test object instantiates the environment and configures the environment for a particular test. There may be multiple tests, each of which configures the environment for that particular test. The environment has one or more agents. Agents have the verification components that generate stimulus to the DUT and monitor the DUT behavior. One agent may have sequencer, driver and the other agent may have monitor, checker and scoreboard etc. So the basic structure of all verification environments is fixed and it increases reusability of the environment. In UVM there are many options of reporting a message. The user can specify actions based on message verbosity and severity. UVM provides a configuration database that is a common area for storing the values and user can retrieve it from the same area when needed. Transaction level modeling (TLM) makes transfer of information from a producer to consumer by a task or function. There are three ways of data

Nangia and Shukla

transfer between components. Producer (initiator in this scenario) pushes data to consumer (target in this scenario) using TLM PUT port. Consumer (initiator in this scenario) pulls data directly from producer (target in this scenario) using TLM GET port. Producer and consumer both are initiator and uses a FIFO as a target. In UVM, factory methods are used to change the type of object at the run time. In addition to infrastructure features UVM provides communication channels for analysis that observe the activities in DUT and record it, make determinations and provide feedback for coverage analysis. Analysis components are like monitor, coverage collector, scoreboard etc. The most important is that, generation of tests is independent of the environment that makes the behavior separate from structure. User wants to be able to change the entire transaction dynamically, i.e., at the run time without changing the environment. UVM Phases In UVM rather than writing a component’s behavior in one large task, its stages are divided into small tasks and functions. All components have construction, run-time and cleanup stages. These are subdivided into substages. These stages are called UVM phases which are controlled by UVM. The construction phase executes at zero simulation time and consists of build phase, connect phase, end of elaboration phase and start of simulation phase. Then the run phase follows construction phase. Cleanup phase executes at the end of simulation time and has subphases those are extract phase, check phase, report phase and final phase. All function phases but build phase are bottom up phases which means that child phase method is called first and then the parent’s phase method. All task-based phases are concurrent. In addition user can also define and add its own phases. Benefits of UVM UVM uses transaction level interfaces for connecting verification components in the environment and provides added features using which objects in the environment can be modified during the run time. Building the testbench environment using UVM have many

JoVDTT (2015) 1-8 © STM Journals 2015. All Rights Reserved

Page 4

Journal of VLSI Design Tools & Technology Volume 5, Issue 3 ISSN: 2249-474X (online), ISSN: 2321-6492(print)

advantages like reusability, lesser time to build testbenches, better synchronization among verification components, better simulation statistics, simple debugging of code and the most important same testbench architecture and run phases. Benefits of UVM are visualized in Figure 1. An environment prepared using UVM give better performance in terms of memory usage and CPU time. UVM provides much more robust debugging facilities as messages reporting can be done with its severity level, category and verbosity level [11]. So message reporting can be done in a managed way. Moreover, the verification components and methods are modular and can

be reused across different designs and even across different design teams. UVM also provides TLM ports those can be parameterized to the type of transaction to synchronize the communication among components [11]. The most important of UVM is that it has a well-defined testbench structure and topology that can not be changed. This standardization of testbench structure makes the environment more reusable from project to project. The execution flow of testbench is determined by built-in phases and subphases those make execution order fixed during simulation.

REUSABILITY SIMPLE DEBUGGING SYNCHRONIZATION STRUCTURED TESTBENCH

Benefits of UVM COMMON TESTBENCH RUNFLOW LESSER TIME TO BUILD TESTBENCH PROGRAMMING EASE

Fig. 1: Benefits of UVM. Role and Responsibilities of UVM Today’s tools are very efficient with their simulators, emulators, and formal property checker but still tools alone are not enough to manipulate the data and turn into useful information. SV provides constrained random simulation, assertions, formal verification and functional coverage. Tools and technologies bring together with a methodology is the way to do functional verification of a design efficiently and

effectively. Thus we can say that because of many reasons like complex designs, time to market, better communication among companies and also within the company, verification experts have defined some common classes and functions which are definitely required to build testbenches and have formed one library and this BCLs with defined functions etc. is called UVM. These base classes and its functions can be extended as per our requirement.

JoVDTT (2015) 1-8 © STM Journals 2015. All Rights Reserved

Page 5

Roles and Responsibilities of Verification Language, Methodology and Tool

VERIFICATION TOOLS With several million gates SoC designs, simulation performance and memory requirement become critical. If the design encompasses thousands or millions of gates, simulating a design, and running all the test cases can take up large amount of debugging and verification time. Also to get the most out of simulation, the data collection and analysis algorithms must be very robust. Traditional simulators were very complex as they combine timing, initialization, and functional

Nangia and Shukla

verification into a single process, which seriously impact the simulation time. Today’s verification tools are of high performance and support 64-bit platform and many languages that enable engineers to spend less time in the simulation phase. One way to enhance simulation performance is by speeding up the simulation through the use of more efficient code as using a methodology. The second method is to employ more efficient simulation technique using an efficient simulator.

Verification Language (SYSTEM VERILOG) Assertions

Coverage Interface

Constraints

VERIFICATION SUCCESS

Verification Methodology (UVM)

EDA Tool (QUESTASIM)

Base Class Librries

Constraints solver Algorithms

Coding Style

Assertion Engine

Layered Structure

Simulator

Run Flow

User Interface

Fig. 2: Role of Language, Verification Methodology and Verification Tool for Verification of a Design.

JoVDTT (2015) 1-8 © STM Journals 2015. All Rights Reserved

Page 6

Journal of VLSI Design Tools & Technology Volume 5, Issue 3 ISSN: 2249-474X (online), ISSN: 2321-6492(print)

Role of EDA Tool for Verification So far we have discussed about verification language and methodology, but can we talk about verifying a design without a verification tool. The answer is NO. Verification of a design can not be completed without a good verification tool. A verification engineer can prepare the verification environment using a methodology and a verification language but to run this environment, a compiler, a simulator and many more solving algorithms are needed, that are provided by the tool only. The source program is compiled, elaborated and then simulated. Parsing, a part of compilation phase is done by a program called parser that receives input in the form of source program instructions and breaks them into parts like objects and methods and their attributes. During compilation the program is checked for any syntax error. Instantiation and connectivity between instantiated components is made during elaboration phase and the source program is checked for connection errors. After compilation and elaboration the source program can be simulated and checked for any run time error. Moreover the size of design that can be handled depends upon the tool being used for verification purpose. Size of a design is a function of number of gates, number of assertions and design’s state levels. Figure 2 shows a layout of the roles of language, methodology and the tool while doing verification. These when work together, result in verification success. A testbench has assertions, constraints, coverage constructs etc to stimulate the DUT and monitor the response from the DUT. These assertions, constraints, and coverage are worked upon by the tool. Different tools have different algorithms to work on these and to solve constraints. So one of the factors defining speed of simulations of the tool is the algorithms used by the tool for different constructs. A constraints solver algorithm works on constraints. Similarly Assertion Engine work on assertions present in the verification environment. Coverage is judged by the coverage collector and so on. A good simulator provided by a good verification tool speeds up the simulations and plays an important role in running an efficient verification environment.

CONCLUDING REMARKS/SUMMARY We have discussed about SV, UVM and verification tool, their capabilities, their role play and responsibilities in verification of a design. SV being a design and verification language is sufficiently expressive to model a design at various abstraction levels as well as provides OOPs capabilities to prepare a testbench of multiple layers. SV provides netlist and register transfer domains to represent a design and also provides constructs for coverage, I/O functions and debugging to build a testbench. Concurrent processes with event options, constrained random stimulus, assertions and finite state expression handling also makes the language ideal for preparing a testbench. But lack of libraries and toolkit makes SV direct use limited for verification of a design. To utilize the capabilities of SV and drastically reduce the time spent on verifying a design, one needs to make a well-defined structure and run flow of a testbench that is much more modular and reusable across different designs, across different projects, from company to company and from industry to industry, and that leads to a verification methodology. Last but not the least, role of tool cannot be ignored that make it possible to handle large designs, to speed up the simulation and much more. From it we can conclude that even there are verification methodologies, we cannot ignore the importance of core language. Yes it is beneficial to go with UVM instead of going only with SV, but the role of SV and verification tool are equally important at their places.

ACKNOWLEDGEMENT The authors are grateful to their organizations for their help and support.

REFERENCES 1. Jonathan B. If SystemVerilog Is So Good, Why Do We Need the UVM? Sharing Responsibilities between Libraries and the Core Language. Forum on Specification and Design Languages (FDL); 2013 Sep 24–26; Verilab Ltd. 1–7p. 2. Accellera Systems Initiative. Accellera System Initiative Releases UVM 1.2. California, USA: Accellera System Initiative Inc.; 2014 Jun 24.

JoVDTT (2015) 1-8 © STM Journals 2015. All Rights Reserved

Page 7

Roles and Responsibilities of Verification Language, Methodology and Tool

3. Young-Nam Y, Jae-Beom K, Nam-Do K, et al. Beyond UVM for practical SoC Verification. Proceedings of the 2011 International SoC Design Conference (ISOCC); 2011 Nov 17–18 Nov 2011; Jeju. 158–62p. 4. Aynsley J. UVM Verification Primer. Hampshire, UK: Doulos; 2010 Jun. Available from: http://www.doulos.com/kno whow/sysverilog/uvm/tutorial_0/ 5. Glasser M. UVM: The Next Generation in Verification Methodology. Wilsonville, OR: Mentor Graphics Corporation; 2011 Feb 4. Available from: http://s3.mentor.com/public _documents/whitepaper/resources/mentorpa per_65287.pdf 6. Tanja C. Universal Verification Methodology (UVM)-based SystemVerilog Testbench for VITAL Models. Wilsonville, OR: Mentor Graphics Corporation; 2011 Dec 13. 7. Flake P. Why SystemVerilog? Proceedings of the Forum on Specification and Design Languages (FDL); 2013 Sep 24–26; Lewes, UK. 1–6p. 8. Jain A, Bonanno G, Gupta H, et al. Generic SystemVerilog Universal Verification Methodology Based Reusable Verification Environment for Efficient Verification of Image Signal Processing IPs/SoCs. Int J VLSICS. 2012; 3(6): 13–25p. 9. Accellera System Initiative. Universal Verification Methodology (UVM) 1.1 Users Guide. California, USA: Accellera System Initiative Inc.; 2011 Jun. 10. Accellera System Initiative. Universal Verification Methodology (UVM) 1.1 Class Reference. California, USA: Accellera System Initiative Inc.; 2011 Jun. 11. Nangia R, Shukla NK. Functional Verification of I2C Core using SystemVerilog. IJEST. 2014; 6(4): 31–44p.

Nangia and Shukla

her Master of Technology (M.Tech) in VLSI Design at ITM University, Gurgaon (Haryana), India. She has completed B.Tech in Electronics and Communication Engineering from Aligarh Muslim University, Aligarh (U.P.), India in 2003. She has worked in LRDE, DRDO, Bangalore, India in 2003 and then in VLSI R&D Industries—Logic Eastern and Virage Logic International (now Synopsys) from 2006 to 2009. She has also worked as an Assistant Professor in Manav Rachna University, Faridabad, India and in other Engineering Colleges from 2009– 2012. Her interest areas are digital system design, ASIC design, VLSI testing and verification. Neeraj K. Shukla (IETE, IE, IACSIT, IAENG, CSI, ISTE, VSI-India), an Associate Professor in the Department of Electrical, Electronics & Communication Engineering, and Project Manager—VLSI Design at ITM University, Gurgaon (Haryana), India. He received his Ph.D from UK Technical University, Dehradun (Uttarakhand), India in Low-Power SRAM Design and M.Tech (Electronics Engineering) and B.Tech (Electronics & Telecommunication Engineering) degrees from the J.K. Institute of Applied Physics & Technology, University of Allahabad, Allahabad (Uttar Pradesh), India in the year 1998–2000, respectively. He has more than 50 publications in the journals and conferences of national and international repute. His main research interests are in Low-Power Digital VLSI Design and its Multimedia Applications, Digital Hardware Design, Open Source EDA, Scripting and their role in VLSI Design, and RTL Design.

AUTHOR BIBLIOGRAPHIES Rakhi Nangia, Assistant Manager at Xinoe System Pvt. Ltd., Gurgaon (Haryana), India working in the area of VLSI Design-Verification using SystemVerilog and UVM. She has done

JoVDTT (2015) 1-8 © STM Journals 2015. All Rights Reserved

Cite this Article Nangia R, Shukla NK. Roles and Responsibilities of Verification Language, Verification Methodology and Verification Tool for Design Verification of a DUT. Journal of VLSI Design Tools and Technology. 2015; 5(3):

Page 8