UVM ARCHITECTURE FOR VERIFICATION

Transcription

1 International Journal of Electronics and Communication Engineering & Technology (IJECET) Volume 7, Issue 3, May June 2016, pp , Article ID: IJECET_07_03_004 Available online at Journal Impact Factor (2016): (Calculated by GISI) ISSN Print: and ISSN Online: IAEME Publication UVM ARCHITECTURE FOR VERIFICATION Pankaj S.Vitankar Department of Electronics & Telecommunication Engineering Vishwabharati Academy s College of Engineering, Ahmednagar, India Dr. A. K. Kureshi Savitribai Phule University of Pune, Pune, India ABSTRACT The System Verilog UVM promises to improve verification productivity while enabling teams to share tests and test benches between projects and divisions. This promise can be achieved; the UVM is a powerful methodology for using constrained randomization to reach higher functional coverage goals and to explore combinations of tests without having to write each one individually. Unfortunately the UVM promise can be hard to reach without training, practice and some significant expertise. Verification is one of the most important activities in the flow of ASIC/VLSI design. Verification consumes large amount of design flow cycle & efforts to ensure design is bug free. Hence it becomes intense requirement for powerful and reusable methodology for verification. The Universal Verification Methodology (UVM) is a powerful verification methodology that may be used to verify a wide range of design sizes and types. UVM is derived from other methodology like VMM, OVM, erm. It is useful to verify designs in any language like Verilog, VHDL, System Verilog. Reusable verification environment is possible using UVM & hence saving considerable time in Verification cycle. This paper talks about the architecture of environment using UVM. It also focuses on terms & ways used in Verification using UVM. Key words: ASIC, VLSI, Simulation, Verification, erm, OVM, VMM, UVM Cite this Article: Pankaj S.Vitankar and Dr. A. K. Kureshi, UVM Architecture for verification, International Journal of Electronics and Communication Engineering & Technology, 7(3), 2016, pp [email protected]

2 Pankaj S.Vitankar and Dr. A. K. Kureshi 1. INTRODUCTION The Universal Verification Methodology, also referred to as UVM [1], is designed to have verification of ASIC [2], full custom. It is also helpful to verify FPGA based designs. All the constructs and capabilities of UVM may not be useful to one project rather it depends on the project, hence the name Universal. UVM base class libraries [3] provide the common platform for verification engineer to develop complex test bench. There are often multiple classes, methods or macros those are basic constructs to develop testbench.uvm Class Reference Manual documents all of these classes but which class to use is not much clear. Some of them are for internal use of the UVM methodology. The goal of this paper is learning and adopting UVM. Paper also suggests architecture of test bench [4] using preferred classes for developer. Verification is important part of VLSI Design. History shows failures of chips due to lack of proper verification strategy [5]. The statistics also shows that around 70% of total time for chip specs to manufacture process is required for verification. Due to increasing need of reducing time to market, time required for verification need to reduce. Reduction in time for verification can happen through reusability. That means the stuffs already developed for verification should be reused for current scope of verification. Maximum is the reusability minimum time required for verification. There are many methods suggested by different EDA vendors. Some of such well known methodologies include erm (e Reusable Methodology) [6], introduced by Verisity & later adopted by Cadence. erm requires knowledge of e language & Specman tool [7]. Other methodologies like OVM (Open Verification Methodology) [8] and VMM [9] are introduced by Synopsys. There become need to have tool independent methodology & should be universal across. This gives the UVM (Universal Verification Methodology) which supported by Cadence, Mentor Graphics as well as Synopsys. The UVM becomes interesting due to tool independent. The base code of UVM is System Verilog [10]. 2. SCOPE & SYSTEM DESIGN The scope of this paper is approach to develop verification environment using UVM. The required components definitions, there use & to reach to testbench development. Idea here is to demonstrate efficient way of developing UVM testbench. To make UVM testbench automated so that it can catch RTL bugs without manual efforts. Such developed UVM testbench is fast enough. Number of transfers/stimuli may be generated with UVM testbench without much manual efforts. UVM testbench captures functional coverage [11] and is measure of verification. Almost all required features and utilities of UVM are demonstrated. 3. UVM TEST BENCH ARCHITECTURE UVM libraries are huge set of classes, macros [12]. It is the first step for verification engineer to select proper classes for his/her verification components development [13]. Once selected proper classes, verification engineer need to implement those components as per the requirement. Fig. 1 shows UVM testbench Architecture components and suggests UVM classes to be used for the development of those components [email protected]

