The Role of Assertions in Verification Methodologies

Platform ......................................................................................................... 1
1 Assertions Overview............................................................................................................................. 1
2 Introduction........................................................................................................................................... 1
3 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"
1A2'31' I31I#IV' V'RI4I1ATIO3 P$AT4ORM
Verif/ing toda/5s com)le( I1s re6uires the s)eed and efficienc/ that can onl/ 7e )rovided in a unified
verification
methodolog/. The 1adence Incisive verification )latform ena7les the develo)ment of a unified
methodolog/ from s/stem
design to s/stem design*in for all design domains. A unified verification methodolog/ consists of man/
different tools8
technologies and )rocesses all wor9ing together in a common environment. The Incisive )latform
)rovides the tools8
technologies8 a common user environment and the su))ort needed to develo) a unified methodolog/.
This a))lication note
details s)ecific to)ics for using the tools and technologies in the Incisive )latform to hel) create a
unified methodolog/ to
verif/ /our design.
1
A##'RTIO3# OV'RVI':
Assertions )la/ an im)ortant role in a unified verification methodolog/. Assertions allow the architect
or designer to ca)ture
his or her design intent and assum)tions in a manner that can 7e verified in the im)lementation.
Assertions are ca)tured
during the develo)ment )rocess and are continuall/ verified throughout the )rocess. Assertions8
wor9ing in a unified
verification methodolog/8 reduce the verification time 7/ detecting 7ugs earlier8 isolating where a 7ug
is located8 and
detecting )rotocol violations that ma/ not cause functional errors to )ro)agate to the out)uts. In
addition to 7ug detection8
assertions im)rove the efficienc/ in a unified methodolog/ 7/ im)roving reuse8 enhancing test7ench
chec9ing8 and ca)turing
coverage information.
2
I3TRO2!1TIO3
Assertions e()ress functional design intent in terms of 7ehavior. Assertions can 7e used to e()ress
assumed in)ut 7ehavior8
e()ected out)ut 7ehavior8 or for7idden 7ehavior. 4or e(am)le8 if a )rocessor has a read signal and a
write interface signal8
a designer might assume that ;the read signal and the write signal should never 7e 7oth active at the
same time.< :ith
assertion*7ased verification =AV> in a simulation environment8 if during a )articular simulation run8
there was ever a c/cle
when 7oth the read and the write signals were active8
Interface
#tructural
A))lication
then the assertion would fire and re)ort a message.
Assertions
Assertions
Assertion
This is an e(am)le of an interface assertion. Interface
assertions are used to chec9 the )rotocol of interfaces
7etween 7loc9s. Other t/)es of assertions include
architectural assertions and structural assertions8 as
shown in 4igure 1. A))lication assertions are used to
Ar7iter
)rove architectural )ro)erties such as fairness and
deadloc9s. 4or e(am)le8 ;after a re6uest for transfer8
P1I
eventuall/ an ac9nowledge is granted.< #tructural
us
assertions are used to verif/ low*level internal
4I4O
4#M
structures within an im)lementation8 such as a 4I4O
Processor
overflow or incorrect 4#M transitions. 4or e(am)le8 ;if
A+
the read and write )ointers of a 4I4O are the same8
us
then the state of the 4#M remains 4I4O?Overflow until
data is read.<
4igure 1. T/)es of Assertions
This document )rovides an introduction to the
P#$%#ugar assertion language and to the P#$%#ugar*7ased im)lementation of AV =2/namic AV>
that is su))orted in the
1adence Incisive verification Platform. The 7enefits of using assertions are discussed8 and a s)ecific
e(am)le of interface
assertions for the AMA A+ )rocessor t/)e interface is )resented. The use models of 1adence5s
im)lementation of
Assertion*ased Verification are also discussed8 including how /ou run a simulation with assertions8
de7ug them8 and turn
them on and off.
3
'3'4IT# O4 !#I3@ A##'RTIO3#
Assertions are created in the unified verification methodolog/ whenever design or architecture
information is ca)tured.
These assertions are then used throughout the verification )rocess to efficientl/ verif/ the design. The
use of assertions
im)roves the s)eed and efficienc/ of verification 7/ 7ug catching and 7/ enhanced test7ench chec9ing.
Assertions also
facilitate re*use and )rovide data that is useful in evaluating functional coverage.
3.1
!@ 1AT1+I3@
The )rimar/ focus of 1adence5s im)lementation of assertion*7ased verification is to identif/ 7ugs as
close to the source as
)ossi7le. This reduces the de7ug time8 es)eciall/ after full chi) integration of 7loc9s when 7ugs ta9e
longer to )ro)agate to
the out)ut and are more difficult to isolate. Assertion chec9ing during simulation can identif/ internal
errors within the module
1
P$AT4ORM APP$I1ATIO3 3OT'
sooner and closer to the source than is )ossi7le without assertions. :ithout assertions8 errors must
)ro)agate to the out)uts
7efore 7eing detected. Assertions reduce the time it ta9es to locate difficult 7ugs 7/ identif/ing where
in a design the 7ug
first a))ears. Assertions also catch 7ugs that do not )ro)agate to the out)ut. :hen an assertion fires8 it
)rovides an
immediate localiAation of the failure8 which sim)lifies the insertion of intellectual )ro)ert/ =IP> into
design environments.
3.2
'3+A31I3@ T'#T'31+ 1+'1BI3@
Assertions hel) to su))lement test7ench chec9ing. Often test7ench chec9ers re6uire added com)le(it/
to verif/ the correct
o)eration of internal device under verification =2!V> 7ehavior8 such as verif/ing that an ar7iter8 7uried
dee) in the design8 is
servicing re6uests in a fair manner. Assertions reduce the necessit/ for com)le(it/ in the chec9er as
the/ can verif/ internal
o)erations close to the source in a sim)le manner. / )lacing assertions throughout the design /ou are
enhancing the
overall chec9ing a7ilit/ of the test7ench.
3.3
R'*!#'
Time to mar9et )ressures8 and the high cost and ris9 of new develo)ments continues to increase the
im)ortance of re*use8
7oth for design and verification IP. A 9e/ o7Cection that designers have in ado)ting re*use
methodologies is that it is difficult
to understand and integrate someone else5s code8 es)eciall/ when the develo)er is no longer availa7le
for consultation.
Also8 there is a general lac9 of confidence in how )roven the code is and how accurate the
documentation 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. 'm7edded
assertions travel with
the design8 ma9ing the design easier to integrate. Assertions can flag when the assum)tions of the
original designer are not
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 therefore
inter)ret8 7oth assumed
and e()ected 7ehavior. 'ach 7ehavior is verified with the simulation vectors8 so in a sense8 the
documentation 7ecomes a
standardiAed format that is )roven and continuall/ tested 7/ simulation vectors.
3."
1OV'RA@'
:ith 1adence5s im)lementation of AV8 assertion statistics re)resent coverage information. This
coverage information can
7e hel)ful in identif/ing 7oundar/ conditions8 corner cases8 or se6uences that have not 7een tested.
"
OV'RVI': O4 P#$%#!@AR
The Verilog and V+2$ simulators of the Incisive verification )latform su))ort the use of assertions
with native simulation
su))ort for the P#$%#ugar assertion language. This section )rovides an overview of the features
commonl/ used. Refer to
the #imulation*ased Assertion 1hec9ing @uide for com)lete details of which features the simulators
in the Incisive
verification )latform su))ort.
P#$%#ugar ma9es it eas/ to e()ress ver/ com)le( 7ehavior. P#$%#ugar is 7ased on oolean
e()ressions8 and defines
dialects that are s)ecific to hardware languages. P#$%#ugar ma9es it straightforward to e()ress the
following 7ehaviorD
1. A 7ehavior ma/ alwa/s or never hold true
2. A 7ehavior ma/ alwa/s or never hold true onl/ within some window
3. 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 configurations
The Verilog and V+2$ simulators in the Incisive verification )latform )rovide native su))ort of
P#$%#ugar language. 3ative
su))ort is ver/ im)ortant for o)timal )erformance.
".1
OO$'A3#
P#$%#ugar is designed to 7e used in conCunction with hardware descri)tion languages =+2$> such as
Verilog or V+2$. At
the 7ottom level8 the P#$%#ugar language is used to s)ecif/ the conditions that define a 7ehavior of
interest8 referring to
signals8 varia7les8 and values within an +2$ descri)tion of a design. Those conditions are re)resented
7/ +2$ e()ressions
that can 7e inter)reted as having oolean values. !sing the underl/ing +2$ s/nta( and semantics for
such e()ressions
ensures that the assertion language can cover the full range of 7ehavior that can 7e descri7ed in the
+2$8 and that there is
no chance of semantic mismatch 7etween the +2$ descri)tion of a 7ehavior and the P#$%#ugar
descri)tion of the same
7ehavior. This also reduces the learning curve for 7eing a7le to e()ress a 7ehavior. 1adence5s
im)lementation of AV
su))orts two dialects of P#$%#ugar. oolean e()ressions ta9e on the s/nta( of the language of the
com)iler. 31Verilog
su))orts the Verilog dialect and 31V+2$ su))orts the V+2$ dialect.
2
P$AT4ORM APP$I1ATIO3 3OT'
".2
1$O1BI3@ A32 'VA$!ATIO3
P#$%#ugar assertions are declarative in nature. This means that ever/ assertion is evaluated on ever/
verification c/cle8 and
all assertions are evaluated concurrentl/. Activation of assertions is not de)endent on the +2$ code. In
other words8
activation of assertions are not affected 7/ )lacement in a conditional statement8 li9e a case statement
or an if statement.
As/nchronous or s/nchronous 7ehavior can 7e e()ressed. Eou can also define a default cloc9 that
a))lies if no e()licit
sam)ling cloc9 is attached to an e()ression. The cloc9 can 7e defined as an/ other oolean e()ression8
and can ma9e use
of edge functions.
".3
#'F!'31' 'GPR'##IO3#
#e6uences can e()ress a sim)le oolean e()ression or a multi*c/cle 7ehavior of oolean e()ressions8
where each c/cle of
a se6uence is se)arated 7/ a ;H<.A se6uence can 7e defined once as a se6uence declaration and then 7e
referenced8 li9e
an alias. The declaration s/nta( isD
VerilogD
se6uence InameJ K LIse6uence?definitionJMH
V+2$D
se6uence InameJ is LIse6uence?definitionJM H
4or e(am)le8 if a8 78 c8 d8 and e are oolean e()ressions8 then the following define legal se6uencesD
se6uence se61 K L a MH
se6uence se62 K L 7Hc MH
se6uence com)le(?se6 K LLse61MH Lse62MMH
The com)le( se6uence8 com)le(?se68 evaluates to true when a is true followed 7/ 7 is true followed 7/
c is true.
3ote the followingD
1.
2.
3.
".
&.
,.
#e6uence names are enclosed in 7races when referenced8 indicating it is a se6uence e()ression.
#uccessive c/cles of a se6uence are se)arated 7/ a semicolon =H>.
A 7oolean e()ression ma/ 7e viewed as having a se6uence length of one. 2efining a se6uence
e()ression of length
one allows /ou to give the e()ression a more meaningful name to im)rove reada7ilit/.
The 9e/word true can 7e used to s)ecif/ a don5t care condition during an/ c/cle.
Eou cannot a))l/ the Verilog N or V+2$not o)erator on a se6uence e()ressions. =for e(am)le8
NLse6uence?e()ressionM 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 for
each +2$ dialect. The more commonl/ used o)eraters are shown 7elowD
Verilog 2ialect
OPQ
ORQ
O P nQ
O Pn Dinf Q
OP D mQ
O Pn D m Q
V+2$ 2ialect
O P Q
ORQ
OP nQ
O Pn to inf Q
O P to m Q
O Pn to m Q
2efinition
Indicates that the e()ression ma/ occur Aero 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)tional
ena7ling condition8 a
fulfilling condition8 which is the 7ehavior to 7e chec9ed8 an o)tional discharging condition8 and an
o)tional cloc9ing condition.
The most general form of a )ro)ert/ and the definition of terms is shown 7elowD
VerilogD
)ro)ert/ InameJ K Oo)eratorQ Oena7ling?condition=s>Q
Oim)lication?o)erator=s>Q =fulfilling?condition>
Ountil S until? S a7ort discharging?conditionQ OT=cloc9?e()ression>QH
V+2$D
)ro)ert/ InameJ is Oo)eratorQ Oena7ling?condition=s>Q
Oim)lication?o)erator=s>Q =fulfilling?condition>
Ountil S until? S a7ort discharging?conditionQ OT=cloc9?e()ression>QH
3
P$AT4ORM APP$I1ATIO3 3OT'
The following descri7es the 9e/ terms of a )ro)ert/ e()ressionD
1.
2.
3.
".
&.
)ro)ert/ is a declaration that what follows is a 7ehavior. The simulator8 7/ default8 will verif/ this
7ehavior.
A )ro)ert/ InameJ is a uni6ue identifier. This should 7e a ver/ descri)tive name 7ecause the failure
message re)orts
onl/ this name and the time of failure. +2$ naming conventions a))l/. The name must 7e uni6ue to
the module or
entit/ 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.
3ote that /ou ma/ choose to omit the alwa/s or never term8 in which case the chec9 occurs at time Aero
onl/.
The ena7ling condition can 7e an/ oolean e()ression or se6uence e()ression. Multi)le ena7ling
conditions and
im)lication o)erators can 7e strung together to form a com)le( ena7le. The assertion is considered to
7egin when the
first 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 is
one of the
following 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 7ehavior
can 7e read as ;if =ena7ling condition> is true8 then the =fulfilling condition> must 7e true in the
ne(t verification c/cle<. The $+# must 7e 7oolean
S*J
,.
'valuation of the right hand side=R+#> is started when the left hand side=$+#> is true. The
7ehavior can 7e read as ;if =ena7ling condition> is true8 then the =fulfilling condition> must also 7e
true<. The $+# must 7e 7oolean.
The R+# is true in some future c/cle8 and must 7e true 7efore the end of simulation. The R+#
must 7e a 7oolean or a se6uence.
The fulfilling condition is the 7ehavior to 7e tested. It is chec9ed on ever/ verification c/cle 7/ default.
The fulfilling
condition can 7e an/ oolean e()ression or se6uence. The fulfilling condition is the last e()ression
)rior to an/
discharging condition.
The discharging condition is a condition that indicates to sto) the chec9ing of the 7ehavior.
2ischarging conditions
include the followingD
until =oolean e()ression>
until? =oolean e()ression>
a7ort =oolean e()ression>
0.
:hen all of the ena7ling conditions have evaluated to true8 the fulfilling condition
must 7e true until the oolean e()ression 7ecomes true. It then finishes
immediatel/. until has no affect until the fulfilling condition is 7eing chec9ed.
:hen all of the ena7ling conditions have evaluated to true8 the fulfilling condition
must remain true u) to and including the c/cle where the oolean e()ression is
true. It then finishes immediatel/. until? has no affect until the fulfilling condition
is 7eing chec9ed
A7ort cancels the chec9ing of an assertion. An a7ort that occurs during the
chec9ing 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 cloc9
edge8 7ut can 7e
an/ 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 followsD
Assuming read and write are interface signals8 the following is an e(am)le of an interface assertionD
VerilogD
V+2$D
)ro)ert/ 3everRd:rothActive K never ==read KK 1> UU =write KK 1>>H
)ro)ert/ 3everRd:rothActive is never ==read K 1> and =write K 1>>H
"
P$AT4ORM APP$I1ATIO3 3OT'
An a))lication assertion might 7e that ever/ re6uest is eventuall/ granted unless a reset occursD
VerilogD
V+2$D
)ro)ert/ 'ver/Re6uestIs'ventuall/@ranted K alwa/s =
Re6 *J eventuall/N =@ranted KK 1>> a7ort =reset KK 1>T=)osedge cl9>
)ro)ert/ 'ver/Re6uestIs'ventuall/@ranted is alwa/s =
Re6 *J eventuall/N =@ranted K 1>> a7ort =reset K 1> T=cl95event and cl9 K V15>
A structural assertion might 7e that if the memor/ tas9 is clear =m?tas9 K 257-->8 it must alwa/s 7e
followed 7/ a three*
c/cle se6uence that must 7e re)eated 2&, times. The se6uence is write?n low for one sam)le followed
7/ a write high for
two sam)les. The write signal is s/nchronous to the )ositive edge of cl9. Reset is high and will cancel
the write.
VerilogD
se6uence :RIT'?P!$#' K L=write?n KK ->H=write?n KK 1>H=write?n KK 1>MH
)ro)ert/ 1$'AR?M'M?:RIT'?3 K alwa/s
Lm?tas9 KK 257--M SKJ L:RIT'?P!$#'OP2&,QM
a7ort =reset KK 1> T=)osedge cl9>8
V+2$D
se6uence :RIT'?P!$#' is L=write?n K ->H=write?n K 1>H=write?n K 1>MH
)ro)ert/ 1$'AR?M'M?:RIT'?3 is alwa/s
Lm?tas9 K 5--5M SKJ L:RIT'?P!$#'OP2&,QM
a7ort =reset K 1> T=cl95event and cl9 K V15>H
"."
2IR'1TIV'#
A se6uence or a )ro)ert/ 7/ itself Cust descri7es 7ehavior8 there is no inherent o7ligation for the
7ehavior to occur.
2irectives s)ecif/ whether a given )ro)ert/ is e()ected to hold =assert> or assumed to hold =assume>. In
addition8 a cover
directive s)ecifies the desire to ensure that a se6uence is encountered during verification. Pro)erties are
alwa/s asserted or
assumed. 4or assertions used in simulation8 assert and assume have the same meaning. =#tatic
verification will )rove
)ro)erties that are asserted8 and will use assumed )ro)erties to limit the state s)ace of the search. >
#e6uences can 7e
used in )ro)erties or the/ can 7e used e()licitl/ for coverage. The format is as follows for 7oth Verilog
and V+2$D
assume S assert I)ro)ert/?nameJH
cover Ise6uence?nameJHD
In 1adence5s im)lementation of simulation*7ased assertion verification8 all )ro)erties are treated as if
the/ are asserted.
That is to sa/8 the assert or assume directives are o)tional.
".&
2'4I3I3@ A##'RTIO3#
1adence5s im)lementation of AV su))orts defining assertions em7edded in the same module or
entit/%architecture as the
+2$ with which it is associated8 or in a se)arate file. 'm7edded assertions are in comments and are
identified using the
s)ecial )ragma identifier sugar. 4or e(am)le8 the following is an em7edded assertion that e()resses
that the read and
write signals are never 7oth active8 assuming the active state is highD
VerilogD %% sugar )ro)ert/ 3everRd:rothActive K never ==read KK 1> UU =write KK 1>>
V+2$D
** sugar )ro)ert/ 3everRd: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))ort
P#$%#ugar.
Assertions ma/ also e(ist in an e(ternal file that references signals8 varia7les8 and values within an
+2$ descri)tion of a
design. !sing assertions from an e(ternal file is descri7ed in the #imulation*ased Assertion 1hec9ing
@uide in 1adence
documentation.
#tructural assertions that are used to verif/ low level internal structures within an im)lementation will
li9el/ 7e inline with the
+2$ code. This is the recommended a))roach when the assertion is s)ecific to a design8 7ecause the
assertion is
guaranteed to travel with the design.
A))lication assertions that are used to )rove architectural )ro)erties ma/ 7e em7edded in the design
+2$8 or the/ ma/ 7e
in an e(ternal file that references the design +2$. The )rimar/ reason for defining assertions in an
e(ternal file is to e()ress
7ehavior that references signals from multi)le modules or entities. Another use for assertions in an
e(ternal file is when
assertions 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)arate
file8 7ut that file is a
standalone module or entit/. The interface assertions are self*contained in the module%entit/ that
contains +2$ code8 so
the/ have the same effect as em7edded assertions. The +2$ code is minimal 7ut can 7e used8 for
e(am)le8 to calculate
e()ected values that are then used in the assertions. Placing the assertions in a se)arate file allows the
interface assertions
to 7e instantiated in an/ 7loc9 that ma9es use of that interface =for 7loc9 level verification> or on the
interface itself when the
7loc9s are integrated. 2efining a se)arate module or entit/ that is instantiated also allows the signal
names to 7e ma))ed
when the interface assertions are instantiated8 ma9ing it easier to use. The AMA A+ Interface
assertions discussed in the
ne(t section )rovide an e(am)le.
&
P$AT4ORM APP$I1ATIO3 3OT'
&
PRA1TI1A$ 'GAMP$' * AMA A+ I3T'R4A1' A##'RTIO3#
The AMA A+P interface is a t/)ical )rocessor interface. This section details how to write P#$%#ugar
com)liance assertions
using the Verilog dialect for an A+ interface. 'ach 7ehavior is descri7ed and the P#$%#ugar
re)resentation is shown. The
ne(t section will show how to simulate with these assertions. The detailed A+ s)ecification can 7e
found at
www.arm.com%armtech%AMA?#)ecWO)en2ocument.
#ignaling interface monitors will 7e +2$ 7ased assertions that use the P#$%#ugar language. This
choice 9ee)s the cloc9
level 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/ Cust
want to chec9 that the
)rotocol s)ecified for the transfer was adhered to. +igher la/er )rotocols are 7etter chec9ed using
higher level languages
li9e #/stem1 7ecause of its e(tended ca)a7ilities8 such as 6ueuing8 and other features for trac9ing
e()ected results.
The A+ assertions will 7e em7edded in an interface assertion monitor that can 7e instantiated in the
design. This allows
the assertion monitor to 7e instantiated within an/ A+ interface device8 or once on an/ A+ 7us
interface. The P#$%#ugar
code is shown 7elow. The to) of the file sim)l/ declares all the signals. It also defines )arameters used
to im)rove
reada7ilit/. #ome +2$ code is re6uired to create varia7les used in the assertions. The assertions are
then defined. 4or each
assertion8 the 7ehavior is descri7ed and then defined in P#$%#ugar. 3ote that all )ro)erties are asserted
7/ default in the
simulators of the Incisive verification )latform8 so the assume directive is not used.
%PPPPPPPPPPPPPPPPPP A+ Interface P#$ #ugar Assertions PPPPPPPPPPPPPPPP%
Xtimescale 1 ns % 1-- )s
module ah71om)liance =ah7Addr?i8 ah7Trans?i8 ah7:rite?i8 ah7#iAe?i8
ah7urst?i8 ah7Prot?i8 ah7:2ata?i8 ah7R2ata?i8 ah7Read/?i8 ah7Res)?i8
ah7Re6?i8 ah7$oc9?i8 ah7@nt?i8 ah7Resetn?i8 ah7#el?i8 ah7Master?i8
ah7Mast$oc9?i8 ah7#)lit?i8 ah71l9?i>H
)arameter dataus:idth
)arameter num#laves
)arameter 7usMaster
K 32H
K 32H
K -H
%P these )arameters define the Transfer T/)e as s)ecified 7/ +Trans P%
)arameter I2$' K 2Y7--H
)arameter !#E K 2Y7-1H
)arameter #'F K 2Y711H
)arameter 3O3#'F K 2Y71-H
%P these )arameters define the urst Mode as s)ecified 7/ +urst P%
)arameter #I3@$' K 3Y7---H
)arameter I31R
K 3Y7--1H
)arameter :RAP" K 3Y7-1-H
)arameter I31R" K 3Y7-11H
)arameter :RAP0 K 3Y71--H
)arameter I31R0 K 3Y71-1H
)arameter :RAP1, K 3Y711-H
)arameter I31R1, K 3Y7111H
%P 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
%P define the transfer res)onse signals as s)ecified 7/ +Res)P%
)arameter OBAE K 2Y7--H
)arameter 'RROR K 2Y7-1H
)arameter R'TRE K 2Y71-H
)arameter #P$IT K 2Y711H
in)ut
in)ut
in)ut
in)ut
in)ut
in)ut
in)ut
in)ut
in)ut
of data in each 7eat as s)ecified 7/ +#iAeP%
3Y7---H
3Y7--1H
3Y7-1-H
3Y7-11H
3Y71--H
3Y71-1H
3Y711-H
3Y7111H
O31D-Q
O1D-Q
ah7Addr?i8 ah7:2ata?i8 ah7R2ata?iH
ah7Trans?i8 ah7Res)?iH
ah7:rite?i8 ah7Read/?i8 ah7Re6?iH
O2D-Q
ah7#iAe?i8 ah7urst?iH
O3D-Q
ah7Prot?i8 ah7Master?iH
ah7$oc9?i8 ah7@nt?i8 ah7Mast$oc9?iH
Onum#laves*1D-Q ah7#el?iH
O1&D-Q
ah7#)lit?iH
ah7Resetn?i8 ah71l9?iH
,
P$AT4ORM APP$I1ATIO3 3OT'
reg O31D-Q )rev?ah7Addr8 )rev?ah7AddrPlus#iAeH
reg )rev?ah7:rite8 )rev?ah7Read/H
reg Onum#laves*1D-Q )rev?ah7#elH
reg O3D-Q )rev?ah7ProtH
reg O2D-Q )rev?ah7#iAe8 )rev?ah7urstH
reg Odataus:idth*1D-Q )rev?ah7R2ata8 )rev?ah7:2ataH
reg O1D-Q )rev?ah7Trans8 )rev?ah7Res)H
integer AddrIncrementH
integer 3um7ereatsK-H
%% s/no)s/s translate?off
%P ca)ture data that is needed in the following assertions P%
alwa/s T=)osedge ah71l9?i or negedge ah7Resetn?i>
7egin
)rev?ah7Addr IK ah7Addr?iH
)rev?ah7Read/ IK ah7Read/?iH
)rev?ah7:rite IK ah7:rite?iH
)rev?ah7R2ata IK ah7R2ata?iH
)rev?ah7:2ata IK ah7:2ata?iH
)rev?ah7Trans IK ah7Trans?iH
)rev?ah7urst IK ah7urst?iH
)rev?ah7Res) IK ah7Res)?iH
)rev?ah7#el
IK ah7#el?iH
)rev?ah7#iAe IK ah7#iAe?iH
)rev?ah7Prot IK ah7Prot?iH
case =ah7#iAe?i>
%P AddrIncrement is used to chec9 the address P%
7its0D
AddrIncrementK1H
7its1,D
AddrIncrementK2H
7its32D
AddrIncrementK"H
7its,"D
AddrIncrementK0H
7its120D AddrIncrementK1,H
7its2&,D AddrIncrementK32H
7its&12D AddrIncrementK,"H
7its1-2"D AddrIncrementK120H
defaultD H
endcase
%P 3um7ereats is used to chec9 )ac9et lengths P%
if =ah7Trans?i KK I2$'>
3um7ereats IK -H
else if = ah7Trans?i KK 3O3#'F>
3um7ereats IK 1H
else if = =ah7Trans?i KK #'F> UU =ah7Read/?i KK 1> >
3um7ereats IK 3um7ereats R 1H
else
3um7ereats IK 3um7ereatsH
%P determine the )redicted address P%
if ==ah7Trans?i NK !#E> UU =ah7Read/?i NK ->>
)rev?ah7AddrPlus#iAe IK ah7Addr?i R AddrIncrementH
end
%PPPPPPPPPPPPPPPPPPPPPPPPPPPP #!@AR A##'RTIO3# PPPPPPPPPPPPPPPPPPPPPPPPPP%
%P define default cloc9 that will 7e used to sam)le all su7se6uent asserts P%
%P 3OT'D it is im)ortant that data does not change on the same edge as cloc9
7ecause8 li9e +2$8 assertions can 7e sensitive to races P%
%% sugar default cloc9 K =)osedge ah71l9?i>H
%P ehaviorD If reset is active then Transfer T/)e is I2$' and Res) is OBAE
=default cloc9> P%
%% sugar )ro)ert/ IdleAndO9a/2uringReset K alwa/s
%%
L=ah7Resetn?i KK ->H=ah7Resetn?i KK 1>M S*J
%%
L=ah7Trans?i KK I2$'> UU =ah7Res)?i KK OBAE>MH
%P ehaviorD If the transfer t/)e is 3O3#'F and urst Mode is #I3@$'8
then on the ne(t cloc9 c/cle8 the transfer t/)e is not #'F and not !#E
=default cloc9> P%
%% sugar )ro)ert/ us/And#e63ever4ollow3onse6On#ingleTransfer K alwa/s =
%%
=ah7Trans?i KK 3O3#'F> UU =ah7urst?i KK #I3@$' > *J
%%
ne(t ==ah7Trans?i NK #'F> UU =ah7Trans?i NK !#E>> >H
%P ehaviorD If the transfer t/)e is !#E and slave is read/8
then on the ne(t cloc9 c/cle8 the transfer t/)e must not 7e I2$' and
must not 7e 3O3#'F unless grant is - and read/ is 1 =default cloc9> P%
%% sugar )ro)ert/ 3ever@o4romus/ToIdleOr3onse6!nless3o@rant K alwa/s =
%%
==ah7Trans?i KK !#E> UU =ah7Read/?i KK 1>> *J
%%
ne(t ==ah7Trans?i NK I2$'> UU =ah7Trans?i NK 3O3#'F>>
%%
a7ort ==ah7@nt?i KK -> UU =ah7Read/?i KK 1>> SS =ah7Resetn?i KK ->>H
%P ehaviorD if the transfer t/)e is I2$'8
c/cle8 the transfer t/)e must 7e either
%% sugar )ro)ert/ Alwa/s@oTo3onse64romIdle
%%
=ah7Trans?i KK I2$'> *J
%%
ne(t ==ah7Trans?i KK I2$'> SS
then on the ne(t cloc9
I2$' or 3O3#'F =default cloc9>P%
K alwa/s =
=ah7Trans?i KK 3O3#'F>> >H
.
P$AT4ORM APP$I1ATIO3 3OT'
%P ehaviorD if the transfer t/)e is !#E then on the corres)onding
data transfer 8 the slave must )rovide a Aero wait state OBAE res)onse
=default cloc9> P%
%% 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
%P ehaviorD if the transfer t/)e is I2$' then on the corres)onding data
transfer8 the slave must )rovide a Aero wait state OBAE res)onse
=default cloc9> P%
%% sugar )ro)ert/ Res)onseToIdleMusteZero:aitOBAE K alwa/s =
%%
==ah7Trans?i KK I2$'> UU =ah7Read/?i KK 1>> *J
%%
ne(t ==ah7Res)?i KK OBAE> UU =ah7Read/?i KK 1>> >H
%P ehaviorD if the )revious res)onse was OBAE8 and the current res)onse
is not OBAE8 then Read/ must 7e - during the second not OBAE res)onse
=default cloc9> P%
%% sugar )ro)ert/ Read/MusteZero2uring4irst3otO9a/Res)onse K alwa/s
%%
L=ah7Res)?i KK OBAE>H=ah7Res)?i NK OBAE>M S*J
%%
Lah7Read/?i KK -M H
%P ehaviorD if the res)onse is #P$IT or R'TRE8 the master must drive I2$'
=default cloc9> P%
%% sugar )ro)ert/ 4irst3otO9a/Res)onse1auses3e(tIdle K alwa/s =
%%
==ah7Res)?i KK #P$IT> SS =ah7Res)?i KK R'TRE>> UU =ah7Read/?i KK -> *J
%%
ne(t =ah7Trans?i KK I2$'>>H
%P ehaviorD if the transfer t/)e is #'F or !#E8 then the controls of the
corres)onding data transfer must 7e the same as their )revious control
=default cloc9> 3OT'D the e6uivalence o)erator is used with ah7Prot
7ecause this is an o)tional signal and ma/ 7e an [G[ value if not
connected P%
%% sugar )ro)ert/ 1ontrolMuste1onstant2uringAurst K alwa/s =
%%
=ah7Trans?i KK #'F> SS =ah7Trans?i KK !#E> *J
%%
==ah7#iAe?i KK )rev?ah7#iAe> UU =ah7Prot?i KKK )rev?ah7Prot> UU
%%
=ah7:rite?i KK )rev?ah7:rite>> >H
%P ehaviorD if Read/ is - and the res)onse is OB or 'RROR8 the address
and control8 and data from the master are held constant =default cloc9>
3OT'D the e6uivalence o)erator is used with ah7Prot 7ecause this is an
o)tional signal and ma/ 7e an [G[ value if not connected P%
%% sugar )ro)ert/ 1ontrolMuste1onstant:hen#lave3otRead/ 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#iAe?i KK )rev?ah7#iAe> 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
%P ehaviorD if read/ is - and the )revious transfer t/)e was #'F or 3O3#'F8
then 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> P%
%% sugar )ro)ert/ :rite2ataMuste1onstant:hen#lave3otRead/And2ataeingTransferred K alwa/s =
%%
=ah7Read/?i KK -> UU =ah7:rite?i KK 1> UU
%%
==)rev?ah7Trans KK #'F> SS =)rev?ah7Trans KK 3O3#'F>> *J ne(t
%%
=ah7:2ata?i KK )rev?ah7:2ata> >
%%
a7ort =ah7Resetn?i KK ->H
%P ehaviorD if transfer t/)e is !#E then address does not change
=default cloc9> P%
%% sugar )ro)ert/ Addr+eld:henMasterus/ K alwa/s =
%%
=ah7Trans?i KK !#E> *J ne(t =ah7Addr?i KK )rev?ah7Addr> >H
%P ehaviorD if transfer is in )rogress8 then 1B 7oundar/ is not e(ceeded
=default cloc9> P%
%% sugar )ro)ert/ PageAddress3ever'(ceeds19oundar/ K alwa/s =
%%
==ah7Trans?i KK #'F> SS =ah7Trans?i KK !#E>> *J
%%
=ah7Addr?iO31D1-Q KK )rev?ah7AddrO31D1-Q> >H
%P ehaviorD If the 7urst t/)e is not I31R and the transfer t/)e is not
I2$' 8 then the 3um7ereats for the urst Mode is not e(ceeded
=default cloc9> P%
%% sugar )ro)ert/ urstIs3otToo$ong K alwa/s =
%%
=ah7urst?i NK I31R> UU =ah7Trans?i NK I2$'> *J
%%
==ah7urst?i KK #I3@$'> UU =3um7ereats IK 1>> SS
%%
==ah7urst?i KK :RAP"> UU =3um7ereats IK ">> SS
%%
==ah7urst?i KK :RAP0> UU =3um7ereats IK 0>> SS
%%
==ah7urst?i KK :RAP1,> UU =3um7ereats IK 1,>> SS
%%
==ah7urst?i KK I31R"> UU =3um7ereats IK ">> SS
%%
==ah7urst?i KK I31R0> UU =3um7ereats IK 0>> SS
%%
==ah7urst?i KK I31R1,> UU =3um7ereats IK 1,>> >H
%P ehaviorD 4or all 7ut I31R urst mode8 if the end of the )ac9et is 7eing
transferred as indicated 7/ a transition from #'F to I2$' when Res) is o9
then the 3um7ereats for the urst Mode is the ma( num7er unless grant is -
=default cloc9> P%
0
P$AT4ORM APP$I1ATIO3 3OT'
%% sugar )ro)ert/ urstIs3otToo#hort K alwa/s
%%
L==ah7urst?i NK I31R> UU =ah7Res)?i KK OBAE> UU =ah7Trans?i KK #'F>>H
%%
=ah7Trans?i KK I2$'> M S*J
%%
L==)rev?ah7urst KK #I3@$'> UU =3um7ereats KK 1>> SS
%%
==)rev?ah7urst KK :RAP"> UU =3um7ereats KK ">> SS
%%
==)rev?ah7urst KK :RAP0> UU =3um7ereats KK 0>> SS
%%
==)rev?ah7urst KK :RAP1,> UU =3um7ereats KK 1,>> SS
%%
==)rev?ah7urst KK I31R"> UU =3um7ereats KK ">> SS
%%
==)rev?ah7urst KK I31R0> UU =3um7ereats KK 0>> SS
%%
==)rev?ah7urst KK I31R1,> UU =3um7ereats KK 1,>>M
%%
a7ort =ah7@nt?i KK -> H
%P ehaviorD if the transfer t/)e is I2$' 8 then on the ne(t cloc9 c/cle8
the transfer t/)e is not #'F and the transfer t/)e is not !#E
=default cloc9> P%
%% sugar )ro)ert/ 3ever@o4romIdleTo#e6Orus/ K alwa/s =
%%
=ah7Trans?i KK I2$'> *J
%%
ne(t ==ah7Trans?i NK #'F> UU =ah7Trans?i NK !#E>> >H
%P ehaviorD R'TRE is alwa/s asserted for two c/cles unless reset is asserted
=default cloc9>P%
%% sugar )ro)ert/ Retr/Res)onseMustPersistTwo1/cles K alwa/s
%%
L=ah7Res)?i NK R'TRE>H=ah7Res)?i KK R'TRE>M SKJ
%%
L=ah7Res)?i KK R'TRE>M
%%
a7ort =ah7Resetn?i KK ->H
%P ehaviorD #P$IT is alwa/s asserted for two c/cles unless reset is asserted
=default cloc9> P%
%% sugar )ro)ert/ #)litRes)onseMustPersistTwo1/cles K alwa/s
%%
L=ah7Res)?i NK #P$IT>H=ah7Res)?i KK #P$IT>M SKJ
%%
L=ah7Res)?i KK #P$IT>M
%%
a7ort =ah7Resetn?i KK ->H
%P ehaviorD 'RROR is alwa/s asserted for two c/cles unless reset is asserted
=default cloc9> P%
%% sugar )ro)ert/ 'rrorRes)onseMustPersistTwo1/cles K alwa/s
%%
L=ah7Res)?i NK 'RROR>H=ah7Res)?i KK 'RROR>M SKJ
%%
L=ah7Res)?i KK 'RROR>M
%%
a7ort =ah7Resetn?i KK ->H
%PPPPPPP incorrectAddress1alculation for 3 e(am)le :RAP modesD This calculates
whether the ne(t address is correct for all wra) modesPPPPPPP%
%P ehaviorD if urst mode is :RAP" and #iAe is 0 7its8 then if
transfer mode is #'F or !#E8 then if )revious transfer mode is not
7us/ and )revious Read/ is not Aero8 then chec9 that the address is as )redicted P%
%% sugar )ro)ert/ 1orrectAddress2uringPage#iAe"urst:ra) K alwa/s =
%%
==ah7urst?iKK :RAP"> UU =ah7#iAe?i KK 7its0>> *J
%%
==ah7Trans?i KK #'F SS ah7Trans?i KK !#E>> *J
%%
==)rev?ah7Trans NK !#E> UU =)rev?ah7Read/ NK ->> *J
%%
==ah7Addr?iO31D2Q KK )rev?ah7AddrO31D2Q> UU
%%
=ah7Addr?iO1D-Q KK )rev?ah7AddrPlus#iAeO1D-Q>> >H
%% sugar )ro)ert/ 1orrectAddress2uringPage#iAe0urst:ra) K alwa/s =
%%
==ah7urst?iKK :RAP"> UU =ah7#iAe?i KK 7its1,>> SS
%%
==ah7urst?iKK :RAP0> UU =ah7#iAe?i KK 7its0>> *J
%%
==ah7Trans?i KK #'F> SS =ah7Trans?i KK !#E>> *J
%%
==)rev?ah7Trans NK !#E> UU =)rev?ah7Read/ NK ->> *J
%%
==ah7Addr?iO31D3Q KK )rev?ah7AddrO31D3Q> UU
%%
=ah7Addr?iO2D-Q KK )rev?ah7AddrPlus#iAeO2D-Q>> >H
%% sugar )ro)ert/ 1orrectAddress2uringPage#iAe2-"0urst:ra) K alwa/s =
%%
==ah7urst?iKK :RAP1,> UU =ah7#iAe?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?iO31D11Q KK )rev?ah7AddrO31D11Q> UU
%%
=ah7Addr?iO1-D-Q KK )rev?ah7AddrPlus#iAeO1-D-Q>> >H
%P ehaviorD the address must increment 7/ siAe during all I31R 7eats P%
%% sugar )ro)ert/ AddressInc/#iAe2uringAllurstIncreats K alwa/s =
%%
==ah7urst?i KK I31R1,> SS =ah7urst?i KK I31R0> SS
%%
=ah7urst?i KK I31R">> *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#iAe> >H
%P ehaviorD alwa/s address must 7e aligned to the transfer siAe P%
%% sugar )ro)ert/ Address3otAlignedToTransfer#iAe K alwa/s =
%%
==ah7#iAe?i KK 7its0> SS
%%
==ah7#iAe?i KK 7its1,> UU =ah7Addr?iO-Q
KK 1Y7->> SS
%%
==ah7#iAe?i KK 7its32> UU =ah7Addr?iO1D-Q KK 2Y7-->> SS
%%
==ah7#iAe?i KK 7its,"> UU =ah7Addr?iO2D-Q KK 3Y7--->> SS
%%
==ah7#iAe?i KK 7its120> UU =ah7Addr?iO3D-Q KK "Y7---->> SS
%%
==ah7#iAe?i KK 7its2&,> UU =ah7Addr?iO"D-Q KK &Y7----->> SS
%%
==ah7#iAe?i KK 7its&12> UU =ah7Addr?iO&D-Q KK ,Y7------>> SS
%%
==ah7#iAe?i KK 7its1-2"> UU =ah7Addr?iO,D-Q KK .Y7------->> > >H
\
P$AT4ORM APP$I1ATIO3 3OT'
%P ehaviorD alwa/s the ma(imum num7er of wait states is 1, P%
%% sugar )ro)ert/ 3everMoreThan1,:ait#tates K alwa/s
%%
L=ah7Read/?i KK 1>H=ah7Read/?i KK ->M SKJ
%%
LL=ah7Read/?i KK ->OP-..1&QMHLah7Read/?i KK 1MM
%%
a7ort =ah7Res)?i NK OBAE>H
%% s/no)s/s translate?on
endmodule
&.1
TIP# 4OR :RITI3@ A##'RTIO3#
+ere are a few things to remem7er that will hel) /ou to get started with writing assertionsD
1.
2.
3.
".
&.
,.
,
Performance is adversel/ affected 7/ eventualities and 7/ un7ounded re)etition in the right hand side
of the assertion.
Assertions are sensitive to race conditions Cust li9e +2$8 so it will 7e a))ro)riate to evaluate most
assertions relative to
a cloc9.
Eou should avoid using never or not a))lied to an im)lication. The semantics are non*intuitive8
7ecause the
im)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 is
alwa/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+2$ )rocedures are ignored. +owever8 an
assertion can utiliAe a
function as )art of a Verilog or V+2$ e()ression.
Remem7er that assertions are evaluated at ever/ verification c/cle and all are evaluated concurrentl/.
An assertion that
e()resses a se6uence of length 3 can have three concurrent evaluations ongoing simultaneousl/ if the
initial
e()ression remains true for e(tended c/cles. This is ver/ )owerful 7ecause it allows for detection of
overla))ing
conditions.
As /ou will see in the ne(t section8 it is im)ortant to give /our )ro)erties descri)tive names 7ecause the
name is the
message that is )rovided when the assertion fires.
A##'RTIO3 !#' MO2'$ I3 T+' I31I#IV' V'RI4I1ATIO3 P$AT4ORM
This section descri7es how to run a Verilog simulation with assertions and how to de7ug assertion
failures. Most assertions
should 7e ena7led all the time 7ecause the overhead is ver/ low relative to the overall simulation times
and the/ )rovide
tremendous value in isolating the cause of 7ugs. It is not necessar/ to alwa/s )ro7e assertions 7ecause
failures will 7e
re)orted regardless of whether or not the assertion is )ro7ed.
,.1
R!33I3@ A V'RI$O@ #IM!$ATIO3
The first ste) is to com)ile and ela7orate the monitor and test fi(ture. 4igure 2 shows the command
used to com)ile the
monitor and test fi(ture8 and the te(t out)ut that is sent to the terminal. =3oteD all design files and
simulation messages are
not shown.> The ncverilog Rassert directs the com)iler to ena7le assertion )rocessing. :ithout this
com)iler o)tion8
all assertions are ignored. If there are assertions in the design8 and the Rassert com)ile o)tion was
s)ecified8 then the
design hierarch/ will show the num7er of assertions. The simulation is run in command line mode so
there are no
7rea9)oints and the simulator runs to the finish. In the @!I mode8 the default is to 7rea9 on assertion
failures8 which ma9es
the de7ug easier 7ecause /ou can 6uer/ current signal values at the time of failure. Assertion errors are
)rinted 7oth to the
terminal and to the log file. Assertions can also 7e directed to their own log file.
1-
P$AT4ORM APP$I1ATIO3 3OT'
!se Rassert to ena7le com)ilation of
P#$%#ugar assertions.
3ote that the 2esign hierarch/ summar/
shows the num7er of assertions.
The assertion failure message is
)rinted to the console and the log
file. The name of the assertion
and the time of failure are
)rovided.
4igure 2. Running a Verilog #imulation with Assertions
11
P$AT4ORM APP$I1ATIO3 3OT'
,.2
2'!@@I3@ A##'RTIO3 4AI$!R'#
In general8 for de7ug8 /ou want to use RaccessRwrc to ela7orate the design so /ou can see all signals.
4igure 3 shows the
waveform that is generated when the test case is run. All in)ut signals were )ro7ed and all the
assertions were )ro7ed to
one event counter. 3otice that this event counter has a red ( an/time a failure of an/ of the assertions
occurs. Eou can
determine which assertion failed 7/ selecting the )ro7e name8 then )lacing the curser on the ( and
choosing the '()lore]
@oTo]1ause menu command. This will o)en the source 7rowser with a )ointer to the location of the
assertion definition8 as
shown in 4igure ". Placing /our curser over a signal or varia7le name will show the current value of
that signal or varia7le. If
multi)le assertions fail8 use the View]'()and #e6uence menu command to select onl/ one assertion
at a time.
4igure " #imulation :aveform #hown with all Assertions Pro7ed to One 'vent 1ounter.
4igure 3 #imulation :aveform #hown with all Assertions Pro7ed to One 'vent 1ounter.
12
P$AT4ORM APP$I1ATIO3 3OT'
Assertion rowser icon
4igure " #ource rowser Points to the 2efinition of the 4ailing Assertion
To de7ug /our assertions in the @!I without using waveforms invo9e the assertion 7rowser 7/
selecting the 7utton with the
assertion 7rowser icon or through the menuD :indows *J 3ew *J Assertion rowser. The assertion
7rowser shows a listing
of all assertions in the design. The colors reflect the 1urrent #tate. :hen an assertion fails8 it is eas/ to
identif/ 7/ the color
red. Another wa/ to locate an assertion is to use the filtering at the 7ottom. Assertions can also 7e
sorted 7/ clic9ing on an/
column heading.
1adence5s im)lementation of assertion*7ased verification defines four statesD 7egun8 finished8 inactive8
and
failed. The assertion is 7egun when the first se6uence of the ena7ling condition is satisfied8 and remains
7egun until the
assertion goes inactive8 finishes or fails. The failed state indicates that the fulfilling condition for an
assertion has
evaluated to false. The finished state indicates that the fulfilling condition for an assertion has evaluated
to true. The
inactive state is when the assertion has not 7egun8 and did not fail or finish during the currect cloc9
c/cle. The assertion
statistics )rovide some feel for what the simulation vectors have e(ercised8 7ut inter)retation can 7e
tric9/ due to
overla))ing conditions. A summar/ of statistics is )rovided for all assertions at the to)8 and for those
dis)la/ed =filtered> at
the 7ottom of the window.
Eou can dou7le clic9 on an/ assertion in the Assertion rowser and it will ta9e /ou to the assertion
definition in the source
7rowser. To de7ug a failed assertion8 dou7le clic9 on the failed assertion to view the source. The source
7rowser shows the
definition of the failed assertion8 e(actl/ as shown in 4igure " a7ove. :hen /ou run in @!I mode and
use the default 7rea9
on assertion failure8 /ou can )lace the cursor over the terms of the fulfilling condition of the assertion
definition to determine
what fired the assertion. This )rovides the current values onl/. Eou will not 7e a7le to see se6uence
values from )revious
simulation time ste)s.
13
P$AT4ORM APP$I1ATIO3 3OT'
4igure & Assertion rowser shows Assertion #tatistics
.
#!MMARE
Assertions within a design sim)lif/ the detection and diagnosis of errors 7/ ma9ing internal test )oints
visi7le when an error
is detected. Assertions document the designer5s assum)tions and e()ected 7ehavior in a standardiAed
wa/ that is tested
and travels with the design8 which is invalua7le to an/ designer who must maintain or e(tend the code
in the future.
This document has )rovided an overview of the Incisive verification )latform5s im)lementation of
assertion 7ased
verification8 including the language su))orted8 e(am)le assertions8 and the Verilog simulation use
model. Additional
information is availa7le in the #imulation*ased Assertion 1hec9ing @uide in 1adence documentation.
0
1.
2.
3.
".
&.
R'4'R'31'#
#imulation*ased Assertions Verification Tutorial ^ 1adence 2ocumentation
#imulation*ased Assertion 1hec9ing @uide ^ 1adence 2ocumentation
#ugar 2.- 2efinition8 March 2-8 2--2.
htt)D%%www.haifa.il.i7m.com%)roCects%verification%sugar%literature.html
Accellera Pro)ert/ #)ecification $anguage Reference Manual. _anuar/ 318 2--3.
htt)D%%www.eda.org%vfv%docs%)sl?lrm*
1.-.)df
AMA A+ s)ecificationD www.arm.com%armtech%AMA?#)ecWO)en2ocument
1"
P$AT4ORM APP$I1ATIO3 3OT'