clifford e. cummings sunburst design, inc. … 2016 page 4 rev 1.0 systemverilog logic specific...

World Class SystemVerilog & UVM Training

SystemVerilogLogicSpecificProcessesforSynthesis‐BenefitsandProperUsage

Clifford E. Cummings

Sunburst Design, Inc. [email protected] www.sunburst-design.com

ABSTRACT

SystemVerilogaddedthenewlogicspecificprocesses:always_comb,always_latchandalways_ff.Thesenewprocessesseemsimpleenoughbut theyalso include importantsimulationchecksand therearesubtle recommendations that should be followed when using these processes that supersederecommendationsthatexistedwithVerilogRTLsynthesiscodingguidelines.

There isalsoan issuerelated to synthesis that shouldbeaddressedbyall synthesisand linting toolimplementations.Toolscurrentlyissuewarningswhentheyshouldissueerrors.

Thispaperwilldescribeadvantagestousingthenew logicspecificprocessesandoffersupplementalcodingguidelinestoensurethatpre‐synthesissimulationsmatchpost‐synthesisimplementations.Thispaperwillalsosuggestpropererrorconditionsthatshouldbereportedbysynthesisandlintingtools.This paper will also detail the proper usage of functions and tasks with the new logic specificprocesses.

SNUG‐2016SiliconValley,CA

VotedBestTechnicalPaper‐2ndPlace

SNUG2016

Page2

Rev1.0


TableofContentsSystemVerilogLogicSpecificProcessesforSynthesis‐BenefitsandProperUsage....................................1

1. Introduction.....................................................................................................................................................................5

2. Findandfixbugsasearlyaspossible...................................................................................................................5

3. RTLSystemVerilog‐8codingguidelines............................................................................................................6

4. functions,voidfunctionsandtasks........................................................................................................................6

4.1 task‐issueswithlogicspecificprocesses...............................................................................................7

4.2 Voidfunctionsasdocumentation.............................................................................................................7

5. Newlogicspecificprocesses.....................................................................................................................................8

5.1 always_comb.....................................................................................................................................................8

5.2 always_latch.......................................................................................................................................................8

5.3 always_ff..............................................................................................................................................................8

6. Newchecksusingalways_typeprocesses...........................................................................................................9

6.1 Multipleprocessesassigningtothesamevarialbleisillegal........................................................9

6.2 Blockingdelayassignmentsareillegal.................................................................................................12

7. Newadvantagestousingalways_typeprocesses.........................................................................................14

7.1 Improvedautomaticsensitivitylistcreation.....................................................................................14

7.2 Abilitytocallvoidfunctionswithoutargumentlists.....................................................................15

7.3 Always_typeprocessesautomaticallytriggerattime‐0................................................................17

7.4 Differencesbetweenalways_combandalways@*.........................................................................17

7.5 Possiblefuturesynthesisenhancement‐dualedgeflip‐flop.....................................................18

8. Simulatorscanwarnofincorrectlyinferredlogic‐theydon't...............................................................19

9. Synthesistoolswarnofincorrectlyinferredlogic‐theyshouldreporterrors................................20

9.1 DesignCompileralways_combwarnings............................................................................................20

9.2 DesignCompileralways_latchwarning...............................................................................................21

9.3 DesignCompileralways_ffwarning......................................................................................................22

9.4 Whywarningsandnoterrors?................................................................................................................24

10. Proposed:always_comb_fb................................................................................................................................25

11. Conclusions..............................................................................................................................................................26

12. Acknowledgements...............................................................................................................................................27

13. References................................................................................................................................................................27

14. Author&ContactInformation..........................................................................................................................27

ToolsandOSversions.............................................................................................................................29 Appendix1

Thedesignflow‐Findingandfixingbugs......................................................................................29 Appendix2

SNUG2016

Page3

Rev1.0


TableofFiguresFigure1‐Multi‐driversimulationwaveform(badresults)................................................................................10

Figure2‐DesignCompilermulti‐drivererrormessage.......................................................................................10

Figure3‐VCSerrormessagesforillegalsame‐variableassignmentsfrommorethanonealways_ffprocess.......................................................................................................................................................................................11

Figure4‐VCSerrormessageforillegalsame‐variableassignmentsfromalways_ff&alwaysprocesses...................................................................................................................................................................................11

Figure5‐TimingdiagramofRTLflip‐flopwithmissedreset............................................................................13

Figure6‐VCSerrormessagewhenblockingdelaysareaddedtoalways_typeprocesses....................13

Figure7‐alwaysprocesssensitivitylistgenerationwhencallingtasksandfunctions..........................14

Figure8‐always_typeprocesssensitivitylistgenerationwhencallingtasksandfunctions...............15

Figure9‐Largecombinationallogicandsplitcombinationallogic.................................................................16

Figure10‐Largecombinationallogicandnarrativecombinationallogiccallingvoidfunctions.......16

Figure11‐DCreportserrorforedge/no‐edgeflip‐flopmodel.......................................................................18

Figure12‐DCerrormessagefordual‐clk‐edgeflip‐flop‐always_ff‐edgeversion...................................19

Figure13‐DesignCompileralways_combwarningmessage............................................................................20

Figure14‐VCSerrormessageforillegalalways_combcodewithsensitivitylist.....................................21

Figure15‐always_latch‐Improperlycodedlatchlogic‐combinationallogic..........................................21

Figure16‐VCSerrormessageforillegalalways_latchcodewithsensitivitylist......................................22

Figure17‐DesignCompileralways_ffwarningmessage....................................................................................22

Figure18‐always_ffcheck_designwarning..............................................................................................................22

Figure19‐Incorrectsynthesizedand‐gatefromerroneousalways_ffprocesssensitivitylist............23

SNUG2016

Page4

Rev1.0


TableofExamplesExample1‐always_ffflip‐flopwithasynchronouslow‐truereset....................................................................8

Example2‐Multi‐driverSystemVerilogmodel‐alwaysprocesses‐simulates(poorly)‐doesnotsynthesize...................................................................................................................................................................................9

Example3‐Multi‐driverSystemVerilogmodel‐always_ffprocesses‐failssimulationcompilation.......................................................................................................................................................................................................10

Example4‐Multi‐driverSystemVerilogmodel‐always_ff&alwaysprocesses........................................11

Example5‐dffmodelusingalwaysprocesswith#2delays‐simulationproblems................................12

Example6‐dffmodelusingalways_ffprocesswith#2delays‐properlyfailstocompile...................13

Example7‐Erroneousedge/no‐edgeflip‐flopmodel.........................................................................................18

Example8‐Dual‐clk‐edgeflip‐flop‐always_ff‐NO‐edgeversion.....................................................................18

Example9‐Dual‐clk‐edgeflip‐flop‐always_ff‐edgeversion.............................................................................19

Example10‐always_comb‐Improperlycodedcombinationallogic‐latchstyle#1..............................20

Example11‐always_comb‐Improperlycodedcombinationallogic‐ff.......................................................20

Example12‐always_latch‐Improperlycodedlatchlogic‐combinational.................................................21

Example13‐always_latch‐Improperlycodedlatchlogic‐combinational.................................................21

Example14‐always_ff‐Improperlycodedfflogic................................................................................................22

TableofTablesTable1‐ComparingSystemVerilogtasks,functionsandvoidfunctions........................................................7

Table2‐Proposedsynthesistoollegal‐logicchecking.........................................................................................25

SNUG2016

Page5

Rev1.0


1. IntroductionSystemVerilogaddedlogicspecificprocesses toshowdesigner intent.SystemVerilogaddedotherfeatures to facilitate RTL design. The new SystemVerilog features motivated a new set ofrecommendedRTLcodingguidelines.Thispaperdetails thebenefitsofmanynewSystemVerilogfeaturesandproposesguidelinesfortheirproperusage.

ThenewSystemVerilogfeaturesshouldhavealsoencouragedsimulationandsynthesisvendorstodoadditionalcheckingandreportingoferrorsintheSystemVerilogRTLcode,buttheaddedchecksdonotgoas farastheycouldtohelpRTLcodersremoveerrors fromsimulatedandsynthesizeddesigns.Appendix2of thispaperdetailsadditionalchecksanderrorsthatshouldbereportedbyvendortools.

RTL coders are encouraged to demand reasonable additional checks from their vendors to helpimprovethequalityoffront‐endRTLdesigns.

2. FindandfixbugsasearlyaspossibleTheearlierabugisidentifiedandfixed,thefasterahighqualitydesignwillbereleasedtomarket,enablingsuccessfulcompaniestobecomemoreprofitable.

0includesadetailedlistofdesignstepsandthetypesofbugsthataretypicallydiscoveredwithineachstep.

Anabbreviatedlistoftechniquesandplacestoidentifyandcorrectbugsis:

