clifford e. cummings heath chambers · 2018-06-20 · world class systemverilog & uvm training...

World Class SystemVerilog & UVM Training

SystemVerilogVirtualClasses,Methods,InterfacesandTheirUseinVerificationandUVM

Clifford E. Cummings Heath Chambers Sunburst Design, Inc. HMC Design Verification [email protected] [email protected] Provo, UT, USA Albuquerque, NM, USA www.sunburst-design.com

ABSTRACT

ThispaperdescribesSystemVerilogvirtualclasses,virtualmethodsandvirtualinterfaces,howtheycanbeusedinverificationandhowtheyareusedinUVM.Thispaperthendescribeshowvirtualmethodsenablepolymorphismforuseinverificationincludingtheconceptsofupcastinganddowncasting.Thispaperalsodescribespurevirtualmethodsandwhythepurekeywordisuseful,includinganexamplefromtheUVMbaseclasses.Thispaperincludesusefulguidelinesregardingtheuseofvirtualclasses,methodsandinterfaces.

SNUG-2018 Silicon Valley, CA

Voted Best Presentation 2nd Place

SNUG2018

Page2 SystemVerilogVirtualClasses,Methods,Interfaces Rev1.0 ‐TheirUseinVerificationandUVM

TableofContents1. Introduction.......................................................................................................................................................................4

1.1 ToolsandOSversions......................................................................................................................................4

2. Classes..................................................................................................................................................................................4

3. Virtualclasses...................................................................................................................................................................4

4. Methods...............................................................................................................................................................................5

5. VirtualMethods................................................................................................................................................................5

6. Extendedandderivativeclasses...............................................................................................................................7

7. Upcasting&Downcasting............................................................................................................................................7

8. Purevirtualmethods..................................................................................................................................................16

8.1 UVMpurevirtualmethodexample.........................................................................................................17

9. VirtualInterfaces..........................................................................................................................................................19

9.1 VirtualInterfacesvsStaticInterfaces....................................................................................................21

9.2 VirtualInterfaceUsageinUVM.................................................................................................................22

10. Summary&Conclusions.......................................................................................................................................25

11. Acknowledgements................................................................................................................................................25

12. References..................................................................................................................................................................26

13. Author&ContactInformation...........................................................................................................................26

SNUG2018


TableofFiguresFigure1‐UVMvirtualdo_compare()methodincludedintheuvm_objectbaseclass 5

Figure2‐UVMtransactionclasses 7

Figure3‐Declaretwobaseclasshandlesandtwoextendedclasshandles 9

Figure4‐Constructtheb1baseclassandsettheavalue 10

Figure5‐Illegaltocopyor$castabaseclasshandletoanextendedclasshandle 10

Figure6‐Constructthee1extendedclassandsettheaanddatavalues 11

Figure7‐Copythee1extendedobjecthandletotheb2baseclasshandle 11

Figure8‐Re‐constructthee1extendedclassobject‐b1stillpointstotheolde1object 12

Figure9‐Theb2basehandlecannotbeusedtoaccessextendedobjectdataormethods 12

Figure10‐$casttheb2handletothee2handle‐Thisisnowlegal 13

Figure11‐UVMdo_copy()virtualmethod 13

Figure12‐Non‐virtualclassmustoverrideapurevirtualmethodfromavirtualclass 16

Figure13‐Non‐virtualclassnotrequiretooverrideapurevirtualmethodifoverriddeninavirtualclass 17

Figure14.VirtualInterfaceBlockDiagram 19

TableofExamplesExample1–test_classespackage 8

Example2‐Upcastinganddowncastingtestmodule 9

Example3‐do_copy()methodimplementedwithdowncasting 14

Example4‐Transactionexamplewithdo_copy()implementedusingdowncasting 15

Example5‐Partialuvm_subscribercode 18

Example6‐Partialcommonscoreboardpredictorcode 18

Example7‐InterfaceInstantiationandConnection 20

Example8‐VirtualInterfaceDeclarationandAssignment 20

Example9‐VirtualInterfaceAccesses 21

Example10‐OVMStyleVirtualInterfaceConnection 23

Example11‐UVMStyleVirtualInterfaceConnection 24

SNUG2018


1. IntroductionVirtual classes, virtualmethods and virtual interfaces are important tools in the construction ofpowerful verification environments. The Accellera 2003 SystemVerilog Standard[9] added thesecapabilities to the Verilog/SystemVerilog language, and they officially became part of the IEEESystemVeriloglanguagestartingwiththeIEEEStd1800‐2005[3].

TheUniversalVerificationMethodology(UVM)[6]isaclasslibraryandmethodologythattakesfulladvantage of virtual classes, methods and interfaces. UVM does not add any new keywords orcapabilitiestotheSystemVeriloglanguage,butusesexistingcapabilitiestoputtogetherapowerfulverificationmethodology.IfasimulatorsupportsthefullSystemVerilogclass‐basedcapabilities,anengineercanrunUVMwithoutanyadditionallicenses.

To fully understand howUVMworks, engineers need to understand the SystemVerilog "virtual"featuresdescribedinthispaper.

1.1 ToolsandOSversions

TheexamplesinthispaperwererunusingthefollowingLinuxandSynopsystoolversions:

64‐bitLinuxlaptop:CentOSrelease6.5

VCSversionK‐2015.09‐SP1_Full64

Runningvcsrequiredthecommandlineswitch-full64

Withoutthe-full64commandlineswitch,VCScompilationwouldfailwiththemessage:g++: /home/vcs/linux/lib/ctype-stubs_32.a: No such file or directory make: *** [product_timestamp] Error 1 Make exited with status 2

2. ClassesSystemVerilog classes can have data members (often called properties in other class‐basedlanguages) and methods (or built‐in subroutines). The SystemVerilog class method types arefunction,voidfunction andtask.Whenconsideringwhichmethod type touse, engineersshould generally use function and void function methods unless the method consumessimulationtime,thenataskshouldbeused.Allthreemethodtypescancallafunctionorvoidfunction,buttaskmethodscanonlybecalledanothertask,soiftaskmethodsareused,onlyanothertaskcancallthem.AquickscanoftheUVMclasslibrariesshowsthatonlyUVMmethodsthatconsumetimearedeclaredastaskmethods.

