1. Introduction to Cindy Eisner Formal Methods Group IBM Haifa Research Laboratory February 2001 Copyright 2001 IBM Haifa Research Laboratory

2. Introduction to RuleBase2 Overview - day 1 What is functional formal verification? Model checking Sugar (basics) EDL (basics) Exercise: a simple arbiter

3. Day 1

4. Introduction to RuleBase4 What is verification? Verification is making sure that: what you designed is what you specified functional verification what you sent to manufacturing is what you designed equivalence checking what was manufactured is what you sent to manufacturing production testing specification VHDL/Verilog transistors silicon

5. Introduction to RuleBase5 Formal verification Prove mathematically that a design obeys its specification Contrast to simulation: Formal verificationSimulation all legal input sequences(large) set of particular cases correctness expressed as correctness usually expressed per set of general propertiesrun (expected results) Methods: theorem proving, model checking

6. Introduction to RuleBase6 Model checking A method for formal functional verification Any piece of sequential random logic is a (very large) state machine, so: View design as a finite state machine Traverse the state machine to determine the truth or falsity of a specification Provide a trace showing a counter-example (if false)

7. Introduction to RuleBase7 Model checking (continued) “if a request is received, it will be processed within 3 clocks” first, we need a language in which to express properties

8. Introduction to RuleBase8 Sugar - introduction Extension of the branching time temporal logic CTL Unwind state graph to obtain infinite computation tree Reason about (infinite) paths in the computation tree FSMInfinite Computation Tree

9. Introduction to RuleBase9 CTL Path quantifiers A - for all paths E - there exists a path Tense Operators Xp- p holds at the next cycle Fp- p holds sometime in the future Gp- p holds globally from the present time p U q- p holds until q holds Temporal Operators AX, AF, AG, AU, EX, EF, EG, EU

10. Introduction to RuleBase10 AX p

11. Introduction to RuleBase11 AF p

12. Introduction to RuleBase12 AG p (exercise) Complete the figure below

13. Introduction to RuleBase13 A[p U q] (exercise) Complete the figure below (use different colors for p and q)

14. Introduction to RuleBase14 EX p (exercise) Complete the figure below

15. Introduction to RuleBase15 EF p (exercise) Complete the figure below

16. Introduction to RuleBase16 EG p

17. Introduction to RuleBase17 E[p U q] (exercise) Complete the figure below (use different colors for p and q)

18. Introduction to RuleBase18 AG AF p

19. Introduction to RuleBase19 Boolean operators &- and |- or !- not ->- implies

20. Introduction to RuleBase20 CTL (exercise) Express in CTL: “if a request is received, it will be processed within 3 clocks” _______________________________

21. Introduction to RuleBase21 CTL (more exercises) “read_en and write_en are mutually exclusive” _________________________________________ “two consecutive grants are not allowed” _________________________________________ “every request will eventually receive a grant” _________________________________________ “whenever a request is issued, signal request will stay asserted until a grant is received” _________________________________________

22. Introduction to RuleBase22 Sugar - syntactic sugaring of CTL AW, EW AX[i] ABG[i..j], ABF[i..j] f until! g, f until g f before! g, f before g next_event!(b)(f), next_event(b)(f), next_event!(b)[i](f), next_event(b)[i](f)

23. Introduction to RuleBase23 Sugar - additional boolean operators ^, xor, !=- logical xor (not equals), =- logical xnor (equals)

24. Introduction to RuleBase24 Sugar (exercises) “if a request is received, it will be processed within 3 clocks” __________________________________________ “if a request is received, it will be processed on the 3rd clock” __________________________________________ “between two requests, there must be an ack” __________________________________________ “whenever read is asserted, read_en must be asserted” __________________________________________

25. Introduction to RuleBase25 Sugar (more exercises) “done is a pulsed signal (i.e., it is never asserted for two consecutive cycles)” __________________________________________ “if there is an error indication, it will remain active forever” __________________________________________ “if grant is asserted, and there is no retry the next cycle, busy must be asserted two cycles after the grant” __________________________________________

26. Introduction to RuleBase26 Vacuity AG (req -> AX (ack -> AF grant)) when is this formula meaningless? solution: vacuity check if formula is false:counter-example if formula is true: witness if formula is vacuous: vacuous pass

27. Introduction to RuleBase27 Environment