Useacolorizedcodeeditortohelpfindmisspelledkeywordsandunterminatedstrings. Use the simulationcompilation tool to identify syntaxandsemanticerrors(illegal coding

stylesthatifpermittedcouldcausebugstogoundetecteduntillateinthedesignflow). UsesimulationtofindfunctionalRTLbugs. Use synthesis compilation tools to identify coding styles that do not match expressed

designerintent.Manylintingtoolscandothistaskiftheengineerhasaccesstolintingtools. Usesynthesizedgate‐levelnetliststorunsimulationstoidentifyamismatchbetweenpre‐

andpost‐synthesissimulations.

Findingbugs,fixingbugs,andexhaustivelyidentifyingallbugsearlyareallreasonstosetguidelinesandaddSystemVeriloglanguagefeatures.Ifabugcanbeidentifiedatanearlierdesignstage,everyeffortshouldbemadetomakethathappen.Ifyouunderstandtheimportanceoffindingandfixingbugsearly,youcanskip0thatdescribesinmoredetailwherebugscanbefound.

SNUG2016

Page6

Rev1.0


3. RTLSystemVerilog‐8codingguidelinesGood coding guidelines help designers avoid mistakes and help identify problems as early aspossible.

In the year 2000, I presented a paper with 8 Verilog RTL coding guidelines to help avoidmismatchesbetweenpre‐andpost‐synthesissimulations[2].Thoseguidelines, shownbelow,stillapplytoSystemVerilogRTLcoding!

RTLCodingGuidelines

Guideline#1: Sequentiallogic‐usenonblockingassignments

Guideline#2: Latches‐usenonblockingassignments

Guideline#3: Combinationallogicinanalwaysblock‐useblockingassignments

Guideline#4: Mixedsequentialandcombinationallogicinthesamealwaysblock‐usenonblockingassignments

Guideline#5: Donotmixblockingandnonblockingassignmentsinthesamealwaysblock

Guideline#6: Donotmakeassignmentstothesamevariablefrommorethanonealwaysblock(ThisguidelineisnowenforcedbytheSystemVerilogcompiler‐seeSection6.1fordetails)

DisplayGuideline

Guideline#7: Use$strobetodisplayvaluesthathavebeenassignedusingnonblockingassignments

GeneralGuideline

Guideline#8: Donotmake#0proceduralassignments

RTL coders that follow these guidelines will remove 90%‐100% of all SystemVerilog raceconditionsfromtheirsimulations.

4. functions,voidfunctionsandtasksVerilog had both functions and tasks. SystemVerilog added the exceptionally useful voidfunction.AquickdescriptionofthefunctionalityandutilityofSystemVerilogtasks,functionsandvoidfunctionsisincludedherebeforetheirpreferredusageisdescribedstartinginSection5andcontinuingthroughtherestofthepaper.

Tasks are time‐consuming subroutines. SystemVerilog void functions are 0‐time subroutines.Verilogfunctionsweresub‐programs that returnedasinglevalueand thefunction had tobepartofanotherexpression.

Whencomparingfunctions,voidfunctionsandtasks, thefollowingtableshowssomeofthesimilaritiesanddifferences.

SNUG2016

Page7

Rev1.0


Timing SimulationNote SynthesisNote

task

Nodelays Legal Legal,butnowdiscouraged

#delays Legal Ignoredbysynthesis

@(posedge clk) Legal Synthesiserror

wait Legal Synthesiserror

function&voidfunction

Nodelays Legal Legalandencouraged

#delays Compilererror Illegal

@(posedge clk) Compilererror Illegal

wait Compilererror Illegal

Table1‐ComparingSystemVerilogtasks,functionsandvoidfunctions

AscanbeseeninTable1,tasksareallowedtouseavarietyofdelaysandtriggersthatareeitherignoredorcausesynthesiserrors.FunctionsarenotallowedtohaveanytypeofdelayortriggerandthesimulationcompilercatchestheseproblemsearlyintheRTLdesigncycle.

Thepoint is,tasks allowRTLdesigners to add time‐dependent constructs and to simulate codethatcancauseproblemsinsynthesis,whilefunctionscannot.TheSystemVerilogvoidfunctiondoes the same thing as an untimed task and hence tasks should no longer be used inSystemVerilogRTLsynthesis.

4.1 task‐issueswithlogicspecificprocesses

always_comb and always_latch will examine the internal equations of a void function tocorrectly add signals to the RTL simulation sensitivity lists, while internal task signals are notexamined.ThisisanotherenhancementthatismadeavailabletoRTLcodersthatwasnotpresentwiththeVerilogalways@*.ThisisdescribedingreaterdetailinSection7.1.

4.2 Voidfunctionsasdocumentation

Tasks are exceptionally useful as a verification subroutine that can consume clock cycles, butVerilogtasks have had very limited valuewhenused in RTL synthesis and that is still true forSystemVerilog.

RTLsynthesistoolsprohibittheuseofedge‐triggeringcode,suchas@(posedgeclk), insideofatask,anddelaysintasksarecompletelyignored,soanythingthatisdelayortriggerrelatedinataskiseitherignoredorillegal.

TheonlyvaluethattaskshadinVerilogsynthesiswasasasubroutinetoassignconstantvaluestomultiple signals inmultiple places; tasks were essentially largemacro‐like assignments. If onewanted to assign variable values to the signals, the variable argumentshad to be listed astaskinputstobeautomaticallyrecognizedandaddedtothesensitivitylistofanalways@*process.Thiswasasignificantlimitationimposedbytasks.

SNUG2016

Page8

Rev1.0


5. NewlogicspecificprocessesAny language or tool feature that identifies problems earlier in the design flow is a feature thathelpsengineersshortenthedesigncycleandimprovethequalityofthedesign.AnynewlanguagefeaturethatcouldhelpidentifyproblemsearlierinthedesignflowisafeatureworthyofadditiontotheSystemVeriloglanguage.

Ingeneral,initialprocessesareusedbyVerilogtestbencheswhilealwaysprocessesareusedforVerilog design modeling. SystemVerilog added three new types of always processes that wereintendedtoshowdesignerintentandtoenabletoolstohelpRTLcodersidentifyproblemsearlierinthedesignflow.

The three new logic specific, always_type processes are: always_comb, always_latch andalways_ff.Theseprocessesaredescribedintheremainderofthissection,alongwithsomeofthenewsimulationcompilationchecksthatareincludedwiththesealways_typeprocesses.

5.1 always_comb

always_comb is used to describe combinational logic and automatically builds the propersensitivity list required by the simulator. In fact, the always_comb process builds a bettersensitivitylistthantheVerilog‐2001always @*.TheimprovementsaredescribedinSection7.1.

Guideline:usealways_combtocodeallRTLcombinationalblocksandquitusingalways @*.

5.2 always_latch

always_latch is used to describe latch‐based logic and also automatically builds the propersensitivitylistrequiredbythesimulator.Justlikethealways_combprocess,always_latchbuildsabettersensitivitylistthantheVerilog‐2001always @*.

Guideline:whendoinglatch‐baseddesign,usealways_latchtocodeallRTLlatchblocksandquitusingalways @*.

5.3 always_ff

always_ff is used to describe clocked logic but it does NOT automatically build the propersensitivitylistrequiredbythesimulator.

Thealways_combandalways_latchprocessescandeterminethecorrectsensitivitylistfromthecodewithinthoseprocesses.Alloftheinformationnecessarytogenerateacorrectsensitivitylistisavailableintheequationswithinthoseprocesses,butthatisnottrueforalways_ff.

Examinethealways_ffRTLcodeforaflip‐flopasshowninExample1.

module dff1 ( output bit_t q, input bit_t d, clk, rst_n); always_ff @(posedge clk, negedge rst_n) if (!rst_n) q <= 0; else q <= d; endmodule

Example1‐always_ffflip‐flopwithasynchronouslow‐truereset

SNUG2016

Page9

Rev1.0


Thereisnoinformationinthealways_ffprocesstoidentifythenameoftheclock. Thereisnoinformationinthealways_ffprocesstoidentifythepolarityoftheclock. Thereisnoinformationinthealways_ffprocesstoidentifyiftheresetissynchronousor

asynchronous.

Forthesereasons,thealways_ffblockstillneedsasensitivitylist.

Guideline:usealways_fftocodeallRTLclockedblocksandquitusingalways @(posedge clk ...).

6. Newchecksusingalways_typeprocessesOneofthegreatadvantagesofusingthenewalways_typeprocessesisthatthesimulationcompilerwillidentifyandissueerrorsforimpropercodingstylesthatarenotnecessarilyrelatedtologicthatwouldbe inferredbysynthesis tools.Thenewerrors thatare identifiedcouldcausemismatchesbetweenpre‐andpost‐synthesissimulations.ThismeansthatsomeimportanterrorswillbecaughtmuchearlierthanusingolderVerilogtechniquesbeforewastingtimerunninginvalidsimulationsandsynthesis.Theadditionalchecksaredescribedbelow.

