The Role of Assertions in Verification Methodologies

8/11/2019 The Role of Assertions in Verification Methodologies

1/22

The Role of Assertions in Verification MethodologiesPlatform ......................................................................................................... 11 Assertions Overview............................................................................................................................. 12 Introduction........................................................................................................................................... 13 enefits of !sing Assertions ................................................................................................................ 1

" Overview of P#$%#ugar ........................................................................................................................ 2& Practical '(am)le * AMA A+ Interface Assertions..........................................................................,, Assertion !se Model in the Incisive verification Platform...................................................................1- #ummar/ ............................................................................................................................................ 1"0 References ......................................................................................................................................... 1"A'' II#IV' V'RI4IATIO P$AT4ORMVerif/ing toda/5s com)le( Is re6uires the s)eed and efficienc/ that can onl/ 7e )rovided in a unifiedverificationmethodolog/. The adence Incisive verification )latform ena7les the develo)ment of a unifiedmethodolog/ from s/stemdesign to s/stem design*in for all design domains. A unified verification methodolog/ consists of man/different tools8technologies and )rocesses all wor9ing together in a common environment. The Incisive )latform)rovides the tools8technologies8 a common user environment and the su))ort needed to develo) a unified methodolog/.This a))lication notedetails s)ecific to)ics for using the tools and technologies in the Incisive )latform to hel) create aunified methodolog/ toverif/ /our design.1A##'RTIO# OV'RVI':Assertions )la/ an im)ortant role in a unified verification methodolog/. Assertions allow the architector designer to ca)turehis or her design intent and assum)tions in a manner that can 7e verified in the im)lementation.Assertions are ca)turedduring the develo)ment )rocess and are continuall/ verified throughout the )rocess. Assertions8wor9ing in a unifiedverification methodolog/8 reduce the verification time 7/ detecting 7ugs earlier8 isolating where a 7ugis located8 anddetecting )rotocol violations that ma/ not cause functional errors to )ro)agate to the out)uts. Inaddition to 7ug detection8assertions im)rove the efficienc/ in a unified methodolog/ 7/ im)roving reuse8 enhancing test7enchchec9ing8 and ca)turingcoverage information.2ITRO!TIOAssertions e()ress functional design intent in terms of 7ehavior. Assertions can 7e used to e()ressassumed in)ut 7ehavior8e()ected out)ut 7ehavior8 or for7idden 7ehavior. 4or e(am)le8 if a )rocessor has a read signal and awrite interface signal8a designer might assume that ;the read signal and the write signal should never 7e 7oth active at the


2/22

same time.< :ithassertion*7ased verification =AV> in a simulation environment8 if during a )articular simulation run8there was ever a c/clewhen 7oth the read and the write signals were active8Interface#tructural

A))licationthen the assertion would fire and re)ort a message.AssertionsAssertionsAssertionThis is an e(am)le of an interface assertion. Interfaceassertions are used to chec9 the )rotocol of interfaces7etween 7loc9s. Other t/)es of assertions includearchitectural assertions and structural assertions8 asshown in 4igure 1. A))lication assertions are used toAr7iter)rove architectural )ro)erties such as fairness anddeadloc9s. 4or e(am)le8 ;after a re6uest for transfer8PIeventuall/ an ac9nowledge is granted.< #tructuralusassertions are used to verif/ low*level internal4I4O4#Mstructures within an im)lementation8 such as a 4I4OProcessoroverflow or incorrect 4#M transitions. 4or e(am)le8 ;ifA+the read and write )ointers of a 4I4O are the same8usthen the state of the 4#M remains 4I4O?Overflow untildata is read.that is su))orted in theadence Incisive verification Platform. The 7enefits of using assertions are discussed8 and a s)ecifice(am)le of interfaceassertions for the AMA A+ )rocessor t/)e interface is )resented. The use models of adence5sim)lementation ofAssertion*ased Verification are also discussed8 including how /ou run a simulation with assertions8de7ug them8 and turnthem on and off.3''4IT# O4 !#I@ A##'RTIO#Assertions are created in the unified verification methodolog/ whenever design or architectureinformation is ca)tured.These assertions are then used throughout the verification )rocess to efficientl/ verif/ the design. The


3/22

use of assertionsim)roves the s)eed and efficienc/ of verification 7/ 7ug catching and 7/ enhanced test7ench chec9ing.Assertions alsofacilitate re*use and )rovide data that is useful in evaluating functional coverage.3.1!@ AT+I@

The )rimar/ focus of adence5s im)lementation of assertion*7ased verification is to identif/ 7ugs asclose to the source as)ossi7le. This reduces the de7ug time8 es)eciall/ after full chi) integration of 7loc9s when 7ugs ta9elonger to )ro)agate tothe out)ut and are more difficult to isolate. Assertion chec9ing during simulation can identif/ internalerrors within the module1P$AT4ORM APP$IATIO OT'sooner and closer to the source than is )ossi7le without assertions. :ithout assertions8 errors must)ro)agate to the out)uts7efore 7eing detected. Assertions reduce the time it ta9es to locate difficult 7ugs 7/ identif/ing wherein a design the 7ugfirst a))ears. Assertions also catch 7ugs that do not )ro)agate to the out)ut. :hen an assertion fires8 it)rovides animmediate localiation of the failure8 which sim)lifies the insertion of intellectual )ro)ert/ =IP> intodesign environments.3.2'+AI@ T'#T'+ +'BI@Assertions hel) to su))lement test7ench chec9ing. Often test7ench chec9ers re6uire added com)le(it/to verif/ the correcto)eration of internal device under verification =!V> 7ehavior8 such as verif/ing that an ar7iter8 7urieddee) in the design8 isservicing re6uests in a fair manner. Assertions reduce the necessit/ for com)le(it/ in the chec9er asthe/ can verif/ internalo)erations close to the source in a sim)le manner. / )lacing assertions throughout the design /ou areenhancing theoverall chec9ing a7ilit/ of the test7ench.3.3R'*!#'Time to mar9et )ressures8 and the high cost and ris9 of new develo)ments continues to increase theim)ortance of re*use87oth for design and verification IP. A 9e/ o7Cection that designers have in ado)ting re*usemethodologies is that it is difficultto understand and integrate someone else5s code8 es)eciall/ when the develo)er is no longer availa7lefor consultation.Also8 there is a general lac9 of confidence in how )roven the code is and how accurate thedocumentation is.Assertions hel) to instill confidence that the design is well documented and functions as s)ecified.'m7edded assertions)rovide a standard format of documented 7ehavior that is chec9ed 7/ simulation vectors. 'm7eddedassertions travel withthe design8 ma9ing the design easier to integrate. Assertions can flag when the assum)tions of theoriginal designer are not