Guideline#1: Classmethodsshouldbefunctionandvoidfunction.Onlyusetaskwhenthemethodconsumessimulationtime.

3. VirtualclassesAvirtualclass is a class declaration that has thevirtual keyword preceding theclasskeyword.

Virtual classes cannot be constructed (new()‐ed) directly. Any attempt to new()–construct avirtualclassobjectwillgiveacompilationerror.This is trueofanycomputer language thatallowstheequivalentofvirtualclassdeclarations.

Virtualclassesareclasses thatmustbeextended inorder touse thevirtualclass functionality.A

SNUG2018


virtualclasscouldbeatop‐levelbaseclassoranextensionofanothervirtualclass.

Virtualclasslibrariesareassembledtoserveastemplatesforaspecificpurpose.MostoftheclassesintheUVMclasslibraryaredefinedasvirtualclasses,whichmeansausercannotbothdeclarehandlesoftheUVMbaseclassesandconstructalocalobjectofthesame.ThereareafewnotableexceptionsintheUVMclasslibrary, includingtheuvm_sequencer(whichissometimesdirectlydeclared and constructed in UVM testbench examples) and the uvm_driver (which probablyshould havebeen avirtual class sincewe can think of no useful examples that could directlyconstructandreasonablyusetheuvm_driverbaseclassobject).

Inpractice, almost all user‐definedUVM testbenches arebuilt fromuser‐defined classes that areextensions of the UVM component classes. All user‐defined transactions are extensions of theuvm_sequence_item virtual class and all user‐defined sequences are extensions of theuvm_sequencevirtualclass.

TheUVMbaseclasslibraryisasetoftemplatefilesthattheuserextendstobuildaUVMtestbenchandsetof tests (transactionsandsequences). Ifauserhad tobuildup theentireUVMtestbenchenvironment fromscratch, itwouldneverhappen.There issomuch functionality included in theUVMbaseclassesthatwasputtherebyverysmartverificationengineersfrommultipleend‐userandEDAcompanies,andmostuserswillneverfullyunderstandeverythingthattheUVMclasslibrarymakespossible.

4. MethodsMethodsinclassesarebuilt‐insubroutinesandasalreadynotedtheyaredefinedasfunctions,voidfunctionsandtasks.

Anextendedclasscanoverridethebaseclassmethods,butwhenanextendedclasshandleisassignedtoabaseclasshandle,callingthemethodusingthebaseclasshandlewillstillexecutetheoriginalbase‐classmethod,unlessthebase‐classmethodwasdefinedtobeavirtualmethod(seeSection5).

Acommonmisconceptionisthatvirtualclassmethodsarevirtualbydefault,butthatisnottrue.Inordertodefineavirtualmethodinavirtualclass,themethodstillhastousethevirtualkeyword.

5. VirtualMethodsSystemVerilog class methods can be either non‐virtual or virtual. Virtual methods include thevirtualkeywordbeforethefunctionortaskkeyword.Classeswithnon‐virtualmethodsfixthemethodcodetotheclassobjectwhenconstructed.Virtualmethodfunctionalityissetatrun‐time,whichallowsextendedclasshandlestobeassignedtobaseclasshandlesandrun‐timemethodcallsusingthebaseclasshandlewillexecutetheextendedclassmethodfunctionality.Thisisapowerfulfeaturethatiscalledpolymorphism.

Everyclassmethodhassomethingcalledthemethodprototype,whichisbasicallytheheaderofthefunction or task. The uvm_object base class includes the virtual function definitionshowninFigure1.

virtual function bit do_compare (uvm_object rhs, uvm_comparer comparer); return 1; endfunction

Figure1‐UVMvirtualdo_compare()methodincludedintheuvm_objectbaseclass

SNUG2018


TheprototypeofthevirtualfunctioninFigure1istheheadercode:

virtual function bit do_compare (uvm_object rhs, uvm_comparer comparer);

Thisvirtualmethodprototypeincludesfiverequiredelements:(1)thereturntypeisbit,(2)theargumentdirectionsforbothargumentsareinput(withoutadirectionkeywordinSystemVerilog,inputisthedefault),(3)therearetwoinputarguments,(4)theargumenttypesareuvm_objectanduvm_comparer,(5)theargumentnamesarerhsandcomparer.Anymethodextendedfromthisvirtualfunctionmustusethesesameexactfiveelements.Extendingavirtualmethodrequiresstrictmethodargumentcompatibility.Theextendedvirtualmethodprototypemustbeidenticaltothe base class virtual method prototype. The easiest way to ensure that the extended methodprototypeiscorrectistocopythebaseclassvirtualprototypeintothederivativeclass.

Becausevirtualmethodprototypesare identicalbetweenbaseclassesandderivativeclasses, it isguaranteedthatanycalltoabaseclassvirtualmethodwillsucceed,evenifaderivativehandlewasassignedtothebaseclasshandle.

Guideline#2: DeclareSystemVerilogclassmethodstobevirtualmethodsunlessthereisaverygoodreasontoprohibitmethod‐polymorphism.

AquickscanofUVMclasslibrarymethodsshowsthatthevastmajorityofmethodsarevirtualmethods.

Althoughnotacommonpractice,abaseclasscanhaveanon‐virtualmethodandanextendedclasscanoverride thatmethodwithavirtualmethod.On theotherhand, ifabaseclasshasavirtualmethod,itisnotpossibletooverridethevirtualmethodwithanon‐virtualmethodinanextendedclass.Onceamethodisdeclaredtobevirtual,allextendedoverridesofthatmethodwillstillbevirtual,withorwithoutthevirtualkeyword.ThiscanbeabitconfusingsincewecannotfindasingleexampleintheUVMbaseclasseswhereanoverriddenvirtualmethodinanextendedclassusesthevirtualkeyword.