6.1 Multipleprocessesassigningtothesamevarialbleisillegal

Newcheck‐RTLcodethatusesthenewalways_typeprocesses‐makingassignmentstothesamevariablefrommorethanonealways_typeprocessisnowillegal.

Foryears,allsynthesistoolshavegivenerrorsifthesameoutputvariablewasassignedfrommorethanoneVerilogalways process, but simulatorsallowed the same coding style tobe simulated.ThismeantthatanengineercouldwriteandsimulateillegalRTLcodeandnotdiscovertheproblemuntilsynthesis.Inotherwords,theproblemwouldbefoundbutitwouldbefoundlateinthedesignflowafterwastingsignificanttimedoingsimulationsofillegalRTLcode.

Considerthed‐flip‐flopcodeinExample2.Thiscodewillsimulate,albeitwitharaceconditionandquestionableresults.Bothalwaysprocessesmakeassignmentstothesameqvariable,butthereisno guarantee which always process will finish last. During simulation, whichever assignmentfinisheslastwillmakethefinalassignmentseeninawaveformdisplay.AscanbeseeninFigure1,VCShasassignedtheq‐variablefromthefirstalwaysblockfollowedbythesecondalwaysblock.This simulation behavior is legal but not guaranteed. Another simulator or even a differentsimulation might cause the first always process assignment to execute last, which would givedifferentresults.

module dff_2a ( output logic q, input logic d1, d2, clk, rst_n); always @(posedge clk or negedge rst_n) if (!rst_n) q <= '0; else q <= d1; always @(posedge clk or negedge rst_n) if (!rst_n) q <= '0; else q <= d2; endmodule

Example2‐Multi‐driverSystemVerilogmodel‐alwaysprocesses‐simulates(poorly)‐doesnotsynthesize

SNUG2016

Page10

Rev1.0


Figure1‐Multi‐driversimulationwaveform(badresults)

Forthisreason,RTLCodingGuideline#6ofSection3states:Donotmakeassignmentstothesamevariablefrommorethanonealwaysblock.Ignoringthisguidelinecausesthesimulationbehaviortobenondeterministic.

WhentheExample2codeisreadintoDesignCompiler(DC),theerrormessageshowninFigure2isproperlyreported.

Error: .../dff_2a.sv:9: Net 'q' or a directly connected net is driven by more than one source, and not all drivers are three-state. (ELAB-366) *** Presto compilation terminated with 1 errors. *** Error: Can't read 'sverilog' file '.../dff_2a.sv'. (UID-59)

Figure2‐DesignCompilermulti‐drivererrormessage

Thepointis,usingVerilogalwaysprocessesallowsthedesignertoconstructflawedRTLcodethatmightnotbediscovereduntil simulation (if the race condition is recognized from thewaveformdisplay), or until read into DC. Finding the bug during simulation or while reading code intosynthesis tools isneedlessly late in thedesign flow.Designersprefer to find this typeofmistakeearlier.

WhatwasoncejustaguidelineisnowenforcedbytheSystemVerilogsimulationcompiler,allowingtheRTLdesignertofindthisbugveryearlyinthedesignflow.

module dff_2b ( output logic q, input logic d1, d2, clk, rst_n); always_ff @(posedge clk or negedge rst_n) if (!rst_n) q <= '0; else q <= d1; always_ff @(posedge clk or negedge rst_n) if (!rst_n) q <= '0; else q <= d2; endmodule

Example3‐Multi‐driverSystemVerilogmodel‐always_ffprocesses‐failssimulationcompilation

TheSystemVerilogRTLcodeofExample3isexactlythesameastheRTLcodeofExample2,exceptthealwaysprocesseshavebeenreplacedwithalways_ffprocesses.Anyattempttocompilethismodelforsimulationwillfailandcauseanerrormessagetobereported.TheerrormessageforthismodelasreportedbyVCSisshowninFigure3.

SNUG2016

Page11

Rev1.0


Error-[ICPD] Illegal combination of drivers dff_2b.sv, 2 Illegal combination of procedural drivers Variable "q" is driven by an invalid combination of procedural drivers. Variables written on left-hand of "always_ff" cannot be written to by any other processes, including other "always_ff" processes. This variable is declared at "dff_2b.sv", 2: logic q; The first driver is at "dff_2b.sv", 9: always_ff @(posedge clk or negedge rst_n) if (!rst_n) begin q <= '0; The second driver is at "dff_2b.sv", 5: always_ff @(posedge clk or negedge rst_n) if (!rst_n) begin q <= '0; ...

Figure3‐VCSerrormessagesforillegalsame‐variableassignmentsfrommorethanonealways_ffprocess

Sowhathappensifassignmentsaremadetothesamevariable fromaSystemVerilogalways_ffprocessandaVerilogalwaysprocessasshowninExample4?

module dff_2c ( output logic q, input logic d1, d2, clk, rst_n); always_ff @(posedge clk or negedge rst_n) if (!rst_n) q <= '0; else q <= d1; always @(posedge clk or negedge rst_n) if (!rst_n) q <= '0; else q <= d2; endmodule

Example4‐Multi‐driverSystemVerilogmodel‐always_ff&alwaysprocesses

Whenassignmentsaremadetoavariable fromanySystemVerilogalways_typeprocessandalsoassignedfromaVerilogalwaysprocess,thesimulationcompilationwillfail.VCSreportstheerrorasshowninFigure4.

Error-[ICPD] Illegal combination of drivers dff_2c.sv, 2 Illegal combination of procedural drivers Variable "q" is driven by an invalid combination of procedural drivers. Variables written on left-hand of "always_ff" cannot be written to by any other processes, including other "always_ff" processes. This variable is declared at "dff_2c.sv", 2: logic q; The first driver is at "dff_2c.sv", 10: q <= '0; The second driver is at "dff_2c.sv", 5: always_ff @(posedge clk or negedge rst_n) if (!rst_n) begin q <= '0; ...

Figure4‐VCSerrormessageforillegalsame‐variableassignmentsfromalways_ff&alwaysprocesses

SNUG2016

Page12

Rev1.0


Guideline:Usethenewalways_typeprocessestohelpidentifyflawedRTLcodingstylesearlierandquitusingtheolderVerilogalwaysprocess.

6.2 Blockingdelayassignmentsareillegal

New check ‐ RTL code that uses the new always_type processes ‐ making blocking delayassignmentstovariablesisnowillegal.12

SynthesistoolsignorealldelaysinRTLcode,butitwaspossibleusingtheVerilogalwaysprocessto add blocking delays to the RTL code, run Verilog simulations, and cause the pre‐synthesissimulationtobehaveincorrectly.ThismeantthatanengineercouldcodeandsimulateillegalRTLcodeandnotdiscoverthefunctionalproblemuntilpost‐synthesissimulations.Inotherwords,theproblem would only be found very late in the design flow after wasting significant time doingsimulationsandsynthesisof flawedRTLcode,andfindingtheproblemrequireddesignerstorungate‐levelsimulationstodiscoverthatthepre‐synthesisfunctionalitysimulationdidnotmatchthepost‐synthesissimulation.

For the flip‐flop design with asynchronous low‐true rst_n shown in Example 5, the RTL codeincludes #2 blocking delays placed in front of the assignments to the q variable. In the timingdiagramforthisexample,showninFigure5,whenclkgoeshigh,thereisnoactive‐lowrst_n,sotheRTLcodewill immediately jump to theelsebranchof thecode.Theelse branchmust firstwait for the #2 delay, and then will assign the d‐input to the q‐output. The problem with thisexampleisthattherst_nsignalwentactive‐low#1aftertheposedge clk,butsincethesimulatorisstuckwaiting for2nanosecondsbeforeexecuting theelsebranch, theactiverst_n ismisseduntil the next posedge clk during the RTL simulation. Thismeans that the RTL simulation iswrongandmightnotbediscovereduntilpost‐synthesisgate‐levelsimulations.

module dff1a ( output logic q, input logic d, clk, rst_n); always @(posedge clk, negedge rst_n) if (!rst_n) #2 q <= '0; else #2 q <= d; endmodule

Example5‐dffmodelusingalwaysprocesswith#2delays‐simulationproblems

1Blockingstatementsarenotthesameasblockingassignments.Blockingstatementsrefertostatementsthatcanforcethesimulationtimetoadvancebeforeallowingthesubsequentstatementstobeexecuted,including#delaysandcallstoproceduresthatcouldblocksuchastaskcallsthatcontainblockingdelays.2Delaysontheright‐hand‐sideofnonblockingassignmentsarenotblockingdelaysandarethereforewilllegalwhenusingalways_typeprocesses.