3 UVM Architecture for verification Figure 1 UVM test bench Architecture All complex test benches may be architected as shown in the figure with little or more modification depending on project complexity. As shown in the figure the environment should be instantiated in the test case. This makes easy for configuration of environment with respect to test case. The environment may consist of one or more agents depending on interface protocol supported by DUT. All agents have similar architecture and consist of one or all of monitor, driver, sequencer and sequences. UVM scoreboard is used for data checking. 4. EXAMPLE OF COMPONENT CODE The code will depend on UVM guidelines. Approach is taken to make more reusable. This paper also covers scoreboard and coverage. Environment code using two agents would look like (full code is not mentioned here) class mem_env extends uvm_env; mem_env_config mem_env_cfg; mem_1_agent mm_1_agent; mem_2_agent mm_2_agent; mem_1_reg_predictor mm_1_reg_predictor; mem_2_reg_predictor mm_2_reg_predictor; mem_env_vir_sequencer mm_env_vir_sequencer; uvm_component_utils(mem_env) 31 [email protected]

4 Pankaj S.Vitankar and Dr. A. K. Kureshi function new(string name, uvm_component parent); super.new(name, parent); endfunction //Not all code shown here :::::::::::::::::::::::::: :::::::::::::::::::::::::: endclass 5. RESULTS With UVM test bench, functional coverage can be achieved. Typical UVM test bench with coverage definition & test cases are the main outcome of this effort. UVM log reports, waveform and functional coverage numbers are importance in verification field. Fig. 2 shows UVM log report if there is no any bug in the DUT. Corresponding waveform is shown in Fig. 4. Please note that with UVM testbench number of stimuli can be generated automatically. Fig.4 is snapshot of waveform of such number of stimulus generated. Figure 2 UVM test bench report without any RTL bug Fig. 3 indicates UVM log report for captured RTL bug. Encircled portion in red color indicates the actual bug. In this case, data written to memory and data read from memory from same address is different. Expectation is to have same data. Report shows expected data is `d12 but received is `d13. Corresponding waveforms for this report are shown in Fig. 5 and Fig. 6. Write operation to memory as seen from Fig.5 is to address `d0 with data `d12. Fig. 6 shows read operation from memory to address `d0. As seen from waveform read data is `d13. As seen we get ready log report from UVM test bench and we may save considerable time compare to analyzing waveform manually [email protected]

5 UVM Architecture for verification Figure 3 UVM test bench report with RTL bug Figure 4 Waveform without RTL bug 33 [email protected]

6 Pankaj S.Vitankar and Dr. A. K. Kureshi Figure 5 Waveform for write transfer Figure 6 Read (Bug: Written Data & Read Data is not same) Functional coverage is measure of verification. Fig. 7 shows functional coverage status before UVM testbench is run. Figure 7 Functional Coverage before UVM test bench run Fig. 8 shows some improvement in functional coverage as we run few test cases. The status shows that we have not yet covered all functionality and there is still need of more test cases to run targeting uncovered portion [email protected]

7 UVM Architecture for verification Figure 8 Functional Coverage as UVM Testbench run Fig. 9 shows achievement of our target of 100% functional coverage. This may require number of test cases to run. If our definition of functional coverage complete, we may conclude of verification activity after achieving 100% functional coverage. Please note that there is also need of achieving code coverage to conclude on verification activity. Code coverage is simulation tool dependent and hence not discussed in this paper. Figure 9 Final Functional Coverage achieved from UVM Testbench 6. CONCLUSION UVM is a rich and capable class library that has evolved over several years from much experience with real verification projects large and small, and SystemVerilog itself is a large and complex language. As a result, although UVM offers a lot of powerful features for verification experts, it can present a daunting challenge to Verilog and VHDL designers who want to start benefitting from test bench reuse. With UVM testbench, functional coverage can be achieved. Typical UVM testbench with coverage definition & testcases are the main outcome of this effort. The showcase of waveform & functional coverage numbers to indicate its importance in verification field 35 [email protected]