28. Introduction to RuleBase28 EDL - overview var req: boolean; assign init(req) := 0; assign next(req) := if busy then 0 else {0,1} endif; var cmd: {READ, WRITE, NOP}; define read_req := req & cmd=READ;

29. Introduction to RuleBase29 EDL - constants and variables Numeric constants: –decimal (1276), binary (1011B), hex (7FFFH) Enumerated constants: –var state: {idle, st1, st2, st3, waiting}; Variable reference: –name-- simple variable/signal –name(i)-- one bit of array –name(i..j)-- a range of bits

30. Introduction to RuleBase30 EDL - expressions Boolean connectives: & | ! ^ Relational operators: = != < <= > >=

31. Introduction to RuleBase31 EDL - expressions (continued) Arithmetic: + - * / mod Non-deterministic choice: {read, write, nop} i..j - equivalent to {i, i+1, …, j}

32. Introduction to RuleBase32 EDL - variable declarations var name1, name2, name3 : type; type is one of: boolean {enum1, enum2, …, enumN} i.. j examples: var read, write : boolean; var state : {idle, read, write, hold} var counter {1,2,3,4,5} var length 4..10

33. Introduction to RuleBase33 EDL - the assign statement assign init(sig1) := expression; assign next(sig1) := expression; assign sig2 := expression; init/next - memory element assign “simple” - combinational element init omitted for a memory element: begins unspecified (any legal value) next omitted for a memory element: can change to any legal value at any moment

34. Introduction to RuleBase34 EDL - if expression Syntax: sig := if condition then expr else expr endif; Example: assign a := if reset then 0 else b endif;

35. Introduction to RuleBase35 EDL - case expression Syntax: sig := case condition1 : expr1 ; condition2 : expr2 ;... else : exprN+1 ; esac else is not mandatory, but if you "fall" into esac the value is undefined

36. Introduction to RuleBase36 EDL - additional operators expr in {e1, e2,..., eN} equivalent to expr=e1 | expr=e2 |... | expr=eN fell(expr) expr was 1 and became 0 rose(expr) expr was 0 and became 1 prev(expr)value of expr in the last cycle

37. Introduction to RuleBase37 EDL - define statement Syntax: define sig1 := expression1; sig2 := expression2;... define’d signals are combinational signals don't use define with non-deterministic expressions (unless you know what you are doing.......) Examples: define selected_c := select & c1 | !selected & c2; define cc := 3;

38. Introduction to RuleBase38 EDL - exercises sticky_bit: if rises, it stays active forever. __________________________________________ req: may rise at any cycle. when rises, it must remain active until (including) the cycle in which gnt is active. __________________________________________ reset: active for 6 cycles. Then inactive forever. __________________________________________ data: an integer of range 0 to 7, stable while data_ready (a boolean signal) is active, and have non-deterministic value elsewhere. __________________________________________

39. Introduction to RuleBase39 EDL - more exercises model control of a cyclic fifo of depth 16 inputs: –put - data is read in –get - data is written out outputs: full and empty put and get can come together put/get cannot come when the fifo is full/empty ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________

40. Introduction to RuleBase40 EDL - arrays declaration: var name ( index1.. index2 ) : type ; actually declares name(index1),..., name(index2) index1 can be either greater or less than index2 examples: var addr(0..7) : boolean; counter(4..5) : 0..3; status(0..3) : {empty, notempty, full };

41. Introduction to RuleBase41 EDL - array operations := = != & | ^ ! -> -- boolean arrays only > >= < <=-- boolean arrays only + - *-- boolean arrays only (beware of *) >> <<-- boolean arrays only rhs is constant or integer

42. Introduction to RuleBase42 EDL - more array operations ++-- concatenate bits or sub-vectors zeroes(n)-- 0++0++... ++0 n times ones(n)-- 1++1++... ++1 n times nondets(n)-- {0,1}++... ++{0,1} n times rep(expr,n)-- expr++... ++ expr n times itobv(i)-- convert integer expr to bit vector bvtoi(vec(i..j))-- convert bit vector to integer expr no need for itobv with numeric constants

43. Introduction to RuleBase43 EDL - array examples var a(0..2), b(0..8), c(7..0) : boolean; define f(0..2) := b(2..0) & c(5..7); assign next( a(0..2) ) := case reset : 0; a(0..2) > b(0..2) : c(1..3); a(0..1) = 10B : d(0..2); else : a(0..2); esac; var counter(0..7) : boolean; assign init ( counter(0..7) ) := 0; next( counter(0..7) ) := counter(0..7) + 1;