SNUG2016

Page13

Rev1.0


Figure5‐TimingdiagramofRTLflip‐flopwithmissedreset

Note that synthesis tools ignore delays in RTL code and would infer the correct flip‐flop withasynchronousreset,whichwillnotmatchthepre‐synthesissimulation.Thisisanerrorthatwillnotbecaughtuntil gate‐simulations fail tomatchpre‐synthesisRTLsimulationsoruntil equivalencechecking tools mathematically prove that the RTL does not match the inferred gate‐levelrepresentation.Thatisundesirablylateinthedesignflow.

If theVerilogalways process is replacedby theSystemVerilogalways_ff process, the includedblocking delays to the RTL code as shown in Example 6 will be flagged as an error duringsimulationcompilation,andthustheerrorwillbeidentifiedveryearlyinthedesignflow.

module dff1c ( output logic q, input logic d, clk, rst_n); always_ff @(posedge clk, negedge rst_n) if (!rst_n) #2 q <= '0; else #2 q <= d; endmodule

Example6‐dffmodelusingalways_ffprocesswith#2delays‐properlyfailstocompile

VCSissuestheerrormessageshowninFigure6,whichindicatesthattheblockingdelay isillegalinsideofthealways_ffprocess.

Error-[SV-BCACF] Blocking construct in always_comb/ff dff1c.sv, 6 "#(2) q <= 0;" Statements in an always_comb shall not include those that block, have blocking timing or event controls, or forkjoin statements. The always_ff procedure imposes the restriction that it contains one and only one event control and no blocking timing controls. Try using simple always blocks.

(NOTE:thiserrormessageisrepeatedforline8)

Figure6‐VCSerrormessagewhenblockingdelaysareaddedtoalways_typeprocesses

SNUG2016

Page14

Rev1.0


7. Newadvantagestousingalways_typeprocessesInadditiontothetwodesignchecksdescribedinSection6, thenewalways_typeprocessesofferadditionaldesignadvantagesdescribedintheremainderofthisSection.

7.1 Improvedautomaticsensitivitylistcreation

Verilog‐2001addedtheabilitytocodeanalwaysprocesswiththe@*sensitivity list.Themotivebehindthisenhancementwastoallowthesimulationandsynthesistoolstoautomaticallycreateacomplete sensitivity list for combinational and latch based logic. The one shortfall with the @*sensitivitylististhatitrequiredalltasksandfunctioncallswithinthescopeofthealwaysprocesstolistthetask/functioncallingargumentsaspartofthetask/functionportdefinitionstoallow@*to findthosesignalstoaddtothesensitivitylist.Anysignalusedwithinatask/functionthatwasnotpartoftheargumentdeclarationsforthetaskandfunctionheaderswouldbemissedandnotaddedtothesensitivitylist.ThisisillustratedinFigure7.

Figure7‐alwaysprocesssensitivitylistgenerationwhencallingtasksandfunctions

TheFigure7exampleincludesbothavoidfunctionandataskthatrepresent3‐inputor‐gates,butonlythea‐inputislistedinthefunctionandtaskheaderswhilethebandc‐inputsarereaddirectly from themodule scope. Thealways@* processeswill only examine the headers of thefunctionandtaskandwill thereforeomit thebandc‐inputs fromtheprocesssensitivity lists.Thepre‐synthesissimulationswillnotmatchthepost‐synthesissimulations.

SNUG2016

Page15

Rev1.0


Figure8‐always_typeprocesssensitivitylistgenerationwhencallingtasksandfunctions

In Figure 8, the same twofunction andtask 3‐inputor‐gates exist, but thealways processeshavebeenreplacedwithalways_combprocesses,whichallowsthealways_combtobuildthefullandpropersensitivitylistfortheprocessthatcallsthevoidfunctionwhilestillnotbuildingthefullsensitivitylistfortheprocessthatcallsthetask.

Thereasonthatcallingataskdoesnotbuildthefullsensitivitylistfromtheinternaltasksignalsisbecauseataskcanconsumetimeanditmaynotevenmakesensetotriggeronalloftheinternaltasksignalssincetheymaynotchangeuntillaterinthesimulation.

Synthesis tools ignore delays anddo not permittasks to include any internal triggering signalssuchas@(posedge clk).Sincedelaysintasksareeitherignoredorillegalwhendoingsynthesis,the preferred SystemVerilog solution is to replace all tasks with void functions. A voidfunction is basically a0‐delaytask callwith the advantage that internalfunction signals areaddedtoanalways_combsensitivitylist.

7.2 Abilitytocallvoidfunctionswithoutargumentlists

Theability to createa full sensitivity list fromvoidfunctionswithall internal functionsignalsremoved fromtheheaderactuallyallowsanothervery interestingandproductivecodingstyle inSystemVerilog.

ConsiderthelargecombinationallogicblockshownontheleftsideinFigure9.Ifthecombinationallogicdoesindeedrequire44linesofcode(ormore)todescribethecombinationalfunctionalityofthisblock,thiscodecouldbequitedifficulttounderstandandmaintain.Onesolutionistosplitthecodeintosmalleralways_combblocksasshownontherightsideofFigure9,butsplittingthecode

SNUG2016

Page16

Rev1.0


doesnotnecessarilydocumentthecodeanybetterthantheonehugealways_combprocess.

Figure9‐Largecombinationallogicandsplitcombinationallogic

Section7.1showedthatanalways_combprocesscannowcallvoidfunctionsthatdonotrequireargument listsandthosevoidfunctions canhaveverydescriptivenames.Thevoidfunctioncalls can nowdocument the higher functionality of the combinational logic.Thevoidfunctioncallscannowtellastoryaboutthecombinationallogic.ThisisshowninFigure10.

Figure10‐Largecombinationallogicandnarrativecombinationallogiccallingvoidfunctions

SNUG2016

Page17

Rev1.0


In this contrived example, the always_comb process executes step_a, followed by steb_b,followedbystep_c,andconcludeswithstep_d.Thehigh‐levelintentofthealways_combprocessismore clear and concise, andwhen an engineer questionswhat should happen instep_b, theengineercanreferencethestep_bvoidfunctiontoseethefunctionalitylow‐leveldetails.

This strategy has the advantage that each step_X void function has encapsulated part of thefunctionality.This strategyhas the advantage that if thestep_b codeneeds tobemodifiedor ifsignalsneed tobeaddedorsubtracted fromstep_b, thosemodificationscanbedone instep_bisolationwithoutanyrequirementtomodifythecallingcodeinthealways_combprocess!

Thisenhancementisahiddengemthatwegetforfreewhenweusealways_combprocessesthatcallvoidfunctions!Thissamecapabilityexistswhenusingalways_latch,butmostengineersavoidcodinglatchesthiscomplex(orcodinglatchesaltogether!)

7.3 Always_typeprocessesautomaticallytriggerattime‐0

Time‐0canbeatrickyplaceinVerilogsimulationsandtime‐0racesimulationconditionsarenotuncommon.Duetothispotentialproblem,simulationvendorshaveimplementedtime‐0executionof simulations such that always processes are started before initial processes. This is notdefined in the Verilog and SystemVerilog Standards, but is common practice among the majorsimulationvendors.Thishiddenpractice removesmanyof the time‐0simulation raceconditionsbecause RTL designs are typicallymodeled using always processes and are therefore activatedbeforetheinitialprocessesthataretypicallyemployedintestbenchstimulusgeneration.

The always_type processes added one more layer of time‐0 race protection not available withalwaysprocesses.Allalways_typeprocessestriggerattheendoftime‐0,soiftheinputstimulusweretobesentbeforethealways_typeprocesseswereactivated,thealways_typeprocesseswouldstilltriggerattheendoftime‐0andwouldthereforeexamineallprocessinputsandreactattime‐0appropriately.

Properstimulustiminggenerationtechniquesandpracticesarebothsignificantandveryimportanttotestbenchstrategies,buttheyarebeyondthescopeofthispaper.

7.4 Differencesbetweenalways_combandalways@*

AsummaryofthedifferencebetweentheVerilogalways @*andtheSystemVerilogalways_combprocessisshownbelow:

always_combmayallowcheckingforillegallatches.TheVerilogalways @*isusedforbothcombinationalandlatch‐basedlogic.

always_combvariablescannotbeassignedfromanotherprocess.ThisallowsthesimulationcompilertoenforceRTLCodingGuideline#6andavoidsynthesiserrors.

always_combcannotincludeblockingdelays,whichremovesacommonpre‐synthesisRTLsimulationproblem.

always_combissensitivetochangeswithinthecontentsofafunction always_combtriggersonceautomaticallyattheendoftime‐0. @*ispermittedtobenestedwithinanalwaysprocesswhilealways_combcannotbe

