world class systemverilog & uvm trainingsnug 2018 page 6 uvm analysis port functionality and rev...

World Class SystemVerilog & UVM Training

UVMAnalysisPortFunctionalityandUsingTransactionCopyCommands

Clifford E. Cummings Heath Chambers SunburstDesign,Inc. HMCDesignVerification cliffc@sunburst‐design.com [email protected] Provo,UT,USA Albuquerque,NM,USA www.sunburst‐design.com

ABSTRACT

ThereissignificantconfusionsurroundingUVManalysisportsandsimilarconfusionabouttheUVMtransactioncopycommand.ManyverificationengineerswhoconsiderthemselvestobeUVM experts can easily spendhoursdebugginganalysisport issues if theyareunawareofimportantconsiderationsrelatedtoanalysisportpaths.Thispaper explainsUVManalysisportusageand compares the functionality to subscribersatelliteTV.Thepapershowssimplified,non‐UVM,analysisportimplementationstoclarifyhowthe correspondingUVMport connectionswork.Thepaperdescribeshow theanalysisportwrite()method efficiently calls each subscriber's write()method. Part of the explanationdescribeswhen an analysis implementation port requires the use of a transaction copy()command. The paper describes problems that arise when multiple analysis portimplementationsarerequiredinthesamecomponentandhowtoaddresstheproblems. Thepaperalsodescribesanexampleofhowimproperhandlingoftransactionscanhidedesignand testbenchbugs.The example showshowabugwashidden ina scoreboard thatwentunnoticed formonthsand tookhours todetectand fixoncewe identified that therewasaproblem.

SNUG-2018 Austin Voted Best Presentation

2nd Place

SNUG2018

Page2 UVMAnalysisPortFunctionalityandRev1.0 UsingTransactionCopyCommands

TableofContents1.Introduction‐SatelliteTVExample..............................................................................................................................5

2.Observerpattern&analysispathbasics.....................................................................................................................5

2.1Observerpatterndefinition................................................................................................................................5

2.2SimpleSystemVeriloganalysispathexamples...........................................................................................5

2.2.1Scenariocommonfiles...............................................................................................................................6

2.2.2Scenario1‐monitor1withseparateanalysis_ifdeclarations–noconnect()methods7

2.2.3Scenario2‐monitor2withseparateanalysis_ifandconnect()methoddeclarations..9

2.2.4Scenario3‐monitor3withanalys_ifqueueandcommonconnect()method...............11

Scenario4–Buggyexamplewheresubscriber2modifiesthetransaction................................13

UVManalysis_port.write()versusanalysis_impwrite()method...................................................14

3.UVMPortFundamentals..................................................................................................................................................15

3.1UVMportconnectionchains............................................................................................................................15

3.1.1UVMPorts....................................................................................................................................................15

3.1.2UVMExports...............................................................................................................................................15

3.1.3UVMImps.....................................................................................................................................................15

3.1.4Unfortunateportnamingconvention..............................................................................................15

3.1.5Port‐Export‐Impchains.........................................................................................................................16

3.1.6UVMPort&Exportinterchangability?............................................................................................17

3.1.7UVMPort&Exportusageguidelines...............................................................................................18

3.2uvm_port_baseconnect()method.................................................................................................................19

3.3Scopeofportdiscussioninthispaper.........................................................................................................19

4.UVManalysisports,exportsandimps.....................................................................................................................20

4.1uvm_analysis_port‐broadcastport.............................................................................................................20

4.1.1Whyisthetransactioncopy()methodsoimportant?..............................................................20

4.2uvm_analysis_export–transferport............................................................................................................20

4.3uvm_analysis_imp–terminationport.........................................................................................................20

4.4port,export,impconfusion..............................................................................................................................21

4.4.1Driver–Car/Port‐Export..................................................................................................................21

4.4.2Export,impconfusion.............................................................................................................................21

5.Declaringandconstructingports&TLMFIFOs....................................................................................................22

5.1HowareanalysisportsandTLMFIFOsdeclared?.................................................................................22

5.2WhereareTLMportsandTLMFIFOsconstructed?.............................................................................23

5.3uvm_analysis_impportusageoptions.........................................................................................................24

SNUG2018


6.uvm_subscriber...................................................................................................................................................................25

6.1purevirtualwritefunction...............................................................................................................................25

6.2multipleuvm_analysis_impportsonthesamecomponent...............................................................25

7.SystemVerilogmailbox.....................................................................................................................................................25

7.1Mailbox–vs‐queue..............................................................................................................................................25

8.TLMFIFOs..............................................................................................................................................................................26

8.1uvm_tlm_fifo_base.................................................................................................................................................26

8.2uvm_tlm_fifo............................................................................................................................................................28

8.2.1uvm_tlm_fifonew()‐constructor&size...........................................................................................28

8.2.2uvm_tlm_fifoput()&try_put()methods.........................................................................................29

8.2.3uvm_tlm_fifoget()&try_get()methods..........................................................................................30

8.2.4uvm_tlm_fifodisadvantage...................................................................................................................30

8.3uvm_tlm_analysis_fifo.........................................................................................................................................31

8.4Quick‐summaryofuvm_tlm_analysis_fifo–vs‐uvm_tlm_fifo............................................................31