InUVM,althoughnotuniversallytrue,itisaprettygoodassumptionthatallextendedmethodsarevirtualmethods,eventhoughthevirtualkeywordisnotpresent.

Many important uvm_object methods, such as copy(), do_copy(), compare(),do_compare(),convert2string(),etc.,arenon‐virtualmethods.Usersarehighlydiscouragedfromoverridingthecopy(),compare()andsimilarcommontransactionmethods.Thecopy(),compare() and other common transaction methods call user‐defined do_copy(),do_compare(),andotherpre‐defineddo_method()methodswhicharecalledbythecopy(),compare(), etc.methods. Users should not override the non‐do variety of thesemethodswithvirtual methods. See Cummings[1] for 72 pages of mind‐numbing fun that describes how thesemethodsandfieldmacroswork!)

With this basic understanding of virtual methods, the question is, what makes virtual methodsvaluable andwhy dowe care?An important part of understanding the value of virtualmethodsrequirestheusertounderstandupcastinganddowncastingdescribedinSection7.

SNUG2018


6. ExtendedandderivativeclassesAn extended class uses theextends keyword to extend the specified base class. If there is anextended class from another extended class, the second‐level extended class is referred to as aderivativeclass,oraderivativeofthebaseclass.

AnexamplefromtheUVMclasslibraryisshownbelow.

Figure2‐UVMtransactionclasses

uvm_transaction is an extended class of the uvm_object base class. At the same time,uvm_transaction, uvm_sequence_item and uvm_sequence are all derivatives ofuvm_object.Itshouldalsobeclearthatuvm_sequenceisbothanextendedclassandaderivativeclassofuvm_sequence_item.

7. Upcasting&Downcasting"Upcastingiscastingtoasupertype,whiledowncastingiscastingtoasubtype.Upcastingisalwaysallowed,butdowncastinginvolvesatypecheckandcanthrowaClassCastException."[7]

Toparaphrasethisdescription,anyextendedorderivativeclasshandlecanbecopiedtoabaseclasshandle, but only some base class handles can be copied to an extended class handle andSystemVerilogrequiresatype‐checkbeforeallowingthelatter.

Baseclasshandlescanonlyaccessdatamembersandmethodsthataredeclaredinthebaseclass,evenifanextendedhandle,withadditionaldatamembersandmethods,iscopiedtothebaseclasshandle.Sinceextendedclassesalreadycontainthebaseclassdatamembersandmethods,itisgiventhatcallingmethods in thebaseclasscould findanequivalentmethod fromtheextendedhandlecopiedtothebasehandle.

Abaseclasshandlecannotbecopiedtoanextendedclasshandle.Anyattempttocopyabasehandletoanextendedhandlewillcauseacompilationerrorsimilarto,"**Error:Illegalassignment…Typesarenotassignmentcompatible."

SNUG2018


Thefollowingtest_classespackage,showninExample1,containsaclassbasedefinitionandaclassextdefinition.TheclassdefinitionsinthispackageareusedinthetestmoduleshowninExample2.

package test_classes; class base; bit [7:0] a; function void showit; $display("BASE(%m): a=%2d", a); endfunction function void seta(bit [7:0] din); a = din; endfunction function bit [7:0] geta(); return(a); endfunction endclass class ext extends base; bit [7:0] data; // Inherit: base::bit [7:0] a; // Inherit: base:: function void seta(bit [7:0] din); // Inherit: base:: function bit [7:0] geta; function void showit; // Overrides base::showit $display(" EXT(%m): data=%2d a=%2d", data, a); endfunction function void setdata(bit [7:0] din); data = din; endfunction function bit [7:0] getdata(); return(data); endfunction endclass endpackage

Example1–test_classespackage

ThemoduletestcodeshowninExample2includesafewlinesthathavebeencommentedout.Eachoftheselinescausedcompilationerrorsasdescribedinthecommentsshownattheendofthesameline.Thisexampleshowsupcastinganddowncastinginpractice.SnippetsofthiscodealongwithexplanationsareshowninFigure3‐Figure10.

SNUG2018


module test; import test_classes::*; base b1, b2; ext e1, e2; bit e1good, e2good; bit [7:0] m_data; initial begin b1 = new(); b1.seta(4); b1.showit(); // e1 = b1; // Error ... types not assignment compatible e1good = $cast(e1, b1); // ILLEGAL assignment - $cast fails-returns 0 if (!e1good) $display("b1->e1 cast failed"); e1 = new(); e1.seta(2); e1.setdata(6); e1.showit(); b2 = e1; b2.showit(); e1 = new(); e1.seta(9); e1.showit(); // b2.setdata(9); // Error ... setdata() not in b2 // m_data = b2.getdata(); // Error ... getdata() not in b2 // e2 = b2; // Error ... types not assignment compatible e2good = $cast(e2, b2); // LEGAL assignment - $cast passes if (e2good) $display("b2->e2 cast PASSED!"); e2.showit; end endmodule

Example2‐Upcastinganddowncastingtestmodule

Figure 3 shows the declaration of twobase class handles (b1 andb2 ) and two extended classhandles(e1ande2).Thesehandlesareinitiallynull.

Figure3‐Declaretwobaseclasshandlesandtwoextendedclasshandles

SNUG2018


InFigure4,theb1baseclassobjectisconstructed,andthea‐variableissetto4.Thentheshowit()methodiscalledanddisplaystheoutputshownatthebottomofthefigure.

Figure4‐Constructtheb1baseclassandsettheavalue

InFigure5,anattemptwasmadetocopytheb1baseclasshandletothee1extendedclasshandle.Thisisanillegalattemptatdowncastingandisacompilationerror.Thenanattemptwasmadeto$casttheb1handletothee1handlebutthe$castfails,sotheif‐testcausesthedisplayedfailuremessageatthebottomofthefiguretobeshown.

Figure5‐Illegaltocopyor$castabaseclasshandletoanextendedclasshandle

SNUG2018


InFigure6,thee1objectisconstructedandthea‐valueanddata‐valueareset,thenthecontentsofthee1objectaredisplayedusingtheshowit()methodandthosecontentsareshownatthebottomofthefigure.