nested.Itshouldbenotedthatnesting@*isnotarecommendedpractice,butisallowedbythesimulator.

Eachofthesedifferenceshelpstoreducedesignandsimulationmistakesandthereforetheyshowwhyalways_combshouldbeusedovertheVerilogalways @*.

SNUG2016

Page18

Rev1.0


7.5 Possiblefuturesynthesisenhancement‐dualedgeflip‐flop

Thissectiondescribesacapabilitythatdoesnotcurrentlyexistinsynthesistools,butitcouldinthefuture.Inotherwords,"don'ttrythisathome,yet!"

Synthesistoolsrequirethateithereverysignalinasensitivitylisthasanedgespecificationorthatnoneofthesignalsinthesensitivitylisthasanedgespecification.

Considerthepoorlycodedalwaysprocessflip‐flopmodelshowninExample1.

module dff1a ( output logic q, input logic d, clk, rst_n); always @(clk, negedge rst_n) if (!rst_n) q <= 0; else q <= d; endmodule

Example7‐Erroneousedge/no‐edgeflip‐flopmodel

Thismodelwill compileandsimulate likeadualclk‐edgeflip‐flop,butDCdoesnotsupport thiscodingstyleandwillreportanerrorwhenthemodelisreadintoDCasshowninFigure11.Oneoftheissueswiththiscodingstyleisthatthesynthesistoolcannotdetermineifthealwaysprocessisanincorrectlycodedcombinationalalwaysprocessorifitisanincorrectlycodedflip‐flopalwaysprocess.TheresimplyisnotenoughinformationintheRTLmodeltodeterminewhattheintendedlogicshouldbe.

Error: .../dff1a.sv:5: The event depends on both edge and nonedge expressions, which synthesis does not support. (ELAB-91) *** Presto compilation terminated with 1 errors. ***

Figure11‐DCreportserrorforedge/no‐edgeflip‐flopmodel

With the addition of the SystemVerilog always_type processes, it would now be possible todetermine designer intent. Consider the dual‐edgealways_ff flip‐flopmodel in Example8. Thealways_ffkeywordshowsthedesigner'sintenttobuildclockedlogic.Thismodelsimulateslikeadual‐edgeflip‐flopbutDCstilldoesnotsupportthiscodingstyle.

module dff1c ( output logic q, input logic d, clk, rst_n); always_ff @(clk, negedge rst_n) if (!rst_n) q <= 0; else q <= d; endmodule

Example8‐Dual‐clk‐edgeflip‐flop‐always_ff‐NO‐edgeversion

Thereisnoreasonthatsynthesistoolscouldnotallowthismodeltobeacceptedandinferadual‐edge flip‐flop. The coding style would require that the signal in the sensitivity list without aposedge/negedgekeywordwouldhavetobeabsent fromtheequationswithinthealways_ff

SNUG2016

Page19

Rev1.0


process.Thatishowthesynthesistoolcouldidentifythesignalasbeingalegalclocksignalforadual‐edgeflip‐flop.

There is one important negative issue with the coding style of Example 8. What if an engineersimplyforgottoaddtheposedgetotheclksignal?Nowthesynthesistoolwouldbuildaperfectlylegalbutunintendeddual‐edgeflip‐flop.Forthisreason,Iproposethatadual‐edgeflip‐flopmodelberequiredtoaddtheedge3keywordtotheclksignal(asshowninExample9)toaffirmthattheengineerintendedtohaveadual‐edgeclkfortheflip‐flopmodel.

module dff1d ( output logic q, input logic d, clk, rst_n); always_ff @(edge clk, negedge rst_n) if (!rst_n) q <= 0; else q <= d; endmodule

Example9‐Dual‐clk‐edgeflip‐flop‐always_ff‐edgeversion

Thecombinationofalways_ffandtheedgeclkshowthedesigner'sintent.Thereisnoambiguityrelated to whether the always process was combinational or sequential or if the clk wasmistakenlyleftblankversusintentionallychosetobeadualedgeclk.

VCSwillsimulatetheExample8codeasadual‐edgeflip‐flop,butcurrentlyDCstillappliesexistingrulesandreportsthattheedgekeywordisnotallowedinsynthesis,asshowninFigure12.

Error: .../dff1d.sv:5: The construct 'edge' is not supported in synthesis. (VER-700) *** Presto compilation terminated with 1 errors. ***

Figure12‐DCerrormessagefordual‐clk‐edgeflip‐flop‐always_ff‐edgeversion

If a futureASICorFPGA library includeddual‐edge flip‐flops, theRTL coding styleofExample9couldbealegalrepresentationofthedesireddual‐edgeclklogic.

8. Simulatorscanwarnofincorrectlyinferredlogic‐theydon'tSection7showedsimulation‐relatederrorsthatarenowdetectedbythesimulationcompilerbutdoesnotaddresserrorsrelatedtoincorrectlyinferredlogicbysynthesistools.

The IEEE Std 1800‐2012[5] permits simulators the option towarnusers if theRTL coding stylewouldnotinfertheintendedandrequestedlogicwhensynthesized.Thisactionispurelyoptionalandtherearenoknownsimulatorsthatissuetheseusefulwarnings.

The warnings would be exceptionally useful to the RTL coders, so why don't simulators reportthesewarnings? Insomecases, itcanbequitedifficult todeterminewhattypeof logicwouldbeinferredbyasynthesistoolstrictlybyexaminingtheRTLsourcecode.

AlthoughtheRTLsimulationwarningswouldbenice,itfallstoRTLsynthesistoolstotrulyreport

3TheedgekeywordwasaddedtoIEEEStd1800‐2005andmadelegalinthiscontextinIEEEStd1800‐2009.

SNUG2016

Page20

Rev1.0


errorsrelatedtomismatchesbetweentheexpresseddesignerintentandactualinferredlogic.

9. Synthesistoolswarnofincorrectlyinferredlogic‐theyshouldreporterrors

Although simulators do not issue RTL related warnings regarding designer intent when usingalways_typeprocesses,synthesistoolsDOwarntheuserwhenthe inferred logicdoesnotmatchthedesigner‐intended,requestedlogic.

9.1 DesignCompileralways_combwarnings

Foran improperlycodedalways_combprocess,DesignCompiler (DC) issueswarningswhentheRTLcodeisreadintoDC.

module ao1e ( output logic q, input logic en, d); always_comb if (en) q <= d; endmodule

Example10‐always_comb‐Improperlycodedcombinationallogic‐latchstyle#1

DCshowsalatchinferencereportforthiscodingstyleandthenwarnsthatalatchwassynthesizedasshowninFigure13.

Warning: .../ao1e.sv:5: Netlist for always_comb block contains a latch. (ELAB-974)

Figure13‐DesignCompileralways_combwarningmessage

module ao1g ( output logic q, input logic d, clk, rst_n); always_comb @(posedge clk, negedge rst_n) if (!rst_n) q <= '0; else q <= d; endmodule

Example11‐always_comb‐Improperlycodedcombinationallogic‐ff