9.`uvm_analysis_imp_decl(SFX)macro.........................................................................................................................32

9.1Howmanyportsareallowedonascoreboard?......................................................................................33

10.Examplewithtypicalanalysis/copy()problems...............................................................................................34

11.Summary&Conclusions...............................................................................................................................................34

12.Acknowledgements.........................................................................................................................................................35

13.References...........................................................................................................................................................................35

SNUG2018


TableofFiguresFigure1‐Monitor&subscribers–Simulationoutput..............................................................................................9

Figure2‐Monitor&subscribers–Buggysimulationoutput..............................................................................13

Figure3‐Commonanalysisportconnections–recommendedconnections..............................................15

Figure4‐Analysispaths‐firstsetofthreepaths.....................................................................................................16

Figure5‐Analysispaths‐secondsetofpaths‐justonepath............................................................................17

Figure6‐NOTRecommended–analysisports&noanalysisexports(butitworks!)............................17

Figure7‐NOTRecommended–analysisexports&1analysisportperanalysissource(butitworks!).........................................................................................................................................................................................18

Figure8‐UVManalysisports–recommendedusageblockdiagram..............................................................18

Figure9‐UVManalysisexports&imps–recommendedusageblockdiagram.........................................18

Figure10‐uvm_tlm_fifo_baseports...............................................................................................................................26

Figure11‐uvm_tlm_fifoput()andget()methodbehavior..................................................................................30

Figure12‐uvm_tlm_analysis_fifo–mostcommonusage.....................................................................................31

Figure13‐uvm_tlm_fifo–vs‐uvm_tlm_analysis_fifousage..................................................................................32

TableofTablesTable1‐uvm_tlm_fifo_baseportnamesandportnamealiases.........................................................................27

Table2‐uvm_tlm_fifo_basemethodsandusagenotes.........................................................................................28

SNUG2018


1.Introduction‐SatelliteTVExampleThose familiarwith satellite TV know that programs are broadcast as scheduled and the viewereitherneedstowatchtheprogramliveasitisbeingbroadcast,ortheyneedtosetupaDigitalVideoRecorder(DVR)torecordtheprogramforlaterviewing.

Thesatellitewillbroadcasttheprogramasscheduledwhetherthereare1,000'sofviewersornoviewersatall.Thebroadcasthasbeenscheduledanditwillhappenonschedule.

IfaviewerneglectstosetupaDVRtorecordadesiredprogramandtheviewerturnstheTVon15minutesaftertheprogramhasstarted,theviewercannotrequestthatthesatellitestartoverandre‐broadcastthedesiredprogramfromthestartforthesetworeasons:(1)theviewerhasnowaytocommunicatetothesatellitethedesiretore‐startaprogram,and(2)otherviewerswouldobjecttoprogramsbeingrestartedwhiletheywerewatchingaprogramlive.

ItshouldalsobenotedthattheviewerofalivebroadcastcannotmodifytheSatelliteversionofthebroadcastprograminrealtime.Iftheviewerhastherightequipmentandsoftware,theviewermightsplicetherecordedprogramorcensorunwantedlanguageandcontent,butthoseeditshavetobedoneonthelocalcopyoftheprogramandnotonthelivesatellitebroadcastoftheprogram.

Theuvm_analysis_portisabroadcastportthatisveryanalogoustothissatelliteTVexample.

Since UVM analysis paths do not broadcast transactions over the airwaves, it is instructive tounderstandhowclassesareassembledtoallownewsubscriberstobeaddedtoananalysisbroadcastsourcewithlittlemodificationtotheexistingenvironment.DespitethefactthatviewersofSatelliteprograms do not modify broadcast programs, engineers are frequently guilty of modifying theoriginaltransactionandsuchmodificationscancausesubtleproblemsthataredifficulttodebug.Thispaperwillshowmanyanalysisfeaturesthatengineersshouldconsiderwhenusinganalysisports.

2.Observerpattern&analysispathbasicsTheUVManalysispathisanexampleofasoftwaredesignpatternknownastheobserverpattern.

2.1Observerpatterndefinition

AconcisedefinitionoftheobserverpatternisfoundinWikipedia.

"Theobserverpatternisasoftwaredesignpatterninwhichanobject,calledthesubject,maintainsa list of its dependents, calledobservers, and notifies them automatically of any state changes,usuallybycallingoneoftheirmethods."[3]

2.2SimpleSystemVeriloganalysispathexamples

Wehavefoundthatmostexamplesofanalysispathsareoverlycomplexanddifficulttounderstand.The multi‐part scenarios shown in this section are an over‐simplification of the analysis pathimplementationinSystemVerilogandarenotfullyUVMcompliant,buttheirsimplicitymakethemeasytocomprehendandbeingsimpleallowsanengineertohaveaconceptualunderstandingofhowtheuvm_analysis_portpathworks.

Fourscenarioswillbepresentedtodemonstratehowanalysispaths(observerpatterns)work.

In all four scenarios, the transaction, analysis_if and subscribers remain unchanged. Alsounchangedisthefactthatthetopmoduledeclaresallofthesubscriberhandlesandhastonew()‐constructeachsubscriber.Thetopmoduleineachscenariowillshowimpotantdifferencesafterthesubscribersareconstructed.

SNUG2018


Thescenariodifferencesarevisibleinthemonitorsandlatterpartofthetopmodules.

Inthefirstscenario,monitor1hastodeclareallofthesubscribersandcalltheirrespectivewrite()methods by explicitly referencing the handle names. The top1 module has to copy all of theconstructed subscriber handles to the monitor1 subscriber handles, which required the top1moduletoknowtheinternalhandlenamesofeachsubscriber.

In thesecondscenario,monitor2definesconnect[#]()methods foreachsubscriberso that thetop2moduleonlyhastoknowthereareconnect()methodswithoutbeingrequiredtoknowthesubscriberhandlenames.

Inthefirsttwoscenarios,eachsubscriberrequiredaseparatedeclaration,separatecallstowrite()methodsandthetopmodulehadtoeithercopyeachsubscriber'shandlenametothecorrespondinghandlenamesinthemonitor,orhadtocallaconnect()methodthatwasuniquetoeachsubscriber.Addingmoresubscribersrequireslotsofextracode.

In the third scenario, monitor3 has a declared queue of analysis_if handles and a commonconnect()methodthatpushesanewhandleontothequeue.Therun()tasksimplyusesaforeachlooptopulleachhandleoffofthequeueandcallthewrite()methoddefinedineachsubscriber.Fromthispointforward,wheneverthetop3moduleaddsanewsubscriber,nomodificationswillbenecessary inside of the monitor. This is possible because each new subscriber that extends theanalysis_if,mustprovideanimplementationofthecommonlynamedvirtualwrite()method.

Inthefourthscenario,subscriber2modifiesthetransactionvaluesandweobservethatsinceeachsubscriberhasahandletoacommontransaction,thatsubscriber3seesthemodifiedtransactionandnottheoriginalbroadcasttransaction.Thisdemonstrateswhysubscribersshouldnevermodifytheoriginaltransactionbutshouldtakeacopybeforedoinganytransactionmodifications.

2.2.1Scenariocommonfiles

Thefilesinthissectionarecommontoallfourofthesubsequentscenarios.

Thetransaction(trans1)thatispassedaroundthesescenarioshastworandomizablefields,addranddata,andbothfields,throughthepost_randomize()method,areautomaticallyprintedeachtimethetransactionisrandomized.Thetrans1classisshowninExample1.

class trans1; rand bit [7:0] addr; rand bit [7:0] data; function void post_randomize(); $display("\nRandomized trans1 values addr=%2h data=%2h", addr, data); endfunction endclass

Example1‐transactionclasswithbuilt‐inpost_randomize()methodtoprintrandomizedtransactionvalues

Avirtualanalysis_ifbaseclass,showninExample2,isdeclaredwithapurevirtualwrite()method.Anyclassthatextendstheanalysis_ifclasswillberequiredtoprovideawrite()methodimplementation. In these examples there will be three subscribers that are extensions of theanalysis_ifclass.Thisissimilarinconcepttoauvm_analysis_impinsideofauvm_subscriber.Sincethereisapurevirtualwrite()methoddefinedintheanalysis_if.Anyclassthatextendstheanalysis_if(uvm_subscriber)isrequiredtousetheexactsameprototype(functionheader)andprovidetheactualimplementation.Theimplementationsinthisexamplewillbesimpledisplay

SNUG2018


commandstoshowthetransactionthatwasreceived. virtual class analysis_if; pure virtual task write(trans1 t); endclass

Example2‐virtualanalysis_ifbaseclassandpurevirtualwrite()methoddefinition

Forthesescenarios,threesubscribers,showninExample3,Example4andExample5,havebeenextendedfromtheanalysis_ifvirtualclass.Allthreehaveawrite()methodimplementationthatdisplays which subscriber[#] issued the message and the current contents of the transaction.subscriber2 in Example 4 includesBUG code tomodify the transactionwhen the simulation iscompiledwith+define+BUG.Thebehaviorofthebugisdescribedlaterinthissection. class subscriber1 extends analysis_if; virtual task write(trans1 t); $display("subscriber1: ", "received addr=%2h data=%2h", t.addr, t.data); endtask endclass

Example3‐Subscriber#1withwrite()methodtodo$display

class subscriber2 extends analysis_if; virtual task write(trans1 t); $display("subscriber2: ", "received addr=%2h data=%2h", t.addr, t.data);

`ifdef BUG t.addr = 8'hFF; t.data = 8'h00; $display("subscriber2: ", "set addr=%2h data=%2h", t.addr, t.data); `endif endtask endclass

Example4‐Subscriber#2withwrite()methodtodo$display–includesBUGtestingcode

class subscriber3 extends analysis_if; virtual task write(trans1 t); $display("subscriber3: ", "received addr=%2h data=%2h", t.addr, t.data); endtask endclass

Example5‐Subscriber#3withwrite()methodtodo$display

2.2.2Scenario1‐monitor1withseparateanalysis_ifdeclarations–noconnect()methods

In the first scenario,monitor1, shown in Example 6, declares threeanalysis_if handleswithhandle namesap1,ap2 andap3. Themonitor1 class also has arun() taskmethod that,whenexecuted,willcallap1.write(),ap2.write()andap3.write().

SNUG2018


class monitor1; analysis_if ap1; analysis_if ap2; analysis_if ap3; task run(); trans1 t = new(); repeat(5) begin void'(t.randomize()); $display("monitor: ", "**BROADCAST** addr=%2h data=%2h", t.addr, t.data); ap1.write(t); ap2.write(t); ap3.write(t); end endtask endclass

Example6‐monitor1withseparateanalysis_ifdeclarations–noconnect()methods

The top1 module, shown in Example 7, declares and new()–constructs the monitor1,subscriber1,subscriber2 andsubscriber3 class objects, then copies the subscriberhandlessub1,sub2andsub3totherespectiveanalysis_if(ap)handlesdeclaredinmonitor1.

module top1; import tb_pkg::*; monitor1 mon; subscriber1 sub1; subscriber2 sub2; subscriber3 sub3; initial begin mon = new(); sub1 = new(); sub2 = new(); sub3 = new(); mon.ap1 = sub1; mon.ap2 = sub2; mon.ap3 = sub3; mon.run(); end endmodule

Example7‐top1modulewithsubscriberhandlescopiedtoaphandlesinmonitor1

When this simulation is run, themonitor1run()–task calls all thewrite()methods fromeachap[#]object.thesimulationloops5times(repeat(5)),eachtimere‐randomizingthetransaction.monitor1thenbroadcaststhetransaction,andeachsubscriber[#]write()methodreceivesanddisplaystherandomizedtransactionvalues.Eachsubscriberre‐prints thecurrentcontentsof thetransactionsinceeachsubscriberhasahandletothesamebroadcasttransaction.

SNUG2018


ThesimulationresultsareshowninFigure1.

Randomized trans1 values addr=f9 data=50 monitor: **BROADCAST** addr=f9 data=50 subscriber1: received addr=f9 data=50 subscriber2: received addr=f9 data=50 subscriber3: received addr=f9 data=50 Randomized trans1 values addr=e9 data=27 monitor: **BROADCAST** addr=e9 data=27 subscriber1: received addr=e9 data=27 subscriber2: received addr=e9 data=27 subscriber3: received addr=e9 data=27 Randomized trans1 values addr=1f data=18 monitor: **BROADCAST** addr=1f data=18 subscriber1: received addr=1f data=18 subscriber2: received addr=1f data=18 subscriber3: received addr=1f data=18 Randomized trans1 values addr=8f data=4d monitor: **BROADCAST** addr=8f data=4d subscriber1: received addr=8f data=4d subscriber2: received addr=8f data=4d subscriber3: received addr=8f data=4d Randomized trans1 values addr=1e data=7e monitor: **BROADCAST** addr=1e data=7e subscriber1: received addr=1e data=7e subscriber2: received addr=1e data=7e subscriber3: received addr=1e data=7e

Figure1‐Monitor&subscribers–Simulationoutput

Scenario1showsthatacommontransactioncanbebroadcasttomultipleobserversorsubscribers.Oneproblemwith this scenario is thateach timeanewsubscriber isadded to thetop1module,anotheranalysis_ifportmustbedeclaredinmonitor1,andtherun()taskmustaddanothercalltothenewanalysis_ifwrite()method.

Ofcoursethetop1modulewouldalsoneedtodeclare,new()‐constructanothersubscriber [#]andcopytheconstructedhandletothenewmonitor1ap[#]handle.Eachnewsubscriberrequirestwoexistingfilestobeupdated.

Inthisscenario,top1needstoknowtheinternalhandlenamesofeachanalysis_if.Itwouldbebettertohaveaconnect()methodtomaketheconnectionsandhidetheinternalanalysis_ifhandlenames.Scenario2willaddthedesiredconnect()method.

2.2.3Scenario2‐monitor2withseparateanalysis_ifandconnect()methoddeclarations

Inthesecondscenario,monitor2,showninExample8,declaresthreeanalysis_ifhandleswithhandlenamesap1,ap2andap3.

monitor2alsohasaddedaconnect()methodforeachindividualanalysis_if.

SNUG2018


class monitor2; analysis_if ap1; analysis_if ap2; analysis_if ap3; function void connect1 (analysis_if port); ap1 = port; endfunction function void connect2 (analysis_if port); ap2 = port; endfunction function void connect3 (analysis_if port); ap3 = port; endfunction task run(); trans1 t = new(); repeat(5) begin void'(t.randomize()); $display("monitor: ", "**BROADCAST** addr=%2h data=%2h", t.addr, t.data); ap1.write(t); ap2.write(t); ap3.write(t); end endtask endclass

Example8‐monitor2withseparateanalysis_ifandconnect()methoddeclarations

Itisstartingtobecomeobviousthattheadditionofeachnewanalysis_ifsubscriberrequirestheoverheadofdeclaringanewanalysis_ifhandle,acorrespondingconnect()methodandacalltotheap[#].write()method.Inscenario3,alloftheseissueswillbeaddressed.

module top2; import tb_pkg::*; monitor2 mon; subscriber1 sub1; subscriber2 sub2; subscriber3 sub3; initial begin mon = new(); sub1 = new(); sub2 = new(); sub3 = new(); mon.connect1(sub1); mon.connect2(sub2); mon.connect3(sub3); mon.run(); end endmodule

Example9‐top2modulewithcallstoseparateconnect()methods

SNUG2018


Thetop2module,showninExample9,declaresandnew()–constructsthemonitor1,subscriber1,subscriber2 andsubscriber3 classobjects, thencalls themonitor2connect[#]()method tocopythehandlessub1,sub2andsub3 totherespectiveanalysis_if (ap )handlesdeclaredinmonitor2.Thetop2modulenolongerneedstoknowtheinternalap[#]handlenames.

Oneproblemthatexistedinscenario1stillexistswiththisscenario.Theproblemisthateachtimeanew subscriber is added to the top2 module, another analysis_if port must be declared inmonitor2,andtherun() taskmustaddanothercall to thenewanalysis_ifwrite()method.Scenario2alsorequirestheadditionofanewconnect()methodforeachnewanalysis_ifhandle.

Ofcoursethetop2modulewouldalsoneedtodeclare,new()‐constructanothersubscriber [#]andconnecttheconstructedhandletothenewmonitor2ap[#]handle.Eachnewsubscriberstillrequirestwoexistingfilestobeupdated.

Whenthesimulationisrun,themonitor2run()–taskcallsallthewrite()methodsfromeachap[#]object. The simulation loops 5 times ( repeat(5) ), each time re‐randomizing the transaction.monitor2thenbroadcaststhetransaction,andeachsubscriber[#]write()methodreceivesanddisplaystherandomizedtransactionvalues.Eachsubscriberre‐prints thecurrentcontentsof thetransactionsinceeachsubscriberhasahandletothesamebroadcasttransaction.

ThesimulationresultsarethesameasthoseshowninFigure1.

2.2.4Scenario3‐monitor3withanalys_ifqueueandcommonconnect()method

Scenario3solvestheproblemsthatrequiredustomodifymonitor1andmonitor2.Inmonitor3,showninExample10,anunboundedqueueofanlysis_ifportsisdeclared:analysis_if ap[$];

Inmonitor3,eachtimetheconnect()methodiscalled,anewsubscriberhandleispush_back–addedtotheap–queue.

Alsoinmonitor3,whentherun()taskiscalled,aforeach–loopcallseachofthewrite()methodsforthequeuedsubscriberhandles. class monitor3; analysis_if ap[$]; // queue of analysis_if ports // Each call to connect will push_back another // analysis_if port onto the ap-queue function void connect (analysis_if port); ap.push_back(port); endfunction task run(); trans1 t = new(); repeat(5) begin void'(t.randomize()); $display("monitor: ", "**BROADCAST** addr=%2h data=%2h", t.addr, t.data); // Call the write method for each port on the ap-queue foreach(ap[i]) ap[i].write(t); end endtask endclass

Example10‐monitor3withanalysisqueueandcommonconnect()method

These three improvements make it possible to add more subscribers without making multiple

SNUG2018


modifications to the monitor3 class. This is roughly how uvm_analysis_ports anduvm_subscriberswork.

Thetop3module,showninExample11,cannowcallacommonconnect()methodeachtimeanewsubscriberisaddedtothedesign.

module top3; import tb_pkg::*; monitor3 mon; subscriber1 sub1; subscriber2 sub2; subscriber3 sub3; initial begin mon = new(); sub1 = new(); sub2 = new(); sub3 = new(); mon.connect(sub1); mon.connect(sub2); mon.connect(sub3); mon.run(); end endmodule

Example11‐top3modulewithcallstocommonconnect()methodthatpushessubscriberhandlesontoqueue

SNUG2018


Scenario4–Buggyexamplewheresubscriber2modifiesthetransaction

In scenario 4, the simulation was run with the +define+BUG compilation switch to forcesubscriber2tomodifytheaddranddatafieldsofthebroadcasttransaction.

AscanbeseeninFigure2,aftersubscriber2modifiestheaddranddatafields,subscriber3readsthe fields from the referenced transactionhandleanddisplays theupdatedvalues.subscriber3shouldhaveactedupontheoriginaladdranddatafields.

Randomized trans1 values addr=f9 data=50 monitor: **BROADCAST** addr=f9 data=50 subscriber1: received addr=f9 data=50 subscriber2: received addr=f9 data=50 subscriber2: set addr=ff data=00 subscriber3: received addr=ff data=00 Randomized trans1 values addr=e9 data=27 monitor: **BROADCAST** addr=e9 data=27 subscriber1: received addr=e9 data=27 subscriber2: received addr=e9 data=27 subscriber2: set addr=ff data=00 subscriber3: received addr=ff data=00 Randomized trans1 values addr=1f data=18 monitor: **BROADCAST** addr=1f data=18 subscriber1: received addr=1f data=18 subscriber2: received addr=1f data=18 subscriber2: set addr=ff data=00 subscriber3: received addr=ff data=00 Randomized trans1 values addr=8f data=4d monitor: **BROADCAST** addr=8f data=4d subscriber1: received addr=8f data=4d subscriber2: received addr=8f data=4d subscriber2: set addr=ff data=00 subscriber3: received addr=ff data=00 Randomized trans1 values addr=1e data=7e monitor: **BROADCAST** addr=1e data=7e subscriber1: received addr=1e data=7e subscriber2: received addr=1e data=7e subscriber2: set addr=ff data=00 subscriber3: received addr=ff data=00

Figure2‐Monitor&subscribers–Buggysimulationoutput

Broadcast transactions from an analysis_port should never be modified. This is why thetransactioncopy()commandissovitaltoaUVMtestbenchenvironment.Thescoreboardpredictorshouldmake a copy of the broadcast transaction, then it reads the copied‐transaction inputs tocalculatethepredictedoutput.Thepredictedoutputisthenplacedintothecopiedtransactionforcomparisontotheactualbroadcasttransaction.Theoriginaltransactionshouldneverbemodified.

Guideline:Modifyingthefieldsofananalysis_portbroadcasttransactionshouldneverbedone.

SNUG2018


UVManalysis_port.write()versusanalysis_impwrite()method

In this simplified example, eachmonitor had arun()method that called each of the subscriberwrite()methods.

InUVMtheuvm_analysis_portcallsananalysis_port.write(tr)methodtobroadcastatrtransaction.Eachuvm_analysis_impdefinesawrite()methodthatisexecutedwhentheanalysisportcallsthewrite()method.Thereareprosandconstothisnamingconvention.

The port.write() command actually reads each uvm_analysis_imp handle and then calls thewrite()methodforeachhandle.Theadvantagetothisapproachisthatanengineeronlyneedstoremember that there is a write() command that broadcasts the transaction and a write()commandattheendofeachanalysispaththatisexecuted.Thedisadvantagetothisapproachisthatengineers often mistakenly think the port.write() command is an actual call to theuvm_analysis_impwrite()method.Theport.write()methodcouldhavebeennamedanything,includingport.broadcast()aslongastheport.command() itselfcalledtherespectivesubscriberwrite()methods.

In short, port.write() is not the same as the subscriber write() methods. The port.write()method CALLS the subscriber write() methods. The port.write() command could have beennamed anything, but the developers of UVM decided to keep the broadcast and implementationmethodnamesthesame.

SNUG2018


3.UVMPortFundamentalsTheUVMBaseClassLibrary(BCL)includesbaseportclassesthatareextendedtodefinetheTLM1(TransactionLevelModel1)portsthatareusedinUVMverificationenvironments.

3.1UVMportconnectionchains

UVMTLMconnectionsincludechainsofport(s)–(exports(s)(optional))–imp(s)(implementations).

Figure3‐Commonanalysisportconnections–recommendedconnections

3.1.1UVMPorts

UVMportsinitiatetransactionactivityandcanconnectto:(1)otherUVMports,(2)UVMexports,and(3)UVMimps.

3.1.2UVMExports

UVMexportsarebasicallytransfer‐portsthatcanconnectto:(1)otherUVMexports,and(2)UVMimps.

3.1.3UVMImps

UVMimps(implementations)terminateachainofport(s)‐(export(s))‐imp.

3.1.4Unfortunateportnamingconvention

AnunfortunatenamingconventioninsideofUVMmakestheimp‐connectionsratherconfusing.UVMdocumentationteachesaboutportsconnectingtoexportsandissomewhatvagueaboutimps.Infacttheuvm_sequencerbaseclassincludesaseq_item_exporthandledeclaration,butthisso‐called"export"handleisreallyauvm_seq_item_pull_impporttype.Similarly,theuvm_subscriberbaseclass, which is frequently extended to help create scoreboards and coverage collectors, has ananalysis_export handle declaration, but this so‐called "export" handle is really auvm_analysis_impporttype.

SNUG2018


3.1.5Port‐Export‐Impchains

Most port‐export‐imp chains only allow a single connection point. The driver‐sequencer is acommonexampleinUVMwherethedriverport(seq_item_port)connectstothesequencerexport(seq_item_export–whichisreallyanimplementationport).

ThebroadcastporttypeinUVMistheuvm_analysis_port.Thisporttypeisallowedtoconnecttomultipleport‐export‐impchains,eachofwhichmustterminatewithauvm_analysis_imp.

Figure3(onpage15)showstwocommonanalysispathsthatareusedinaUVMtestbench.

The common sets of paths are shown in Figure 4. The first analysis paths originate with auvm_analysis_portonthetb_monitorthatbroadcaststoanotheruvm_analysis_portonthetb_agent,whichthenbranchesintotwopathswiththefirstpath(labeledPath#1)terminatingattheuvm_analysis_imp onthetb_covercoveragecollector.Thesecondbranchfromthetb_agentconnectstotheuvm_analysis_exportonthetb_scoreboard.Theuvm_analysis_exportonthetb_scoreboardthenbranchesintotwopathswiththefirstpath(labeledpath#2)terminatingatauvm_analysis_imp port on the sb_predictor (extended from the uvm_subscriber), and thesecondpath(labeledpath#3)connectstoauvm_analysis_exportonthesb_comparator,whichthen terminates at a uvm_analysis_imp on the uvm_tlm_analysis_fifo with handle nameoutfifo.

Figure4‐Analysispaths‐firstsetofthreepaths

The second analysis path is shown in Figure 5 on page 9. The analysis path starts with auvm_analysis_port on thesb_predictor that connects to theuvm_analysis_export on thesb_comparator and terminates at auvm_analysis_imp on theuvm_tlm_analysis_fifowithhandlenameexpfifo.

SNUG2018


Figure5‐Analysispaths‐secondsetofpaths‐justonepath

3.1.6UVMPort&Exportinterchangability?

Aninterestingfactaboutanalysisportsandexportsisthattheyarelargelyinterchangeable,exceptfortheoriginatinguvm_analysis_portthatisresponsibleforbroadcastingthetransaction.

Replacingalloftheuvm_analysis_export(s)(asshowninFigure3)withuvm_analysis_port(s)(asshowninFigure6)doesnotchangethebehavioroftheUVMtestbench.Replacingtheexportswithnon‐broadcastingportsjustchangesthetypeoftransferport.ThesimulationcontinuestorunthesameasitdidinFigure3.

Figure6‐NOTRecommended–analysisports&noanalysisexports(butitworks!)

Similarly,replacingallofthenon‐broadcastinguvm_analysis_port(s)(asshowninFigure3)withuvm_analysis_export(s) (as shown in Figure 7) does not change the behavior of the UVMtestbench.Replacingthenon‐broadcastingportswithexportsjustchangesthetypeoftransferport.ThesimulationcontinuestorunthesameasitdidinFigure3.

SNUG2018


Figure7‐NOTRecommended–analysisexports&1analysisportperanalysissource(butitworks!)

3.1.7UVMPort&Exportusageguidelines

Wedonot recommend randomly replacingexportswithports andportswithexports since thepracticeisconfusingtomostUVMverificationengineers.

Guideline:useuvm_analysis_port(s)forcomponentoutputsthatareforwardingatransactiontootherportsonananlysispath,asshowninFigure8

Figure8‐UVManalysisports–recommendedusageblockdiagram

Guideline: useuvm_analysis_export(s) oruvm_analysis_imp for component inputs that arereceivingatransactionfromotherportsonananlysispath,asshowninFigure9.

Figure9‐UVManalysisexports&imps–recommendedusageblockdiagram

SNUG2018


3.2uvm_port_baseconnect()method

Thevirtualuvm_port_baseclassincludesmultiplemethods,virtualandnon‐virtual,thatareused to define theTLM1port types. Among themethods in theuvm_port_base is thevirtualconnect()method.Thevirtualconnect()methodincludes46linesofcodethatperformscertainimportantinspectionstoensurethattheTLMconnectionsarelegal.

Theconnect()methodincludesfunctionalitythatexaminestheUVMtestbenchcodetomakesurethataUVMexportisnotconnectedtoaUVMport.Theportmustconnecttoanexport.Similarly,theuvm_port_baseconnect()methodcheckstomakesureaUVMimpisnotconnectedtoanyotherport.Theportorexportmustconnecttoafinalimp.

3.3Scopeofportdiscussioninthispaper

A full understanding of all of the different UVM port types, how they can be connected and themethods that are available to pass transactions between components using TLM1 and TLM2 isbeyondthescopeofthispaper.

Thispaperfocusesontheuseoftheanalysisport‐chains,someoftheunderlyingimplementationbasics and theproperuse ofmethodswithin analysis‐chains. This paper alsodescribes commonmistakesthataremadewithanalysischainsandhowthosemistakesmanifestthemselvesinaUVMverificationenvironment.Theproperuseofthetransactioncopy()methodisusedtoavoidmanyanalysis‐chainproblems,andisdiscussedinthispaper.

SNUG2018


4.UVManalysisports,exportsandimpsTheUVManalysispathoriginateswithauvm_analysis_portthatbroadcastsatransaction,whichcanpassthroughoneormoreuvm_analysis_port(s)and/oruvm_analysis_export(s),andhasone or more uvm_analysis_imp termination points. If a uvm_analysis_port connects to anyuvm_analysis_export(s),thentheremustbeauvm_analysis_impattheendofeachanalysispathchain. It is legal for auvm_analysis_port to connect to otheruvm_analysis_port(s)withoutconnectingtoanyuvm_analysis_export(s)oruvm_analysis_imp.Thisisanalogoustoasatellitebroadcastwherenobodyiswatchingorrecordingtheprogram.Thesatellitedoesnotquerytofindoutifanybodyiswatchingthebroadcastprogramandtheuvm_analysis_portdoesnotquerytofindoutifthereareanyuvm_analysis_impterminationpointsontheUVManalysispath.

Detailsaboutthesedifferentporttypesaredescribedbelow.

4.1uvm_analysis_port‐broadcastport

Asalreadynoted,theuvm_analysis_port isabroadcastportthatbroadcastsatransactionfromtheportuntilitreacheszeroormoreuvm_analysis_impportswherethetransactioniseitherusedimmediately(in0‐time),oracopyofthetransactionismadesothatthecopycanbemanipulatedovertimewithoutmodifyingtheoriginalbroadcasttransaction.Thisiswhythetransactioncopy()commandIsoimportant(seeSection4.1.1).

Auvm_analysis_portcanbeconnectedtootheruvm_analysis_ports,uvm_analysis_exportsanduvm_analysis_imps,butthereisonlyoneuvm_analysis_impperanalysispath.

4.1.1Whyisthetransactioncopy()methodsoimportant?

Any component that needs to use the transaction over multiple cycles must take a copy of thetransactionbecausethebroadcasttransactioncanbechangedatanytimeandthereisnowayforacomponenttocommunicatetotheuvm_analysis_porttoholdtheoriginaltransaction.

Anycomponentthatneedstomodifyanyofthefieldsofthetransactionmustalsotakeacopyofthetransactionbecausetheremaybemanycomponentsthatareaccessingthebroadcasttransaction;therefore,modifyingthefieldsofthebroadcasttransactionwillcauseproblemsforothersubscribersthatneededtoaccesstheoriginaltransactioncontents.

Even if therearenoothersubscribers,acomponentshould takeacopyof the transactionbeforemodifyinganyfields,sinceanothercomponentmightlaterbeaddedtotheanalysispathanditwouldrelyonanoriginalunmodifiedtransaction.

4.2uvm_analysis_export–transferport

The uvm_analysis_export is little more than a transfer‐point connection between thebroadcasting uvm_analysis_port source and each uvm_analysis_imp termination point.uvm_analysis_export(s)canbeviewedasatransferport.

4.3uvm_analysis_imp–terminationport

Auvm_analysis_impprovidestherequiredwrite()methodimplementationtoterminateaUVManalysis path. The verification engineer is required to override the write() method with animplementationfortheuvm_analysis_imp.

SNUG2018


4.4port,export,impconfusion

When it comes to the behavior ofports, exports (and imps), there is a great deal of confusionsurroundingthesenames.Portsinitiateactivitybyexecutingcommandswhileexports(andimps)are the targetsof the commandsandactuallyprovide the implementationof the commands. FormanyengineersnewtoTransactionLevelModeling thisseemsbackwards.Manybelieve that theinitiatoristheexportandthetargetshouldbetheport.Whatisthereasoningbehindthesenames?Thiscanbebestdescribedwithanexample.

4.4.1Driver–Car/Port‐Export

Everycarhasasteeringwheel.Whenthedriverturnsthesteeringwheelintheclockwisedirection,thecarturnstotheright.Whenthewheelismovedinthecounterclockwisedirectionthecarturnstotheleft.Thedriverdoesnotnecessarilyknowifthesteeringisaccomplishedthroughrackandpinionsteering,powersteering,steer‐by‐wireorsomeothermechanism.Thedriverjustknowshowtoturnthesteeringwheeltomakethecarturntotherightortheleft.

Everycarhasanacceleratorpedal.Whenthedriverpushesontheacceleratorpedal,thecarwillaccelerate.Whenthedriverletsuponthepedal,thecarwillcoastandslowdown.Thedriverdoesnotknow if theacceleration isaccomplished throughacarburetor, fuel injectionorsometypeofelectricmotor.Thedriverjustknowsthatpushingtheacceleratorpedalwillincreasethecarspeedwhilelettinguponthepedalwillcausethecartocoastandslowdown.

Everycarhasabrakepedal.Whenthedriverpushesonthebrakepedal,thecarwillslowdownandstop.Whenthedriverletsuponthebrakepedalthecarwillstarttomoveandcannowbeaccelerated.The driver does not know if the braking system uses disc brakes, drum brakes or some type ofelectronicrecoveryandbatterychargingsystem.Thedriverjustknowsthatdepressingthebrakepedalslows thecarorbrings it toastop,andthatreleasing thebrakepedalallowsthecar togoforwardagain.

Ineachofthesescenarios,thedriverissuesthecommandsbutdoesnothavetheabilitytoexecuteanyofthedescribedactions.Itisthecarthatmustexporttothedriverthecapabilitiesthatthedriverwillcontrol,but it isthecarthathastheactual implementationofeachoftherequiredfunctions.Similarly,thecarcannotexecuteanyofthecommandsautonomouslybutmustwaituntiladriverinitiatestheappropriatecommands.Thedriveristheinitiator‐port,whilethecaristhetarget‐export.

Note,thedrivercannotsuccessfullyissueanycommandthatisnotexportedbythecar.Thedrivermighttrytoplaceahands‐freecallovertheautomobileBluetoothconnectiontothedriver'smobilephone, but if the car does not export theBluetooth‐Phone control capability (because it is not afeature of that particular car), such a commandby the driverwill fail. Thedriver can only issuecommandsthatareexportedtothedriverbythecar.

ThisiswhathappenswithTLMconnections.Theportcanonlyexecutecommandsthatareexportedbytheconnectedexportorimp.

4.4.2Export,impconfusion

TheUVMdocumentationdescribesallconnectionsasport‐exportconnections,butinreality,itisanimp(implementationexport)thatprovidestheactualexportedfunctionality.TwoexamplesfoundincommonUVMtestbenchesinclude:

Driverseq_item_portconnectstothesequencerseq_item_export.

1. seq_item_portisjustthehandlenameoftheuvm_seq_item_pull_port(port)2. seq_item_exportisjustthehandlenameoftheuvm_seq_item_pull_imp(imp‐lementation)

SNUG2018


TheUVMsubscribercomponenthasabuilt‐inanalysis_export,which is really just thehandlenameforauvm_analysis_imp(imp‐lementation).

TheUVMdocumentationseeminglytriestohidetheexistenceofimpsbygivingthem"export"handlenames insteadof"imp"handlenames.Wepersonallybelieve it isamistaketodeclare impswith"export"handlenamesbutthatishowtheUVMbaseclassesaredefinedsoanengineerjusthastounderstandthisnaminginconsistency.

5.Declaringandconstructingports&TLMFIFOsTLMFIFOisanimportantcomponentthatisusedfortestbenchsynchronization,especiallyinaUVMscoreboard.TLMFIFOsarebuiltfromSystemVerilogmailboxes.MailboxesaredescribedinSection7.TLMFIFOsaredescribedinSection8.

PortsandTLMFIFOsareUVMbaseclassesthatareNOTregisteredwiththefactoryandareuseddirectlyinaUVMtestbench.Becausetheyarenotregisteredwiththefactoryandbecausetheyareuseddirectly,theyarenew()‐constructedandnotfactory::type_id::create‐ed.

5.1HowareanalysisportsandTLMFIFOsdeclared?

The declaration of the different analysis port types has a subtle difference. An exampleuvm_analysis_portisdeclaredwiththetransactiontypeparameterdisplayednearthetopofthetb_monitorclassshowninExample12.Thedeclarationrequiresthetransaction‐typeparameter.Inthisexample,thetb_monitorbroadcastsatransactionusingtheap.write()commandintherun_phase().

class tb_monitor extends uvm_monitor; ... uvm_analysis_port #(trans1) ap; ... function void build_phase(uvm_phase phase); ... ap = new("ap", this); // build the analysis port ... task run_phase(uvm_phase phase); ... ap.write(tr);

Example12‐tb_monitorwithuvm_analysis_portdeclarationandap.write()command

SNUG2018


Anexampleuvm_analysis_exportisdeclaredwiththetransactiontypeparameterdisplayednearthetopofthetb_scoreboardclassshowninExample13.Thedeclarationrequiresthetransaction‐type parameter. The uvm_analysis_export is typically connected to otheruvm_analysis_port(s),uvm_analysis_export(s) andpossibly oneuvm_analysis_imp. Therearenowmethodsthatneedtobeexcutedtopropagatetransactionsontheuvm_analysis_export.

class tb_scoreboard extends uvm_scoreboard; ... uvm_analysis_export #(trans1) axp; sb_predictor prd; sb_comparator cmp; ... function void build_phase(uvm_phase phase); axp = new("axp", this); prd = sb_predictor::type_id::create("prd", this); cmp = sb_comparator::type_id::create("cmp", this); endfunction function void connect_phase( uvm_phase phase ); axp.connect (prd.analysis_export); axp.connect (cmp.axp_out); endfunction ...

Example13‐tb_scoreboardwithuvm_analysis_exportdeclarationandconnectiontootheranalysis‐typeports

Theuvm_analysis_imp,unliketheuvm_analysis_portanduvm_analysis_exportdeclarations,is required to declare TWO parameters, the transaction type and the class name. An exampleuvm_analysis_impisdisplayednearthetopofthesb_predictorclassshowninExample14.Thedeclareduvm_analysis_impmustbebuiltandmustoverridethewrite()methodtoprovidetherequiredimplementation.

class sb_predictor extends uvm_component; ... uvm_analysis_imp #(trans1, sb_predictor) analysis_export; uvm_analysis_port #(trans1) results_ap; ... function void build_phase(uvm_phase phase); ... analysis_export = new("analysis_export", this); results_ap = new("results_ap", this); endfunction function void write(trans1 t); ... results_ap.write(exp_tr); ...

Example14‐sb_predictorwithuvm_analysis_impdeclarationandwrite()method

5.2WhereareTLMportsandTLMFIFOsconstructed?

The construction of TLM ports and TLM FIFOs can either be done in the component new()constructor,orinthebuild_phase()method.

SNUG2018


TheUVMClassRefence[4] has examples of constructingports andTLMFIFOs in the componentnew()‐constructor(e.g.Section14.TLM1Interfaces,Ports,ExportsandTransport Interfaces,andSection 16. Analysis Ports) and in the build_phase() (e.g. Section 14. TLM1 Interfaces, Ports,ExportsandTransportInterfaces(sameexample)).

Asidefromtheports,allcomponentsarebuiltinthebuild_phase()methodtoallowruntime,build‐this, factory lookupandcreationofcomponentsregisteredwith the factory.SinceportsandTLMFIFOsarenot registeredwith the factory, theydonothave tobe created in thebuild_phase()method.

That being said, we prefer to new()‐construct ports and FIFOs in the build_phase() of acomponent.Webelieveitmakesmoresensetoputallbuildingoffactory‐selectedcomponents,aswellasportsandTLMFIFOcomponentsinasingleplaceforeasyexamination.

Removingnew()‐constructionofportsandTLMFIFOsfromtheconstructoralsomeansthat90%+ofallcomponentconstructorscanusethesame identical,boring, three linesofnew()‐constuctorcode:

function new (string name, component parent); super.new(name, parent); endfunction

Inshort,itdoesnotmatterwhetherportsandFIFOsareplacedinthecomponentnew()‐constructororinthecomponentbuild_phase(),butweprefertoputtheminthebuild_phase().

5.3uvm_analysis_impportusageoptions

Whenterminatingananalysispath,therearethreeoptions.

Option#1:istoexplicitlydeclareuvm_analysis_impportsinsideofcomponents.Thisoptionhasthreeimportantrequirements:

(1) Unlike the uvm_analysis_port and uvm_analysis_export port declarations, theuvm_analysis_impdeclarationrequirestwoparameters,thetransactiontypeandthenameoftheclasswheretheuvm_analysis_impisdeclared.

(2) Theuvm_analysis_impmustbebuiltineitherthebuild_phase()(ourpreference)orinthecomponentnew()‐constructor.

(3) Theclasswiththeuvm_analysis_impdeclarationmustoverridethewrite()methodandprovideanimplementationforthatsamemethod.

Option#2:istodeclareacomponentthatisanextensionoftheuvm_subscriberbaseclass.Thisalternativeincludesapre‐declaredandconstructeduvm_analysis_imp.Theuserisonlyrequiredto override the write() method and provide an implementation for that same method. Theuvm_subscriberisdescribedinSection6.

Option #3: is to declare and build a uvm_tlm_analysis_fifo and then connect theuvm_tlm_analysis_fifo to a uvm_analysis_export on the component. Theuvm_tlm_analysis_fifohasalreadypre‐declaredauvm_analysis_impportwithcorrespondingwrite()methodtostorethetransactionintotheuvm_tlm_analysis_fifo.

SNUG2018


6.uvm_subscriberTheuvm_subscriberbaseclassisappropriatelynamed.Asubscriberisconnectedeitherdirectlyorindirectly to a uvm_analysis_port and provides the write() method required by auvm_analysis_imp.

6.1purevirtualwritefunction

Thepurekeywordisonlylegalinavirtualclass.Apurevirtualmethodisamethodthatisonlyaprototype in thevirtual class (only themethodheader)and requires that theextendedclassactuallyprovidethemethodimplementation.Theuvm_subscribervirtualclassincludesapurevirtualwrite()method.Anyclassthatextendstheuvm_subscribermustoverridethewrite()methodwithanactualimplementation.

6.2multipleuvm_analysis_impportsonthesamecomponent

Each uvm_analysis_imp requires a function called write(). When there are multipleuvm_analysis_imp(s)on thesamecomponent,eachmusthave itsownwrite()method,butofcourse,eachcomponentclassscopeisonlyallowedtohaveonemethodnamedwrite().Sowhatcanbedoneifmorethanoneuvm_analysis_impisrequiredonthesamecomponent?AsolutiontothisproblemisshowninSection9.

7.SystemVerilogmailboxThe SystemVerilog language added the mailbox keyword and a mailbox is a special type ofSystemVerilogqueueorFIFOthatisveryusefulinverificationenvironments.

Acircularqueueisasequentiallyaccessedmemorywithwriteandreadpointersthatwrapbacktozerowhen the queue depth is reached, thus allowing the reuse of eachmemory location as thepointers"wrap"backtolocationzero.

FIFOsarecircularqueuesdesignedwithafixednumberofaddressablewordsorentries.FIFOsalsohavefullandemptyflagstoindicatewhenalloftheavailablelocationshaveeitherbeenfilledoralloftheavailablelocationsareempty.

ASystemVerilogqueuecanhaveaboundedsize,likeaFIFO,orbeunboundedinsize,whichisthedefault.ASystemVerilogqueuecanbemanipulatedusingaqueue‐specificalgebrainSystemVerilog(seeIEEEStd1800‐2012[2]section7.10.1),ortheycanbemanipulatedusingqueue‐specificbuilt‐inmethods(seesection7.10.2).

7.1Mailbox–vs‐queue

SystemVerilogaddedboththequeueandmailboxdynamictypes,whichdidnotpreviouslyexistinVerilog.Aswillbedescribedlater,theuvm_tlm_fifoanduvm_tlm_analysis_fifobothusethemailboxandnotthequeuebecausethemailboxoffersanimportantblockingfeaturethatisusedinUVMscoreboards.

Boththequeueandmailboxcanbedeclaredtobeunbounded,whichistosaythatbothcanholdanunlimitednumberofentries,orbothcanbedeclaredtobebounded,whichistosaythedeclarationcanindicatethemaximumnumberofentriesallowedineach.

Both have put() and try_put() methods where the put() method is a built‐in task and thetry_put() isabuilt‐infunction. Sinceaqueueormailbox canbebounded, theymightbe full

SNUG2018


forcingtheput()commandtoblockforaperiodoftimeuntilthequeueormailboxhasspacetoallowanewentrytobeadded(whenacorrespondingget()ortry_get()hasremovedanitemfromthequeueormailbox).Thetry_put()commandisafunctionthatcompletesin0‐timebyeither successfully placing a new item on the queue or mailbox and returning status that thetry_put()commandsucceeded,orthetry_put() failsbecauseaboundedqueueormailbox isalready full, inwhich case thetry_put() command returns a "fail" status of0. If the queue ormailboxisunbounded,boththeput()andtry_put()commandswillalwayssucceedwiththeonlydifferencebeing that thetry_put() commandwill return status to indicate that thetry_put()operationsucceeded(returnsapositivevalueof1).

Thetry_put()methodcanbecalledbyeitherataskorfunctionsinceitcompletesin0‐time,whileaput()methodcanonlybecalledbyatasksincetheput()commandmightblockandconsumesimulationtime.

8.TLMFIFOsTherearetwotypesofbuilt‐inTLMFIFOsinUVM,(1)uvm_tlm_fifo,describedinSection8.2,and(2)uvm_tlm_analysis_fifo,describedinSection0.BothoftheseTLMFIFOsarederivativesoftheuvm_tlm_fifo_base class, descrbed in Section 8.1 TLM FIFOs are valuable synchronizationstructures that are commonly used in UVM, especially in scoreboards. We find theuvm_tlm_analysis_fifototypicallybemorevaluableinaUVMscoreboard.

8.1uvm_tlm_fifo_base

Theuvm_tlm_fifo_base virtual class in theUVMBaseClassLibrary (BCL)defines fourports, abuild_phase() method and 17 additional virtual methods. The purpose of theuvm_tlm_fifo_base class is to reserve method prototypes to be used by the uvm_tlm_fifo,extended from the uvm_tlm_fifo_base, and the uvm_tlm_analysis_fifo, extended from theuvm_tlm_fifo. Although legal, verification engineers typically do not extend theuvm_tlm_fifo_baseclass.

Figure10‐uvm_tlm_fifo_baseports

SNUG2018


As canbe seen in Figure10, theuvm_tlm_fifo_base class has two inputports and twooutputanalysisports.Theinputportshavemanyaliasednameswhiletheoutputuvm_analysis_port(s)onlyhavethenamesget_apandput_ap.TheporttypesandaliasednamesforthoseportsareshowninTable1.ThereservedmethodnamesandnotesaboutmethodimplementationareshowninTable2.

Table1‐uvm_tlm_fifo_baseportnamesandportnamealiases

Porttype Portnameoralias Portcommonlyusedinuvm_tlm_fifooruvm_tlm_analysis_fifo?

uvm_put_imp put_export

blocking_put_export

non_blocking_put_export

No

uvm_get_peek_imp get_peek_export blocking_get_export

non_blocking_get_export

get_export

blocking_peek_export

non_blocking_peek_export

peek_export

blocking_get_peek_export

non_blocking_get_peek_export

No

uvm_analysis_port put_ap No

uvm_analysis_port get_ap No

SNUG2018


Table2‐uvm_tlm_fifo_basemethodsandusagenotes

Virtualemptymethod

Note Nativemailboxmethod?

Implementedbyuvm_tlm_fifo?

Implementedbyuvm_tlm_analysis_fifo?

put() blocks Yes Yes Yes

get() blocks Yes Yes Yes

peek() blocks Yes Yes Yes

try_put() returnsbit Yes Yes Yes

try_get() returnsbit Yes Yes Yes

try_peek() returnsbit Yes Yes Yes

can_put() returnsbit No Yes Yes

can_get() returnsbit No Yes Yes

can_peek() returnsbit No Yes Yes

build_phase() UVMphase UVMphase

flush() clearsfifo No Yes Yes

ok_to_put() returnsuvm_tlm_event

Notimplemented

Notimplemented

Notimplemented

ok_to_get() returnsuvm_tlm_event

Notimplemented

Notimplemented

Notimplemented

ok_to_peek() returnsuvm_tlm_event

Notimplemented

Notimplemented

Notimplemented

is_empty() returnsbit No Yes Yes

is_full() returnsbit No Yes Yes

size() returnsint No Yes Yes

used() returnsint Yes Yes Yes

8.2uvm_tlm_fifo

Theuvm_tlm_fifocanbeusedinUVMscoreboarddesign.Theuvm_tlm_fifo is internallybuiltusingaSystemVerilogmailboxandisdefinedwithadefaultdepthof just1transaction,whichisnearlyuseless,butthiscanbechangedandisalsmostalwayschangedwhentheuvm_tlm_fifoisnew()‐constructed.

8.2.1uvm_tlm_fifonew()‐constructor&size

Thenew()constructorfortheuvm_tlm_fifotakesthreearguments,name,parentandsize.Thesizeargumenthasthedefaultdepthof1.Settingthesizeargumentto0causestheuvm_tlm_fifoto have unbounded depth, and setting the size to 0 is generally recommended for scoreboarddesigns.Note,theuvm_tlm_analysis_fifo,describedinSection0hasadefaultsizealreadysetto0,whichisgenerallyidealforverificationpurposes.

SNUG2018


The tb_scoreboard in Example 15 declares two uvm_tlm_fifo(s) to hold expected and actualtransactions.Botharenew()‐constructedwithanunboundedsizevalueof0,andbotharewrittentousingvoid‐castedtry_put()methods.Thewrite_prd() (write‐predictor)methodalso takesacopyofthebroadcasttransactionbeforepredictingandstoringthecorrectoutputvaluesintotheexpectedtransaction(etr). class tb_scoreboard extends uvm_scoreboard; `uvm_component_utils(tb_scoreboard) ... uvm_tlm_fifo #(trans1) expfifo; uvm_tlm_fifo #(trans1) outfifo; ... function void build_phase(uvm_phase phase); super.build_phase(phase); ... expfifo = new("expfifo", this, 0); // Unbounded tlm_fifo outfifo = new("outfifo", this, 0); // Unbounded tlm_fifo endfunction function void write_prd(trans1 tr); ... etr.copy(tr); // create copy of tr object ... void'(expfifo.try_put(etr)); endfunction function void write_out(trans1 tr); void'(outfifo.try_put(tr)); endfunction task run_phase(uvm_phase phase); forever begin expfifo.get(exp_tr); outfifo.get(out_tr); ...