4/22

true8 or when assumed interface )rotocol is violated. The error is caught at or near the source.P#$%#ugar hel)s in )roviding good code documentation 7ecause it eas/ to e()ress8 and thereforeinter)ret8 7oth assumedand e()ected 7ehavior. 'ach 7ehavior is verified with the simulation vectors8 so in a sense8 thedocumentation 7ecomes astandardied format that is )roven and continuall/ tested 7/ simulation vectors.

3."OV'RA@':ith adence5s im)lementation of AV8 assertion statistics re)resent coverage information. Thiscoverage information can7e hel)ful in identif/ing 7oundar/ conditions8 corner cases8 or se6uences that have not 7een tested."OV'RVI': O4 P#$%#!@ARThe Verilog and V+$ simulators of the Incisive verification )latform su))ort the use of assertionswith native simulationsu))ort for the P#$%#ugar assertion language. This section )rovides an overview of the featurescommonl/ used. Refer tothe #imulation*ased Assertion hec9ing @uide for com)lete details of which features the simulatorsin the Incisiveverification )latform su))ort.P#$%#ugar ma9es it eas/ to e()ress ver/ com)le( 7ehavior. P#$%#ugar is 7ased on ooleane()ressions8 and definesdialects that are s)ecific to hardware languages. P#$%#ugar ma9es it straightforward to e()ress thefollowing 7ehaviorD1. A 7ehavior ma/ alwa/s or never hold true2. A 7ehavior ma/ alwa/s or never hold true onl/ within some window3. A 7ehavior ma/ e()ress some s)ecific se6uence of events =including overla))ing se6uences>". A 7ehavior ma/ e()ress an eventualit/&. An/ 7ehavior ma/ have e(ce)tions to the rule,. An/ 7ehavior ma/ onl/ hold true for s)ecific configurationsThe Verilog and V+$ simulators in the Incisive verification )latform )rovide native su))ort ofP#$%#ugar language. ativesu))ort is ver/ im)ortant for o)timal )erformance.".1OO$'A#P#$%#ugar is designed to 7e used in conCunction with hardware descri)tion languages =+$> such asVerilog or V+$. Atthe 7ottom level8 the P#$%#ugar language is used to s)ecif/ the conditions that define a 7ehavior ofinterest8 referring tosignals8 varia7les8 and values within an +$ descri)tion of a design. Those conditions are re)resented7/ +$ e()ressionsthat can 7e inter)reted as having oolean values. !sing the underl/ing +$ s/nta( and semantics forsuch e()ressionsensures that the assertion language can cover the full range of 7ehavior that can 7e descri7ed in the+$8 and that there isno chance of semantic mismatch 7etween the +$ descri)tion of a 7ehavior and the P#$%#ugardescri)tion of the same7ehavior. This also reduces the learning curve for 7eing a7le to e()ress a 7ehavior. adence5sim)lementation of AV


5/22

su))orts two dialects of P#$%#ugar. oolean e()ressions ta9e on the s/nta( of the language of thecom)iler. Verilogsu))orts the Verilog dialect and V+$ su))orts the V+$ dialect.2P$AT4ORM APP$IATIO OT'".2

$OBI@ A 'VA$!ATIOP#$%#ugar assertions are declarative in nature. This means that ever/ assertion is evaluated on ever/verification c/cle8 andall assertions are evaluated concurrentl/. Activation of assertions is not de)endent on the +$ code. Inother words8activation of assertions are not affected 7/ )lacement in a conditional statement8 li9e a case statementor an if statement.As/nchronous or s/nchronous 7ehavior can 7e e()ressed. Eou can also define a default cloc9 thata))lies if no e()licitsam)ling cloc9 is attached to an e()ression. The cloc9 can 7e defined as an/ other oolean e()ression8and can ma9e useof edge functions.".3#'F!'' 'GPR'##IO##e6uences can e()ress a sim)le oolean e()ression or a multi*c/cle 7ehavior of oolean e()ressions8where each c/cle ofa se6uence is se)arated 7/ a ;H


6/22

NLse6uence?e()ression is not valid>.Re)etition s)ecifiers can 7e used for an/ e()ression of a c/cle. inf can 7e used to e()ress infinit/.4ormats e(ist foreach +$ dialect. The more commonl/ used o)eraters are shown 7elowDVerilog ialectQ

Q nQ n Dinf Q D mQ n D m QV+$ ialect QQ nQ n to inf Q to m Q n to m QefinitionIndicates that the e()ression ma/ occur ero or more consecutive times.Indicates that the e()ression ma/ occur one or more consecutive times.Indicates that the e()ression should occur e(actl/ n consecutive times.Indicates that the e()ression should occur a minimum of n consecutive times.Indicates that the e()ression ma/ occur a ma(imum of m consecutive times.Indicates that the e()ression ma/ occur n or m consecutive times.PROP'RTI'#A )ro)ert/ defines a 7ehavior to 7e chec9ed. A )ro)ert/ can 7e thought of as containing an o)tionalena7ling condition8 afulfilling condition8 which is the 7ehavior to 7e chec9ed8 an o)tional discharging condition8 and ano)tional cloc9ing condition.The most general form of a )ro)ert/ and the definition of terms is shown 7elowDVerilogD)ro)ert/ nameJ K o)eratorQ ena7ling?condition=s>Qim)lication?o)erator=s>Q =fulfilling?condition>until S until? S a7ort discharging?conditionQ =cloc9?e()ression>QHV+$D)ro)ert/ nameJ is o)eratorQ ena7ling?condition=s>Qim)lication?o)erator=s>Q =fulfilling?condition>until S until? S a7ort discharging?conditionQ =cloc9?e()ression>QH3P$AT4ORM APP$IATIO OT'The following descri7es the 9e/ terms of a )ro)ert/ e()ressionD1.2.3.".&.)ro)ert/ is a declaration that what follows is a 7ehavior. The simulator8 7/ default8 will verif/ this7ehavior.


7/22

A )ro)ert/ nameJ is a uni6ue identifier. This should 7e a ver/ descri)tive name 7ecause the failuremessage re)ortsonl/ this name and the time of failure. +$ naming conventions a))l/. The name must 7e uni6ue tothe module orentit/ in which it is used.The o)erator is one of alwa/s or never and indicates whether the 7ehavior should alwa/s occur or