Fortheimproperlycodedalways_combprocessofExample11,thesimulatorwillreportanerrorbecauseVCSexpectsnosensitivitylistafterthealways_combkeywordandthereforeinterpretsthe@(posedge clk ... asablockingdelay thatprecedes theif‐teston thenext line.Blockingdelaysusedinalways_typeprocessesarenotlegalaswillbeexplainedinSection6.2.Inthisexample,theVCScompiler(andnotDC)reportsatimingrelatederrornotrelatedtotheincorrectalways_comb:

SNUG2016

Page21

Rev1.0


Error-[SV-BCACF] Blocking construct in always_comb/ff ao1g.sv, 5 ao1g Statements in an always_comb shall not include those that block, have blocking timing or event controls, or forkjoin statements. The always_ff process imposes the restriction that it contains one and only one event control and no blocking timing controls. Try using simple always blocks.

Figure14‐VCSerrormessageforillegalalways_combcodewithsensitivitylist

ThecodeinExample11neverevencompilesforsimulationsoitwasnotreadintoDC.

9.2 DesignCompileralways_latchwarning

Foranimproperlycodedalways_latchprocess,DesignCompiler(DC)issueswarningswhentheRTLcodeisreadintoDC.

module lat1d ( output logic q, input logic en, d); always_latch q = en & d; endmodule

Example12‐always_latch‐Improperlycodedlatchlogic‐combinational

DC shows NO latch inference report for this coding style and then warns that a latch was notsynthesizedasshowninFigure15.

Warning: .../lat1d.sv:5: Netlist for always_latch block does not contain a latch. (ELAB-975)

Figure15‐always_latch‐Improperlycodedlatchlogic‐combinationallogic

module lat1e ( output logic q, input logic d, clk, rst_n); always_latch @(posedge clk, negedge rst_n) if (!rst_n) q <= '0; else q <= d; endmodule

Example13‐always_latch‐Improperlycodedlatchlogic‐combinational

Fortheimproperlycodedalways_latchprocessofExample13,thesimulatorwillreportanerrorbecauseVCSexpectsnosensitivitylistafterthealways_latchkeywordandthereforeinterpretsthe@(posedge clk...asablockingdelay("a single statement which is an event control")thatprecedestheif‐testonthenextline.Blockingdelaysusedinalways_typeprocessesarenotlegalaswillbeexplainedinSection6.2.Inthisexample,theVCScompiler(andnotDC)reportsatimingrelatederrornotrelatedtotheincorrectalways_comb:

SNUG2016

Page22

Rev1.0


Error-[OECAB] Singular control statement in always lat1e.sv, 5 lat1e 'always_comb'/'always_ff' block has a single statement which is an event control. Such usage is disallowed due to likelihood of user error.

Figure16‐VCSerrormessageforillegalalways_latchcodewithsensitivitylist

9.3 DesignCompileralways_ffwarning

Foranimproperlycodedalways_ffprocess,DesignCompiler(DC)issueswarningswhentheRTLcodeisreadintoDC.

module dff1d ( output logic q, input logic d, clk, rst_n); always_ff @(clk, rst_n) if (!rst_n) q <= '0; else q <= d; endmodule

Example14‐always_ff‐Improperlycodedfflogic

Thealways_ff sensitivity listofExample14 ismissing edge specifications. If this exampleonlyusedtheolderVerilogalwayskeyword,thesynthesistoolwouldassumethatthecoderepresentedcombinationallogic,butthealways_ffkeywordisrecognizedbyDCsoDCwarnsthataflip‐flopwasnotsynthesizedasshowninFigure17.

Warning: .../dff1d.sv:6: Netlist for always_ff block does not contain a flip-flop.

Figure17‐DesignCompileralways_ffwarningmessage

Thealways_ffcodeofExample14alsocausesDCtoreportapotentialproblemandinstructstheusertorunthecheck_designcommandasshowninFigure18.

Information: There are 1 potential problems in your design. Please run 'check_design' for more information. check_design: Warning: In design 'dff1d', port 'clk' is not connected to any nets.

Figure18‐always_ffcheck_designwarning

After running thecheck_design command,DCreports that thedesign ismissing theclk signalfrom any assignments in the process and then proceeds to build the 2‐inputand‐gate shown inFigure 19. Also shown in Figure 19 is that theclk signal is unconnected and is just a danglingsignal.

SNUG2016

Page23

Rev1.0


Figure19‐Incorrectsynthesizedand‐gatefromerroneousalways_ffprocesssensitivitylist

WhatisdisturbingaboutthisimplementationisthattherewasnowarningissuedbyDCthatthed‐inputsignalwasnotpartofthesensitivitylist.Themissingd‐inputsignalmeansthatpre‐synthesischangestothed‐inputwillnotcausethealways_ffprocesstore‐evaluatetheassignmentsinthealways_ff process,while thepost‐synthesis gate‐level simulationwill indeed re‐evaluate theq‐output assignment every time the d‐input changes. This is a potential source for mis‐matchesbetweenpre‐synthesisandpost‐synthesissimulations.

9.3.1 DidDesignCompilerquitissuingsensitivitylistwarnings?

IrememberthatDCusedtobuildcombinationallogicfromanalwaysprocesswithoutconsideringtheprocess sensitivity list, but afterbuilding the logic,would thenwarn theuser if signalsweremissing from the sensitivity list. This was a valuable warning but it appears that the missingsensitivitylistsignalsarenolongerbeingchecked.

MycolleagueBrianKanenoticedthissameproblemin2013andreportedtheissue.Theassignedcasenumberwas"Case 8000639472 : incomplete combinatorial sensitivity"

TheSynopsysresponsetoBrianatthattimewas

I was able to reproduce what you described, and I was as surprised by it as you were, since historically the tool would issue an ELAB-292 warning for an incomplete sensitivity list. I did some research, and it turns out that the behavior you're seeing is part of a larger effort to remove lint-like (i.e. code quality) checks from HDL Compiler. According to R&D, "HDL Compiler was issuing too many 'false positives', thus the message was unreliable and it was removed." The expectation nowadays is that users will do their code quality checks with a dedicated linting tool.

Removal of linting checks from DC does not benefit users but at least with the addition ofalways_comb and always_latch, there is no need to check the sensitivity list for thesealways_typeprocesses.

Unfortunatelyifanalways_ffprocessisusedincorrectly,DCnowwarnsthataflip‐flopwasnotinferred, builds combinational logic, and then does not warn users that the combinational pre‐synthesisRTLismissingimportantsensitivitylistsignals.Ifthesynthesistoolwouldissueanerrorforthisflawedcodingstyle,therewouldbenoneedforDCtocheckthesensitivitylistsignalsbutthatcurrentlyisnotthecase.

SNUG2016

Page24

Rev1.0


9.4 Whywarningsandnoterrors?

Whydosynthesisvendorsissuewarningsinsteadoferrors?

First, it should be noted that synthesis behavior regarding the implementation of always_typeprocessesisnotdefinedbyanyIEEEStandard.

Second,vendorsareconcernedaboutissuingfalseerrormessages("falsepositives").Ifthevendortool issuesanerrormessagewherenoerror ispresent,customerswill loseconfidence invendorerrormessages.

Third,vendorsynthesis toolshave issuedalways_typewarnings foryearsand if theychange thewarningstoerrors,thismightcausepoorlycodeddesignsthatpreviouslycompiledtofailsynthesiscompilation.Therearetwopossiblesolutionstothislatterproblem:

a) My preference is that vendors change the always_type warnings to errors and forcedesignerstousegoodandinformedcodingstyles.Ifanalways_combprocessinferslatches,I believe synthesis tools should force the engineer to change the flawed‐always_combkeywordtotheactual‐intentkeywordofalways_latch.Asanalternative,thedesignercanchangethealways_combtoalwayskeywordtoavoidadditionalchecking,ortoolvendorscould give engineers a new command switch that converts always_type violations fromerrorsintothecurrentlyreportedwarnings.

b) Asecondand less‐attractivealternative is togivedesignersasynthesis switch toconvertalways_typewarningsintoerrors.Theflawwiththisalternativeisthatthesynthesistoolisissuing warnings when errors would help designers identify design‐intent errors. If thisalternativeisimplemented,Iwouldencourageallsynthesisengineerstoturnthisswitchonpermanently.

Thealways_typesynthesiscompilationwarningsshouldbereplacedwitherrorsforthefollowingreasons.

If I,asanRTLdesigner, took the timetospecify the typeof logicI intendedtobe inferred inmydesign,andifthatlogicisnotinferredbythesynthesistool,thenIwantanerrorthatwillforcemetocorrectmydesignbeforeDClegallyreadsthedesign,notawarningthatiseasilylostasitscrollspastmyvisiblesynthesistranscriptwindow.Thewholeintentofaddingalways_typeprocessesistoallowmetoshowenforceabledesignerintentandwarningsjustdonotadequatelyachievethatgoal. If the proposed synthesis tool errors prove to be problematic, I have an existing fallbackposition.IcanremoveallofthenewSystemVerilogalways_typeprocessesandgobacktousingaplainoldVerilogalwaysprocess,whichismostlyignoredbysynthesistoolsasitpertainstointent‐checking.

There is some concern regardingwhich inferred logic should be legalwith existingalways_typecoding styles. As someone who has worked with RTL coders for about 22 years and who alsoparticipatedonthecreationoftheIEEEStd.1364.1‐2002[6]standard(RTLsynthesisstandard),IproposethatthefollowingstylesshouldbelegalorillegalasoutlinedinTable2.

SNUG2016

Page25

Rev1.0


Table2‐Proposedsynthesistoollegal‐logicchecking

AsnotedbeneathTable2,itshouldbelegalforalways_latchandalways_fftosimultaneouslyinfercombinational logicas longastheyalsodrivethedatapinof therequested latchesandflip‐flopsrespectively.

AlsoasnotedinTable2,combinational feedback logiccanbeproblematic fordesigns.FullStaticTimingAnalysis(STA)cannotbeperformedonacombinationalfeedback loopandsuchfeedbackloopshavelatch‐behaviorwithoutcheckingthesetupandholdtimesofthelatchingcontrolsignalsinherently associated with such logic. For those reasons, I propose that currently definedalways_typeblocksbeprohibitedfromlegallybuildinglogicwithcombinationalfeedbackloops.Ifsuchlogicisdesired,engineersshouldbeforcedtouseolderVerilogalwaysprocessessothattheyareawareofthepotentialdangersofthesetypesofdesigns.SeeSection10foraproposedsolutiontothisissue.