Figure6‐Constructthee1extendedclassandsettheaanddatavalues

InFigure7,thee1extendedobjecthandleiscopiedtotheb2baseclasshandle.Itisalwayspossibletocopyanextendedhandletoabaseclasshandlebecausebaseclassdatamembersandmethodshavebeeninheritedbytheextendedclass,soitispossibletousethebaseclasshandletocallinheritedbaseclassdatamembersandmethods.Thisisupcastingandisalwayslegal.

Figure7‐Copythee1extendedobjecthandletotheb2baseclasshandle

SNUG2018


InFigure8,thee1objectisre‐constructedandthea‐valueisset,whilethedata‐variableretainsitsdefaultvalueof0.Thenthecontentsofthee1objectaredisplayedusingtheshowit()methodandthosecontentsareshownatthebottomofthefigure.

Notethattheolde1objectstillexistsandispointedtobytheb2classhandle.

Figure8‐Re‐constructthee1extendedclassobject‐b1stillpointstotheolde1object

ItcanbeseeninFigure9thatanyattempttoaccesstheextendedclassdatavariableoranyattempttocalltheextendedmethodswillcauseacompilererror.Thedatavariable,setdata()andgetdata()methodsallexistintheobjectpointedtobytheb2handle,butabaseclasshandledoesnotknowaboutextendedmembersandmethods,sothecompilerwillnotallowthebasehandletomakethecommented‐outaccesscommands.

Figure9‐Theb2basehandlecannotbeusedtoaccessextendedobjectdataormethods

SNUG2018


InFigure10,anattemptismadetoagaincopyabaseclasshandle(b2)toanextendedclasshandle(e2),butthisisstillillegalandflaggedasacompilererror.

ButinFigure10,itisnowlegalto$casttheb2baseclasshandletothee2extendedclasshandle,becausethe$castoperationfirstcheckstoseeiftheobjectpointedtobyb2isanextendedobject,andoncethecompilerconfirmsthatthebasehandleisindeedpointingtoanextendedobjecttheb2basehandlecannowbecopied($cast ) to thee2extendedhandle.This isanexampleof legaldowncasting,asdescribedatthebeginningofSection7.

Figure10‐$casttheb2handletothee2handle‐Thisisnowlegal

HowdoengineersusethiscapabilityinaUVMtestbench?Onecommonexampleiswhenoverridingthedo_copy()methodintheuser'stransactionclassdefinition.

User defined transaction classes are typically extensions or derivatives of theuvm_sequence_itemclass,andaswasshowninFigure2,uvm_sequence_itemisaderivativeofuvm_object; therefore, user defined transactions are also derivatives ofuvm_object. Thismeansthatanyuserdefinedobjecttransactionhandlecanbecopiedorpassedtoauvm_objecthandle,asisthecasewhenoverridingthedo_copy()method.

Thedo_copy()methodasdefinedinuvm_objectisshowninFigure11.

virtual function void uvm_object::do_copy (uvm_object rhs); return; endfunction

Figure11‐UVMdo_copy()virtualmethod

SNUG2018


Whenoverridingthedo_copy()method, it is importanttodeclareahandleoftheuser'sdefinedtransactionclasstype(inthisexample,transtr).Whenthedo_copy()methodiscalledwithauser defined transaction handle, it is upcast to the uvm_object type. Any attempt to accesstransactionfieldsfromtherhshandlewillfailbecausetherhshandleisoftheuvm_objectbaseclasstype,butthetrobjectfieldsarestillthere,justnotaccessible.Togainaccesstotheobjectfields,therhshandleneedstobedowncasttothetransactiontype($cast(tr, rhs);).Thecopy()definedinuvm_objectcallsthedo_copy()methodandbydefiningthedo_copy()methodto$cast theargumenthandlerhs to thedesiredtranshandletr ,weknowthatanycall to thetransactiontr.copy(new_tr)methodwillsucceedincopyingthefieldsofthenew_trhandletothelocalfieldsofthetranstrobject,wherenew_tristhehandleofanotherobjectofthesametransactiontype.

function void do_copy (uvm_object rhs); trans tr; super.do_copy(rhs); $cast(tr, rhs); field_1 = tr.field_1; field_2 = tr.field_2; ... endfunction

Example3‐do_copy()methodimplementedwithdowncasting

Whenauseroverridesthevirtualdo_copy()ordo_compare()methods,itisrequiredtodeclarealocaltransactionhandleinthefunctionsanddowncasttheuvm_objectrhshandletothelocallydeclaredtransactionhandle.

ManyindustryUVMtestbenchexamplesnamethelocaltransactionhandlerhs_,butwebelievethisis confusing and therefore a poor practice. Using rhs_ means that casting is done in the form$cast(rhs_, rhs);andthenfieldsarereferencedasrhs_.field_1,etc.Itiseasytoconfusetheuvm_objectrhs handle with the transaction classrhs_ handle.We believe it is a betterpracticetomakesurethelocaltransactionhandlehasaverydistinctnon‐rhshandlenamesuchastr,toavoidconfusionaboutwhichhandleisbeingreferencedinsidethemethod.

Guideline3: Declarelocaltransactionhandlesusingdistinctnamessuchastrandavoidlocaltransactionhandlenamessuchasrhs_.

Partialdo_copy()anddo_compare()transclassmethodswithtranstrhandledeclarationsand$cast(tr, rhs);downcastingcommandsareshownatthebeginningofSection7.

SNUG2018


class trans extends uvm_sequence_item; ... int f1; ... virtual function void do_copy (uvm_object rhs); trans tr; //---------------------------------- super.do_copy(rhs); $cast(tr, rhs); f1 = tr.f1; ... endfunction virtual function bit do_compare (uvm_object rhs, uvm_comparer comparer); trans tr; bit eq; //---------------------------------- eq = super.do_compare(rhs, comparer); $cast(tr, rhs); eq &= comparer.compare_field_int("f1", f1, tr.f1); ... return(eq); endfunction ... Endclass

