WIXLIB

International Journal of Engineering Research & Technology (IJERT)ISSN: 2278-0181Vol. 2 Issue 11, November - 2013How easier to built Basic Verification Testbench using UVM compared toSystemVerilogNimesh PrajapatiDepartment of Electronics & Communication, L.D.College of Engg.Gujarat Technological University, AhmedabadAbstractKeywordsIJERTASIC verification is done to get the maximumconfidence in the correctness of DUT. Overall, morethan 70% of the time is spent on verification. So thereis a need for constructing a reusable and robustverification environment. Universal VerificationMethodology was introduced to fulfil that goal. Thisarticle describes that how easier to built the basicverification testbench using UVM compared toSystemVerilog.Figure 1 shows basic verification testbenchenvironment of DUT. A testbench that allows you toprovide a documented, repeatable set of stimuli that isportable across different simulators. A test bench canbe as simple as a file with clock and input data or amore complicated file that includes error checking, fileinput and output, and conditional testing. Testbenchmimic the environment in which the design will reside.It checks whether the RTL Implementation meets thedesign spec or not. This Environment creates invalidand unexpected as well as valid and expectedconditions to test the design.2. Basic Testbench Using SVUVM (Universal Verification Methodology), SV(SystemVerilog), DUT (Design Under Test)1. IntroductionThe purpose of a Testbench is to determine the actualcorrectness of the DUT and the goal is to ensure fullconformance with specification. The testbench createsconstrained random stimulus, and gathers functionalcoverage. The testbench includes the following steps Generate stimulus Apply stimulus to the DUT Capture the response Check for correctness Measure progress against the overall verificationgoals.SystemVerilog has become a primary language for thedesign and verification of digital hardware designs.SystemVerilog was first introduced in 2002 as anAccellera standard that specified a large number ofextensions to the Verilog-2001 Hardware DescriptionLanguage.SystemVerilog provides a very powerful mechanism togenerate random stimulus. It is based on class-objectrandomization, which means random variables of aclass-object are automatically randomized by a call tothe predefined randomize method associated with theobject. Constraints further argument the randomizationfeature. Constraints are properties that define theboundaries within which the randomization featureworks. Figure 2 shows verification testbenchenvironment using SystemVerilog.Figure 2. Verification testbench using SVFigure 1. Basic verification testbenchIJERTV2IS110828www.ijert.org2514

International Journal of Engineering Research & Technology (IJERT)ISSN: 2278-0181Vol. 2 Issue 11, November - 20132.1 GeneratorIn generator class packet elements are declared i.e.preamble, start frame, address, data, end frame etc.Constraints are also written in the same class. Figure 3shows an example of generator class.Scoreboard to compare it with actual packet. Figure 6shows an example of receiver.Figure 6. Receiver class in SV2.5 ScoreboardFigure 3. Generator class in SV2.2 TransactionIJERTIn transaction class the elements are randomized, thenmake a packet and forward it to Driver class with thehelp of Mailbox. Figure 4 shows an example oftransaction class.Scoreboard receives packet form Driver and Receiverand then compares them. Scoreboard has twomailboxes. One is used to for getting the packets fromthe driver and other from the receiver. Then the packetsare compared and if they don't match, then error isasserted. Figure 7 shows an example of scoreboard.Figure 4. Transaction class in SV2.3 DriverThe driver class translates the operations produced bythe generator into the actual inputs for the DUT. Driverand DUT are connected through interface. Driver alsosend same packet to Scoreboard for comparisonprocess. This is done with the help for Mailbox. Figure5 shows an example of driver class.Figure 7. Scoreboard class in SV3. Basic Testbench Using UVMUVM represents the latest advancements in verificationtechnology and is designed to enable creation of robust,reusable, interoperable verification IP and testbenchcomponents. It uses system Verilog as its language.UVM Class Library provides the building blocksneeded to quickly develop well-constructed ts.Figure 5. Driver class in SV2.4 Receiver (Monitor)Receiver reports the protocol violation and identifies allthe transactions. There are two types of receivers, (i)Passive and (ii) Active. Passive Receivers do not driveany signals. Active Receivers can drive the DUTsignals. Sometimes this is also referred as Monitor.Receiver and DUT are connected through interface.Receiver receives all transactions form the DUT andcombines them to form the packet. Then it sends it toIJERTV2IS110828Figure 8. Verification testbench using UVMIn UVM, the class is used as a container to representcomponents, transactions, sequences, tests, andwww.ijert.org2515