Theproblemwiththeproposederrorcheckingisthat,asnotedabove,synthesistoolshaveallowedengineers to get by with warnings on existing designs. Synthesis tool vendors might find itacceptabletoprovidea-warn_onlyor-relax_fatalswitch(theexactnameisnotimportant)toallow engineers to use the toolswithout errors if they choose to ignore important design intentviolations.

Asanalternative,synthesistoolscouldissue"violations,"whichcouldbeputunderusercontroltoeitherconvertviolationsintoerrorsorintothecurrentsetofwarningsasselectedbytheuser.

Thepointis,synthesistoolsarecurrentlyissuingwarningswhenerrorsareincorrectlycodedintoRTL designs. Warnings are almost useless. Errors/violations will help engineers to build betterdesigns!

10. Proposed:always_comb_fbOneobservationthatImadewhilecompilingthe listof importantsynthesistoolerrorsshowninTable2,isthatIbelieveRTLdesignersactuallyneedanotheralways_typeprocess.

RTLmodelsshouldbe re‐targetable todifferentdevices toallow for reuse in futureprojectsandtechnologies, and therefore the RTL code cannot know if the target implementation will havelatchesavailable

Althoughalways_comb,always_latchandalways_ffcover95%+ofRTLcodingstyles,thereisstillonemorestylethat,althoughrarelyused,mightbeuseful tosomedesigners. Thatstyle isa

SNUG2016

Page26

Rev1.0


combinationalfeedbackloopthatactslikealatch.

Although latches are frequently discouraged inRTLdesigns bymost companies, there are timeswhenlatch‐basedlogicisuseful.TherearemanyFPGAfamiliesthatdonotincludeusablelatchesandforthoseFPGAdevices,alatchmustbemodeledascombinationallogicwithafeedback‐looptohold the desired latched values. I propose that one new always_type process be added toSystemVerilog:always_comb_fb(combinationallogicwithintentionalfeedback).

RTLsimulationsfrequentlydonothaveenoughcontexttoknowifa latchwillbeavailableintheimplementationlogic.ASICscouldallowlatcheswhileequivalentprototypeFPGAdevicesmightnothave access to dedicated latches. Since this is a real possibility, simulators should just treatalways_comb_fbthesameasalways_comb.Forsimulators,always_combandalways_comb_fbwouldbesynonyms.

Forsynthesistools,therearemultiplescenariosthatshouldbeaddressed:

(1)Ifalatchisinferredfromanalways_combprocess,thesynthesistoolshouldreportoneoftwoerrors, with messages similar to, "always_comb inferred a latch" or "always_comb inferredcombinationallogicwithafeedbackloop."

(2)Ifnolatchisinferredfromanalways_latchprocess,thesynthesistoolshouldreportoneoftwo errors, with messages similar to, "always_latch used but no latch inferred" or"always_latchinferredcombinationallogicwithafeedbackloop."

(3) If a latch is inferred from an always_comb_fb process, the synthesis tool should report anerror,withamessagesimilarto,"always_comb_fbinferredalatch."

(4)Ifnon‐latchandnon‐feedbacklogicisinferredfromanalways_comb_fbprocess,thesynthesistoolshouldreportanerror,withamessagesimilar to, "always_comb_fb inferredcombinationallogicbutnocombinationalfeedbacklogicasrequested."

Ihavealsoconsideredacodingstylethatinfersbothlatchesandflip‐flopsfromthesameprocess,butIconsiderthattobesomewhatquestionablesinceanRTLcodercouldeasilyseparatelatchesfromtheflip‐flopsbyseparatelycodingthealways_latchandalways_ffprocesses.

11. ConclusionsFollow the 8 RTL coding guidelines shown in Section 3. These guidelines, originally shown forVerilogRTLdesignsstillapplytoSystemVerilogRTLdesigns.

Guideline:QuitusingtasksinRTLdesign.Replacealltaskswithvoidfunctions.

Guideline:Quitusingthealways@*processforRTLcombinationalandlatchinglogic.Thealways@*doesnotdodeep‐searchingintocalledfunctionstobuildthecompleteprocesssensitivitylist.

Guideline: Quit using all always processes for RTL designs and instead use the always_typeprocessesexclusively.

ThenewSystemVerilogalways_typelogicprocessesarefarsuperiortoexistingalwaysprocesses.Thealways_type processes domore checking during simulation compilation for potential errorconditionsandtheycurrentlyallowsynthesistoolstoat leastwarnengineerswhentheintendedlogicisnotsynthesized.

Synthesistoolwarningsrelatedtoalways_typeprocessesarenotnearlyasusefulaserrorsthatwouldcausethesynthesistooltostopbeforecompilingadesign.Warningsaretooeasilymissed.

SNUG2016

Page27

Rev1.0


Synthesistoolvendorsshouldissueerrorswhenthedesigner'sintendedandrequestedlogicisnotinferredasdescribedinTable2.Designershaveareadilyavailablefallbackpositioniftheywanttoavoidtheerrors,andthatfallbackpositionistousethesimpleVerilogalwaysprocess.Synthesistool vendors could help accelerate correct RTL synthesis by allowing the current always_typewarningstobeconvertedintoerrors.

Calltoaction!AskyoursynthesistoolvendortopleasegiveusawaytogenerateerrorsinsteadofwarningswhentheRTLdesignsarereadintothesynthesistool.Askthesynthesistoolvendortodisallowcompilationof the incorrectdesignsuntil theerrorshavebeenaddressedby thedesignengineer.

12. AcknowledgementsIamgrateful tomycolleaguesStuartSutherlandandBrianKane for theirreviewsandsuggestedimprovementstothispaper.

13. References[1] Clifford E. Cummings, '"full_case parallel_case", the Evil Twins of Verilog Synthesis,' SNUG'99 Boston

(SynopsysUsers GroupBoston,MA, 1999) Proceedings, 1999. Also available online atwww.sunburst‐design.com/papers

[2] Clifford E. Cummings, "Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!," SNUG(Synopsys Users Group) 2000 User Papers, section‐MC1 (1st paper), March 2000. Also available atwww.sunburst‐design.com/papers

[3] Clifford E. Cummings, “SystemVerilog Implicit Port Enhancements Accelerate System Design &Verification,” SNUG (Synopsys Users Group) September 2007 (Boston, MA), September 2007. Alsoavailableatwww.sunburst‐design.com/papers

[4] DonMillsandCliffordE.Cummings,“RTLCodingStylesThatYieldSimulationandSynthesisMismatches,”SNUG(SynopsysUsersGroup)1999Proceedings,section‐TA2(2ndpaper),March1999.Alsoavailableatwww.lcdm‐eng.com/papers.htmandwww.sunburst‐design.com/papers

[5] IEEE Standard Verilog Hardware Description Language, IEEE Computer Society, IEEE, New York, NY,IEEEStd1364‐2001.

[6] IEEEStandardforVerilogRegisterTransferLevelSynthesis,IEEEComputerSociety,IEEE,NewYork,NY,IEEEStd1364.1‐2002

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

14. Author&ContactInformation

CliffCummings,PresidentofSunburstDesign,Inc.,isanindependentEDAconsultantandtrainerwith34yearsofASIC,FPGAandsystemdesignexperienceand24yearsofSystemVerilog,synthesisandmethodologytrainingexperience.

Mr Cummings has presentedmore than 100 SystemVerilog seminars and training classes in thepast13yearsandwasthefeaturedspeakerattheworld‐wideSystemVerilogNOW!seminars.

MrCummingshasparticipatedoneveryIEEE&AccelleraSystemVerilog,SystemVerilogSynthesis,

SNUG2016

Page28

Rev1.0


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

Page29

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

DesignCompilerversionK‐2015.06‐SP4

Thedesignflow‐FindingandfixingbugsAppendix2Theearlierabugisidentifiedandfixed,thefasterahighqualitydesignwillbereleasedtomarket.Thesubsectionsinthisappendixgivesomewhatdetaileddescriptionsofhowandwherebugscanbeidentifiedandfixed.

CodingAppendix2.1

IfabugcanbespottedwhiletheRTLisbeingentered,thebugcanbequicklyfixedbeforeanytoolisusedtoidentifybugs.Acolorizingandindentingeditorwillhelptheskilledcodertoidentifybugsbeforethedesignisevencompiledbyanytool.

SystemVerilog does not necessarily add any new features that a colorizing editor would use toidentifybugsthatwerenotalreadyfoundusingacolorizingeditorwithVerilog.

LintingAppendix2.2

Lintingtoolsexaminecodetoidentifysuspectdeclarations,assignmentsand/orcodingstyles.Ifacompanyhasaccess toa linting tool, thedesignshouldbe "linted" (compiledby the linting tool)beforeitiscompiledforsimulation.