Example4‐Transactionexamplewithdo_copy()implementedusingdowncasting

SNUG2018


8. PurevirtualmethodsSystemVerilog‐2009[4]addedthepurekeywordtotheSystemVeriloglanguage.Thepurekeywordisonlylegalinavirtualclass.Thepurekeywordisnotlegalinanon‐virtualclass.

Purevirtualmethodsservetwoimportantpurposes:(1) Purevirtualmethodscanonlybeamethodprototype.Purevirtualmethodsareaplace‐

holder.(2) Purevirtualmethodsmustbeoverriddeninanon‐virtualclass.

Tosummarizethesepurposes,purevirtualmethodscreateamethodplace‐holderthatimposestherequirementthatitmustbeimplementedinthenon‐virtualclass.

Asapurevirtualmethodplaceholder,thepurevirtualmethodinavirtualclassimposesthefollowingrestrictions:

(1) Thepurevirtualmethodcanonlybeaprototype.(2) Thepurevirtualmethodcannothaveabody,itisnotallowedtohaveanyofthe

implementationcode.(3) ThepurevirtualmethodisNOTevenallowedtohavean"end"keyword

(endfunction/endtask).

Question:Ifavirtualclassdeclaresapurevirtualmethod,doesthefirstderivativenon‐virtualclasshavetooverridethepuremethod?Ifnootherderivativevirtualclasseshaveoverriddenthepuremethodwithanimplementation,theanswerisyes.ThisisshowninFigure12.

Figure12‐Non‐virtualclassmustoverrideapurevirtualmethodfromavirtualclass

SNUG2018


Ifaderivativeextendedvirtualclasshasoverriddenthepuremethodwithanimplementation,thefirstderivativenon‐virtualclassdoesnothavetooverridethepuremethod.ThisisshowninFigure13.

Figure13‐Non‐virtualclassnotrequiretooverrideapurevirtualmethodifoverriddeninavirtualclass

8.1 UVMpurevirtualmethodexample

One common place where UVM verification engineers encounter pure virtual methods is in theuvm_subscriber.ThisUVMbaseclassisoftenextendedtocreateacoveragecollectorcomponentandissometimesusedtohelpcreatecomponentsthatarepartofatestbenchscoreboard.

The uvm_subscriber has a built‐in uvm_analysis_imp port with port nameanalysis_export. To use the uvm_analysis_imp port requires a write function, so theuvm_subscriberalsoincludesthedeclarationofapure virtual function write (…)

Extendingtheuvm_subscribertocreateatestbenchcoveragecollectormeansthatthecoveragecollectorinheritstheuvm_analysis_impportandrequiresverificationengineerstoimplementthewrite()function.

SNUG2018


Partialcodefromtheuvm_subscriberbaseclassisshowninExample5.

virtual class uvm_subscriber #(type T=int) extends uvm_component; typedef uvm_subscriber #(T) this_type; // Port: analysis_export uvm_analysis_imp #(T, this_type) analysis_export; function new (string name, uvm_component parent); super.new(name, parent); analysis_export = new("analysis_imp", this); endfunction // Function: write // // A pure virtual method that must be defined in each subclass. Access // to this method by outside components should be done via the // analysis_export. pure virtual function void write(T t); endclass

Example5‐Partialuvm_subscribercode

Example6showspartofascoreboardpredictor,commonlyused inaUVMscoreboard.Sincethesb_predictor extendstheuvm_subscriber,thepredictorisrequiredtooverridethewritemethodwithafullimplementation.

class sb_predictor extends uvm_subscriber #(trans1); `uvm_component_utils(sb_predictor) // Inherit the uvm_analysis_imp port declared in uvm_subscriber // uvm_analysis_imp #(T, this_type) analysis_export;

... // MUST override the write method function void write(trans1 t); ... endfunction endclass

Example6‐Partialcommonscoreboardpredictorcode

Sincethesb_predictorisaparametereizedclassoftypetrans1,thewrite()methodmustalsousetrans1astheinputtype.ThetypeTparameteroftheuvm_subscriberwastheinputtypeof thewrite()method(asshowninExample5),sowhatevertype isusedintheextendedsb_predictormustalsobetheinputtypeofthewrite()function(asshowninExample6).

Guideline#4: Declareapuremethodwheneveritisimportanttoforceaderivativeclasstoimplementthemethod,asisdonebytheuvm_subscribervirtualclass.

SNUG2018


9. VirtualInterfacesVirtualinterfacesareclassdatamemberhandlesthatpointtoaninterfaceinstance.ThisallowsadynamicclassobjecttocommunicatewithaDesignUnderTest(DUT)moduleinstancewithoutusinghierarchicalreferencestodirectlyaccesstheDUTmoduleportsorinternalsignals.Thisisimportantgiventwofacts:(1)classdefinitionsaretypicallygatheredintooneormorepackages,and(2)itemsthat are defined inside of a package are not permitted tomake hierarchical references to itemsoutsideofthatpackage.ThisSystemVerilogpackagerestrictionexistsbecausethepackagemightbeusedinadesignthatdoesnotincludethehierarchicalpathsthatmightbereferencedinthepackage.

InFigure14,itcanbeseenthattheclassmethodsaccessthevirtualinterface(usingthenormaldotnotation,<virtualinterface>.<signal>).Sincethevirtualinterfaceispointingattheinterfaceinstance,theclassmethodsareineffectaccessingtheinterfaceinstance.WiththeDUTinstanceconnectedtotheinterfaceinstance,theclassmethodsareindirectlyaccessingtheDUTinstancewithoutusingahierarchicalreferenceoutsideoftheclass.

Figure14.VirtualInterfaceBlockDiagram

Tosuccessfullyuseavirtualinterfacetherearethreerequirements: Aninstantiatedinterfacemustbecorrectlyconnectedtothemoduleinstance. Avirtualinterfacehandlemustbedeclaredinaclass. Anassignmentmustbemadetosettheclassvirtualinterfacehandletopointtothemodule

interfaceinstance.

ClassObject TopModule

VirtualInterface InterfaceInstance

Methods DUT