Example15‐tb_scoreboardthatusestwouvm_tlm_fifo(s)

8.2.2uvm_tlm_fifoput()&try_put()methods

Since theuvm_tlm_fifo is extended from theuvm_tlm_fifo_base, theuvm_tlm_fifo has twoinputportsandtwouvm_analysis_port(s).Althoughitispossibletoconnecttoanyoftheseports,theyarefrequentlyleftunconnectedinascoreboarddesign.

The put() and try_put() methods store transactions into the uvm_tlm_fifo mailbox. Thesecommandsalsobroadcastthesametransactionoutoftheput_apasshowninFigure11.Theput_apuvm_analysis_portisrarelyused.

Setting the uvm_tlm_fifo size to 0 means that the put() and try_put() methods bothautomaticallysucceed,withthelatterreturningastatusvalue,whichwillalwaysindicatethatthetry_put()actionsucceeded.

Generallywhencallingthetry_put()methodonanunboundeduvm_tlm_fifoavoid‐castisusedtothrowawaythereturnvalue(asshowninExample15).

SNUG2018


Since the write() method defined for auvm_analysis_imp is a function, only the try_put()method canbeused towrite to themailbox even thoughbothwould succeed for anunboundeduvm_tlm_fifo.1

Figure11‐uvm_tlm_fifoput()andget()methodbehavior