Notalldesignershaveaccesstolintingtools.Designersthatdohaveaccesstolintingtoolsoftencanidentify problems that otherwise would not be found until a design is compiled for simulation,simulated,compiledforsynthesisorsynthesized.Itshouldbenotedthatasynthesistoolisaveryexpensivelintingtoolthatonlyreportsafewerrorsatatimewhilecommerciallintingtoolshavebeenoptimizedtofindandreportasmanyerrorsasispossiblewithjustafewpassesthroughthetoolandbeforeusinganyothertool.

ThesameSystemVerilogfeaturesthatenablesimulatorsandsynthesistoolstoidentifybugsearlywillalsohelplintingtoolstobecomemorevaluable.

Iamfrequentlyaskedifthereareanypublicdomainlintingtools.Asofthiswriting,Iknowofnofreely available, public domain linting tools. If I become aware of any publically available lintingtools,Iwillreportthatinformationinanupdatedversionofthispaperonthesunburst‐design.comwebpage.PleasedonotemailtoaskifIknowofanyupdates!FeelfreetoemailmeifYOUknowofanyupdates!

CompilingforsimulationAppendix2.3

Compilation typically refers to both: (a) syntax checking during a compilation phase, and (b)

SNUG2016

Page30

Rev1.0


connectivityandparameterresolutionduringanelaborationphase.Somesimulatorsdobothwhenyoucallthecompilationcommand,whileothersimulatorsdopart(a)duringcompilationandpart(b)whenaseparatesimulationcommandiscalled.

Finding bugs during compilation saves lengthy and wasted simulations. Every designer whoexecutes a simulation command automatically calls a tool that performs these syntax andconnectivitychecks,andthedesignerisrequiredtofixproblemsbeforesimulationwillstart.

SystemVerilog enhancements add value to the compilation and elaboration steps, helping toidentifyadditionalproblemsthatpreviouslywentundetectedduringVerilogcompilation.Examplesofthishavebeenshowninthispaper.ThebottomlineisthatSystemVeriloghelpscatchmorebugsearlierinthedesigncompilationstage.

SimulationAppendix2.4

Functional simulation (pre‐synthesis simulation) is used to prove that the logic, as coded, willfunctionproperlyinanactualdesign,assumingthattherearenocodingissuesthatwouldcauseamismatchbetweenpre‐synthesisandpost‐synthesissimulations.

Simulationrequiresthedesignandverificationteamstoputtogetheranelaboratesetoftestcasesto apply useful stimulus to the design. It should be noted that simulation is not inherentlyexhaustive,andisonlyasthoroughaswhataverificationengineeringteamcodedforthetestbenchstimulusandoutputchecking.

Simulationshouldbeusedtoprovethedesignfunctionalityiscorrectbeforelaunchingasynthesistool.Ifthedesignisnotproventobefunctionallycorrectbeforesynthesis,thensynthesisrunsarelargelyawasteofprojecttime.

Simulation‐codecoverageAppendix2.5

Whena full setof tests is runagainst thedesign,codecoveragecanbeenabled throughvendor‐specificcommandlineswitches.Codecoveragedoesnotrequireanyspecialeffortonthepartoftheverification engineer, aside from enabling the switches and the time spent to analyze the codecoverageresults,whichcanbesignificant.

Atthesametime,codecoveragedoesnotanswerthequestionregardingcompletenessofdesignorcompletenessof test generation.Theonlyquestion answeredby code coverage is if there is anycodethathasnotbeentouchedbyanyofthetestsandhence,ifthereisanycodethathasnotbeentested.Untouchedcodecouldstillhavefunctionalbugs.Codecoverageisusedtoensurethatallthecodehasbeentouched.

Simulation‐functionalcoverageAppendix2.6

While code coveragewas a semi‐automaticprocess to ensure that all codehadbeen touchedbytests,functionalcoverageisnotautomaticandrequiresatestplan.Functionalcoverageisusedtoensurethatallofthespecifieddesignfeatureshavebeenexercised.Functionalcoveragedoesnotensurethatthefeaturesworkproperly. It isacombinationofsimulationandfunctionalcoveragereports (ideally with 100% functional coverage) that indicates that the design is functionallycorrectandreadytobedeliveredtocustomers.Inaperfectscenario,functionalcoverageindicatesthatideally100%ofthespecifiedfeatureshavebeentestedandifthefunctionalsimulationpasses,thosefeaturesareworking.

SystemVerilog adds features to significantly improve functional coverage capabilities, but thosefeaturesarenotdescribedinthispaper.

SNUG2016

Page31

Rev1.0


SynthesiscompilationAppendix2.7

SynthesiscompilationisbasicallythesynthesislintingsteptoidentifyillegalRTLcodingstylespertheRTLcodingpoliciesofthesynthesistool,followedbyinferenceoflogicfromtheRTLequationsand mapping the design into target‐specific gates. The logic inference is also influenced by theavailabilityofcommongatesinspecificvendorlibraries.Forexample,mostASICfamiliescaninferlatcheswhilemanyFPGAfamiliesdonothavelatches.

SystemVerilog could potentially add significant value to identify problems during synthesiscompilation, helping to identify additional problems that previously went undetected duringVerilogsynthesis.Exampleshavebeenshowninthispaper.SystemVeriloghelpscatchmorebugsearlierinthedesignstage.

It should also be noted that SystemVerilog synthesis tools should do a better job of identifyingproblems than is currently true.How SystemVerilog synthesis tools can improvewere shown inSection9.

Wherepossible,synthesistoolsshouldreporterrorsasopposedtoreportingwarnings.Warningsareeasilymissedand indeedare frequentlymissed.Validerrorreporting ismuchmorevaluablethanreportingwarningsasthelattercanoftenleadtowastedsynthesisruns.

Post‐synthesissimulation/EquivalencycheckingAppendix2.8

Afterthedesignissynthesizedandagate‐levelnetlistisavailable,adesignershouldperformpost‐synthesissimulationsorequivalencycheckingbeforetape‐outofadesign.

Ifanengineerdoesnothaveaccesstoequivalencycheckingtools,theengineermustrungate‐levelsimulations (gate‐sims) to prove that the post‐synthesis gate‐level design matches the pre‐synthesisRTLrepresentationofthedesign.

A frequently asked question regarding gate‐sims is, if the design passed RTL simulations andpassedsynthesis,whydoIhavetorungate‐sims?Therearemanywelldocumentedcodingstylesand coding practices that can lead to amis‐match between pre‐synthesis simulations and post‐synthesissimulations[1][4].Thesemismatchesareindicationsoffunctionalbugs.

If a designerhas access to equivalency checking tools, these tools canbeused to reduce lengthygate‐levelsimulations.Equivalencycheckingtoolsattempttomathematicallyprovethatthepost‐synthesisgate‐levelrepresentationofthedesignmatchesthepre‐synthesisRTLrepresentationofthedesign. If itcanbeprovenmathematicallythatthegate‐levelrepresentationmatchestheRTLrepresentation, and if the RTL simulations proved that the designed worked and was fullyfunctional,thenthereisreducedneedtorungate‐sims.

Gate‐levelsimulationscanhelpchecktimingconstraintsortimingexceptionsandcantestlogicthatdoesnotexistinRTLsimulationssuchasDFTlogic.

SystemVerilogdoesnotnecessarilyaddanynewfeatures thatgate‐simsorequivalencecheckingtoolswouldusetoidentifybugsthatwerenotalreadyfoundusingVerilogversionsofthesetools.

SilicontestingAppendix2.9

PlacingthecompletedASICorFPGAintoadesignforsystemtestingisthesecond‐to‐lastplaceanengineerwantstofindabug.ForASICsandFPGAs,findingabugthislateinthedevelopmentcyclewillrequireengineeringteamstoidentifydeficienciesinthefunctionalcoveragemodel,followedbythedeficiencyinthesimulationtests,followedbythedeficiencyintheRTLcodeitself.

Replacing a failingASIC that cannotbe fixedby softwarepatches canbe a very costly and time‐

SNUG2016

Page32

Rev1.0


consuming process. Replacing the FPGA is less painful but still requires all of the sameASIC re‐testingstepsfollowedbysuccessfulsynthesis,placementandroutingoftheFPGAdesign.

OneofthegoalsofSystemVerilogistoidentifymoreoftheseissuesearlytohelpavoidthesecostlyproblems.

Silicontestingisusedtofindanyfinalbugsbeforedeliveringthechiptothecustomer.

CustomertestingAppendix2.10

Findingthebugoncethedesignisinthehandsofcustomersisthelastplaceanengineerwantstofind a bug. Fixing bugs found by a customer can require a costly recall of the product, or goingbankrupt!

OneofthegoalsofSystemVerilogistokeepyourcompanyfromgoingbankrupt!

clifford e. cummings sunburst design, inc. … 2016 page 4 rev 1.0 systemverilog logic specific...

Documents