world class systemverilog & uvm training - … class systemverilog & uvm training...

World Class SystemVerilog & UVM Training

SystemVerilogAssertions‐Bindfiles&BestKnownPracticesforSimpleSVAUsage

Clifford E. Cummings

Sunburst Design, Inc. [email protected] 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


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


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


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


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


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


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


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


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


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


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


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.

ìnclude "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: àssert_clk_xrst ($changed(din) |-> ##1 (dout == $past(din))); ERR_dout_did_not_reset: àssert_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


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


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


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


Figure4‐fifo1modulewithassertionsembeddedabovethealways_ffcode

YetotherassertionswouldbeplacedafterthealwaysprocessasshowninFigure5.

SNUG2016

Page17 Rev1.0


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


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


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


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


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


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


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


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


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


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


8.1 SunburstDesignSVAmacrodefinitions

Ikeepthefollowingmacrodefinitionsinafilecalledassert_macros.sv.

ìfndef 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); èndif

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: àssert_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


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.


Figure18‐Viewingimplicationoperatorswithsmallfonts

WhenIstandbehindanengineerwhousesasmallerfont,IseecodethatlookssimilartowhatisshowninFigure19!Thetinyfontsmakeitdifficulttoseeanyimplicationoperatorusageerrors.


Figure19‐Viewingimplicationoperatorswithsmallfontsfromadistance

SNUG2016

Page29 Rev1.0


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


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


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


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


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


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


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.

world class systemverilog & uvm training - … class systemverilog & uvm training...

Documents