44. Introduction to RuleBase44 EDL - more array examples assign co++sum(0..15) := 0++op1(0..15) + 0++op2(0..15); prod(0..7) := zeroes(4)++op1(0..3) * zeroes(4)++op2(0..3); var cmd(0..4): boolean; assign cmd(0..4) := {5, 7, 13}; var cmd(0..4): {5, 7, 13}; -- totally different

45. Introduction to RuleBase45 EDL- array exercise cmd_lt(0..2) should be equal to the value of cmd(0..2) the previous cycle ________________________________ ________________________________ ________________________________

46. Introduction to RuleBase46 EDL - another array exercise cmd(0..2) can be one of read(101), write(010), sync(011), or idle(000). The command must be stable until (including) gnt is asserted. The cycle after gnt, cmd must be 0. gnt is a pulse. ________________________________ ________________________________ ________________________________

47. Introduction to RuleBase47 EDL - %for %for i in 0..3 do define aa(i) := i > 2; define bb%{ii} := i > 2; %end is equivalent to: define aa(0) := 0>2;define bb0 := 0>2; define aa(1) := 1>2; define bb1 := 1>2; define aa(2) := 2>2; define bb2 := 2>2; define aa(3) := 3>2;define bb3 := 3>2;

48. Introduction to RuleBase48 EDL - %for example define parity := %for i in 0..15 do data(i) ^ %end 0;

49. Introduction to RuleBase49 EDL - clocks In a one clock design, declare the clock to be a constant 1: define clk := 1; For multiple synchronous clocks, declare the fastest clock to be a constant 1, others to be a function of it

50. Introduction to RuleBase50 EDL -resets Designs with reset signal: var reset_counter : 0..4; assign init(reset_counter) := 0; next(reset_counter) := if reset_counter=4 then 4 else reset_counter+1 endif; define RESET := reset_counter != 4; Designs with initial values don't need reset

51. Introduction to RuleBase51 EDL - exercises from the time data_en is asserted until one cycle after it, data should be stable, elsewhere it can change. ________________________________ ________________________________ ________________________________ ________________________________ ________________________________

52. Introduction to RuleBase52 EDL - more exercises config_reg: a 3-bit array variable that chooses a value from 0 through 5 and remains with it forever. ____________________________________ ____________________________ sticky_bit: may rise randomly and stay active forever. ________________________________

53. Introduction to RuleBase53 RuleBase exercise 1 Copy directory exercise1 from $RBEXERCISES/exercise1 See file README

54. Day 2

55. Introduction to RuleBase55 Overview - day 2 More Sugar Fairness More EDL Size problems (basics) Managing multiple environments RuleBase options Design for formal verification Exercise - a simple buffer

56. Introduction to RuleBase56 Sugar - safety vs. liveness Safety: nothing bad ever happens AG, AX, AW, ABG, ABF, until, before, next_event Liveness: something good eventually happens AF, AU, until!, before!, next_event! Safety is easier to verify than liveness Safety on-the-fly, liveness on-the-fly

57. Introduction to RuleBase57 Sugar - sequences {e0,e1,e2,...}(f) f must hold on the last cycle of all computations that agree with the sequence e0 at cycle 0, e1 at cycle 1, e2 at cycle 2, etc. Example: ”every req on cycle X that gets a gnt at cycle X+1 and doesn't get retried at cycle X+2, should cause busy to be active at cycle X+2" AG {req,gnt,!retry}(busy)

58. Introduction to RuleBase58 Sugar - sequence operators e1,e2e1, then e2 (e2 starts the cycle after e1 completes) e1~e2e1, then e2 (e2 starts the same cycle that e1 completes) e1||e2either e1 occurs, or e2 occurs e1&&e2both e1 and e2 occur e1[*]e1 occurs 0 or more times e1[+]e1 occurs 1 or more times

59. Introduction to RuleBase59 Sugar - more sequence operators e1[i]e1 occurs i times e1[i..j]e1 occurs at least i but not more than j times e1[i..]e1 occurs i or more times e1[..j]e1 occurs no more than j times [*],[+], etc.abbreviate true[*], true[+], etc. b[=j]a sequence in which b occurs i times b[>j], b[>=j], b[ j, =j, <k], etc.