8.2.3uvm_tlm_fifoget()&try_get()methods

Theget()andtry_get()methodsretrievetransactionsfromtheuvm_tlm_fifomailbox.Thesecommandsalsobroadcastthesametransactionoutoftheget_apasshowninFigure11.Theget_apuvm_analysis_portisrarelyused.

get()isablockingtaskthatwaitsuntilthereisatransactioninthemailboxoftheuvm_tlm_fifotoberetrieved.Theblockingget()commandisidealforuseinascoreboardcomparatorsinceitwaits (blocks) until a transaction is available to retrieve. There is no equivalent blockingget()methoddefined for theSystemVerilogqueue,which iswhy theuvm_tlm_fifo is abetter choiceinsteadofusingaqueueinascoreboardcomparator.

Engineerswhotrytouseaqueueinascoreboardcomparatortypicallyhavetoeitherdosamplingoruseeventtriggerstowaituntilthereisaqueuedtransactionthatcanbeproperlyextracted.

8.2.4uvm_tlm_fifodisadvantage

Placing a uvm_tlm_fifo into an analysis path has the disadvantage that the scorebard mustsomewhereimplementauvm_analysis_impwrite()methodtoreceivethebroadcasttransactionand then does thevoid'(try_put(etr)) to store the transaction into theuvm_tlm_fifo. Theuvm_tlm_analysis_fifo described in the next section removes the need to implement thewrite()methodtoexecutethetry_put()command.