should never occur.ote that /ou ma/ choose to omit the alwa/s or never term8 in which case the chec9 occurs at time eroonl/.The ena7ling condition can 7e an/ oolean e()ression or se6uence e()ression. Multi)le ena7lingconditions andim)lication o)erators can 7e strung together to form a com)le( ena7le. The assertion is considered to7egin when thefirst se6uence of the ena7ling condition evaluates to true.The im)lication o)erator s)ecifies the logical relationshi) 7etween two e()ressions. The o)erator isone of thefollowing s/m7olsD*J *J ne(t 'valuation of the R+# is started in the last c/cle of the $+#. The $+# must 7e a se6uence when this is used.SKJ 'valuation of the R+# is started following the c/cle when the $+# condition 7ecomes true. The $+# must 7e a se6uence when this is used.eventuall/N.'valuation of the R+# is evaluated in the ne(t c/cle after the $+# 7ecomes true. The 7ehaviorcan 7e read as ;if =ena7ling condition> is true8 then the =fulfilling condition> must 7e true in thene(t verification c/cle


8/22

must remain true u) to and including the c/cle where the oolean e()ression istrue. It then finishes immediatel/. until? has no affect until the fulfilling conditionis 7eing chec9edA7ort cancels the chec9ing of an assertion. An a7ort that occurs during thechec9ing of the ena7ling condition or the fulfilling condition will cancel the chec9ing.This is different than the until or until? that re6uires that the fulfilling condition

is 7eing chec9ed.The cloc9 e()ression is the condition that is used to sam)le the assertion. This is generall/ a cloc9edge8 7ut can 7ean/ oolean e()ression. A default cloc9 can 7e s)ecified8 eliminating the need to s)ecif/ it for ever/assertion.#ome e(am)les are as followsDAssuming read and write are interface signals8 the following is an e(am)le of an interface assertionDVerilogDV+$D)ro)ert/ everRd:rothActive K never ==read KK 1> UU =write KK 1>>H)ro)ert/ everRd:rothActive is never ==read K 1> and =write K 1>>H"P$AT4ORM APP$IATIO OT'An a))lication assertion might 7e that ever/ re6uest is eventuall/ granted unless a reset occursDVerilogDV+$D)ro)ert/ 'ver/Re6uestIs'ventuall/@ranted K alwa/s =Re6 *J eventuall/N =@ranted KK 1>> a7ort =reset KK 1>=)osedge cl9>)ro)ert/ 'ver/Re6uestIs'ventuall/@ranted is alwa/s =Re6 *J eventuall/N =@ranted K 1>> a7ort =reset K 1> =cl95event and cl9 K 15>A structural assertion might 7e that if the memor/ tas9 is clear =m?tas9 K 257-->8 it must alwa/s 7efollowed 7/ a three*c/cle se6uence that must 7e re)eated 2&, times. The se6uence is write?n low for one sam)le followed7/ a write high fortwo sam)les. The write signal is s/nchronous to the )ositive edge of cl9. Reset is high and will cancelthe write.VerilogDse6uence :RIT'?P!$#' K L=write?n KK ->H=write?n KK 1>H=write?n KK 1>H)ro)ert/ $'AR?M'M?:RIT'? K alwa/sLm?tas9 KK 257-- SKJ L:RIT'?P!$#'2&,Qa7ort =reset KK 1> =)osedge cl9>8V+$Dse6uence :RIT'?P!$#' is L=write?n K ->H=write?n K 1>H=write?n K 1>H)ro)ert/ $'AR?M'M?:RIT'? is alwa/sLm?tas9 K 5--5 SKJ L:RIT'?P!$#'2&,Qa7ort =reset K 1> =cl95event and cl9 K 15>H"."IR'TIV'#A se6uence or a )ro)ert/ 7/ itself Cust descri7es 7ehavior8 there is no inherent o7ligation for the7ehavior to occur.irectives s)ecif/ whether a given )ro)ert/ is e()ected to hold =assert> or assumed to hold =assume>. Inaddition8 a coverdirective s)ecifies the desire to ensure that a se6uence is encountered during verification. Pro)erties are


9/22

alwa/s asserted orassumed. 4or assertions used in simulation8 assert and assume have the same meaning. =#taticverification will )rove)ro)erties that are asserted8 and will use assumed )ro)erties to limit the state s)ace of the search. >#e6uences can 7eused in )ro)erties or the/ can 7e used e()licitl/ for coverage. The format is as follows for 7oth Verilog

and V+$Dassume S assert )ro)ert/?nameJHcover se6uence?nameJHDIn adence5s im)lementation of simulation*7ased assertion verification8 all )ro)erties are treated as ifthe/ are asserted.That is to sa/8 the assert or assume directives are o)tional.".&'4II@ A##'RTIO#adence5s im)lementation of AV su))orts defining assertions em7edded in the same module orentit/%architecture as the+$ with which it is associated8 or in a se)arate file. 'm7edded assertions are in comments and areidentified using thes)ecial )ragma identifier sugar. 4or e(am)le8 the following is an em7edded assertion that e()ressesthat the read andwrite signals are never 7oth active8 assuming the active state is highDVerilogD %% sugar )ro)ert/ everRd:rothActive K never ==read KK 1> UU =write KK 1>>V+$D** sugar )ro)ert/ everRd:rothActive is never ==read K 1> and =write K 1>>ecause the assertions can 7e s)ecified as comments8 the/ will 7e ignored 7/ tools that do not su))ortP#$%#ugar.Assertions ma/ also e(ist in an e(ternal file that references signals8 varia7les8 and values within an+$ descri)tion of adesign. !sing assertions from an e(ternal file is descri7ed in the #imulation*ased Assertion hec9ing@uide in adencedocumentation.#tructural assertions that are used to verif/ low level internal structures within an im)lementation willli9el/ 7e inline with the+$ code. This is the recommended a))roach when the assertion is s)ecific to a design8 7ecause theassertion isguaranteed to travel with the design.A))lication assertions that are used to )rove architectural )ro)erties ma/ 7e em7edded in the design+$8 or the/ ma/ 7ein an e(ternal file that references the design +$. The )rimar/ reason for defining assertions in ane(ternal file is to e()ress7ehavior that references signals from multi)le modules or entities. Another use for assertions in ane(ternal file is whenassertions are added to legac/ IP8 where the IP cannot 7e modified.Interface assertions that chec9 the )rotocol of interfaces 7etween 7loc9s8 are li9el/ to 7e in a se)aratefile8 7ut that file is astandalone module or entit/. The interface assertions are self*contained in the module%entit/ thatcontains +$ code8 sothe/ have the same effect as em7edded assertions. The +$ code is minimal 7ut can 7e used8 fore(am)le8 to calculate