International Journal of Engineering Research & Technology (IJERT)ISSN: 2278-0181Vol. 2 Issue 11, November - 2013configurations. Because it is a class, a UVMcomponent can be extended after-the-fact in arbitraryways. An extension can add new features or can modifyexisting features.sequences. Transactions and sequences togetherrepresent the domain of dynamic data within theverification environment.3.3 SequencerIn particular, we require this extension capability sothat a test can extend a transaction or a sequence inorder to add constraints, and then use the factorymechanism to override the generation of thosetransactions or sequences. Figure 8 shows verificationtestbench environment using UVM.Sequencer is the component on which the sequenceswill run. The DUT needs to be applied a sequence oftransaction to test its behavior. So sequence oftransaction is generated and it is applied to driverwhenever it demands by the sequencer. Figure 11shows an example of sequencer class.3.1 TransactionTransactions are the basic data objects that are passedbetween components. Data item are basically the inputto the DUT. All the transfer done between differentverification components in UVM is done throughtransaction object.Figure 11. Sequencer class in UVM3.4 DriverA driver is an active entity that emulates logic thatdrives the DUT. The driver pulls transactions from itssequencer and controls the signal-level interface to theDUT.IJERTNetworking packets, instructions for processor aresome examples of transactions. From the top level testmany data items are generated and applied to the DUTso by intelligently randomizing the data items objectwe can check corner cases and maximize the coverageon the device under test. Pack, unpack, print andcompare methods are overwrite in this class. Figure 9shows an example of transaction class.A typical driver repeatedly receives a data item anddrives it to the DUT by sampling and driving the DUTsignals. For example it can generate read or writesignal, write address and data to be transferred. It is theactive part of the verification logic.Figure 12 shows anexample of driver class.Figure 9. Transaction class in UVM3.2 SequenceSequences are assembled from transactions and areused to build realistic sets of stimuli. A sequence couldgenerate a specific pre-determined set of transactions, aset of randomized transactions, or anything in between.Figure 10 shows an example of sequence class.Figure 12. Driver class in UVM3.5 MonitorA monitor is the passive element of the verificationenvironment. It just samples the DUT signal from theinterface but does not drive them.Figure 10. Sequence class in UVMIt is similar to a transaction in outline, but the baseclass uvm sequence is parameterized with the type ofthe transaction of which the sequence is composed.Also every sequence contains a body task, which whenit executes generates those transactions or runs otherIJERTV2IS110828It collects the pin information, package it in form of apacket and then transfer it to scoreboard or othercomponents for coverage information.www.ijert.orgFigure 13 shows an example of monitor class.2516

International Journal of Engineering Research & Technology (IJERT)ISSN: 2278-0181Vol. 2 Issue 11, November - 2013Figure 15 shows an example of scoreboard class.3.8 EnvironmentEnvironment is at the top of the test bench architecture,it will contain one or more agents depend on design. Ifmore than one agent is there then it will be connected inthis component. Agents are also connected to othercomponents like scoreboard in this component. Figure16 shows an example of environment classFigure 13. Monitor class in UVM3.6 AgentSequencers, drivers, and monitors can be reusedindependently, but this requires the environmentintegrator to learn the names, roles, configuration, andhookup of each of these entities. To reduce the amountof work and knowledge required by the test writer,UVM recommends that environment developers createa more abstract container called an agent. Anenvironment may contain one or more agent. Figure 14shows an example of agent class.Figure 16. Environment class in UVM3.9 TestIJERTThe test class enables configuration of the testbenchand verification components, as well as utilities forcommand-line test selection. Tests in UVM are classesthat are derived from an uvm test class. Figure 17shows an example of test class.Figure 14. Agent class in UVM3.7 ScoreboardA critical component of self checking test-benches isthe scoreboard that is responsible for checking dataintegrity from input to output. A scoreboard checksthat the DUT is behaving correctly. It keeps track ofhow many times the response matched with theexpected response and how many time it failed.Figure 17. Test class in UVM4. Comparison of SV and UVM In UVM, there are predefined functions are alreadyavailable for copy, compare, pack, unpack, print etc.If we want to use them, then directly call them fromlibrary. While in SV it is not available. We have towrite our own logic code for copy, compare pack,unpack, print etc.Figure 15. Scoreboard class in UVMIJERTV2IS110828 In UVM, the communication between the modulesis done through Ports and Exports. While in SV, Itis done through Mailboxes.www.ijert.org2517

International Journal of Engineering Research & Technology (IJERT)ISSN: 2278-0181Vol. 2 Issue 11, November - 2013 Predefined macros are available in UVM i.e. uvm info, uvm error etc. These types of macrosare not available in SV. Making the testbench using UVM takes less timecompared to making the testbench using SV.ConclusionIt can be concluded that using UVM, it is easier to builtverification testbench compared to SV. Moreover ittakes less time compared to SV. Using UVM, we candevelop testbench more reusable and perfect comparedto SV.ReferencesIJERT1. Universal Verification Methodology 1.1, Accellera,May, 20112. SystemVerilog 3.1a Language Reference ManualAccellera’s Extensions to Verilog3. http://www.testbench.co.in4. http://www.doulos.com/knowhow/sysverilog/uvm/5. Mark Glasser, “UVM: The Next Generation inVerification Methodology”, Verification Horizons,Feb-20116. John Aynsley, “Easier UVM for FunctionalVerification by Mainstream Users”, DVcon, Mar20117. Martin Keaveney, Anthony McMahon, NiallO’Keeffe,Kevin Keane, James O’Reilly, “THEDEVELOPMENTOFADVANCEDVERIFICATION ENVIRONMENTS USINGSYSTEM VERILOG”, ISSC(International SystemSafety Conference),June-20088. Rudra Mukherjee, Sachin Kakkar, “Towards anObject-Oriented Design Methodology UsingSystemVerilog”, Mentor GraphicsIJERTV2IS110828www.ijert.org2518

testbench environment using UVM. 3.1 Transaction Transactions are the basic data objects that are passed between components. Data item are basically the input to the DUT. All the transfer done between different verification components in UVM is done through transaction object. Networking packets, instructions for processor areAuthor: Nimesh PrajapatiPublish Year: 2013