1Note:oneoftheEDAvendorsusedtoallow(andmaystillallow)theput()methodtobecalledfrom the uvm_analysis_imp write() method when the uvm_tlm_fifo was declared to beunbounded,becausetheput()methodwouldexecutein0‐timeandsucceed.TheotherEDAvendorsproperly disallowed the put() method since it should not be legal to call a put() task from awrite() function.We recommend that engineers not use a put() method with an unboundeduvm_tlm_fifoevenifyourchosenvendorallowstheoperation.

SNUG2018


8.3uvm_tlm_analysis_fifo

Theuvm_tlm_analysis_fifoextendstheuvm_tlm_fifo(describedinSection8.2)andthereforeinheritsalloftheportsandcapabilitiesoftheuvm_tlm_fifo.

Theuvm_tlm_analysis_fifohasfiveports;thesamefourportsdefinedintheuvm_tlm_fifoasdescribed in Section 8.2 plus one additional uvm_analysis_imp port with handle nameanalysis_exportasshowninFigure12.Thefouruvm_tlm_fifoinheritedportsarerarelyusedinaUVMscoreboard.

Figure12‐uvm_tlm_analysis_fifo–mostcommonusage

The uvm_tlm_analysis_fifo is ideal to store transactions that were broadcast from auvm_analysis_port. Within an analysis path, the uvm_tlm_analysis_fifo has two distinctadvantagesovertheuvm_tlm_fifo:(1)bydefault,theuvm_tlm_analysis_fifohasunboundedsize,whichisperfectforUVMscoreboarddevelopment,and(2)theuvm_tlm_analysis_fifohasabuilt‐in uvm_analysis_imp port with corresponding write() method to store the broadcasttransaction.