SNUG2018


Example 7 shows the interface instantiated as dif and hierarchically connected to the moduleinstanceduttosatisfythefirstrequirementabove(thisisacommonstyleofconnectinganinterfacetoamoduleinstanceforusewithanon‐UVMclassbasedtestenvironment).Ifthemodulehadusedtheinterfaceasaport,theconnectionoftheinterfacetothemoduleinstantiationisshowninthecommentedoutinstantiationatthebottom.

Example7‐InterfaceInstantiationandConnection

Example8showsthesecondtworequirements.Firstisthedeclarationofthevirtualinterface,vif,insideoftheTestbenchclass.Secondistheassignmentoftheinterfaceinstancehandle,dif,tothevirtualinterface,vif,usingthenew()constructoroftheclass.Thisisarelativelycommonnon‐UVMstyleofconnectingthevirtualinterfacetotheinterfaceinstance(section9.2willshowtheUVMstyle).

Example8‐VirtualInterfaceDeclarationandAssignment

module top(); … // The actual instantiation of the Interface (note: this is the // only physical copy of the interface in the environment). dut_if dif(.*); // DUT instantiation with hierarchical port connections with the // .* at the end to do port-type checking for connection errors. simple_dut dut(.clk(dif.clk), .rst_n(dif.rst_n), .valid(dif.valid), .in_char(dif.in_char), .ack(dif.ack), .out_char(dif.out_char), .*); // If the DUT used the interface as a port rather than a discreet // port list, then the instantiation would be similar to this. // simple_dut dut(.lif(dif), .*); … endmodule

class Testbench; … // The virtual interface declaration. virtual dut_if vif; // When constructing the testbench object, take the passed in // handle to the actual interface instance and assign it to the // virtual interface of the testbench. function new (virtual dut_if nif); vif = nif; endfunction … endclass module top(); … // The testbench class object handle and construction. Testbench tb = new(dif); … endmodule

SNUG2018


Oncethevirtualinterfaceisconnectedcorrectly,theclassobjectscancommunicatewiththemoduleinstancebyaccessingthesignalsinsideoftheinterfacethatareconnectedtothemodule,asshowninExample9.

Example9‐VirtualInterfaceAccesses

9.1 VirtualInterfacesvsStaticInterfaces

Whendealingwithinterfaces,therearethreedifferentperspectivesthatshouldbeconsidered.Thefirsttwoarestaticinnatureandareconstructedandconnectedduringcompile/elaborationofthedesignandenvironment.Thethirdiscreatedandassigneddynamicallyduringrun‐time.

Thefirstisthestaticinterfaceinstanceitself.ThiswasshownastheinstantiationofdifinExample7,which iscreatedduringcompilation/elaborationandcannotbechangedduringrun‐time. Theinstantiationofaninterfaceistheonlyplacethatanactualinterfaceexists.Allotherreferencestoaninterfacearehandlespointingtotheactualinterfaceinstantiation.

The second is the static handle to an interface from amodule port list. Thiswas shown in thecommentedoutmoduleinstantiationinExample7wheretheportlifwasconnectedtothestatichandledif.Thishandleissetandconnectedtotheportstaticallyduringcompilation/elaborationandcannotbechangedduringrun‐time.

Thethirdisthedynamicvirtualinterfacewithinclasses.ThecreationandsettingofthevifvirtualinterfacewasshowninExample8andtheaccessofinterfacesignalswasshowinExample9.Thisdynamicfieldissetandusedduringrun‐time.Sinceitisdynamic,anenvironmentcouldbedesignedthathadmultipleinterfacesinstantiated,butonlyonevirtualinterfacethatpointedatthedifferentinterfaceinstancesatdifferenttimesduringrun‐time(thisisjustbeingmentionedasatheoreticalpossibility,notasa recommendationas itwouldprobablycreateaverycomplexandconvolutedenvironmentthatwouldbeanightmaretocreateandmaintaineffectively).

Notice that the instance name of an interface instantiation is used to represent both the actualinstanceandahandle. Thehandle is treatedasastatichandlewhen it isconnectedtoamodule

class Testbench; … task run_test(); vif.rst_n <= '0; vif.valid <= '0; @(negedge vif.clk); vif.rst_n = '1; @(negedge vif.clk); // Drive the test string into the DUT. foreach (test_str[i]) begin vif.in_char = test_str[i]; vif.valid = '1; @(negedge vif.clk); vif.valid = '0; end repeat (3) @(negedge vif.clk); $finish(2); endtask endclass

SNUG2018


instanceportandasadynamichandlewhenpassedintoaclasstosetavirtualinterfacehandle.

9.2 VirtualInterfaceUsageinUVM

Since UVM is a class‐based verification methodology and it is recommended to group theenvironmentintoapackage.OneormorevirtualinterfacesarerequiredfortheUVMtestbenchtoaccesstheDUT.TheUVMdriverandUVMmonitoraretypicallytheonlytwolocationsthatneedtoaccesstheDUT,sotheyaretheonlytwolocationswithinUVMthatrequireavirtualinterface.

ThemostcommonUVMstyleofinstantiatingandconnectingthevirtualinterfacetotheDUTwasshowninExample7usingthenamedportconnectionsthathierarchicallyconnecttothe internalsignalsoftheinterface.

WheretheUVMdiffersfromthebasicvirtualinterfaceusage, is intheconnectionoftheinterfaceinstancetothevirtualinterface. Therearethreewaystodothisconnectionandthefirsttwoaregenerallynotrecommended.

ThefirstwaythatisnotrecommendedwasshowninExample8bypassingtheinterfacehandleintothenew()constructoroftheclass.ThisstyleinUVMcreatesspaghetti‐likecodingasyouhavetopasstheinterfacehandletoeachleveloftheUVMcomponentstructureuntilyougetittothedriverandmonitorwheretheyareactuallyused.

