world class systemverilog & uvm training - … class systemverilog & uvm training...
Post on 10-Mar-2018
293 Views
Preview:
TRANSCRIPT
World Class SystemVerilog & UVM Training
SystemVerilogAssertions‐Bindfiles&BestKnownPracticesforSimpleSVAUsage
Clifford E. Cummings
Sunburst Design, Inc. cliffc@sunburst-design.com www.sunburst-design.com
ABSTRACT
SystemVerilogAssertions(SVA)canbeaddeddirectlytotheRTLcodeorbeaddedindirectlythroughbindfiles.Bestknownpracticessuggestthatitisbettertoaddmostassertionsusingbindfiles. This paper will explain why adding assertions directly to the RTL code can beproblematicandwhybindfilessolvemanyoftheproblems.Thispaperalsoexplainshowtousebindfilesefficientlyandwhyengineersshouldgenerallyuseconcurrentassertionswhileavoidingimmediateassertions.Thispaperwillalsogiveassertioncodingguidelinesandstylesthathelpreduceassertioncodingeffort,assertioncodingmistakesandencouragedesignerstobemoreproactiveinaddingassertionstotheirdesigns.
SNUG-2016 Silicon Valley, CAVoted Best Paper
1st Place
SNUG2016
Page2 Rev1.0
SystemVerilogAssertions‐Bindfiles&BestKnownPracticesforSimpleSVAUsage
TableofContents1. Introduction.....................................................................................................................................................................5
1.1 Assertionterminology...................................................................................................................................5
2. DesignEngineersandSVA.........................................................................................................................................6
3. HowmuchSVAtraining?............................................................................................................................................6
4. Bindfiles.............................................................................................................................................................................7
4.1 Howbindfileswork........................................................................................................................................7
4.2 Thebindcommand.........................................................................................................................................7
4.3 Bindfileusagemodels....................................................................................................................................8
4.3.1 Bindtoallinstancesofamodule................................................................................................9
4.3.2 BindtospecificDUTinstancewithorwithoutusingthemodulename..................10
4.4 Bindfilesforparameterizedmodels......................................................................................................11
4.5 Bindfileswith.*portconnections..........................................................................................................12
4.6 Nobindfilenesting........................................................................................................................................12
5. Inlineassertioncode.................................................................................................................................................13
5.1 FrontendtoolSVAsupport........................................................................................................................13
5.2 Makefiles...........................................................................................................................................................14
5.3 VisibilityofSVAinbindfiles......................................................................................................................14
5.4 Bindfiledisadvantages................................................................................................................................18
6. Assertionlabelsfordebugging.............................................................................................................................19
7. Concurrentassertions‐vs‐immediateassertions........................................................................................21
8. Simpleassertionmacros.........................................................................................................................................26
8.1 SunburstDesignSVAmacrodefinitions..............................................................................................27
9. Implications|‐>|=>..................................................................................................................................................28
10. Conclusions..............................................................................................................................................................29
11. Acknowledgements...............................................................................................................................................29
12. Postlude.....................................................................................................................................................................30
13. References................................................................................................................................................................30
14. Author&ContactInformation..........................................................................................................................30
ToolsandOSversions.............................................................................................................................32 Appendix1
Editorkeydefinitionstoeaseaddingassertionlabels..............................................................32 Appendix2
BindtospecificDUTinstance..............................................................................................................34 Appendix3
BindtoaninstancenamewithoutspecifyingtheDUTmodulename................................34 Appendix4
SNUG2016
Page3 Rev1.0
SystemVerilogAssertions‐Bindfiles&BestKnownPracticesforSimpleSVAUsage
TableofFiguresFigure1‐bind‐2‐box/2‐partcommand....................................................................................................................7
Figure2‐Multipletop‐levelmodules‐tb1andbindfiles.....................................................................................10
Figure3‐fifo1modulealways_ffcode.........................................................................................................................15
Figure4‐fifo1modulewithassertionsembeddedabovethealways_ffcode.............................................16
Figure5‐fifo1modulewithassertionsembeddedbelowthealways_ffcode............................................17
Figure6‐assertionsinseparatefile‐side‐by‐sidewindowstohelpdebugtheDUT..............................18
Figure7‐Assertionlabelsdisplayedinthewaveformdisplay(beforeexpandingtheNamepane).19
Figure8‐Assertionlabelsdisplayedinthewaveformdisplay(afterexpandingtheNamepane).....20
Figure9‐Assertionlabelexpandedtoshowallsignalstestedbytheassertion........................................21
Figure10‐Immediateassertion‐assertfinal$onehot(...)FSMexampletocorrectracecondition..22
Figure11‐Concurrentassertion‐`assert_clk($onehot(...))FSMexample...................................................22
Figure12‐ImmediateassertionDVEdisplaywithoutlabelname(Note:unnamed$$_1).....................24
Figure13‐ImmediateassertionDVEdisplaywithlabelname(ERR_reset_went_unknown)..............25
Figure14‐If‐statement"assertion"testingof$castandrandomize()functions......................................26
Figure15‐TheSVA"circleoflife"..................................................................................................................................26
Figure16‐ReasonsengineersabandonSVA.............................................................................................................26
Figure17‐Viewingimplicationoperatorswithlargefonts................................................................................28
Figure18‐Viewingimplicationoperatorswithsmallfonts..............................................................................28
Figure19‐Viewingimplicationoperatorswithsmallfontsfromadistance..............................................28
Figure20‐Rawlabelentryusingvim..........................................................................................................................32
Figure21‐Labelproperlyformattedusingvimkeydefinition.........................................................................32
Figure22‐Examplesofrawlabel‐textentryusingvim........................................................................................32
Figure23‐Examplelabelsproperlyformattedusingvimkeydefinition.....................................................32
SNUG2016
Page4 Rev1.0
SystemVerilogAssertions‐Bindfiles&BestKnownPracticesforSimpleSVAUsage
TableofExamplesExample1‐DUTmoduleheaderandcorrespondingDUT_assertsmoduleheader....................................8
Example2‐Recommendedbindstyle‐bindstoallinstancesofaDUT..........................................................9
Example3‐Separatebindfilesmodule‐bindfiles.sv...............................................................................................9
Example4‐run1.fcommandfile‐noassertions.......................................................................................................9
Example5‐run2.fcommandfile‐bindassertions...................................................................................................9
Example6‐fifo1modulewithassertionmoduledirectlyinstantiated..........................................................11
Example7‐Parameterizedregistermodule.............................................................................................................11
Example8‐DUTmodulewiththreeuniquelyparameterizedregisterinstances.....................................12
Example9‐Parameterizedregister_assertsmodule.............................................................................................12
Example10‐Immediateassertion‐assert$onehot(...)FSMexamplewithpotentialracecondition.......................................................................................................................................................................................................22
Example11‐Flip‐flopwithasynchronousresetandinlineimmediateassertion.....................................23
Example12‐DUT_assertsmodulewithimmediateassertiontocheckresetand$errorreporting..23
Example13‐DUT_assertsmodulewithimmediateassertiontocheckresetanddefaultERR_labelreporting...................................................................................................................................................................................24
Example14‐assert_macros.svfile.................................................................................................................................27
Example15‐Properlycodedconcurrentassertion‐verbosestyle................................................................27
Example16‐Properlycodedconcurrentassertion‐macrostyle....................................................................27
Example17‐Non‐recommendedbindstyle‐bindstojustoneinstanceofaDUT...................................34
Example18‐Non‐recommendedbindstyle‐bindstoaninstancenameonly..........................................35
SNUG2016
Page5 Rev1.0
SystemVerilogAssertions‐Bindfiles&BestKnownPracticesforSimpleSVAUsage
1. IntroductionIn2009Iwroteapaperentitled,"SystemVerilog Assertions ‐Design Tricks and SVA Bindfiles,"[3]sowhyseeminglywriteanotherpaperonthesametopic?
In2010,alongwithSystemVerilogandFormalVerificationexpert,HarryFoster, Ico‐presentedaseries of seminars in North America and Europe on "SystemVerilog Assertion (SVA) BasedVerification,"tolocaldesignandverificationengineeringaudiencesaswellasafewonsite,captiveseminarsforlargecompanies.DuringthecourseofthoseseminarsHarryandIwereabletoshareour best SVA practiceswith seminar attendees andwith each other.We also were given directfeedback,especiallyfromlargecompaniesandpowerSVAusersontheirbestSVAusagepractices.Traveling with Harry gave me the opportunity to ask Harry, co‐inventor of the OVL (OpenVerification Library), co‐author of the first Assertion Based Design book [2], Chairman of theAccellera Formal Verification Committee, and Chairman of the IEEE‐1850 PSL1 Working GroupquestionsaboutwhycertaintokensandcapabilitieswereaddedtobothSVAandPSL.
Based on the information presented at the seminars, feedback shared with us from power‐SVAusers and conversations that Harry and I held with each other, I developed a new set ofrecommendedSVAusageBestPractices.
In recent years other excellent papers on SVAusage have been shared and have similarly givenusefulrecommendations[5][9].ThispaperwilldetailnewSVAcodingpracticesandexplainwhyIfind these practices to be superior to other techniques that have been previously presented.Readersareinvitedtoconsidertheseguidelines,comparethemtoalternateguidelinesofferedbyotherrespectedcolleaguesandchooseforthemselves.
1.1 Assertionterminology
In this paper I will refer to the following abbreviations and the following different types ofassertions:
DUT‐DeviceUnderTest.
SVA‐SystemVerilogAssertions.
Immediate assertions ‐ uses the keyword assert (not assert property), and is placed inproceduralcodeandexecutedasaproceduralstatement.
Concurrentassertions ‐usesthekeywordsassertproperty, isplacedoutsideofaproceduralblockandisexecutedoncepersamplecycleattheendofthecycle.Thesamplecycleistypicallyaposedgeclkandsamplingtakesplaceattheendoftheclockcycle,justbeforeeverythingchangesonthenextposedgeclk.
Embedded concurrent assertions ‐ another form of concurrent assertions added to IEEE Std1800‐2009[7] and also uses the keywords assert property but is placed inside of a clockedalwaysprocess.Placingtheassertioninaclockedalwaysprocessallowstheconcurrentassertiontoinherittheclocking‐samplesignalfromthealwaysprocess.
See0fortoolandOperatingSystemversionsusedtotesttheexamplesinthispaper.
1PSL‐PropertySpecificationLanguageandprecursortoSVA
SNUG2016
Page6 Rev1.0
SystemVerilogAssertions‐Bindfiles&BestKnownPracticesforSimpleSVAUsage
2. DesignEngineersandSVA Onequestionthatauthorsandexpertshavetriedtoaddressis,whattypesofassertionsshouldbeaddedbydesignersandwhattypesofassertionsshouldbeaddedbyverificationengineers?
Somerespectedcolleagueshavesuggestedthatimmediateassertionsshouldbeaddedbydesignersandconcurrentassertionsshouldbeaddedbyverificationengineers.Idisagree.
Iprefer the recommendationmadebyHarryFoster in theAssertionBasedVerificationseminarsthatHarry and I did back in 2010. Among other recommendations,Harry suggested thatDesignEngineers should create the low‐level and simple assertionswhile Verification Engineers shouldcreatehigher‐levelandperhapsmorecomplexassertions(HarryhadmoredistinctionsregardingtheseparationofconcernsbetweenDesignandVerificationengineersnotrepeatedinthispaper‐see[1]).
I too recommend that designers should generally add the low‐level and simple assertions usingconcurrentassertionsandingeneralshouldavoidimmediateassertions.
Ifyouwanttoencourageyourdesignteamtouseassertions(anddesignersshouldbeencouragedtouseassertions)Ihavefoundthatthefollowingassertioncodinggoalsshouldbefollowed:
StartlearningandusingSVAafter2‐3hoursoflectureand1‐3hoursoflabs. Usebindfilestoaddassertionstoadesign Uselong,descriptivelabelsto:
o documenttheassertionso acceleratedebuggingusingwaveformdisplays
Usesimplemacrosto:o efficientlyaddconciseassertionso reduceassertioncodingeffortso reduceassertionsyntaxerrors
Useconcurrentassertionsbutavoidimmediateassertions Use|->##1implicationsinsteadof|=>implications
Eachoftheserecommendations,andmore,willbedescribedinthispaper.
3. HowmuchSVAtraining?In recent years I have been called on to conduct SystemVerilog Assertion (SVA) training forcompanies that had previously takenmulti‐day SVA training, not because the training they hadreceivedwasbad,butbecausethetrainingtheyhadreceivedwastoomuchandtheirengineeringteamshadahardtimerememberingalloftheSVAoptionsandsyntaxpossibilities.TheproblemIhaveseenisthatdesignersuseSVAsporadicallyforafewmonthsononeproject,thentheymightgomanymonthsbeforetheyneedtouseitagain.Thisisaclassiccaseofunlessaskillispracticed,itisforgotten.
The SVA constructs in the SystemVerilog language are powerful andprovide extensive assertioncapabilities,whichunfortunatelyformanydesignengineersisperhapstheirgreatestdisadvantage.Unless an engineerhas a fulltime job adding assertions to all of theprojects at a company, thenthoseengineersshouldfocusonasubsetoftheSVAsyntaxandcapabilitiesandaddadditionalSVAcapabilitiesasneeded.
Myexperiencehasbeenthatifadesignengineerhastowrite3ormorelinesofassertioncodetotesteachDUTfeature, theywillquicklyabandontheuseofSVAandwilldesignatethetasktobedonebyverificationengineers.Concise,syntaxerror‐avoidancecodingstylesarerequiredtomake
SNUG2016
Page7 Rev1.0
SystemVerilogAssertions‐Bindfiles&BestKnownPracticesforSimpleSVAUsage
adesignengineerproductiveandkeepthementhusiasticaboutaddingSVAtotheirRTLdesigns.
Myexperiencehasshownthat2‐3hoursofSVAlecturefollowedby1‐3hoursofSVAlabworkcanmakedesignengineersbothproductiveandenthusiasticaboutusingSVAintheirdesignwork.
IfanengineerDOEShavethefull‐timejobtoaddandsupportassertionsonmultipleprojects,thatengineershouldtakemulti‐daySVAtraining.
Guideline#1:StartlearningandusingSVAafter2‐3hoursoflectureand1‐3hoursoflabs.
4. BindfilesLetmesummarizethissectionwithtwoshortstatements.
Guideline#2:bindfiles‐usethem!
Guideline#3:InlineSVAcode‐avoidit!
This section will describe bindfile usage and also explain why I discourage placing assertionsdirectlyintheRTLcode.
There aremany sources that recommend embedding assertions directly into the RTL code, butagain,Ibelievethereisabetterapproach.HarryFoster,authorofoneofthefirstAssertionBasedDesign books, used to recommend putting assertions directly into the RTL code, but he nowrecommendsNOTputting theassertions in theRTLcode, andHarryand I are inagreement thatassertions should instead be put in a separate bindfile. Harry and I gave Assertion BasedVerification seminars in North America and Europe in 2010where we shared SVA Best CodingPracticetechniques,includingtheproperuseofbindfiles.
4.1 Howbindfileswork
Ingeneral,usingbindfilesisactuallydoingindirectinstantiation.Theengineerwillbind(indirectlyinstantiate) onemodule inside of anothermodule using thebind keyword. The IEEE Std 1800‐2012Standardfrequentlyreferstobindfilesas"bind_instantiation."[8]
AnRTLdesignermightnotevenknowthatthebindfilehasbeeninstantiatedintotheRTLdesignunlesstheengineeropensawaveformviewer,likeDVE,toseethattheRTLdesignnowhasanothersub‐level of hierarchy that can be displayed in the waveform display. A new and perhapsunexpectedlevelofhierarchyistheindirectlyinstantiatedbindfile.
To create a bindfile, declare a module that will encapsulate the assertion code (and otherverificationcodeifneeded).Themoduleneedsaccesstoalloftheimportantsignalsintheenclosingfile so all of the ports and internal signals from the enclosing file are declared asinputs to thebindfile.
4.2 Thebindcommand
Thebindcommandcanbeviewedasa2‐boxcommand.
bind fifo1 fifo1_asserts p1 (.*);
Figure1‐bind‐2‐box/2‐partcommand
As shown in Figure 1, the first box of the bind command includes the bind keywordfollowedbytheDUTmodulename,theDUTinstancename,orboth.
SNUG2016
Page8 Rev1.0
SystemVerilogAssertions‐Bindfiles&BestKnownPracticesforSimpleSVAUsage
Inthesecondboxisaninstantiationcommandthatdescribeshowtheboundmodulewouldbe instantiated if placed directly in the module being bound to. Simply put, if you hadinstantiatedthebindfiledirectlyintoamodule,whatwouldtheinstantiationcodebe?Thatinstantiation code is the second box in the bind command. Binding is simply indirectinstantiation.
Whencreatingbindfiles,itisagoodideatocopytheDUTmoduletoaDUT_assertsmodule,keepallexistinginputdeclarations, changealloutputdeclarationstoinputdeclarations,anddeclareallinternalsignalsasinputdeclarationstothebindfile.Thebindfilewillsampletheportandinternalsignals fromtheDUT. InExample1thefifo1.sv filewascopiedtothefifo1_asserts.sv file,thedoutoutputwaschanged toadoutinput declaration,allinput declarationswerekeptasoriginallydeclared,andall internallogicsignalsweremodifiedtobeinputlogicdeclarations.There was no need to copy the internal array from the fifo1 design so that was omitted. The`include"assert_macros.sv" commandwithcorrespondingmacrodefinitions isexplainedinSection8.
module fifo1 ( output logic [7:0] dout, output logic full, empty, input logic write, read, clk, rst_n, input logic [7:0] din); logic [7:0] fifo1mem [0:15]; logic [3:0] wptr, rptr; logic [3:0] cnt;
module fifo1_asserts ( input logic [7:0] dout, input logic full, empty, input logic write, read, clk, rst_n, input logic [7:0] din, input logic [3:0] wptr, rptr, input logic [3:0] cnt); `include "assert_macros.sv"
Example1‐DUTmoduleheaderandcorrespondingDUT_assertsmoduleheader
ItisnotrequiredtolistalloftheDUTsignalsintheassertsfile,onlythosesignalsthatwillbecheckedbyassertions;however,itishighlyrecommendtoaddALLoftheDUTsignalstothe asserts file because it is common to add more assertions in the future that mightrequirepreviouslyunusedDUTsignals.
IfyoumatchalloftheDUTsignalnames(outputs,inputsandinternalsignals)andconvertthemintoinputdeclarationsontheassertsfile,itisverysimpletobindtheassertsfiletotheDUTbecauseallportconnectionscanbemadeusing.*implicitportconnections.Forthose engineers who are uncomfortable using the .* port connections, all of theconnections can also be made using the SystemVerilog .name or Verilog named portconnections.(seeCummings.*paper[4])
4.3 Bindfileusagemodels
Bindfileusageisexplainedinsection23.11oftheIEEEStd1800‐2012[8].
Therearethreebindfileusagemodels:(1)bindtoallinstancesofamodule,(2)bindtoaspecificinstance of a DUT, and (3) bind to an instance namewithout specifying the DUTmodule name.Usage, advantages and disadvantages of these three use models are described below and inAppendix3andAppendix4.
SNUG2016
Page9 Rev1.0
SystemVerilogAssertions‐Bindfiles&BestKnownPracticesforSimpleSVAUsage
Inallthreeusagemodels,thebox#2instantiationcodeisthesame.Theonlyvisibledifferentiationisinthebox#1code.
4.3.1 Bindtoallinstancesofamodule
Guideline#4:UsethebindcommandstylethatbindstoallDUTmodules,notthebindstylethatonlybindstospecifiedinstances.
Thisstylespecifiesthetargetmodulenametobindtobutdoesnotspecifyaninstancename.
bind fifo1 fifo1_asserts p1 (.*);
Example2‐Recommendedbindstyle‐bindstoallinstancesofaDUT
Example2 showshow tobind thefifo1_asserts file toall instancesof thefifo1 design.Thisstyledoesnotrequirethatthebindcommandbescopedtothesamemoduleasanyinstanceofthefifo1.Itdoesnotmatterwherethefifo1modulesareinstantiatedbecausethisbindcommandindirectly instantiates theassertions to thefifo1designsregardlessofwhere theyareplaced inthedesignhierarchy.
ThebehavioristhesameasifalloftheassertionshadbeenaddedtotheDUTmoduledirectlyandeach instance of the DUT will have the same assertion checking during simulation. In general,engineers shoulddo assertion checkingon every instanceof aDUTmodulebecausean engineerneverknowswhichDUTmightfail.
AnotherundocumentedadvantageofbindingtoanyDUTmoduleisthatitdoesnotmatterwherethisbindcommandisplaced. It iscommonpractice toplace thisbindcommandin the top‐leveltestbenchbutIprefertoplacethisbindcommandinastandalonemodulecalledbindfilesinafilecalledbindfiles.sv
module bindfiles; bind fifo1 fifo1_assert p1 (.*); endmodule
Example3‐Separatebindfilesmodule‐bindfiles.sv
Ialsokeeptwocopiesofmysimulationrun1.fcommandfile,onethatdoesnotcallthebindfiles.svfileandonethatdoes.
tb1.sv fifo1.sv
Example4‐run1.fcommandfile‐noassertions
tb1.sv fifo1.sv bindfiles.sv fifo1_assert.sv
Example5‐run2.fcommandfile‐bindassertions
Verilog‐2001[6]madeit legal todefineandsimulate twotop‐leveldesigns.WhenIsimulatewiththerun2.fcommandfile,Iamsimulatingboththedesignandtheseparatebindfilesmodule.TheVCS simulation log in Figure 2 shows that there were two "Top Level Modules: tb1 bindfiles," and indeed the when this simulation was run, it reported failing assertions (notshown).
SNUG2016
Page10 Rev1.0
SystemVerilogAssertions‐Bindfiles&BestKnownPracticesforSimpleSVAUsage
Command: vcs -R -sverilog -f run1.f -l logfile -full64 Chronologic VCS (TM) Version K-2015.09-SP1_Full64 -- Wed Dec 16 11:33:13 2015 Copyright (c) 1991-2015 by Synopsys Inc. ALL RIGHTS RESERVED This program is proprietary and confidential information of Synopsys Inc. and may be used and disclosed only as authorized in a license agreement controlling such use and disclosure. Parsing design file '../SIMUTIL.v' Parsing design file 'tb1.sv' Parsing design file 'fifo1.sv' Parsing design file 'bindfiles.sv' Parsing design file 'fifo1_assert.sv' Parsing included file 'assert_macros.sv'. Back to file 'fifo1_assert.sv'. Top Level Modules: tb1 bindfiles TimeScale is 1 ns / 1 ns Starting vcs inline pass...
Figure2‐Multipletop‐levelmodules‐tb1andbindfiles
IfIwanttorunwithoutassertions,Icansimplycalltherun1.fcommandfiletorunthesimulation.
Havingaseparatebindfilesmoduleallowsdifferentdesignandverificationteamstoputmultiplebind commands in thisbindfiles module without touching the RTL design or testbench. AnyMakefile that is controlling simulation and synthesis will completely ignore the bindfilesmodule.
Itshouldalsobenotedthatthebindfilesmodulerequiresnoadditionalsignaldeclarations.Thismakesusingthebindfilesapproachveryeasytodo.Thesignaldeclarationsmustexist inthefilethatisbeingboundtobecausethebindisanindirectinstantiationintothatfile,butsincethebindistoanotherfileandnotthebindfilesmodule,thesignaldeclarationsdonotandshouldnotbedeclaredinthebindfilesmodule.
4.3.2 BindtospecificDUTinstancewithorwithoutusingthemodulename
Recommendation:Donotusethesestyles.
It is possible tobind to a specific instance of a DUT using both themodule name and instancename,ortobindtoaspecificlocally‐scopedinstancenamewithoutreferencingthemodulenamecorrespondingtotheinstancename.
It is generally notwise to limit assertion checking to just one copy of amodule or to a genericinstancename ina localscopebecauseadesignermightbind toaworkingversionofamodulewhileanotherinstanceofthesamemodulecouldbefailingelsewhereinthedesign.Bindingtothemodulenamewithout limitingto justoneinstanceallowscheckingtoproceedonall instancesofthemodule.
ReferenceAppendix3andAppendix4toseehowothernon‐recommendedbind‐styleswork.
SNUG2016
Page11 Rev1.0
SystemVerilogAssertions‐Bindfiles&BestKnownPracticesforSimpleSVAUsage
4.4 Bindfilesforparameterizedmodels
If an engineer is unsurehow tousebindfiles especiallywhen the engineer is uncertainhow theinstantiationwillappearinabindcommand,Irecommendfollowingthesethreesteps:
(1)PuttheassertionsdirectlyintotheRTLdesignandfigureouthowtheywouldworkthere.
(2)Thenmove theassertions toabindfileandinstantiate thebindfiledirectly into theDUTandmakethatwork,asshowninExample6.
module fifo1 ( output logic [7:0] dout, output logic full, empty, input logic write, read, clk, rst_n, input logic [7:0] din); logic [7:0] fifo1mem [0:15]; logic [3:0] wptr, rptr; logic [3:0] cnt; ... fifo1_assert p1 (.*); // The assertion module could be // instantiated here endmodule
Example6‐fifo1modulewithassertionmoduledirectlyinstantiated
(3)Thenremovetheinstantiatedmoduleandplacetheinstance‐codeintothebindfiles.svfilewiththebindcommand.
These steps are also sound advice when considering how to make bindfiles work withparameterizedmodulesthatmightbeinstantiatedmultipletimeswithdifferentparameters.
Consider the overly simple (but easy to understand) definition of a register module with SIZEparameterasshowninExample7.
module register #(SIZE=8) ( output logic [SIZE-1:0] dout, input logic [SIZE-1:0] din, input logic clk, rst_n); always_ff @(posedge clk or negedge rst_n) if (!rst_n) dout = '0; else dout = din; endmodule
Example7‐Parameterizedregistermodule
IfthreeinstancesofthisregisterareplacedintoalargerDUTwiththreedifferentparametervaluesasshowninExample8,thismightseemtoposeaproblemforanassertionbindfile.
SNUG2016
Page12 Rev1.0
SystemVerilogAssertions‐Bindfiles&BestKnownPracticesforSimpleSVAUsage
module DUT ( output logic [11:0] q, input logic [11:0] d, input logic clk, rst_n); logic [3:0] n1; logic [7:0] n0; register r1 (.dout(n0), .din(d[11:4]), .*); register #(.SIZE( 4)) r2 (.dout(n1), .din(d[ 3:0]), .*); register #(.SIZE(12)) r3 (.dout(q), .din({n0,n1}), .*); endmodule
Example8‐DUTmodulewiththreeuniquelyparameterizedregisterinstances
In reality, differentparameter valuesdonotpose aproblem.For theDUTmoduleofExample8,whatisrequiredisabindfilethatisalsoparameterizedasshowninExample9.
`include "assert_macros.sv" module register_asserts #(SIZE=8) ( input logic [SIZE-1:0] dout, input logic [SIZE-1:0] din, input logic clk, rst_n); ERR_dout_value_does_not_follow_din: `assert_clk_xrst ($changed(din) |-> ##1 (dout == $past(din))); ERR_dout_did_not_reset: `assert_clk (!rst_n |-> (dout == '0)); endmodule
Example9‐Parameterizedregister_assertsmodule
Thisassertionmoduleisrathercontrivedbecauseittypicallyisnotworthwhiletocheckaregisterto ensure that inputswere transferred to the outputs on a clock edge, but this overall exampledemonstratesthepointthatassertionfilescanbeparameterizedthesameasanyothermodule.
4.5 Bindfileswith.*portconnections
Asmentionedearlier,aproperlycodedassertsfilecanbeveryeasilyconnectedtotheDUTusingSystemVerilog's.*connections.
Unfortunately, SystemVerilogdoesnot allow.* parametermatching soparametersmust still bepassed by name. Allowing .* parameter matching would be a welcome enhancement toSystemVerilog.
4.6 Nobindfilenesting
FromtheIEEEStd1800‐2012:
"It shall be an error for a bind statement to bind a bind_instantiation underneath the scope ofanotherbind_instantiation."
What thismeans is that if you bind a file to onemodule and then bind thatmodule to another
SNUG2016
Page13 Rev1.0
SystemVerilogAssertions‐Bindfiles&BestKnownPracticesforSimpleSVAUsage
module, you have created a nested bindfile, which is illegal per the IEEE Std 1800‐2012. Thathavingbeensaid,Ihavesuccessfullynestedbindfilesusingmultipletools,includingVCS,withoutany reported errors.As I havediscussed this inconsistencywithEDAvendors, the vendorshaveemphasizedthatnestedbindingistechnicallyillegalandmaynotbesupportedinfutureversionsoftheirEDAtools.
In short, because nested binding is illegal per the IEEE Std 1800‐2012, vendors can remove thenestedbindfile capability at any time, so it is advised to avoid using nestedbindfiles even if itappearstowork.
5. InlineassertioncodeSystemVerilog allows SVA to be added directly to the RTL code and one of the first books onAssertionBasedDesignbyHarryFoster,AdamKrolnikandDavidLacey[2],didindeedrecommendthatassertionsbeaddeddirectlytotheRTLcodeandtoplacetheassertionsneartotheRTLthattheassertionswereintendedtocheck.
Otherauthors in recentyearshavesimilarly recommendedaddingassertionsdirectly to theRTLcode.
While doing the ABV seminars in 2010, I noticed that Harry Foster was telling the seminarattendeestoNOTputtheassertions intotheirRTLdesigns.AtoneoftheseminarsIaskedHarrywhy he was contradicting recommendations from his own book. Harry mentioned twodevelopments in recent years that had caused him to change the book recommendation: (1)engineers fighting with tools that did not support SVA, and (2) engineering teams that useMakefilestocontrollargesimulationsandlargesynthesisruns.Bothareexplainedbelow.
IwillalsodetailathirdproblemthatanengineerexperienceswhenaddingassertionsclosetotheRTLcode.Inpractice,addingassertionsclosetotheRTLcodethattheyareintendedtotestiseasiersaidthandone.
5.1 FrontendtoolSVAsupport
Intheory,simulatorsandformalcheckingtoolsshouldreadandsupportSVA,andonwholemostofthesetoolsdosupportSVA.MostothertoolsshouldquietlyignoreanySVAconstructsintheRTLcode,butthatisnotuniversallytrue.
At DVCon 2015, my colleague, Stuart Sutherland, accurately showed a table that listed threedifferent vendors (anonymously listed to protect the guilty!) and which vendor tools properlysupported SVA capabilities. Although there was broad support for SVA capabilities, most of thetoolshadtroubleswiththecheckerstatementandsomehadtroubleswiththeletstatement,twocapabilitiesaddedtoSystemVerilog2009.
At SNUG‐SV 2015[9], Stu Sutherland, also showed a table that listed SVA support by VCS (v.2014.12),DesignCompiler(v.2014.09‐SP5)andSynplify‐Pro(v.2014.09‐SP2),againshowingtherewas broad support for SVA capabilities, but that the tools still had support deficiencies in a fewareas.
IfengineersaddSVAcheckingthroughabindfile,allof thesesupport issuesgenerallydisappear.TheRTL,withoutSVA,ispristineSystemVerilogcodeandtherearenostraySVAkeywordstocausea synthesis tool, or any other front‐end tool to abortwith errors. There could still be simulatorsupportissuesthatarenotcoveredbyusingabindfile.
Thepointisbindfilesremoveallofthenon‐simulationsupportissuesrelatedtotheRTLdesign.
SNUG2016
Page14 Rev1.0
SystemVerilogAssertions‐Bindfiles&BestKnownPracticesforSimpleSVAUsage
5.2 Makefiles
PerhapsthebiggestreasontoavoidaddingSVAdirectlytotheRTLcodeisMakefiles.
Harry Foster and I heard from large companies that large projects often control simulation andsynthesisrunsthroughtheuseofMakefiles.EngineeringteamsputtheRTLcodeunderrevisioncontrol and an engineermight checkout the design and execute theMakefile for simulation orsynthesis. If therehavebeennodesignchanges,nosimulationwillberunandnosynthesis toolswillbecalledtore‐synthesizethedesign.TheMakefileensuresthatthemostcurrentdesignhasbeensimulatedandsynthesizedwithouttyingupexpensivesimulationorsynthesislicenseswhenunnecessary.
The problem that existswith projects that allowengineers to add assertions directly to theRTLcodeisthatanytimeanengineeraddsanewassertiontooneoftheRTLfiles,thetimestamponthefile is updated and calling the Makefile for either simulation or synthesis can cause a lengthysimulationorsynthesisruntostarteventhoughtherewerenochangestotheactualdesign.Thiscouldunnecessarilytieuptoollicensesforhours.
TherearesomecompaniesthatallowtheirengineerstoaddinlineassertionstotheRTLuntilthedesignisputunderMakefilecontrol.Afterthat,engineersarethenencouragedtoputremainingassertionsintoabindfile.YetothercompaniesallowthebindfileassertionstobetransferredintotheRTLdesignwhenthereisanactualdesignchange,butmanagingthatscenariocanprovetricky.
The bindfile eliminates this potential problem. The bindfile is not tested by the Makefile toinitiatelongregressionsimulations,norisittestedbyMakefilesforsynthesisexecution.ThisisasimplesolutiontotheMakefileproblemandthereasonthatmanylargecompanieshavemovedallassertioncodetoaseparatebindfile.
5.3 VisibilityofSVAinbindfiles
OnejustificationsometimesmentionedfornotusingbindfilesisthatitdistancestheSVAcodefromthe RTL code and that separation makes it hard to do cross‐reference debugging between thedesignandassertioncode.Myexperiencehasbeenjusttheoppositeofthissituation.
IthasbeenassumedthatplacinganassertionnexttotheRTLthatitisintendedtocheckmakesiteasiertoseeanddebug.IthasalsobeenclaimedthataddingimmediateassertionstotheRTLalsomakestheassertioneasiertousefordebugging.InpracticeIhavenotfoundeitheroftheseclaimstobetrue.
Considerthebuggyfifo1codeshowbelow.Thisisascreenshotfrommylaptopofalargeportionofthefifo1codethatIuseinatraininglab.
SNUG2016
Page15 Rev1.0
SystemVerilogAssertions‐Bindfiles&BestKnownPracticesforSimpleSVAUsage
Figure3‐fifo1modulealways_ffcode
As is truewithmanyRTLdesigns, it is common to find largealways processes in theDUTwithmultiplelinesofcode.
Trying to place multiple concurrent assertions related to this fifo1 close to the code that theassertionsshouldcheck isnotaneasy task.Concurrentassertionscannotbeplacedinsideof theprocesssosomeoftheassertionswouldbeplacedbeforetheprocess,asshowninFigure4.
SNUG2016
Page16 Rev1.0
SystemVerilogAssertions‐Bindfiles&BestKnownPracticesforSimpleSVAUsage
Figure4‐fifo1modulewithassertionsembeddedabovethealways_ffcode
YetotherassertionswouldbeplacedafterthealwaysprocessasshowninFigure5.
SNUG2016
Page17 Rev1.0
SystemVerilogAssertions‐Bindfiles&BestKnownPracticesforSimpleSVAUsage
Figure5‐fifo1modulewithassertionsembeddedbelowthealways_ffcode
Althoughanengineercanadd inlineembeddedconcurrentassertions(anenhancementaddedtoSystemVerilog2009[7])and immediate assertions, bothwould further expand the largeblockofcodetospreadthecodeovermultiplescreens.
It shouldalsobenoted thatmyexperiencehasshown thatassertionsoftenarenoteasilyplacednexttoallofthepertinentproceduralcodeinthedesign.AssertionsfrequentlytesttheinteractionofcodefromdifferentblocksintheRTLdesign,andoftenthedesignerhastopageupanddownbetweendifferentpagesofcodetoexaminepartoftheRTLdesignandtheassertionthatinteractswiththatpartofthedesign.
Ontheotherhand,myexperiencehasshownthatengineerstypicallynowworkwithwide‐screenlaptopsoralaptopandsecondscreen,orboth.BelowisascreenshotfrommylaptopwhereIamworkingwiththebindfileassertionsinonescreenandtheDUTcodeinthesecondscreen.
SNUG2016
Page18 Rev1.0
SystemVerilogAssertions‐Bindfiles&BestKnownPracticesforSimpleSVAUsage
Figure6‐assertionsinseparatefile‐side‐by‐sidewindowstohelpdebugtheDUT
With this very commonwide‐screen setup, I can easily place one ormore assertions inmy left‐screenandscrollthroughmyRTLcodeontherightscreen,whichisnowmoreconciseandfitsonfewerpages.IfanassertionreliesoninteractionsbetweenmultipleproceduralblocksindifferentsectionsofmyRTLcode,Icankeeptheapplicableassertionvisibleintheleftscreenwhiletracingthrough different blocks of RTL code in the right screen. I find this type of RTLdebuggingwithassertionstobemucheasiertohandlethanplacinganassertionnexttopartoftheRTLdesignandpaging to the next part of my RTL design where the assertion is no longer visible. From myexperience,IhavefoundthatdebuggingismucheasiertodowhenIcankeepmyassertionsvisibleinanadjoiningterminal.
WhileconductingSVAtraining,Ihavesimilarlyfoundthatmystudentscandebugthefifo1designquickeriftheykeeptheassertionsvisibleinoneoftheterminalwindows.
5.4 Bindfiledisadvantages
Thereareacoupleofdisadvantagestousingbindfiles:
(1) The bindfile code is not visible when the dutfile is viewed. Since assertions document thecorrect behavior of the DUT, placing assertions in a separate bindfile moves useful DUTdocumentationtoaseparatefile.ThisiswhymanyengineersprefertoaddtheassertionsdirectlytotheDUTcode.
(2) bindfiles can slow simulation performance. A separate bindfile can require the simulationcompilertokeepboundsignalsvisible,bycontrastremovingthebindfilemightallowasimulationcompilertoremovesomeinternalsignaldetailsthatareunnecessaryforoptimizedsimulation. Ifimprovingsimulationperformanceduringa regression run isdesired, engineers canuse the twodifferent run.f files shown in Example 4 and Example 5 to run with or without the boundassertions.Thetradeoffisthatalongregressionsimulationexecutedwithouttheassertionscouldfailand theabsenceof theassertionswouldeithermakebugidentificationharderorrequire thelongsimulationtoberepeatedwiththebindfile.
SNUG2016
Page19 Rev1.0
SystemVerilogAssertions‐Bindfiles&BestKnownPracticesforSimpleSVAUsage
6. AssertionlabelsfordebuggingGuideline#5:Adddescriptivelabelstoyourassertioncode.
Guideline #6: In general, do not use $error(...) or $display(...) messages in assertionactionblocks.
Uselong,descriptivelabelsto:
Documenttheassertions Acceleratedebuggingusingwaveformdisplays
Adding labels to assertions is optional buthighly recommended to accelerate assertion andDUTdebugging.The labelshelpdebugmuchbetterthanusingassertionaction‐block$error(...)or$display(...)commands.Howisthispossible?
FirstnotethatthereisnothingintheIEEEStd1800‐2012thatdescribeshowavendormustdisplayusefulassertiondetailswhenassertionerrormessagesaredisplayed,butmostvendorswillincludethe assertion label in displayed assertion failure messages. Now let's look at how VCS handlesassertionerrormessages(mostEDAtoolsshowsimilarassertionerrorinformation).
Using assertion action‐block $error(...) or $display(...) commands will cause the errormessagestobedisplayedinthesimulationtranscriptwindow,butthoseerrorsdonotshowupinwaveformdisplays.Engineerswillneedtoreadthetranscripterrorandtimingmessagestofigureoutwheretolookinthewaveformdisplay.
Conversely,addingdescriptive labels to theassertionscauses those labels tobedisplayedby thedefaultassertionerrormessagesinthesimulationtranscriptwindowANDtheyalsoshowupinthewaveformdisplaywiththeassertionlabelvisibleasshowninFigure7.
Figure7‐Assertionlabelsdisplayedinthewaveformdisplay(beforeexpandingtheNamepane)
SNUG2016
Page20 Rev1.0
SystemVerilogAssertions‐Bindfiles&BestKnownPracticesforSimpleSVAUsage
NotethatinFigure7,thelabelnamesaretruncatedbythesizeoftheNamewindowpane.Thisistypicalwhentheassertionsarefirstaddedtothewaveformwindow.ThenextstepistogrowtheNamepanesothatwecanseethefullassertionlabelnames.
TherearetwowaystogrowtheNamepane‐theannoying‐beginnerwayortheeasy‐expertway.
Theannoying‐beginnerwayistograbtheedgeoftheNamepaneandtodragitjustalittletotheright,anddrag itabitmore,andabitmore,andabitmore ...etc ...untilall the labelnamesarefinallyvisible.Veryannoying!!
Theeasy‐expertway is tograbtheedgeoftheNamepaneandtodragitalmostovertotherightsideofthewaveformwindow,exposingthefulllabelnames,thendragitbacktothetrailingedgeofthelabelnames.Twomovesandyouarereadytodebug!!Pleasedon'tbeannoying!
In Figure 8 the label names have now been exposed and we are ready to view the simulationwaveformsandassertionstohelpdebugtheRTLdesign.
Guideline#7:Uselabelnamesthatstartwith"ERR"or"ERROR"andthenincludeashortsentencetodescribewhatiswrongifthatassertionisfailing.
This labeltechniquehelpsdescribeapotentialproblem,making iteasiertodebuginawaveformdisplay, plus this same label will be reported in the simulation transcript window when theassertion fails. This label is basically an active design comment and removes the need to add somanycommentstotheRTLcode.
Figure8‐Assertionlabelsdisplayedinthewaveformdisplay(afterexpandingtheNamepane)
ThefirstlabelnamevisibleinFigure8is:ERR_FIFO_RESET_SHOULD_CAUSE_EMPTY1_FULL0_RPTR0_WPTR0_CNT0:
Andnoticethatthereisanassertionfailureattime50(reddown‐pointingarrow).
Thenextstepinthewaveformdisplayistoexpandthefailingassertionbyselectingthe[+]!totheleftofthefailingassertion.InDVE,selectingthe[+]!symbolwillexpandtheassertionsothatallofthe signals that were used in that assertion will be visible under the assertion name. This is
SNUG2016
Page21 Rev1.0
SystemVerilogAssertions‐Bindfiles&BestKnownPracticesforSimpleSVAUsage
extremely useful. This means the engineer does not have to hunt for the signals used in thisassertion anddrag themdown to theassertion labelnamebeforedebugging.Adescriptive labelnameandaccesstoalloftheassertionsignalsmeansthatdebuggingwillbemucheasiertodowiththeseassertions.
InFigure9thefailingassertionhasbeenexpanded.Basedontheassertionlabelname,wewouldexpectresettocausethelistedsignalstobeassignedthefollowingvalues:
rst_n = asserted empty = 1 full = 0 rptr = 0 wptr = 0 cnt = 0
But from the waveform display in Figure 9, we see that the rptr is unknown (X). A quickexaminationofthefifo1codewillshowthatrptrwasnotincludedintheresetoperationandisthereforeuninitialized.
Figure9‐Assertionlabelexpandedtoshowallsignalstestedbytheassertion
Long descriptive labels in the waveform display will certainly accelerate design debug usingassertions.SeeAppendix2foreditormacrosthatautomaticallychangesentencestolabels.
7. Concurrentassertions‐vs‐immediateassertionsGuideline#8:Useconcurrentassertionsandavoidusingimmediateassertions.
Alloftheexamplesinthepaperuptothispointuseconcurrentassertions.
Concurrentassertionssamplealloftheimportantsignalsonlyoncepercycleattheendofthecycle,justbeforethesignalschangeonthenextclockedge,muchlikeactualhardwareregisterssamplethesignalsaftertheyhavesettledattheendofthepreviouscycle.Aswithrealhardwareregisters,
SNUG2016
Page22 Rev1.0
SystemVerilogAssertions‐Bindfiles&BestKnownPracticesforSimpleSVAUsage
we typically do not care about combinational settling or glitching during the cycle,we just carewhatthefinalvaluesareattheendofthecycle.
Immediate assertions sample signals ondemandwhencalled. Immediateassertions canbequiteuseful to test asynchronous control signals such as reset, preset and latch enables. If anyasynchronouscontrol signalsglitch theycan indeedcause immediatechanges thatmight requireimmediateevaluation.
Thisis thereasonfortheGuideline#8at thebeginningofthissection.~95%+ofsignalscanbesampledattheendofacycleandproperlyevaluatedwhileperhapsonly~5%oftheasynchronouscontrolsignalsneedtobesampledandevaluatedimmediately.Thisbestdescribesmyownusageratioofconcurrentandimmediateassertions.
Rememberthatimmediateassertionsusethekeywordassertandareplacedinproceduralcodeand executed as a procedural statement. They do not wait until the end of a sample cycle likeconcurrentassertions.
Consider the assertion example shownwith potential combinational logic‐settling race conditionshowninExample10.
logic S1, S2, S3, S4; // 1-bit variables to represent different states always_comb begin // triggers on changes to each state bit assert ($onehot({S1,S2,S3,S4}) else $error("state bits not one-hot"); case (1’b1) S1: ... // do stuff for state 1 S2: ... // do stuff for state 2 S3: ... // do stuff for state 3 S4: ... // do stuff for state 4 endcase end
Example10‐Immediateassertion‐assert$onehot(...)FSMexamplewithpotentialracecondition
InExample10,thereisapotentialraceconditioniftheRTLcodetriggersmultipletimesallowingmultipleonehotbitstobesetmomentarilybeforesettlingtothecorrectonehotnextstatevalue.
ApotentialsolutiontotheproblemistousethefinalkeywordaddedtotheassertstatementasshowninFigure10.
assert final ($onehot({S1,S2,S3,S4}) else $error("state bits not one-hot");
Figure10‐Immediateassertion‐assertfinal$onehot(...)FSMexampletocorrectracecondition
Althoughthisapproachisvalidandreasonable,theuseofthefinalkeywordstillmightreportafalse‐error ifunitdelaysareadded to theRTLcodeduringsimulation.Runningsimulationswithunitdelaysonadesignwithimmediateassertionsshouldnotbedone.
For designs like the one shown in Example 10, it is generally best to avoid any combinationalsettling issues and any potential race hazards by testing the same condition using a concurrentassertionfromabindfileasshowninFigure11.
ERR_state_is_not_onehot: `assert_clk($onehot({S1, S2, S3, S4}));
Figure11‐Concurrentassertion‐`assert_clk($onehot(...))FSMexample
SNUG2016
Page23 Rev1.0
SystemVerilogAssertions‐Bindfiles&BestKnownPracticesforSimpleSVAUsage
AnothercommonandusefulexampleisanimmediateassertionusedtotrapillegalresetconditionsasshowninExample11.
// Assume the rst_n control line is never an X or Z always_ff @(posedge clock or negedge rst_n) begin assert (!$isunknown(rst_n)) else $error("unknown value on rst_n"); if (!rst_n) q <= 0; else q <= d; end
Example11‐Flip‐flopwithasynchronousresetandinlineimmediateassertion
Thisstyledoesindeedworkundermostconditions,butiftherearehundredsoftheseregistersinadesign,anyresetsignalthatgoesunknownwillexecutehundredsoftheseerrormessages.Sendinghundreds of error messages to the terminal can both slow down simulation performance andintroduce a huge annoyancewhenhundreds of errormessages are basically reporting the sameproblem.
One other problem with this immediate assertion example is that although it catches rst_ntransitionsfrom1-to-X/Z,itwillnotcatchresettransitionsfrom0-to-X/Z-to-1(risingedgeonrst_n)thatoccurallwithinthesamecycle.
Abindfilecannotinsertimmediateassertionsintothemiddleofaproceduralblock,butabindfilecanincludeimmediateassertionstocheckasynchronouscontrolsignalswhennecessary.
Instead of adding the immediate assert to do reset checking in every RTL register, put animmediateassertintoanalwaysprocessinabindfileasshowninExample12.
module DUT_asserts ( // input declarations, including reset ); always @* begin assert(!$isunknown(rst_n)) else begin $error("ERR_reset_went_unknown"); repeat(2) @(posedge clk); $finish; end end ... endmodule
Example12‐DUT_assertsmodulewithimmediateassertiontocheckresetand$errorreporting
AddingtheimmediateassertcommandtothebindfileoffersthreevisibleadvantagesoverputtingtheimmediateassertcommandintotheDUTmodelitself:
Theassertcanbecheckedonceandissuejustoneerrormessage. The always @* trigger will also catch the 0-to-X/Z-to-1 transitions missed by the
immediateassertofExample11. Thealwaysprocesscanbesetuptotriggeranimmediateasserterrormessageandthen
waitfor2moreclockcyclesbeforeabortingthesimulationwiththe$finishcommand,asshowninExample12.
SNUG2016
Page24 Rev1.0
SystemVerilogAssertions‐Bindfiles&BestKnownPracticesforSimpleSVAUsage
Figure12‐ImmediateassertionDVEdisplaywithoutlabelname(Note:unnamed$$_1)
Allowing the assert to issue amessage and thenwait for two clock cycles typicallymakes thewaveformdisplay easier to read.Manywaveformviewersmighthave adisplay‐update race thatwouldterminatethesimulationbeforecapturingthefinalsignalsthatcausedtheassertiontofail.ThewaveformdisplayinFigure12showsthefailingassertionjustbeforetheendofthesimulation.
OneproblemwiththeimmediateassertcommandinExample12isthatithasa$errormessagebut no assertion label. In the absence of a label, DVE has assigned a default identifier ofunnamed$$_1 totheimmediateassertioninthewaveformwindow.Ifthereweredozensoftheseimmediateassertcommandsinuse,thewaveformwindowwouldbedifficulttouse.
Justaswedidwithconcurrentassertions,theimmediateassertcommandcanremovethe$errormessageandprependtheassertkeywordwithanassertionlabelasshowninExample13.
module DUT_asserts ( // input declarations, including reset ); always @* begin ERR_reset_went_unknown: assert(!$isunknown(rst_n)) else begin repeat(2) @(posedge clk); $finish; end end ... endmodule
Example13‐DUT_assertsmodulewithimmediateassertiontocheckresetanddefaultERR_labelreporting
SNUG2016
Page25 Rev1.0
SystemVerilogAssertions‐Bindfiles&BestKnownPracticesforSimpleSVAUsage
Figure13‐ImmediateassertionDVEdisplaywithlabelname(ERR_reset_went_unknown)
Adding the descriptive label to the immediate assert command in Example 13 causes DVE todisplay the label name in the waveform window as shown in Figure 13, just like it does withconcurrent assertions. The immediate assert with descriptive label in the waveform windowagainsimplifiesthedebuggingtask.ThefactthatthecodeofExample13wasaddedtoabindfileandwaitedtwoclockcyclesaftertheimmediateassertfailed,alsoallowedthewaveformdisplayto shown some useful information before aborting the simulation. This could simplify thedebuggingtask.
To summarize this section, immediate assertions are very useful to test asynchronous controlsignals suchasasynchronous reset, asynchronousset,and latchenables. If asynchronouscontrolsignals glitch in the middle of a clock cycle, they can cause unexpected behavior in the RTLsimulationanddetectingthoseglitchesismosteasilyaccomplishedusingimmediateassertions.
When should engineersuse concurrent assertions?Concurrent assertions should be used to testcycle based synchronous activity including combinational logic thatmay be harmlessly glitchingandsettlingbetweenclockcycles.Ingeneralengineersdonotcareifcombinationallogicisglitchingas longas itsettlestoavalidandstablevalue intimetomeetthesetuptimeofthenextregisterinputs.
Immediate assertions are sometimes used to test the success of $cast and the class‐basedrandomize() method. Very large companies have shared with Harry Foster and I that they nolongeruseimmediateassertionsfortheseactivities.IbelievethatHarryandIgenerallyagreewiththeselargecompanies;hence,thefollowingadditionalimmediateassertionguideline:
Guideline: Do not use immediate assertions to do assert($cast ...) orassert(class_variable1.randomize()) success checking. These assertions are too easilydisabled from the command line or from unseen code that disables all assertions with$assert_off.Totest$castand$randomizestatements, itisbettertouseif‐testsasshowninFigure14.
SNUG2016
Page26 Rev1.0
SystemVerilogAssertions‐Bindfiles&BestKnownPracticesforSimpleSVAUsage
if (!$cast ...) $error("Cast operation failed ..."); if (!class_variable.randomize())$error("Randomization failed ...");
Figure14‐If‐statement"assertion"testingof$castandrandomize()functions
8. SimpleassertionmacrosGuideline#9:UsemacrostoreduceSVAcodingefforts.
FormanyyearsIhavedocumentedwhatIcall:
TheSVA"circleoflife"(alsoknownasThedisillusionedDesignEngineercycle!!).
TheSVA"circleoflife"consistsofthefollowingsteps:
EngineersgetexcitedaboutSVAcapabilities EngineerstakeSVAtraining EngineersstarttouseSVA EngineersfindSVAtobetooverbose EngineersabandonSVA!!
Figure15‐TheSVA"circleoflife"
Overtheyears,IhavenotedthefollowingissuesthathavecontributedtotheabandoningofSVAusagebydesigners.
ThereisalotofSVAsyntaxtolearnandremember. SVA syntax can be very verbose. The syntax often requires three ormore (many
more) lines of code to test one simple design feature (X lines of code to test onesimplefeature).
SVA coding styles are very susceptible to syntax errors and typos (engineerscomplainthattheyare"spendingtoomuchtimedebuggingassertions!")
Assertionsaresometimeshardtodebug. Somefrontendtoolsdonotsupportsomeassertionkeywordsandabort.
Figure16‐ReasonsengineersabandonSVA
Ifyouwantdesignengineerstouseassertions,Iclaimtheassertioncodingstylehastobesimpleandithastobeconcise.In2009Iauthoredapaperthatshowedconcisemacrosthatcouldbeusedtoreduceassertioncodingerrorssignificantlyandreduceassertioncodingverbosityby40%‐80%overconventionalassertioncodingstyles[3].Somecolleagueshavementionedthattheydonotusethemacrosbecausetheyarenotpowerfulenough,andmycolleaguesarecorrect,butIhavefoundthattheconciseandsimplenatureofthemacrosisveryattractive tomostdesignengineers. If themacrosarenotpowerfulenough towritetheassertionsthatyouwantitmaybethatyouarewritingassertionsthataretypicallytoocomplexformanydesigners.
WhenIshowthesemacrostodesignerswhohavebeentrained,usedandabandonedSVA,theoverwhelmingmajorityre‐embraceSVAadoptionbyusingthesimplemacros.
InrecentyearsIhaveslightlymodifiedthemacronamesandcontentfromthemacrosthatIshowedinthe2009paper.Section8.1documentsthemacrodefinitionsthatInowuse.
SNUG2016
Page27 Rev1.0
SystemVerilogAssertions‐Bindfiles&BestKnownPracticesforSimpleSVAUsage
8.1 SunburstDesignSVAmacrodefinitions
Ikeepthefollowingmacrodefinitionsinafilecalledassert_macros.sv.
`ifndef ASSERT_MACROS `define ASSERT_MACROS `define assert_clk_xrst( arg ) \ assert property (@(posedge clk) disable iff (!rst_n) arg); `define assert_clk( arg ) \ assert property (@(posedge clk) arg); `endif
Example14‐assert_macros.svfile
Thefirsttwolinesofcodeinthisfileareacommontrickusedbysoftwareengineerstoensurethatonlyonecopyoftheassertionmacrosfileisread.
The first macro, assert_clk_xrst( arg ), has all of the necessary code to properly add aconcurrentassertion toabindfile.The "_xrst "portionof themacro indicates thatassertion ischeckedoneachclockedge,"exceptwhenresetisasserted"(disable iff (!rst_n)).
Thesecondmacro,assert_clk( arg ),hasallofthenecessarycodetoproperlyaddaconcurrentassertiontoabindfileandisnotdisabledforanycondition,notevenreset.
Not only do these macros reduce assertion coding effort, a major complaint by most designengineers,buttheyalsoreduceassertionsyntaxerrors.
OneofthemostcommonsyntaxerrorsencounteredbymostnewSVAusersisthecorrectnumberandbalancingofparentheses.
Considerthefollowingassertionexamplewithoutusingamacro:
ERR_FIFO1_SHOULD_NOT_BE_EMPTY: assert property (@(posedge clk) disable iff (!rst_n) cnt>0 |-> !mt)
Example15‐Properlycodedconcurrentassertion‐verbosestyle
Inthisproperlycodedassertionexample,therearethreeopenparens(((andthreeclosedparens))). Coding the same example using the first macro shown in Example 14 would be done asfollows:
ERR_FIFO1_SHOULD_NOT_BE_EMPTY: `assert_clk_xrst(cnt>0 |-> !mt);
Example16‐Properlycodedconcurrentassertion‐macrostyle
Since the overhead‐code has been captured in the macro, the macro has reduced the requirednumberofparenthesesinthisexampletojustoneset.
SNUG2016
Page28 Rev1.0
SystemVerilogAssertions‐Bindfiles&BestKnownPracticesforSimpleSVAUsage
9. Implications|‐>|=>Guideline#10:Use|-> ##1implicationsandnot|=>implications.
|->testsforavalidconsequentexpressioninthesamecycle.
|=>testsforavalidconsequentexpressioninthenextcycle.
Implication operations can be described in English as, "IF a qualifying (antecedent) condition ismet,theimplicationisthattheresultant(consequent)conditionmustalsobetrueinthesamecycle(|->),orinthenextcycle(|=>),orinn‐cycles(|-> ##n)."
These similarbut slightlydifferent implicationoperators areoftenconfusedor switchedbynewusersandtheirsimilarsyntaxoftenmakesthemdifficulttodetect.
AtmultipleDAC conferencesmany years ago (~2004and~2005),my colleague, AlanHunter ofARMsharedthatARMengineerswerenotallowedtouse|=> insteadtheywererequiredtouse|-> ##1
Anotherrespectedcolleague,HarryFoster,explained tomethehistoryofhow|=>wasaddedtoPSLandsubsequentlytoSVA.HarryexplainedthattherewasoneunidentifiedmemberofthePSLcommitteewho complained that he frequentlywas checking consequent expressions in the nextcycleandwantedadedicatedshortertokentodothattypeoftesting;hence,the|=>operatorwasborn.Thistypeofoperatorisoftencalled"syntacticsugar."
Incomputerscience,syntacticsugarissyntaxwithinaprogramminglanguagethatis designed to make things easier to read or to express. It makes the language"sweeter"forhumanuse:thingscanbeexpressedmoreclearly,moreconcisely,or inanalternativestylethatsomemayprefer.[10]
Basically,|-> isasupersetof the|=>operator.The|=>operator iscompletelyunnecessary,butwasaddedforengineerswhowantedtoavoidtheslightlymoreverbosecodingstyle:|-> ##1
Lookingattheimplicationswithlargefontsmakesitreasonablyeasytoseethedifferent|=>and|->implicationoperatorsasshowninFigure17.
ERR_b_did_not_follow_a: `assert_clk (a |=> b); ERR_fifo1_not_full: `assert_clk ((cnt>15) |-> full);
Figure17‐Viewingimplicationoperatorswithlargefonts
Youngengineerswithmega‐perfecteyesightfrequentlyusesmallerfontsanditissomewhathardertoseethedifferencebetweenthe|=>and|->operatorsasshowninFigure18.
ERR_b_did_not_follow_a: `assert_clk (a |=> b); ERR_fifo1_not_full: `assert_clk ((cnt>15) |-> full);
Figure18‐Viewingimplicationoperatorswithsmallfonts
WhenIstandbehindanengineerwhousesasmallerfont,IseecodethatlookssimilartowhatisshowninFigure19!Thetinyfontsmakeitdifficulttoseeanyimplicationoperatorusageerrors.
ERR_b_did_not_follow_a: `assert_clk (a |=> b); ERR_fifo1_not_full: `assert_clk ((cnt>15) |-> full);
Figure19‐Viewingimplicationoperatorswithsmallfontsfromadistance
SNUG2016
Page29 Rev1.0
SystemVerilogAssertions‐Bindfiles&BestKnownPracticesforSimpleSVAUsage
BeforeIencouragedengineerstoonlyusetheoverlappingimplicationoperator,mystudentsandIwouldbothfrequentlymissthattheywereusingthewrongimplicationoperatorandthedebuggingtaskwastakinglongerthanitshould.
Engineersmust be taught and understand both syntax styles because there aremany examplesusingeachstyle in conferencepapersandbeingused in industry,but if youwant tomake fewerassertion codingmistakes, restrict your own usage to just the overlapping implication operator(|->)andusecycledelaysasrequired.
Iwasawareofthisrecommendationforyearsandhaveshownthisrecommendationfrequentlyintraining, but only in recent years have I made this as a strong recommendation inmy trainingclasses.
After adding this strong recommendation, engineers in my training classes suddenly madedramaticallyfewerassertioncodingmistakes.Iamnowastrongproponentofcompletelyavoidingthe|=>implicationoperator.
10. ConclusionsThispaperhasdescribedanumberofusefulguidelines to improvesimpleassertionusagebyallengineers.Asummaryofthoseguidelinesfollows:
Guideline#1:StartlearningandusingSVAafter2‐3hoursoflectureand1‐3hoursoflabs.
Guideline#2:bindfiles‐usethem!
Guideline#3:InlineSVAcode‐avoidit!
Guideline#4:UsethebindcommandstylethatbindstoallDUTmodules,notthebindstylethatonlybindstospecifiedinstances.
Guideline#5:Adddescriptivelabelstoyourassertioncode.
Guideline #6: In general, do not use $error(...) or $display(...) messages in assertionactionblocks.
Using long, descriptive labels (a) documents the assertions, and (b) accelerates debugging usingwaveformdisplays.
Guideline#7:Uselabelnamesthatstartwith"ERR"or"ERROR"andthenincludeashortsentencetodescribewhatiswrongifthatassertionisfailing.
Guideline#8:Useconcurrentassertionsandavoidusingimmediateassertions.
Guideline#9:UsemacrostoreduceSVAcodingefforts.
Guideline#10:Use|-> ##1implicationsandnot|=>implications.
Following theseguidelineswillsimplify theuseofassertions, reduceassertioncodingerrorsandaccelerateRTLdesigndebugusingassertions.
11. AcknowledgementsIamgratefultomycolleagueDonMillsofMicrochipforhisreviewandsuggestedimprovementstothispaper.DonMillsandChuckMcClishofMicrochip are also responsible for theEMACSmacrocodeshowninAppendix2.2.
SNUG2016
Page30 Rev1.0
SystemVerilogAssertions‐Bindfiles&BestKnownPracticesforSimpleSVAUsage
12. PostludeItshouldbenotedthatittookmeafewyearstoadoptsomeofthebestpracticesdescribedinthispaper,evenaftertheyweresharedwithmebyrespectedcolleagues.IthoughtIwasalreadyusingbest practices when I was shown these contradictory recommendations. As engineers, we aresometimes resistant to new and often foreign recommendations before we arrive at our ownconclusionthatthenewpracticeswillserveusbetterthanthosethatwearecurrentlyusingandthathaveseeminglyserveduswell.
Ifullyexpectthatthereaderwillalsoneedtimetoconsidertherecommendationsinthispaper.
Ialsoknowthattoday'sbestpracticesmaybesupersededbynewandbetterpracticesinthefuture.ItwouldbeamistakeformetoassumethatInowhaveallofthefinal‐bestpractices.Asengineersitwouldbewisetokeepanopenmindtonewrecommendationsthatmightcometousinthefuture.PleasefeelfreetoemailmewithyourownbestSVApractices.
13. References[1] HarryFoster,"MaturingaProject'sABVProcessCapabilities."Availableat
https://verificationacademy.com/sessions/maturing‐abv‐process‐capabilities
[2] HarryFoster,AdamKrolnik,DavidLacey,"AssertionBasedDesign,2ndEdition,"Springer,www.springeronline.com
[3] CliffordE.Cummings,“SystemVerilogAssertions‐DesignTricks&SVABindfiles,”SNUG2009(SanJose).Availableatwww.sunburst‐design.com/papers
[4] CliffordE.Cummings,“SystemVerilogImplicitPortEnhancementsAccelerateSystemDesign&Verification,”SNUG2007(Boston).Availableatwww.sunburst‐design.com/papers
[5] Don Mills, "Being Assertive With Your X (SystemVerilog Assertions for Dummies)," SNUG 2004.Availableatwww.lcdm‐eng.com/papers/snug04_assertiveX.pdf
[6] "IEEEStandardVerilogHardwareDescriptionLanguage,"IEEE,NewYork,NY,IEEEStd1364‐2001
[7] "IEEEStandardForSystemVerilog‐UnifiedHardwareDesign,SpecificationandVerificationLanguage,"IEEE,NewYork,NY,IEEEStd1800‐2009
[8] "IEEEStandardForSystemVerilog‐UnifiedHardwareDesign,SpecificationandVerificationLanguage,"IEEE,NewYork,NY,IEEEStd1800™‐2012
[9] StuartSutherland,"WhoPutAssertionsInMyRTLCode?AndWhy?HowRTLDesignEngineersCanBenefitfromtheUseofSystemVerilogAssertions,"SNUG2015(SiliconValley).Availableatwww.sutherland‐hdl.com/papers/2015‐SNUG‐SV_SVA‐for‐RTL‐Designers_paper.pdf
[10] Syntacticsugardefinition.https://en.wikipedia.org/wiki/Syntactic_sugar
14. Author&ContactInformation
CliffCummings,PresidentofSunburstDesign,Inc.,isanindependentEDAconsultantandtrainerwith34yearsofASIC,FPGAandsystemdesignexperienceand24yearsofSystemVerilog,synthesisandmethodologytrainingexperience.
Mr Cummings has presentedmore than 100 SystemVerilog seminars and training classes in thepast13yearsandwasthefeaturedspeakerattheworld‐wideSystemVerilogNOW!seminars.
SNUG2016
Page31 Rev1.0
SystemVerilogAssertions‐Bindfiles&BestKnownPracticesforSimpleSVAUsage
MrCummingshasparticipatedoneveryIEEE&AccelleraSystemVerilog,SystemVerilogSynthesis,SystemVerilog committee, and has presented more than 40 papers on SystemVerilog &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
LastUpdated:April2016
SNUG2016
Page32 Rev1.0
SystemVerilogAssertions‐Bindfiles&BestKnownPracticesforSimpleSVAUsage
ToolsandOSversionsAppendix1TheexamplesinthispaperwererunusingthefollowingLinuxandSynopsystoolversions:
64‐bitLinuxlaptop:CentOSrelease6.5
VCSversionK‐2015.09‐SP1_Full64
Runningvcsanddveeachrequiredthecommandlineswitch‐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
EditorkeydefinitionstoeaseaddingassertionlabelsAppendix2LabelingisanimportanttipthatIsharedinthisAssertionspaper[3]andinSection6ofthispaper.Invim, Ihaveakeydefinition thatauto‐inserts "_"charactersbetweentextandensures that thelastcharacteronthelabelisa":"
Thekeydefinitionallowsmetoenterthetypeoferrorthatishappeningiftheassertionisfailingwithouttheneedtokeephitting<shift><_>inplaceofalloftheblanks.Itisaconveniencekeythatallowsmetoenterassertionlabelsquicklyandnaturally.
UsingVIM,Icreatelabelsbytyping:
ERR definition of what is going wrong if the assertion fails
Figure20‐Rawlabelentryusingvim
Ithenexittheviminsertionmodeandthenpressthe<shift><_>keys,whichconvertsthistextintothefollowingvalidlabel:
ERR_definition_of_what_is_going_wrong_if_the_assertion_fails:
Figure21‐Labelproperlyformattedusingvimkeydefinition
Ihaveassignedthevimkeydefinitiontothe"_"key,soafterIaddmytextandexittheinsertmodeof vim, I can hit the <shift><_> keys once and itwill insert the proper "_" characters and labeltermination.Ihaveplacedthiskeydefinitioninthe.vimrcfileinmyusershomedirectory.
Forexample,ifIhaveanyofthefollowingtextexamples:
ERR FULL write caused wptr to change ERR FULL write caused 1 2 3 wptr to change :: : :
Figure22‐Examplesofrawlabel‐textentryusingvim
Afterhittingthe_keyoneachline,thetextisproperlymodifiedasshownbelow:
ERR_FULL_write_caused_wptr_to_change: ERR_FULL_write_caused_1_2_3_wptr_to_change:
Figure23‐Examplelabelsproperlyformattedusingvimkeydefinition
SNUG2016
Page33 Rev1.0
SystemVerilogAssertions‐Bindfiles&BestKnownPracticesforSimpleSVAUsage
ForanequivalentEMACSkeydefinition,seeAppendix2.2.
TheVIMkeyassertionlabeldefinitionAppendix2.1
Thefollowingisanexplanationofmyvimkeydefinition.
VIMkeydefinition(andexplanation):map _ ma:%s// /ge><cr>'a:s/\(\w\)\s\+\(\w\)/\1_\2/ge<cr>:s//\1_\2/ge<cr>:s[_: ]*$/:/<cr>:/:$/<cr>'az.
Explanation:
map _ mapthe"_"key
ma Markthecurrentlineas"a"
:%s/ <tab character> / <8 spaces> /ge><cr> Whole file, replace all <tab> characterswith8spaces(ge‐globallyandignorenot‐founderrors)
'a Gobacktolinemarked"a"
:s/\(\w\)\s\+\(\w\)/\1_\2/ge<cr> This line only, find and save any wordcharacter\(\w\),followedbyoneormorewhitespacecharacters\s\+,andagainfindandsaveanywordcharacter\(\w\),replaceitwiththe1st word character saved \1, followed by "_", followed by 2nd wordcharactersaved\2,andreplaceitgloballyonthisline(ge<cr>).
:s//\1_\2/ge<cr> Problem: the above command does not properly substitute singlecharacters ( "full 1 empty"becomes"full_1 empty" )because thesingle character cannot both end the last found pattern and start thenextfoundpattern,sorepeattheprevioussubstitution(//findsthelastsearchedpatternagain).
:s[_: ]*$/:/<cr> This lineonly, findanypatternof "_": andblanksat theendofa lineandreplacethemwithasingle:(labeltermination).
:/:$/<cr> Find":"attheendofaline(thiswillhighlightalllabelterminationsinthefile,usefulforviewinglabels).
'a Gobacktolinemarked"a"
z. Centerthislineonthescreen
SNUG2016
Page34 Rev1.0
SystemVerilogAssertions‐Bindfiles&BestKnownPracticesforSimpleSVAUsage
EMACSauto‐assertionlabelcreationAppendix2.2
My colleagues Don Mills and Chuck McClish of Microchip have graciously supplied a similardefinitionthatcanbeusedinEMACStoinsertthe"_"charactersjustlikethevimkeydescriptionshowninAppendix2.1.Thecodebelowismappedto"C‐x_"buttheEMACSusercanmapthemacrotoanykeytheywant.
(fset 'auto-underscore-insert [?\C-x ?r ? ?q ?\C-a ?\C- ?\C-e ?\M-x ?n ?a ?r ?r ?o ?w ?- ?t ?o ?- ?r ?e ?g ?i ?o ?n return ?\C- ?\C-\M-r ?\\ ?w ?\C-m ?\C-f ?\C-w ?: ?\C-a ?\C-\M-s ?\\ ?w ?\C-m ?\C-b ?\C- ?\C-e ?\M-x ?r ?e ?p ?l ?a ?c ?e ?- ?r ?e ?g ?e ?x ?p return ? return ?_ return ?\C-a ?\M-x ?w ?i ?d ?e ?n return ?\C-x ?r ?j ?q]) (global-set-key (kbd "C-x _") 'auto-underscore-insert)
BindtospecificDUTinstanceAppendix3Recommendation:Donotusethisstyle.
Thisstylespecifiesboththetargetdutfiletobindto,aswellaswhichinstanceofthetargetdutfileisbeingbound to. In theory, it is possible to listmultiplebind commandsof this style todifferentinstancesofthetargetdutfile.
bind fifo1 :u1 fifo1_asserts p1 (.*);
Example17‐Non‐recommendedbindstyle‐bindstojustoneinstanceofaDUT
Example17showshowtobindtotheu1instanceofthefifo1design.Thisstylerequiresthatthebind commandbe scoped to the samemodule as theu1 instance of thefifo1 since thefifo1could be placed inmultiple levels of hierarchy and in each scoped hierarchy the instance namecouldalsobeu1.
The:u1instancenamecouldbeahierarchicalpathsuchas:w1.u1andcouldbealistofinstancesinthedesignwithdifferenthierarchicallistings.
NOTE: Until recently, older versions of VCS did not support this bind‐style but as of the VCS2015.06 version, this style is now fully supported. I am not sure which VCS version started tosupportbindingtoasingleinstance.VCS'previouslackofsupportforthisstylewasnotanissueformebecauseinmyopinion,itwasnotwisetolimitassertioncheckingtojustonecopyofamodule.AdesignerwhousesthisstyleorthestyleshowninAppendix4mightbindtoaworkinginstancewhileanotherinstanceinthedesigncouldbefailing.
BindtoaninstancenamewithoutspecifyingtheDUTAppendix4modulename
Recommendation:Donotusethisstyle.
This style only specifies the instance name of the target dutfile that is being bound to withoutspecifying themodule type,while the style inAppendix3 first referenced themodulenameandthenincludedtheinstancename.
SNUG2016
Page35 Rev1.0
SystemVerilogAssertions‐Bindfiles&BestKnownPracticesforSimpleSVAUsage
Aswith thepreviousstyle, it ispossible to listmultiplebind commandsof thisstyle todifferentinstancesofdifferentDUTs.
bind :u1 fifo1_asserts p1 (.*);
Example18‐Non‐recommendedbindstyle‐bindstoaninstancenameonly
Example18showshowtobindtotheu1instanceinthecurrentscope.Thisstylealsorequiresthatthebindcommandbescopedtothesamemoduleastheu1instanceoftheDUT.
Onceagain,the:u1instancenamecouldbeahierarchicalpathsuchas:w1.u1andcouldbealistofinstancesinthedesignwithdifferenthierarchicallistings.
NOTE:even thougholderversionsofVCSdidnotsupport theability tobind toone instanceofamoduleuntilrecently,VCShaslongsupportedthisstyletobindtoaninstancename.
top related