10/22

e()ected values that are then used in the assertions. Placing the assertions in a se)arate file allows theinterface assertionsto 7e instantiated in an/ 7loc9 that ma9es use of that interface =for 7loc9 level verification> or on theinterface itself when the7loc9s are integrated. efining a se)arate module or entit/ that is instantiated also allows the signalnames to 7e ma))ed

when the interface assertions are instantiated8 ma9ing it easier to use. The AMA A+ Interfaceassertions discussed in thene(t section )rovide an e(am)le.&P$AT4ORM APP$IATIO OT'&PRATIA$ 'GAMP$' * AMA A+ IT'R4A' A##'RTIO#The AMA A+P interface is a t/)ical )rocessor interface. This section details how to write P#$%#ugarcom)liance assertionsusing the Verilog dialect for an A+ interface. 'ach 7ehavior is descri7ed and the P#$%#ugarre)resentation is shown. Thene(t section will show how to simulate with these assertions. The detailed A+ s)ecification can 7efound atwww.arm.com%armtech%AMA?#)ecWO)enocument.#ignaling interface monitors will 7e +$ 7ased assertions that use the P#$%#ugar language. Thischoice 9ee)s the cloc9level anal/sis in the native language of the simulator so it does not re6uire having to traverse a lower)erformance interface.Eou ma/ not want to chec9 that the contents of what was written were written correctl/8 /ou ma/ Custwant to chec9 that the)rotocol s)ecified for the transfer was adhered to. +igher la/er )rotocols are 7etter chec9ed usinghigher level languagesli9e #/stem 7ecause of its e(tended ca)a7ilities8 such as 6ueuing8 and other features for trac9inge()ected results.The A+ assertions will 7e em7edded in an interface assertion monitor that can 7e instantiated in thedesign. This allowsthe assertion monitor to 7e instantiated within an/ A+ interface device8 or once on an/ A+ 7usinterface. The P#$%#ugarcode is shown 7elow. The to) of the file sim)l/ declares all the signals. It also defines )arameters usedto im)rovereada7ilit/. #ome +$ code is re6uired to create varia7les used in the assertions. The assertions arethen defined. 4or eachassertion8 the 7ehavior is descri7ed and then defined in P#$%#ugar. ote that all )ro)erties are asserted7/ default in thesimulators of the Incisive verification )latform8 so the assume directive is not used.% A+ Interface P#$ #ugar Assertions %Xtimescale 1 ns % 1-- )smodule ah7om)liance =ah7Addr?i8 ah7Trans?i8 ah7:rite?i8 ah7#ie?i8ah7urst?i8 ah7Prot?i8 ah7:ata?i8 ah7Rata?i8 ah7Read/?i8 ah7Res)?i8ah7Re6?i8 ah7$oc9?i8 ah7@nt?i8 ah7Resetn?i8 ah7#el?i8 ah7Master?i8ah7Mast$oc9?i8 ah7#)lit?i8 ah7l9?i>H)arameter dataus:idth)arameter num#laves


11/22

)arameter 7usMasterK 32HK 32HK -H% these )arameters define the Transfer T/)e as s)ecified 7/ +Trans %)arameter I$' K 2Y7--H

)arameter !#E K 2Y7-1H)arameter #'F K 2Y711H)arameter O#'F K 2Y71-H% these )arameters define the urst Mode as s)ecified 7/ +urst %)arameter #I@$' K 3Y7---H)arameter IRK 3Y7--1H)arameter :RAP" K 3Y7-1-H)arameter IR" K 3Y7-11H)arameter :RAP0 K 3Y71--H)arameter IR0 K 3Y71-1H)arameter :RAP1, K 3Y711-H)arameter IR1, K 3Y7111H% define the amount)arameter 7its0)arameter K)arameter 7its1,)arameter K)arameter 7its32)arameter K)arameter 7its,")arameter K 7its120 K 7its2&, K 7its&12 K 7its1-2" K% define the transfer res)onse signals as s)ecified 7/ +Res)%)arameter OBAE K 2Y7--H)arameter 'RROR K 2Y7-1H)arameter R'TRE K 2Y71-H)arameter #P$IT K 2Y711Hin)utin)utin)utin)utin)utin)utin)utin)utin)utof data in each 7eat as s)ecified 7/ +#ie%3Y7---H3Y7--1H


12/22

3Y7-1-H3Y7-11H3Y71--H3Y71-1H3Y711-H3Y7111H