Thesecondway,whichisnolongerrecommended,istheolderOVMstyleusingawrapperclassandtheconfigobjecttabletostoreandretrievethatwrapper.ThisstylewasrequiredinOVMandwillstillworkforUVM,butisnotrecommendedforUVMsinceitrequiresthecreationofanextrawrapperclass for thesolepurposeofstoring the interfacehandle insideofaclassobject thatcan thenbestored into a uvm_object (config object) table using the now‐deprecated1set_config_object() / get_config_object() commands. The wrapper class wasnecessarybecauseastaticinterfacehandlecannotbedirectlyplacedintoaclass‐basedstoragetable.

1set_config_object()andget_config_object()commandsweredeprecatedinUVM1.2.Thesecommandswerereplacedbytheuvm_config_db#(…)::set(…)anduvm_config_db#(…)::get(…)commands.

SNUG2018


Example10showshowthewrapperclasshastobecreated,itsvirtualinterfacepointedtotheactualinterface,andthenthewrapperclassobjectisstoredinsideoftheconfigobjecttablebeforethecalltorun_test().Theninthedriverandmonitorclasses(Example10onlyshowsthedriver,butthemonitorwouldusethesamecoding),thewrapperobjectmustberetrievedfromtheconfigobjecttableanddowncastfromtheuvm_objectclassbackintothewrapperclassbeforethestoredvirtualinterfacehandlecanberetrievedandassignedtothelocalvifhandle.Thisassignmentistypicallydoneinthebuild_phase()methodandonceit isdone,thetestbenchhasaccesstothevirtualinterfaceforthedriverandmonitorclassestoindirectlycommunicatewiththeDUT.

Example10‐OVMStyleVirtualInterfaceConnection

module top; … dut_if dif; dut_if_wrapper w; // dut_if_wrapper is derived from uvm_object initial begin w = new(dif); set_config_object("*", "vif", w, 0); run_test(); end endmodule class dut_if_wrapper extends uvm_object; virtual dut_if vif; function new (virtual dut_if nif); vif = nif; endfunction endclass class tb_driver extends uvm_driver #(trans1); … virtual dut_if vif; … function void build_phase(uvm_phase phase); super.build_phase(phase); uvm_object obj; dut_if_wrapper w; //------------------------------- if (!get_config_object("vif", obj, 0)) `uvm_fatal("NOVIF",{"virtual interface must be set for:", get_full_name(),".vif"}); if (!$cast(w, obj)) `uvm_fatal("NOVIF",{"bad dut_if_wrapper handle for", get_full_name()}); vif = w.vif; endfunction … endclass

topmodulewithinterfaceandinterfacewrapper

dut_if_wrapperclassdefinition

tb_driverclassthataccessesthewrapperclasstoretrievetheinterface

handle

SNUG2018


The third, and recommended,way to set virtual interfaces inUVM is a cleanerandeasier touseapproachasitbasicallydoesthewrapperhandlingautomatically.Example11firstshowsthattheactualinterfacehandle,dif,isstoredintotheuvm_config_dbatstringlocation"vif"usingtheset()commandjustbeforetherun_test()callinthetoplevelmodule.Thenitshowstheuseoftheget()functionoftheuvm_config_dbtoretrievethevirtualinterfacehandlefromthesame"vif"locationandassignittothelocalvifvirtualinterfacehandleinthedriverclass(thesamecodewillbeusedinsideofthemonitorclass).

Example11‐UVMStyleVirtualInterfaceConnection

This third technique eliminates the need to create a separate wrapper class to store the staticinterfacehandle,andeliminatestheneedtodeclareauvm_objectbaseclasshandleanddowncastthathandletoawrapperhandlebeforeretrievingthevirtualinterfacehandle.

Guideline#5: Use uvm_config_db#(virtual dut_if)::set(…)and uvm_config_db#(virtual dut_if)::get(…)commandstostoreandretrieveaninterfaceforusebyaUVMtestbench.

module top; … dut_if dif; … initial begin uvm_config_db#(virtual dut_if)::set(null, "*", "vif", dif); run_test(); end endmodule class tb_driver extends uvm_driver #(trans1); … virtual dut_if vif; … function void build_phase(uvm_phase phase); super.build_phase(phase); // Get the virtual interface handle that was stored in the // uvm_config_db and assign it to the local vif field. if (!uvm_config_db#(virtual dut_if)::get(this, "", "vif", vif)) `uvm_fatal("NOVIF", {"virtual interface must be set for: ", get_full_name(), ".vif"}); endfunction … endclass

SNUG2018


10. Summary&ConclusionsThispapergaveaquickintroductiontoclasses,classextension,classmethods,virtualclassesandvirtualmethods.

Aguidelineforchoosinghowtoimplementclassmethodswasgiven:

Guideline#1: Classmethodsshouldbefunctionandvoidfunction.Onlyusetaskwhenthemethodconsumessimulationtime.

This paper described how virtual methods are frequently used in UVM and how upcasting anddowncastingworkandarealsousedinUVM.Thisleadtothesecondguideline:

Guideline#2:DeclareSystemVerilogclassmethodstobevirtualmethodsunlessthereisaverygoodreasontoprohibitmethod‐polymorphism.

UVMusestheimportantvirtualmethodsdo_copy(),do_compare()andothervirtualmethodsthatarecalledbythecopy(),compare()andotherstandardtransactionmethods,whichrequirethat the uvm_object method prototypes be copied and used. The prototype methods takeuvm_objecthandlesasinputs,whichupcastsalltransactionhandlesintouvm_objecthandles.Thesemethods require the user to declare handles of the transaction type and to downcast thehandlesinsideofthesemethodstorecoverthetransactiondatamembers.Thispaperdescribedwhyitmightbeconfusingtodeclaretransactionhandlesnamedrhs_andrecommendedthatdistinctnamesbegiventothelocaltransactionhandlesinthesemethods.

Guideline#3: Declarelocaltransactionhandlesusingdistinctnamessuchastrandavoidlocaltransactionhandlenamessuchasrhs_.

Thispaperalsodiscussedthekeywordpureandhowitisusedinvirtualclassestoimposeastrictmethodprototyperequirementthatalsoeventuallyrequiresaderivativeclasstoimplementthefullmethod.Auvm_subscriberclassexamplewasincludedtoshowhowthisiscommonlyusedinUVMtestbenches.