8 Pankaj S.Vitankar and Dr. A. K. Kureshi The UVM Committee is to be congratulated for producing such an extensive and useful implementation of the UVM class library. UVM delivers on its goals of enabling the creation of modular reusable verification components, environments and tests. However, it is important to realize that when using UVM, most of the implementation of the library is dedicated to infrastructure and support of the relatively small set of features that Test Writers, Environment Writers and Sequence Writers will actually use. Indeed, the set of features identified in this paper consists of 10 classes, 30 methods and 7 macros that users need to be familiar with, in order to use UVM (in addition to proper SystemVerilog coding and general use-model approaches). When compared to the 357 classes and 1037 unique methods (938 functions and 99 tasks) that comprise UVM1.2, this means that UVM users really only need to learn 3% of UVM (2% of classes and 3% of methods) to be productive. Given the anecdotal feedback from many current and prospective UVM users that UVM is too complicated and too hard to learn, this paper should serve to allay those fears to some degree. Those feelings surely are exacerbated when one considers that the UVM Reference Manual, which is the official documentation for UVM, includes documentation for such a large number of classes and methods that will never (and in reality were never meant to) be deployed by UVM users. Perhaps the Accellera UVM Working Group could use this as an opportunity to streamline the UVM Specification to focus on including only the user-facing API in the version that it contributes to the IEEE. ADVANTAGES Better Performance in terms of CPU time and memory usage. Much easier debugging Reusability of base classes, methods, environment Easier to synchronize the communication between verification components Very much structured testbench Fixed run flow because of UVM phases Easy to prepare the code Lesser time to build the testbench APPLICATIONS 1. The Universal Verification Methodology (UVM) is a powerful verification methodology that was architected to be able to verify a wide range of design sizes and design types 2. The Universal Verification Methodology (UVM) is a standardized methodology for verifying integrated circuit designs. 3. UVM (Universal Verification Methodology) is a library which is used in SystemVerilog language to provide automation in various fields. Thus it can't be compared in a "versus SystemVerilog" mode cos it extends the capabilities of the systemverilog language [email protected]

9 UVM Architecture for verification REFERENCES [1] Universal Verification Methodology (UVM) 1.1 User guide by accellera [2] Michael Smith, Application Specific Integrated Circuits Pearson Education Asia [3] Universal Verification Methodolog (UVM) 1.2 Class by accellera [4] Rich Edelman Mentor Graphics Fremont, CA Shashi Bhutada Mentor Graphics, Los Angeles, CA An approach to automating UVM testbench writing. [5] H. Foster. Redefining Verification Performance (part 2), August 2010 [6] e Reusable Methodology, Cadence [7] Incisive Enterprise Specman Products, Verification automation from block to chip to system levels, Cadence [8] OVM-SC Library Reference Version 2.0.1, February, 2009., Cadence Design Systems, Inc [9] VMM user guide, Synopsys, Inc [10] SystemVerilog 3.1a Language Reference Manual, Accellera s Extensions to Verilog [11] J. Bergeron. Writing Testbenches: Functional Verification of HDL models. Kluwer Academic Publishers, [12] A. Erickson. Are OVM & UVM Macros Evil? A Cost-Benefit Analysis. In Proceeding of Design and Verification Conference (DVCON), Mar [13] Vijayakumar Suvvari and M.V.H. Bhaskara Murthy, VLSI Implementation of Huffman Decoder Using Binary Tree Algorithm, International Journal of Electronics and Communication Engineering & Technology, 4(6), 2013, pp [14] Mr. Nitin S. Sonar and Dr. R.R. Mudholkar, Implementation of Data Error Corrector Using VLSI Technique, International Journal of Electronics and Communication Engineering & Technology, 5(5), 2014, pp [15] Advanced UVM in the real world, Mark Litterick Jason Sprott Jonathan Bromley 37 [email protected]