Unliketheuvm_tlm_fifo,theuvm_tlm_analysis_fifohasanextrauvm_analysis_impportthatmust be connected inside of the scoreboard. Section 8.4 describes and graphically shows thedifferencesbetweenusingtheuvm_tlm_fifoversustheuvm_tlm_analysis_fifoinascoreboarddesign.

8.4Quick‐summaryofuvm_tlm_analysis_fifo–vs‐uvm_tlm_fifo

Most UVM scoreboards are most efficiently implemented using unbounded TLM FIFOs. Theuvm_tlm_analysis_fifo isunboundedbydefault,whichisperfectforscoreboarddevelopment.Theuvm_tlm_fifomustbenew()‐constructedwithasize=0 tobecomeunbounded.This isaminoradvantagetousingtheuvm_tlm_analysis_fifo.

The biggest advantage of the uvm_tlm_analysis_fifo over the uvm_tlm_fifo is that theuvm_tlm_analysis_fifo has a built‐in uvm_analysis_imp port with corresponding built‐inwrite() method to capture transactions that were broadcast from an analysis port. This is anextremelyusefuladvantageovertheuvm_tlm_fifoandsavesagreatdealofworkindevelopingaUVMscoreboard.

SNUG2018


ThesedifferencesareshowngraphicallyinFigure13.