Guideline#4: Declareapuremethodwheneveritisimportanttoforceaderivativeclasstoimplementthemethod,asisdonebytheuvm_subscribervirtualclass.

Thispaperalsoshowedhowvirtualinterfacesareusedtodrivesignalsfromaclass‐basedtestbenchtoarealtestbenchinterfaceandthattherealinterfacesignalstouchthepinsoftheDUT,effectivelyallowingtheclass‐drivensignalstotouchtheDUTpinsinatestbench.

It was also shown that the new uvm_config_db#(…)::set(…) anduvm_config_db#(…)::get(…) commands greatly simplify the process of connecting a classbasedtestbenchtoaDUT.

Guideline#5: Use uvm_config_db#(virtual dut_if)::set(…)and uvm_config_db#(virtual dut_if)::get(…)commandstostoreandretrieveaninterfaceforusebyaUVMtestbench.

11. AcknowledgementsWe are grateful to our colleagues John Dickol, Don Mills and Jeff Vance for their reviews andsuggested improvements to this paper. Their contributions have ensured the presentedmaterialincludesexplanationsandinsightthatwewouldhaveotherwiseneglectedtoinclude.

SNUG2018


12. References[1] CliffordE.Cummings,“UVMTransaction‐Definitions,MethodsandUsage,”SNUG2014(SiliconValley).

Availableatwww.sunburst‐design.com/papers

[2] IEEEStandardVerilogHardwareDescriptionLanguage,IEEEComputerSociety,IEEE,NewYork,NY,IEEEStd1364‐2001.

[3] "IEEEStandardFor SystemVerilog:UnifiedHardwareDesign, SpecificationandVerificationLanguage,"IEEEComputerSocietyandtheIEEEStandardsAssociationCorporateAdvisoryGroup,IEEE,NewYork,NY,IEEEStd1800™‐2005

[4] "IEEEStandardForSystemVerilog‐UnifiedHardwareDesign,SpecificationandVerificationLanguage,"IEEEComputerSocietyandtheIEEEStandardsAssociationCorporateAdvisoryGroup,IEEE,NewYork,NY,IEEEStd1800™‐2009

[5] "IEEEStandardForSystemVerilog‐UnifiedHardwareDesign,SpecificationandVerificationLanguage,"IEEEComputerSocietyandtheIEEEStandardsAssociationCorporateAdvisoryGroup,IEEE,NewYork,NY,IEEEStd1800™‐2012

[6] "IEEE Standard For Universal Verification Methodology Language Reference Manual," IEEE ComputerSocietySponsoredbytheDesignAutomationStandardsCommittee,IEEE,NewYork,NY,IEEEStd1800.2™‐2017

[7] https://stackoverflow.com/questions/23414090/what‐is‐the‐difference‐between‐up‐casting‐and‐down‐casting‐with‐respect‐to‐class

[8] https://www.tutorialcup.com/cplusplus/upcasting‐downcasting.htm

[9] "SystemVerilog 3.1 – Accellera’s Extensions to Verilog®," 2003, Accellera Organization, Inc., Napa, CA94558

13. Author&ContactInformationCliffCummings,PresidentofSunburstDesign,Inc.,isanindependentEDAconsultantandtrainerwith36yearsofASIC,FPGAandsystemdesignexperienceand26yearsofSystemVerilog,synthesisandmethodologytrainingexperience.

Mr.Cummingshaspresentedmorethan100SystemVerilogseminarsandtrainingclassesinthepast15yearsandwasthefeaturedspeakerattheworld‐wideSystemVerilogNOW!seminars.

Mr. Cummings participated on every IEEE & Accellera SystemVerilog, SystemVerilog Synthesis,SystemVerilog committee from 1994‐2012, and has presented more than 40 papers onSystemVerilog&SystemVerilogrelateddesign,synthesisandverificationtechniques.

Mr. Cummings holds a BSEE from Brigham Young University and an MSEE from Oregon StateUniversity.

Sunburst Design, Inc. offers World Class Verilog & SystemVerilog training courses. For moreinformation,visitthewww.sunburst‐design.comwebsite.

Emailaddress:cliffc@sunburst‐design.com

HeathChambersisPresidentofHMCDesignVerification,Inc.,acompanythatspecializesindesignandverificationconsultingandhigh tech training.Mr.Chambers isa consultantwith22yearsofVerilogExperience15yearsofSystemVerilogexperience,18yearsofconsultingandverificationleadexperienceformultipleprojectsandhasbeenaninstructorforSunburstDesignsincetheyear2000.Heathhas18yearsofSystemVerilog,Verilog,synthesisandUVMVerificationmethodologytraining

SNUG2018


experience for Sunburst Design, Inc., and was previously a contract Specman Basic Traininginstructor for Verisity. Heath has ASIC and system verification, firmware, and self‐test designexperience and is capable of answering the very technical questions asked by experiencedverificationengineers.

Mr. Chambers,was amemberof the IEEE1364Verilog and IEEE1800SystemVerilog StandardsGroups from 2000 to 2012, and has helped to develop and improve Sunburst Design Verilog,SystemVerilog,UVMandsynthesistrainingcourses.

Mr.ChambersspecializesinverificationofASICsandsystemsusingtop‐downdesignmethodologiesand is proficient in SystemVerilog,Verilog,UVM, 'e', C, andPerl.Mr. Chambers specializes in theQuesta,Cadence,Synopsyssimulationtools.

Before becoming an independent Consultant, Mr. Chambers worked for Hewlett‐Packard doingverificationofmulti‐milliongateASICsandsystemscontainingmultiplechips.Mr.Chamberswastheleadverificationengineerforthelasttwoprojectsheworkedonbeforeleavingthecompany.

Mr.ChambersholdsaBSCSfromNewMexicoInstituteofMiningandTechnology.

Emailaddress:[email protected]

LastUpdated:June2018

clifford e. cummings heath chambers · 2018-06-20 · world class systemverilog & uvm training...

Documents