31D-Q1D-Qah7Addr?i8 ah7:ata?i8 ah7Rata?iHah7Trans?i8 ah7Res)?iHah7:rite?i8 ah7Read/?i8 ah7Re6?iH2D-Qah7#ie?i8 ah7urst?iH3D-Qah7Prot?i8 ah7Master?iHah7$oc9?i8 ah7@nt?i8 ah7Mast$oc9?iHnum#laves*1D-Q ah7#el?iH1&D-Qah7#)lit?iHah7Resetn?i8 ah7l9?iH,P$AT4ORM APP$IATIO OT'reg 31D-Q )rev?ah7Addr8 )rev?ah7AddrPlus#ieHreg )rev?ah7:rite8 )rev?ah7Read/Hreg num#laves*1D-Q )rev?ah7#elHreg 3D-Q )rev?ah7ProtHreg 2D-Q )rev?ah7#ie8 )rev?ah7urstHreg dataus:idth*1D-Q )rev?ah7Rata8 )rev?ah7:ataHreg 1D-Q )rev?ah7Trans8 )rev?ah7Res)Hinteger AddrIncrementHinteger um7ereatsK-H%% s/no)s/s translate?off% ca)ture data that is needed in the following assertions %alwa/s =)osedge ah7l9?i or negedge ah7Resetn?i>7egin)rev?ah7Addr K ah7Addr?iH)rev?ah7Read/ K ah7Read/?iH)rev?ah7:rite K ah7:rite?iH)rev?ah7Rata K ah7Rata?iH)rev?ah7:ata K ah7:ata?iH)rev?ah7Trans K ah7Trans?iH)rev?ah7urst K ah7urst?iH)rev?ah7Res) K ah7Res)?iH)rev?ah7#elK ah7#el?iH)rev?ah7#ie K ah7#ie?iH)rev?ah7Prot K ah7Prot?iHcase =ah7#ie?i>% AddrIncrement is used to chec9 the address %


13/22

7its0DAddrIncrementK1H7its1,DAddrIncrementK2H7its32DAddrIncrementK"H

7its,"DAddrIncrementK0H7its120D AddrIncrementK1,H7its2&,D AddrIncrementK32H7its&12D AddrIncrementK,"H7its1-2"D AddrIncrementK120HdefaultD Hendcase% um7ereats is used to chec9 )ac9et lengths %if =ah7Trans?i KK I$'>um7ereats K -Helse if = ah7Trans?i KK O#'F>um7ereats K 1Helse if = =ah7Trans?i KK #'F> UU =ah7Read/?i KK 1> >um7ereats K um7ereats 1Helseum7ereats K um7ereatsH% determine the )redicted address %if ==ah7Trans?i NK !#E> UU =ah7Read/?i NK ->>)rev?ah7AddrPlus#ie K ah7Addr?i AddrIncrementHend% #!@AR A##'RTIO# %% define default cloc9 that will 7e used to sam)le all su7se6uent asserts %% OT'D it is im)ortant that data does not change on the same edge as cloc97ecause8 li9e +$8 assertions can 7e sensitive to races %%% sugar default cloc9 K =)osedge ah7l9?i>H% ehaviorD If reset is active then Transfer T/)e is I$' and Res) is OBAE=default cloc9> %%% sugar )ro)ert/ IdleAndO9a/uringReset K alwa/s%%L=ah7Resetn?i KK ->H=ah7Resetn?i KK 1> S*J%%L=ah7Trans?i KK I$'> UU =ah7Res)?i KK OBAE>H% ehaviorD If the transfer t/)e is O#'F and urst Mode is #I@$'8then on the ne(t cloc9 c/cle8 the transfer t/)e is not #'F and not !#E=default cloc9> %%% sugar )ro)ert/ us/And#e6ever4ollowonse6On#ingleTransfer K alwa/s =%%=ah7Trans?i KK O#'F> UU =ah7urst?i KK #I@$' > *J%%ne(t ==ah7Trans?i NK #'F> UU =ah7Trans?i NK !#E>> >H% ehaviorD If the transfer t/)e is !#E and slave is read/8then on the ne(t cloc9 c/cle8 the transfer t/)e must not 7e I$' and


14/22

must not 7e O#'F unless grant is - and read/ is 1 =default cloc9> %%% sugar )ro)ert/ ever@o4romus/ToIdleOronse6!nlesso@rant K alwa/s =%%==ah7Trans?i KK !#E> UU =ah7Read/?i KK 1>> *J%%ne(t ==ah7Trans?i NK I$'> UU =ah7Trans?i NK O#'F>>

%%a7ort ==ah7@nt?i KK -> UU =ah7Read/?i KK 1>> SS =ah7Resetn?i KK ->>H% ehaviorD if the transfer t/)e is I$'8c/cle8 the transfer t/)e must 7e either%% sugar )ro)ert/ Alwa/s@oToonse64romIdle%%=ah7Trans?i KK I$'> *J%%ne(t ==ah7Trans?i KK I$'> SSthen on the ne(t cloc9I$' or O#'F =default cloc9>%K alwa/s ==ah7Trans?i KK O#'F>> >HP$AT4ORM APP$IATIO OT'% ehaviorD if the transfer t/)e is !#E then on the corres)ondingdata transfer 8 the slave must )rovide a ero wait state OBAE res)onse=default cloc9> %%% sugar )ro)ert/ Res)onseTous/MusteZero:aitOBAE K alwa/s =%%==ah7Trans?i KK !#E> UU =ah7Read/?i KK 1>> *J%%ne(t ==ah7Res)?i KK OBAE> UU =ah7Read/?i KK 1>> >H% ehaviorD if the transfer t/)e is I$' then on the corres)onding datatransfer8 the slave must )rovide a ero wait state OBAE res)onse=default cloc9> %%% sugar )ro)ert/ Res)onseToIdleMusteZero:aitOBAE K alwa/s =%%==ah7Trans?i KK I$'> UU =ah7Read/?i KK 1>> *J%%ne(t ==ah7Res)?i KK OBAE> UU =ah7Read/?i KK 1>> >H% ehaviorD if the )revious res)onse was OBAE8 and the current res)onseis not OBAE8 then Read/ must 7e - during the second not OBAE res)onse=default cloc9> %%% sugar )ro)ert/ Read/MusteZerouring4irstotO9a/Res)onse K alwa/s%%L=ah7Res)?i KK OBAE>H=ah7Res)?i NK OBAE> S*J%%Lah7Read/?i KK - H% ehaviorD if the res)onse is #P$IT or R'TRE8 the master must drive I$'=default cloc9> %%% sugar )ro)ert/ 4irstotO9a/Res)onseausese(tIdle K alwa/s =%%


15/22

==ah7Res)?i KK #P$IT> SS =ah7Res)?i KK R'TRE>> UU =ah7Read/?i KK -> *J%%ne(t =ah7Trans?i KK I$'>>H% ehaviorD if the transfer t/)e is #'F or !#E8 then the controls of thecorres)onding data transfer must 7e the same as their )revious control=default cloc9> OT'D the e6uivalence o)erator is used with ah7Prot