Figure13‐uvm_tlm_fifo–vs‐uvm_tlm_analysis_fifousage

Comparing the usage requirements of the uvm_tlm_fifo to the uvm_tlm_analysis_fifo in ascoreboard,asshowninFigure13,isdescribedbelow:

(1) The uvm_tlm_fifo typically requires the declaration and construction of a separateuvm_analysis_imp (or uvm_subscriber with built‐in uvm_analysis_imp) and thenrequires the implementation of a corresponding write() method, which uses avoid'(try_put()) call to store the transaction into the uvm_tlm_fifo. Of course theseparateuvm_tlm_fifomustalsobedeclaredandconstructed.

(2) The uvm_tlm_analysis_fifo typically requires the declaration and construction ofseparate uvm_analysis_export and the uvm_tlm_analysis_fifo. Theuvm_analysis_export port is then connected to the uvm_tlm_analysis_fifo. Theuvm_tlm_analysis_fifoalreadyhastherequireduvm_analysis_impandcorrespondingwrite()method.

9.ùvm_analysis_imp_decl(SFX)macroIftherearemultipleuvm_analysis_imp(s)inacomponent,theusermustdefinemultipleuniquelynameduvm_analysis_imp_SFXportswithcorrespondingwrite_SFX()methods.

UVMhasamacrotodefinenewuvm_analysis_impportswithuniqueport‐suffixnamesanduniquewrite‐method‐suffixnames.Themacroisùvm_analysis_imp_decl(SFX).Thismacroistypicallyusedforeachuvm_analysis_impportonamulti‐uvm_analysis_impcomponent.

ThefirsttwolinesofExample16usetheùvm_analysis_imp_decl(SFX)macros.TheSFXvaluescanbenumbersorcharactersandcanincludethe"_"asshowninthisexampleoromitthe"_".Thisexampleusessuffixvaluesof"_prd"for"predictor"and"_out"for"output."

