Clifford E. Cummings Heath Chambers · 2018-06-20 · World Class SystemVerilog & UVM Training...
Transcript of 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
Page3 SystemVerilogVirtualClasses,Methods,Interfaces Rev1.0 ‐TheirUseinVerificationandUVM
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
Page4 SystemVerilogVirtualClasses,Methods,Interfaces Rev1.0 ‐TheirUseinVerificationandUVM
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
Page5 SystemVerilogVirtualClasses,Methods,Interfaces Rev1.0 ‐TheirUseinVerificationandUVM
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
Page6 SystemVerilogVirtualClasses,Methods,Interfaces Rev1.0 ‐TheirUseinVerificationandUVM
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
Page7 SystemVerilogVirtualClasses,Methods,Interfaces Rev1.0 ‐TheirUseinVerificationandUVM
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
Page8 SystemVerilogVirtualClasses,Methods,Interfaces Rev1.0 ‐TheirUseinVerificationandUVM
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
Page9 SystemVerilogVirtualClasses,Methods,Interfaces Rev1.0 ‐TheirUseinVerificationandUVM
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
Page10 SystemVerilogVirtualClasses,Methods,Interfaces Rev1.0 ‐TheirUseinVerificationandUVM
InFigure4,theb1baseclassobjectisconstructed,andthea‐variableissetto4.Thentheshowit()methodiscalledanddisplaystheoutputshownatthebottomofthefigure.
Figure4‐Constructtheb1baseclassandsettheavalue
InFigure5,anattemptwasmadetocopytheb1baseclasshandletothee1extendedclasshandle.Thisisanillegalattemptatdowncastingandisacompilationerror.Thenanattemptwasmadeto$casttheb1handletothee1handlebutthe$castfails,sotheif‐testcausesthedisplayedfailuremessageatthebottomofthefiguretobeshown.
Figure5‐Illegaltocopyor$castabaseclasshandletoanextendedclasshandle
SNUG2018
Page11 SystemVerilogVirtualClasses,Methods,Interfaces Rev1.0 ‐TheirUseinVerificationandUVM
InFigure6,thee1objectisconstructedandthea‐valueanddata‐valueareset,thenthecontentsofthee1objectaredisplayedusingtheshowit()methodandthosecontentsareshownatthebottomofthefigure.
Figure6‐Constructthee1extendedclassandsettheaanddatavalues
InFigure7,thee1extendedobjecthandleiscopiedtotheb2baseclasshandle.Itisalwayspossibletocopyanextendedhandletoabaseclasshandlebecausebaseclassdatamembersandmethodshavebeeninheritedbytheextendedclass,soitispossibletousethebaseclasshandletocallinheritedbaseclassdatamembersandmethods.Thisisupcastingandisalwayslegal.
Figure7‐Copythee1extendedobjecthandletotheb2baseclasshandle
SNUG2018
Page12 SystemVerilogVirtualClasses,Methods,Interfaces Rev1.0 ‐TheirUseinVerificationandUVM
InFigure8,thee1objectisre‐constructedandthea‐valueisset,whilethedata‐variableretainsitsdefaultvalueof0.Thenthecontentsofthee1objectaredisplayedusingtheshowit()methodandthosecontentsareshownatthebottomofthefigure.
Notethattheolde1objectstillexistsandispointedtobytheb2classhandle.
Figure8‐Re‐constructthee1extendedclassobject‐b1stillpointstotheolde1object
ItcanbeseeninFigure9thatanyattempttoaccesstheextendedclassdatavariableoranyattempttocalltheextendedmethodswillcauseacompilererror.Thedatavariable,setdata()andgetdata()methodsallexistintheobjectpointedtobytheb2handle,butabaseclasshandledoesnotknowaboutextendedmembersandmethods,sothecompilerwillnotallowthebasehandletomakethecommented‐outaccesscommands.
Figure9‐Theb2basehandlecannotbeusedtoaccessextendedobjectdataormethods
SNUG2018
Page13 SystemVerilogVirtualClasses,Methods,Interfaces Rev1.0 ‐TheirUseinVerificationandUVM
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
Page14 SystemVerilogVirtualClasses,Methods,Interfaces Rev1.0 ‐TheirUseinVerificationandUVM
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
Page15 SystemVerilogVirtualClasses,Methods,Interfaces Rev1.0 ‐TheirUseinVerificationandUVM
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
Page16 SystemVerilogVirtualClasses,Methods,Interfaces Rev1.0 ‐TheirUseinVerificationandUVM
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
Page17 SystemVerilogVirtualClasses,Methods,Interfaces Rev1.0 ‐TheirUseinVerificationandUVM
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
Page18 SystemVerilogVirtualClasses,Methods,Interfaces Rev1.0 ‐TheirUseinVerificationandUVM
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
Page19 SystemVerilogVirtualClasses,Methods,Interfaces Rev1.0 ‐TheirUseinVerificationandUVM
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
Page20 SystemVerilogVirtualClasses,Methods,Interfaces Rev1.0 ‐TheirUseinVerificationandUVM
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
Page21 SystemVerilogVirtualClasses,Methods,Interfaces Rev1.0 ‐TheirUseinVerificationandUVM
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
Page22 SystemVerilogVirtualClasses,Methods,Interfaces Rev1.0 ‐TheirUseinVerificationandUVM
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
Page23 SystemVerilogVirtualClasses,Methods,Interfaces Rev1.0 ‐TheirUseinVerificationandUVM
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
Page24 SystemVerilogVirtualClasses,Methods,Interfaces Rev1.0 ‐TheirUseinVerificationandUVM
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
Page25 SystemVerilogVirtualClasses,Methods,Interfaces Rev1.0 ‐TheirUseinVerificationandUVM
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
Page26 SystemVerilogVirtualClasses,Methods,Interfaces Rev1.0 ‐TheirUseinVerificationandUVM
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
Page27 SystemVerilogVirtualClasses,Methods,Interfaces Rev1.0 ‐TheirUseinVerificationandUVM
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