7ecause this is an o)tional signal and ma/ 7e an [G[ value if notconnected %%% sugar )ro)ert/ ontrolMusteonstanturingAurst K alwa/s =%%=ah7Trans?i KK #'F> SS =ah7Trans?i KK !#E> *J%%==ah7#ie?i KK )rev?ah7#ie> UU =ah7Prot?i KKK )rev?ah7Prot> UU%%=ah7:rite?i KK )rev?ah7:rite>> >H% ehaviorD if Read/ is - and the res)onse is OB or 'RROR8 the addressand control8 and data from the master are held constant =default cloc9>OT'D the e6uivalence o)erator is used with ah7Prot 7ecause this is ano)tional signal and ma/ 7e an [G[ value if not connected %%% sugar )ro)ert/ ontrolMusteonstant:hen#laveotRead/ K alwa/s =%%=ah7Read/?i KK -> UU ==ah7Res)?i KK OBAE> SS =ah7Res)?i KK 'RROR>> *J ne(t%%=ah7Trans?i KK )rev?ah7Trans> UU =ah7#ie?i KK )rev?ah7#ie> UU%%=ah7Prot?i KKK )rev?ah7Prot> UU =ah7:rite?i KK )rev?ah7:rite> UU%%=ah7Addr?i KK )rev?ah7Addr> UU =ah7urst?i KK )rev?ah7urst> >%%a7ort =ah7Resetn?i KK ->H% ehaviorD if read/ is - and the )revious transfer t/)e was #'F or O#'F8then on the ne(t c/cle the write data is the same as the )revious write data=default cloc9> =This assertion is designed to failNNN> %%% sugar )ro)ert/ :riteataMusteonstant:hen#laveotRead/AndataeingTransferred K alwa/s =%%=ah7Read/?i KK -> UU =ah7:rite?i KK 1> UU%%==)rev?ah7Trans KK #'F> SS =)rev?ah7Trans KK O#'F>> *J ne(t%%=ah7:ata?i KK )rev?ah7:ata> >%%a7ort =ah7Resetn?i KK ->H% ehaviorD if transfer t/)e is !#E then address does not change=default cloc9> %%% sugar )ro)ert/ Addr+eld:henMasterus/ K alwa/s =%%=ah7Trans?i KK !#E> *J ne(t =ah7Addr?i KK )rev?ah7Addr> >H% ehaviorD if transfer is in )rogress8 then 1B 7oundar/ is not e(ceeded=default cloc9> %


16/22

%% sugar )ro)ert/ PageAddressever'(ceeds19oundar/ K alwa/s =%%==ah7Trans?i KK #'F> SS =ah7Trans?i KK !#E>> *J%%=ah7Addr?i31D1-Q KK )rev?ah7Addr31D1-Q> >H% ehaviorD If the 7urst t/)e is not IR and the transfer t/)e is not

I$' 8 then the um7ereats for the urst Mode is not e(ceeded=default cloc9> %%% sugar )ro)ert/ urstIsotToo$ong K alwa/s =%%=ah7urst?i NK IR> UU =ah7Trans?i NK I$'> *J%%==ah7urst?i KK #I@$'> UU =um7ereats K 1>> SS%%==ah7urst?i KK :RAP"> UU =um7ereats K ">> SS%%==ah7urst?i KK :RAP0> UU =um7ereats K 0>> SS%%==ah7urst?i KK :RAP1,> UU =um7ereats K 1,>> SS%%==ah7urst?i KK IR"> UU =um7ereats K ">> SS%%==ah7urst?i KK IR0> UU =um7ereats K 0>> SS%%==ah7urst?i KK IR1,> UU =um7ereats K 1,>> >H% ehaviorD 4or all 7ut IR urst mode8 if the end of the )ac9et is 7eingtransferred as indicated 7/ a transition from #'F to I$' when Res) is o9then the um7ereats for the urst Mode is the ma( num7er unless grant is -=default cloc9> %0P$AT4ORM APP$IATIO OT'%% sugar )ro)ert/ urstIsotToo#hort K alwa/s%%L==ah7urst?i NK IR> UU =ah7Res)?i KK OBAE> UU =ah7Trans?i KK #'F>>H%%=ah7Trans?i KK I$'> S*J%%L==)rev?ah7urst KK #I@$'> UU =um7ereats KK 1>> SS%%==)rev?ah7urst KK :RAP"> UU =um7ereats KK ">> SS%%==)rev?ah7urst KK :RAP0> UU =um7ereats KK 0>> SS%%==)rev?ah7urst KK :RAP1,> UU =um7ereats KK 1,>> SS%%==)rev?ah7urst KK IR"> UU =um7ereats KK ">> SS%%==)rev?ah7urst KK IR0> UU =um7ereats KK 0>> SS%%


17/22

==)rev?ah7urst KK IR1,> UU =um7ereats KK 1,>>%%a7ort =ah7@nt?i KK -> H% ehaviorD if the transfer t/)e is I$' 8 then on the ne(t cloc9 c/cle8the transfer t/)e is not #'F and the transfer t/)e is not !#E=default cloc9> %

%% sugar )ro)ert/ ever@o4romIdleTo#e6Orus/ K alwa/s =%%=ah7Trans?i KK I$'> *J%%ne(t ==ah7Trans?i NK #'F> UU =ah7Trans?i NK !#E>> >H% ehaviorD R'TRE is alwa/s asserted for two c/cles unless reset is asserted=default cloc9>%%% sugar )ro)ert/ Retr/Res)onseMustPersistTwo/cles K alwa/s%%L=ah7Res)?i NK R'TRE>H=ah7Res)?i KK R'TRE> SKJ%%L=ah7Res)?i KK R'TRE>%%a7ort =ah7Resetn?i KK ->H% ehaviorD #P$IT is alwa/s asserted for two c/cles unless reset is asserted=default cloc9> %%% sugar )ro)ert/ #)litRes)onseMustPersistTwo/cles K alwa/s%%L=ah7Res)?i NK #P$IT>H=ah7Res)?i KK #P$IT> SKJ%%L=ah7Res)?i KK #P$IT>%%a7ort =ah7Resetn?i KK ->H% ehaviorD 'RROR is alwa/s asserted for two c/cles unless reset is asserted=default cloc9> %%% sugar )ro)ert/ 'rrorRes)onseMustPersistTwo/cles K alwa/s%%L=ah7Res)?i NK 'RROR>H=ah7Res)?i KK 'RROR> SKJ%%L=ah7Res)?i KK 'RROR>%%a7ort =ah7Resetn?i KK ->H% incorrectAddressalculation for 3 e(am)le :RAP modesD This calculateswhether the ne(t address is correct for all wra) modes%% ehaviorD if urst mode is :RAP" and #ie is 0 7its8 then iftransfer mode is #'F or !#E8 then if )revious transfer mode is not7us/ and )revious Read/ is not ero8 then chec9 that the address is as )redicted %%% sugar )ro)ert/ orrectAddressuringPage#ie"urst:ra) K alwa/s =%%==ah7urst?iKK :RAP"> UU =ah7#ie?i KK 7its0>> *J%%==ah7Trans?i KK #'F SS ah7Trans?i KK !#E>> *J%%