60. Introduction to RuleBase60 Sugar - sequence examples “an urgent request must be served within the next five (not necessarily consecutive) scrolls AG {urgent_req,{scroll[>5] && serve_urgent[=0]}}(false) “if there is a request and one cycle after there is either read and no cancel_read until done, or write and no cancel_write until done, then ok is asserted with done” AG {request,{read,!cancel_read[*],done}|| {write,!cancel_write[*],done}}(ok)

61. Introduction to RuleBase61 Sugar - more sequences {p, q} -> {s[*], t}! {p, q} -> {s[*], t} A sequence matching the left-hand side must be followed by a sequence matching the right-hand side The strong version (!) must reach its end (in example above, t must eventually occur) The weak version is not required to reach its end (in example above, s may hold forever)

62. Introduction to RuleBase62 Sugar - sequence exercises “Whenever a read request is followed on the next cycle by an ack, then eventually we expect to see a grant followed by a read data cycle __________________________________________ “Whenever signal get is asserted and tag has the value 1, then the next time that signal get is asserted, tag will have the value 2. However, it is not required that there be such a next time.” __________________________________________

63. Introduction to RuleBase63 Sugar - more exercises “whenever a high priority request is received, then one of the next two grants must be to a high priority requestor” __________________________________________ __________________________________________ “every transaction must complete, and within every transaction, a full data transfer must occur” __________________________________________ __________________________________________

64. Introduction to RuleBase64 Sugar - more exercises “a sequence beginning with the assertion of signal start, and containing eight not necessarily consecutive assertions of signal get, during which kill is not asserted, must be followed by a sequence containing eight assertions of signal put before signal end can be asserted” __________________________________________ __________________________________________ __________________________________________

65. Introduction to RuleBase65 Fairness Design under verification req ack start done idle busy gen done !start start done start problem - the env model can stay in state busy forever

66. Introduction to RuleBase66 Fairness (continued) fairness is used to filter out paths from the environment Syntax: fairness expr; requires that expr occur an infinite number of times

67. Introduction to RuleBase67 Fairness (continued) idle busy gen done !start start done start Be careful with fairness! What is wrong with the following? fairness state=gen_done;

68. Introduction to RuleBase68 Fairness (continued) idle busy gen done !start start done start What is the correct fairness constraint? ____________________________________

69. Introduction to RuleBase69 EDL - modules module proc(gnt)(req, cmd) { var req: boolean; var cmd: {read, write, nop}; assign init(req) := 0; assign next(req) := if gnt then {0,1} else 0 endif; } instance proc1: proc(gnt1)(req1, cmd1); instance proc2: proc(gnt2)(req2, cmd2);

70. Introduction to RuleBase70 EDL - processes process { var a: boolean; a := 0; if (b | c) a := 1; }

71. Introduction to RuleBase71 EDL - assign vs. define assign requires a state variable define is “for free”

72. Introduction to RuleBase72 EDL - invariants Syntax: invar expr; restricts the analysis to states in which expr holds can be used to model the environment or to (over) restrict the design

73. Introduction to RuleBase73 EDL - invariant example Suppose the environment must supply a read request, or a write request, but never both: var read_req, write_req: boolean; assign write_req := if read_req then 0 else {0,1} endif; a simpler way using invariants: var read_req, write_req: boolean; invar !(read_req & write_req);

74. Introduction to RuleBase74 Size problems - strategies (over) restrict the environment: define pipeline_enable := 0; design overrides: var override internal_sig1: boolean; define override internal_sig2 := 0; var override internal_sig3: boolean; assign init(internal_sig3) := …; assign next(internal_sig3) := …;

75. Introduction to RuleBase75 Size problems - strategies (continued) Safety on-the-fly BDD reordering –enabling –configuring –toggling –bdd order pool

76. Introduction to RuleBase76 Managing multiple environments foo (1) lowest priority define override foo := …;(2) mode read_only { define override foo := …; } rule read_only_no_pipeline { envs read_only; (3) define override foo := …;(4) highest priority }

77. RuleBase options

78. Introduction to RuleBase78 Design for Formal Verification Control works well under model checking, datapath doesn’t: –Separate control from datapath! –Also separate control from address path, bookkeeping code

79. Introduction to RuleBase79 RuleBase exercise 2 Copy directory exercise2 from $ $RBEXERCISES/exercise2 See file README

80. Introduction to RuleBase80 RuleBase exercise 3 Copy directory exercise3 from $ $RBEXERCISES/exercise3 See file README