Assertions

1. Assertions Jean-Michel Chabloz

2. Assertions basic Idea • We assert that a certain “thing” should be true. • If it is true, fine • If it is false, then we get an error/warning/etc. • Pieces of code that continuously inspect the waveforms and signal whenever they find something strange

3. SVA • SVA stands for System Verilog Assertions • it is almost an independent language, often taught as stand-alone. • 150 pages of the LRM (CRSG and functional coverage are around 50 pages each)

4. Immediate assertions • are found inside procedural code: initial begin … assert(a==10) else $info(“a is not 10”); … end • We could do the same check with an “if” • The only advantages are: • we can give a name to the assertion, so we can deactivate it, monitor it, etc. • it can be inserted into RTL code, the synthesizer will automatically ignore it (it will not ignore an “if”) • Immediate assertions are found also in VHDL • Bottom line: nothing special

5. Concurrent Assertions • This is the powerful stuff. It allows us to do complex checks across many clock cycles. • has the keyword “property” • From now on in this lecture we use assertions as synonym of concurrent assertions • Example: checkOnReq: assert property (@(negedge clk) req |-> ##2 !req ##1 valid==1) else $error(“error found”);

6. Failure action In an assertion we specify what to do when the assertion fails, because that’s what interests us. checkOnReq: assert property (@(negedge clk) req |-> ##2 !req ##1 valid==1) else $error(“error found”); • we could write also what to do when the assertion succeeds, but normally this is not done because we are interested in the assertion failures only. • from now on in these slides we abbreviate • a.p. (req |-> ##2 !req ##1 valid==1) • for • assert property (@(negedge clk) req |-> ##1 !req ##1 valid==1)

7. Severity level assert property (…) else • $fatal(“…”); • close the simulation, the error was so bad that it is worthless to continue • $error(“…”); • stop the simulation – the user might continue if he so wishes • $warning(“…”); • like error, but can be disabled • $info(“…”); • just print a message to the console without stopping the simulation, this was not a real error, just want to print some info for us

8. Single-cycle assertions • Assertions that complete in a single cycle, no implication. • assert property (@(negedge clk) cond) • if cond is false the assertion fails • variable a should never be 3 • assert property (@(negedge clk) a!=3) • the value of a is checked on every negative edge of the clock • If ever a becomes 3 during the simulation the assertion will fail

9. Implication in Single-Cycle assertions • If a is one then b must be one • assert property (@(negedge clk) a |-> b) • Any alternatives?

10. Implication in Single-Cycle assertions • If a is one then b must be one • assert property (@(negedge clk) a |-> b) • Alternatives: accepted (a,b)=(0,0),(0,1),(1,1) • a.p. (!(a & !b)) • a.p. (!a | b) • a.p. (!b |-> !a)

11. Writing assertions • Often writing assertions consists in translating the rules in the specs from english to SVA. • Pay attention to all the words

12. Implication in Single-Cycle assertions • if cond2, then cond1 must be true • a.p. (cond2 |-> cond1) • cond1 can be true only if cond2 • a.p. (cond1 |-> cond2) • a.p. (!cond2 |-> !cond1); • If cond2, then cond1 can be true • same as the last example

13. Multicycle Assertions • a.p.(a==2 ##1 a==4) • a: 2 4 2 2 4 • c: 0 1 2 3 4 • one evaluation attempt is started in every cycle: the assertion fails as soon as it is determined that it cannot match. • In cycle 0: matches at 1 • In cycle 1: fails at 1 • at 1 we know the assertion will never match • In cycle 2: fails at 3 • at 2 we think the assertion may match • at 3 we realize we were wrong • In cycle 3: matches at 4

14. Multicycle assertions • We normally want to write assertions that are triggered by something • a.p.(req |-> ##1 grant) • one evaluation attempt is started in every cycle • if the enabling condition is false, then the attempt is aborted (no failure) • if the enabling condition matches, then we check if what is right of the implication matches

15. Overlapped and non-overlapped implication • |-> what is right must start in the same cycle as what is left ends • |=> what is right must start one cycle after what is left ends • equivalent to: |-> ##1

16. sampled functions • $rose(a): a is one and was zero in the past cycle • $fell(a): a is zero and was one in the past cycle • $stable(a): a has the same value as in the past cycle • $past(a): the value that a had in the past cycle • $past(a,7): the value that a had 7 cycles ago

17. sampled functions • a 0010111101000011001 • $rose(a) 0010100001000010001 • $fell(a) ?001000010100000100 • $stable(a) ?100011100011101010 • $past(a) ?001011110100001100 • $past(a,2) ??00101111010000110

18. Common error • check that grant rises three cycles after a request is issued • g: 0 0 0 0 0 0 0 1 1 1 • r: 0 0 0 0 1 1 1 1 1 1 • c: 0 1 2 3 4 5 6 7 8 9 • a.p. (r |-> ##3 $rose(g)) // wrong • the assertion will abort immediately at 0,1,2,3 because the enabling condition doesn’t match • the enabling condition matches at 4, 5, 6, 7… • The attempt started at 4 matches at 7 • All other attempts (5, 6, 7, …) fail

19. Common error • Grant rises three cycles after a request is issued • g: 0 0 0 0 0 0 0 1 1 1 • r: 0 0 0 0 1 1 1 1 1 1 • c: 0 1 2 3 4 5 6 7 8 9 • a.p. ($rose(r) |-> ##3 $rose(g)) //good • the assertion will abort immediately at 0,1,2,3,5,6,7,… because the enabling condition doesn’t match • the enabling condition matches at 4 • The attempt started at 4 matches at 7 • No failure

20. sequence in the enabling condition • a.p.(a ##1 !a ##1 a |-> ##1 grant ##1 !grant) • c: 0 1 2 3 4 5 6 7 8 9 • a: 0 1 0 1 0 1 0 0 0 1 • g: 0 0 0 0 1 0 0 0 1 0 • e.a. started at 0: aborted at 0 • e.a. started at 1: matches at 5 • e.a. started at 2: aborted at 2 • e.a. started at 3: fails at 6 (en.cond. matched) • e.a. started at 4: aborted at 4 • e.a. started at 5: aborted at 7

21. or • At least one between two or more sequences match • the sequence matches at all times in which at least one of the two sequences matches • example: a.p. ($rose(r) |-> (##1 !r) or (##1 g ##1 !g)) • the assertion will match as soon as it is determined that at least one of the two ORed sequences matches

22. or • a.p. (a ##1 !a ##1 a) or (a##1 !a ##1 !a ##1 a) • will match both 101 and 1001 • alternative syntax: • (a ##1 !a [*1:2] ##1 a)

23. or • (a ##1 !a [*1:$] ##1 a) • matches both 101, 1001, 10001, 100001, etc. • (a ##1 !a [*0:$] ##1 a) • matches both 11, 101, 1001, 10001, etc.

24. and • Both sequences should match • Example: • $rose(r) |-> (!g [*2:$] ##1 g) and (r [*2:$] ##1 !r) • If request rose, then grant should be zero for at least two cycles and then go to one; r should remain one for at least two cycles and then go to zero • e.a. started at 1 will succeed (at 6) in the following waveforms (grant sequence matches at 4, req sequence matches at 6) • c: 0 1 2 3 4 5 6 7 8 9 • r: 0 1 1 1 1 1 0 0 0 0 • g: 0 0 0 0 1 1 1 1 1 1

25. intersect • Both sequences should match at the same time • Example: • $rose(r) |-> (!g [*2:$] ##1 g) intersect (r [*2:$] ##1 !r) • If request rose, then grant should be zero for at least two cycles and then go to one; r should remain one for at least two cycles and then go to zero; the time at which r drops must be the time at which g rises. • e.a. started at 1 will fail (at 4) in the following waveforms (grant sequence matches at 4, req sequence matches at 5, at 4 it is determined that the two cannot match in the same cycle) • c: 0 1 2 3 4 5 6 7 8 9 • r: 0 1 1 1 1 1 0 0 0 0 • g: 0 0 0 0 1 1 1 1 1 1

26. ORed enabling sequences • When a certain sequence happens, then some other sequence should start • a ##1 !a [*0:$] ##1 b |-> c ##1 [*0:$] ##1 d • The sequence after the implication must match every time the enabling sequence matches • One evaluation attempt can result into two or more matches of the enabling condition at different times, the sequence after the implication should match for all of them

27. ORed enabling sequences • Normally you want to have enabling sequences that match only once – that doesn’t mean they can’t be ORed • Typical example: check that the first time a rises after reset, cond1 is satisfied • $rose(reset) ##1 !a [*0:$] ##1 a |-> cond1 • will match only once

28. ORed enabling sequences • sequence that match on the first occurrence of a == 1 after b was 1 • b ##1 !a [*0:$] ##1 a • c: 0 1 2 3 4 5 6 7 8 9 • b: 0 1 0 0 0 0 1 0 0 0 • a: 0 0 0 1 0 1 0 1 1 0 • The evaluation attempt started at 1 matches only at 3, not at 5, 7, 8 • The evaluation attempt started at 6 matches only at 7, not at 8 • all other evaluation attempts fail as soon as they start because b is not 1

29. range delay operator • There is also the operator ##[1:4] - equivalent to ##1 or ##2 or ##3 or ##4 • Can use the $: ##[1:$] • Easy to make mistakes with it: • c: 0 1 2 3 4 5 6 7 8 9 • b: 0 1 0 0 0 0 0 0 0 0 • a: 0 0 0 1 0 1 0 1 1 0 • b ##[1:$] a |-> cond1 • The evaluation attempt started at 1 will fail if condition 1 is false at 3, 5, 7, 8… every time a is 1 after a single issuing of b. After b has become one, the enabling condition will match every time a is one. • b ##1 !a [*0:$] ##1 a |-> cond1 is different – The evaluation attempt started at 1 will fail if condition 1 is false at 3 (first occurrence of a==1 after b). It will not fail if cond1 is false at 5, 7, 8. • Recommendation: do not use ##[n:m]– easy to make mistakes with it

30. Evaluation attempts • With concurrent assertions, one evaluation attempt is started in every cycle • An evaluation attempt will be aborted as soon as it is determined that the evaluation condition cannot match • The sequence at the right of the implication sign must match for all cycles in which the enabling condition matches • As soon as it is determined that it is so, the evaluation attempt succeeds • As soon as it is determined that it is not so, the evaluation attempt fails

31. Evaluation attempts • Three possible outcomes: • aborted • failed • matched • By probing the assertions as transactions, we can see on the waveforms all evaluation attempts: when they start and when they match or fail.

32. Stand-alone sequences • Sometimes it is efficient to define stand-alone sequences • sequence s1; • ##1 b [*0:$] ##1 b; • endsequence • sequence s2; • $fell(b) ##1 !b ##1 b; • endsequence • We can then write • a.p. (s1 |-> ##2 s2) • a.p. (a==0 |=> s1 or s2) • a.p. (s1 ##1 s2 |-> a==5) • 1.p. (s1 and s2 |=> b==1 ##1 b==0) • etc. etc. • Good for code reuse and for keeping a good coding style

33. Internal variables • The other big advantage of sequences is that they can have local variables • sequence s1; • int cnt; • (a==1, b=cnt) ##1 !a [*0:$] ##1 (a && b==cnt+1); • endsequence • the sequence corresponds to: if a is 1, save the value of b in cnt, then wait until a rises again and check that b is equal to cnt+1; • In other words: every time that a is 1, b must be one more compared to the last time a was 1

34. Internal variables • If a is one, then the next time a is one the value of b should be equal to the value that b had the last time a was one, plus one • a.p. (a |-> s1) • sequence s1; • int cnt; • (1, cnt=b) ##1 !a *[0:$] ##1 (a & b==cnt+1); • endsequence • since in the sequence we want to record the value cnt every time a is one, we don’t have a condition. But we cannot write • cnt=b ##1 !a *[0:... • We always need a condition, in case there is no condition then use the trivial condition “1” • You can have multiple assignments: • (1, cnt=b, cnt2=c) • Can even have function calls and $display – useful for debugging – example ##1 (a==1, $display(cnt))

35. throughout • Often the assertions take the form: • after r is one, then r will go to zero and remain at zero for at least one cycle cycles, then it will raise. Check that cond1 is true for all the cycles in which r is zero • a.p. (r |-> ##1 !r [*1:$] ##1 r) is the assertion that checks that r goes to zero for at least one cycle and then rises.

36. throughout • a.p. (r |-> cond1 throughout (##1 !r [*1:$] ##1 r)) • checks that cond1 is true from the cycle in which r is one to the next cycle in which r is one included

37. throughout • a.p. (r |-> ##1 (cond1 throughout (!r [*1:$] ##1 r))) • checks that cond1 is true from the cycle in which r goes to zero to the next cycle in which r is one included

38. throughout • a.p. (r |-> ##1 (cond1 throughout (!r [*1:$])) ##1 r) • checks that cond1 is true during all the cycles during which r is zero

39. Finishing a simulation with assertions on • When finishing a simulation with $finish, all evaluation attempts of the assertions for which the enabling condition has already met fail (the implied sequence will not match because the simulation is ended) • Good to add $assertkill before $finish, this kills all ongoing evaluation attempts.