18/22

==)rev?ah7Trans NK !#E> UU =)rev?ah7Read/ NK ->> *J%%==ah7Addr?i31D2Q KK )rev?ah7Addr31D2Q> UU%%=ah7Addr?i1D-Q KK )rev?ah7AddrPlus#ie1D-Q>> >H%% sugar )ro)ert/ orrectAddressuringPage#ie0urst:ra) K alwa/s =

%%==ah7urst?iKK :RAP"> UU =ah7#ie?i KK 7its1,>> SS%%==ah7urst?iKK :RAP0> UU =ah7#ie?i KK 7its0>> *J%%==ah7Trans?i KK #'F> SS =ah7Trans?i KK !#E>> *J%%==)rev?ah7Trans NK !#E> UU =)rev?ah7Read/ NK ->> *J%%==ah7Addr?i31D3Q KK )rev?ah7Addr31D3Q> UU%%=ah7Addr?i2D-Q KK )rev?ah7AddrPlus#ie2D-Q>> >H%% sugar )ro)ert/ orrectAddressuringPage#ie2-"0urst:ra) K alwa/s =%%==ah7urst?iKK :RAP1,> UU =ah7#ie?i KK 7its1-2">> *J%%==ah7Trans?i KK #'F> SS =ah7Trans?i KK !#E>> *J%%==)rev?ah7Trans NK !#E> UU =)rev?ah7Read/ NK ->> *J%%==ah7Addr?i31D11Q KK )rev?ah7Addr31D11Q> UU%%=ah7Addr?i1-D-Q KK )rev?ah7AddrPlus#ie1-D-Q>> >H% ehaviorD the address must increment 7/ sie during all IR 7eats %%% sugar )ro)ert/ AddressInc/#ieuringAllurstIncreats K alwa/s =%%==ah7urst?i KK IR1,> SS =ah7urst?i KK IR0> SS%%=ah7urst?i KK IR">> *J%%==ah7Trans?i KK #'F> SS =ah7Trans?i KK !#E>> *J%%==)rev?ah7Trans NK !#E> UU =ah7Read/?i NK ->> *J%%=ah7Addr?i KK )rev?ah7AddrPlus#ie> >H% ehaviorD alwa/s address must 7e aligned to the transfer sie %%% sugar )ro)ert/ AddressotAlignedToTransfer#ie K alwa/s =%%==ah7#ie?i KK 7its0> SS%%==ah7#ie?i KK 7its1,> UU =ah7Addr?i-QKK 1Y7->> SS%%


19/22

==ah7#ie?i KK 7its32> UU =ah7Addr?i1D-Q KK 2Y7-->> SS%%==ah7#ie?i KK 7its,"> UU =ah7Addr?i2D-Q KK 3Y7--->> SS%%==ah7#ie?i KK 7its120> UU =ah7Addr?i3D-Q KK "Y7---->> SS%%

==ah7#ie?i KK 7its2&,> UU =ah7Addr?i"D-Q KK &Y7----->> SS%%==ah7#ie?i KK 7its&12> UU =ah7Addr?i&D-Q KK ,Y7------>> SS%%==ah7#ie?i KK 7its1-2"> UU =ah7Addr?i,D-Q KK Y7------->> > >H\P$AT4ORM APP$IATIO OT'% ehaviorD alwa/s the ma(imum num7er of wait states is 1, %%% sugar )ro)ert/ everMoreThan1,:ait#tates K alwa/s%%L=ah7Read/?i KK 1>H=ah7Read/?i KK -> SKJ%%LL=ah7Read/?i KK ->-..1&QHLah7Read/?i KK 1%%a7ort =ah7Res)?i NK OBAE>H%% s/no)s/s translate?onendmodule&.1TIP# 4OR :RITI@ A##'RTIO#+ere are a few things to remem7er that will hel) /ou to get started with writing assertionsD1.2.3.".&.,.,Performance is adversel/ affected 7/ eventualities and 7/ un7ounded re)etition in the right hand sideof the assertion.Assertions are sensitive to race conditions Cust li9e +$8 so it will 7e a))ro)riate to evaluate mostassertions relative toa cloc9.Eou should avoid using never or not a))lied to an im)lication. The semantics are non*intuitive87ecause theim)lication =a *J 7> is true if a is false8 so )ro)ert/ e(am)le K never =a*J7> can onl/ 7e true if a isalwa/s true.In addition8 the statistics will not indicate that a never assertion ever finishes 7ecause it can onl/ fail.Assertions inside functions and Verilog tas9s and V+$ )rocedures are ignored. +owever8 anassertion can utilie afunction as )art of a Verilog or V+$ e()ression.Remem7er that assertions are evaluated at ever/ verification c/cle and all are evaluated concurrentl/.An assertion thate()resses a se6uence of length 3 can have three concurrent evaluations ongoing simultaneousl/ if the


20/22

initiale()ression remains true for e(tended c/cles. This is ver/ )owerful 7ecause it allows for detection ofoverla))ingconditions.As /ou will see in the ne(t section8 it is im)ortant to give /our )ro)erties descri)tive names 7ecause thename is the