Usingthe ùvm_analysis_imp_decl(SFX)macroswilldefinetwonewuvm_analysis_impporttypesthatmustincludethesuffixvaluesdeclaredinthemacros.Inthisexample,theporttypesareuvm_analysis_imp_prdanduvm_analysis_imp_out.Themacrosalsocreatetwonewwrite()methodsthatmustincludethesuffixvaluesdeclaredinthemacros.Inthisexample,thewritemethod

SNUG2018


namesarewrite_prd()andwrite_out()andthesearethecorrespondingwritemethodsfortheuvm_analysis_imp_prdanduvm_analysis_imp_outportsrespectively.

Notethattheuvm_analysis_imp_SFXhandlenamesarenotrequiredtousetheSFXvalues,butwebelieve it is a good idea to use the suffix names as part of the handle names to reduce codingconfusion.

ùvm_analysis_imp_decl(_prd) ùvm_analysis_imp_decl(_out) class tb_scoreboard extends uvm_scoreboard; ùvm_component_utils(tb_scoreboard) ... uvm_analysis_imp_prd #(trans1, tb_scoreboard) ap_prd; uvm_analysis_imp_out #(trans1, tb_scoreboard) ap_out; ... function void build_phase(uvm_phase phase); super.build_phase(phase); ap_prd = new("ap_prd", this); ap_out = new("ap_out", this); ... endfunction function void write_prd(trans1 tr); ... function void write_out(trans1 tr); ...

Example16‐tb_scoreboardwithtwoùvm_analysis_imp_decl(SFX)macros,portsandwrite()methods

9.1Howmanyportsareallowedonascoreboard?

Wehavetalkedtoasurprisinglylargenumberofengineerswhowereundertheimpressionthatascoreboardcouldhaveonlyoneortwoportsofanytypeandthattheyhadtousethesametransactiontypeonthe2‐portvariety.Thisisnottrue.

UVM scoreboards can have any number of ports, exports and imps and the ports can beparameterizedtoanynumberoftransactiontypes.

It is true that most block‐level scoreboards only have one or two input‐port types to sample acommontranscationandtoperformsimplecalculationsofexpectedvaluestocompareagainstactualsampledoutputvalues,butforlargerUVMenviironments,itisnotuncommontohavemultipleportsthatareparameterizedtomultiple transaction typesandthenallowthescoreboard toperformatransfer function on one of the transactions before comparing specific fields between multipletransactiontypes.

UVM even has a uvm_algorithmic_comparator documented in the UVM Class Reference[4](Section18.2)thatisdesignedforthispurpose.Theuvm_algorithmic_comparatorisdescribedasacomparatorthat:

SNUG2018


"compares two streams of transactions; however, the transaction streams might be of different type objects. This device will use a user written transformation function to convert one type to another before performing a comparison."

10.Examplewithtypicalanalysis/copy()problemsConsideraUVMtestbenchexamplethatappearedtobeworkingbutthathadhiddenproblemsformonths.Oncewediscoveredthattherewasaproblem,itstilltookhourstoidentifythecauseandfixthe problem. We want to help the reader to avoid the same time consuming mistakes. You'rewelcome!

Wehadatraininglabthathadascoreboardwithtwouvm_analysis_impportstodemonstratethemulti‐impportsolutiondescribedinSection9.Thewrite_prd()methodtookthetransactionandcalculatedtheexpectedoutputvaluesandwrotethembacktothetransactionandputthemintotheexpected uvm_tlm_fifo. The write_out() method simply put the transaction into the actualoutputuvm_tlm_fifo.Thescoreboardcomparisonlogicthencomparedtheexpectedoutputstotheactual outputs to determine if each simulation vector passed or failed. Once the testbench wasworkingwethoughtweweredone.

Somemonths laterwedecidedtoadda feature to the lab.Weaskedengineers tobreak theDUT(DesignUnderTest)andobservethereportederrorstoseeiftheymadesenserelativetothebug.Muchtooursurprise, thetestbenchcontinuedtoreport that thetestspassed.WebroketheDUTmore,andthetestbenchstillcontinuedtopass.WetracedthesignalsontheDUTandnoticedthattheexpectedwrongoutputswerebeinggeneratedbutthetestbenchoutputcontinuedtoshowandreportvalidoutputs.

Wefinallyfiguredoutthatthewrite_prd()calculate‐expectedfunctionwasusingthetransactioninputs tomodify the outputs of the broadcast transactionbefore putting them into the expecteduvm_tlm_fifo. This meant that the original transaction now had corrected outputs that hadoverwritten the erroneous DUT outputs so the transaction that was put in the actual outputuvm_tlm_fifo had been corrected and the testbench reported no failures while showing theupdatedoutputvalues.

This is why any subscriber that intends to modify a transaction should first take a copy of thetransactionandusetheinputsofthecopiedtransactiontocalculatetheoutputstobeplacedbackintothecopiedtransaction.

Guideline:oncetheUVMtestbenchisworking,breaktheDUTtoseeiftheUVMtestbenchcancatchthebug.Thiswillshowyouifyouhavethesameproblemthatwedescribedinthissection.

11.Summary&ConclusionsThe uvm_analysis_port is a port that broadcasts transactions to zero or more destinations,typicallycalledsubscribers.Theendofeachanalysispathsubscriberchainisauvm_analysis_impthatmustprovideanimplementationbyoverwritingtheimp'swrite()method.

Eachcomponentthatsubscribestoacommontransactionanalysispathhasahandletoacommontransaction.Anycomponentthatneedstomodifyanyofthetransactionfieldsshouldfirsttakeacopyofthetransactionandonlymodifythefieldsofthecopiedtransaction.Thisistheprimaryreasontohaveacopy()methoddefinedwithinthetransaction.Failuretomakealocalcopyofthetransactioncanhaveadverseeffectsonothercomponentsthatreferencethecommontransaction.Modifyingthefieldsofananalysis_portbroadcasttransactionshouldneverbedone.

SNUG2018


WedemonstratedinSection3.1.6thatmostuvm_analysis_port(s)anduvm_analysis_export(s)are interchangeable. Even though they are interchangeable, use uvm_analysis_port(s) forcomponent outputs that are forwarding a transaction to other ports on an anlysis path and useuvm_analysis_export(s) or uvm_analysis_imp for component inputs that are receiving atransactionfromotherportsonananlysispath.

For scoreboard development, setting the FIFO size to 0 is generally recommended and theuvm_tlm_analysis_fifo,describedinSection8.3alreadyhasadefaultsizesetto0,

Iftherearemultipleuvm_analysis_imp(s)inacomponent,theusermustdefinemultipleuniquelynamed uvm_analysis_imp_SFX ports with corresponding write_SFX() methods. This is mosteasily accomplished by using the `uvm_analysis_imp_decl(_SFX) macros to create newuvm_analysis_impporttypeswithcorrespondingwrite()methods.

Wementionedthat theuvm_analysis_imp_SFXhandlenamesdonotrequiretheuseof theSFXvalues,butwebelieveitisagoodideatousethesamesuffixnamesaspartofthehandlenamestoreducecodingconfusion.

Finally,provethatyourscoreboardanalysispathsareworkingcorrectly.OncetheUVMtestbenchappearstobeworking,breaktheDUTtoseeiftheUVMtestbenchcancatchthebug.ThisisagoodcorrectnessindicatorforyourUVMtestbench.

Oneofourpaperreviewers,JeffVance,mentionedanotheroptionthathehasseeninpracticethatisworthconsidering.Wedescribedtheuseoftheuvm_subscriberinSection6.Anotheroptionistodeclaremultipleuvm_subscriber instances insideacomponent. I.e., thescoreboarddeclaresanarrayofsubscribers,andpassesahandlethatpointstoitself(thescoreboard)toeachsubscriber.Then each subscriber can have an extended write() method that pushes transactions to thescoreboardqueues.Theadvantagebeing,alltheseportconnectiondetailsareencapsulatedanditiseasytoaddorremoveconnectionsbyjustadding/removingsubscribers.Butitrequiresdefininganextendedsubscriberclass.WethankJeffforsharingthisinterestingtechnique.Wedidnothavetimetotrythisourselvesbutitcertainlyappearstobeaworthytechnique.

12.AcknowledgementsWeacknowledgeourcolleaguesJeffVance,KellyLarson,DonMills,DavidLeeandDanChaplinfortheir reviews and suggested improvements to this paper and the presentation slides. Theircontributions helped identify areas that needed additional explanation andmodifications to thepresentation slides and their ordering to make this difficult topic easier to understand.We aregratefulfortheirinsightfulandgenerouscontributions.

13.References[1] Clifford E. Cummings, "OVM/UVM Scoreboards ‐ Fundamental Architectures," SNUG (Synopsys Users

Group)2013(SiliconValley,CA).Alsoavailableatwww.sunburst‐design.com/papers

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

[3] "Observerpattern,"Wikipediaarticle.https://en.wikipedia.org/wiki/Observer_pattern

[4] "UniversalVerificationMethodology(UVM)1.2ClassReference,"AccelleraSystemsInitiativeInc.,1370TrancasStreet#163,Napa,CA94558,USA.,June2014

SNUG2018


14.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,synthesisandUVMVerificationmethodologytrainingexperience 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:October2018

world class systemverilog & uvm trainingsnug 2018 page 6 uvm analysis port functionality and rev...

Documents