message that is )rovided when the assertion fires.A##'RTIO !#' MO'$ I T+' II#IV' V'RI4IATIO P$AT4ORMThis section descri7es how to run a Verilog simulation with assertions and how to de7ug assertionfailures. Most assertionsshould 7e ena7led all the time 7ecause the overhead is ver/ low relative to the overall simulation timesand the/ )rovidetremendous value in isolating the cause of 7ugs. It is not necessar/ to alwa/s )ro7e assertions 7ecausefailures will 7ere)orted regardless of whether or not the assertion is )ro7ed.,.1R!I@ A V'RI$O@ #IM!$ATIOThe first ste) is to com)ile and ela7orate the monitor and test fi(ture. 4igure 2 shows the commandused to com)ile themonitor and test fi(ture8 and the te(t out)ut that is sent to the terminal. =oteD all design files andsimulation messages arenot shown.> The ncverilog assert directs the com)iler to ena7le assertion )rocessing. :ithout thiscom)iler o)tion8all assertions are ignored. If there are assertions in the design8 and the assert com)ile o)tion wass)ecified8 then thedesign hierarch/ will show the num7er of assertions. The simulation is run in command line mode sothere are no7rea9)oints and the simulator runs to the finish. In the @!I mode8 the default is to 7rea9 on assertionfailures8 which ma9esthe de7ug easier 7ecause /ou can 6uer/ current signal values at the time of failure. Assertion errors are)rinted 7oth to theterminal and to the log file. Assertions can also 7e directed to their own log file.1-P$AT4ORM APP$IATIO OT'!se assert to ena7le com)ilation ofP#$%#ugar assertions.ote that the esign hierarch/ summar/shows the num7er of assertions.The assertion failure message is)rinted to the console and the logfile. The name of the assertionand the time of failure are)rovided.4igure 2. Running a Verilog #imulation with Assertions11P$AT4ORM APP$IATIO OT',.2'!@@I@ A##'RTIO 4AI$!R'#In general8 for de7ug8 /ou want to use accesswrc to ela7orate the design so /ou can see all signals.


21/22

4igure 3 shows thewaveform that is generated when the test case is run. All in)ut signals were )ro7ed and all theassertions were )ro7ed toone event counter. otice that this event counter has a red ( an/time a failure of an/ of the assertionsoccurs. Eou candetermine which assertion failed 7/ selecting the )ro7e name8 then )lacing the curser on the ( and

choosing the '()lore]@oTo]ause menu command. This will o)en the source 7rowser with a )ointer to the location of theassertion definition8 asshown in 4igure ". Placing /our curser over a signal or varia7le name will show the current value ofthat signal or varia7le. Ifmulti)le assertions fail8 use the View]'()and #e6uence menu command to select onl/ one assertionat a time.4igure " #imulation :aveform #hown with all Assertions Pro7ed to One 'vent ounter.4igure 3 #imulation :aveform #hown with all Assertions Pro7ed to One 'vent ounter.12P$AT4ORM APP$IATIO OT'Assertion rowser icon4igure " #ource rowser Points to the efinition of the 4ailing AssertionTo de7ug /our assertions in the @!I without using waveforms invo9e the assertion 7rowser 7/selecting the 7utton with theassertion 7rowser icon or through the menuD :indows *J ew *J Assertion rowser. The assertion7rowser shows a listingof all assertions in the design. The colors reflect the urrent #tate. :hen an assertion fails8 it is eas/ toidentif/ 7/ the colorred. Another wa/ to locate an assertion is to use the filtering at the 7ottom. Assertions can also 7esorted 7/ clic9ing on an/column heading.adence5s im)lementation of assertion*7ased verification defines four statesD 7egun8 finished8 inactive8andfailed. The assertion is 7egun when the first se6uence of the ena7ling condition is satisfied8 and remains7egun until theassertion goes inactive8 finishes or fails. The failed state indicates that the fulfilling condition for anassertion hasevaluated to false. The finished state indicates that the fulfilling condition for an assertion has evaluatedto true. Theinactive state is when the assertion has not 7egun8 and did not fail or finish during the currect cloc9c/cle. The assertionstatistics )rovide some feel for what the simulation vectors have e(ercised8 7ut inter)retation can 7etric9/ due tooverla))ing conditions. A summar/ of statistics is )rovided for all assertions at the to)8 and for thosedis)la/ed =filtered> atthe 7ottom of the window.Eou can dou7le clic9 on an/ assertion in the Assertion rowser and it will ta9e /ou to the assertiondefinition in the source7rowser. To de7ug a failed assertion8 dou7le clic9 on the failed assertion to view the source. The source7rowser shows thedefinition of the failed assertion8 e(actl/ as shown in 4igure " a7ove. :hen /ou run in @!I mode anduse the default 7rea9


22/22

on assertion failure8 /ou can )lace the cursor over the terms of the fulfilling condition of the assertiondefinition to determinewhat fired the assertion. This )rovides the current values onl/. Eou will not 7e a7le to see se6uencevalues from )revioussimulation time ste)s.13

P$AT4ORM APP$IATIO OT'4igure & Assertion rowser shows Assertion #tatistics#!MMAREAssertions within a design sim)lif/ the detection and diagnosis of errors 7/ ma9ing internal test )ointsvisi7le when an erroris detected. Assertions document the designer5s assum)tions and e()ected 7ehavior in a standardiedwa/ that is testedand travels with the design8 which is invalua7le to an/ designer who must maintain or e(tend the codein the future.This document has )rovided an overview of the Incisive verification )latform5s im)lementation ofassertion 7asedverification8 including the language su))orted8 e(am)le assertions8 and the Verilog simulation usemodel. Additionalinformation is availa7le in the #imulation*ased Assertion hec9ing @uide in adence documentation.01.2.3.".&.R'4'R''##imulation*ased Assertions Verification Tutorial ^ adence ocumentation#imulation*ased Assertion hec9ing @uide ^ adence ocumentation#ugar 2.- efinition8 March 2-8 2--2.htt)D%%www.haifa.il.i7m.com%)roCects%verification%sugar%literature.htmlAccellera Pro)ert/ #)ecification $anguage Reference Manual. _anuar/ 318 2--3.htt)D%%www.eda.org%vfv%docs%)sl?lrm*1.-.)dfAMA A+ s)ecificationD www.arm.com%armtech%AMA?#)ecWO)enocument1"P$AT4ORM APP$IATIO OT'

The Role of Assertions in Verification Methodologies

Documents

Transcript of The Role of Assertions in Verification Methodologies