Introduction to Cindy Eisner Formal Methods Group IBM
Introduction to Cindy Eisner Formal Methods Group IBM Haifa Research Laboratory February 2001 Copyright 2001 IBM Haifa Research Laboratory Introduction to Rule. Base
Overview - day 1 • • • What is functional formal verification? Model checking Sugar (basics) EDL (basics) Exercise: a simple arbiter Introduction to Rule. Base 2
Day 1 Introduction to Rule. Base
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 Introduction to Rule. Base 4
Formal verification • Prove mathematically that a design obeys its specification • Contrast to simulation: Formal verification Simulation all legal input sequences correctness expressed as set of general properties (large) set of particular cases correctness usually expressed per run (expected results) • Methods: theorem proving, model checking Introduction to Rule. Base 5
Model checking • A method 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) Introduction to Rule. Base 6
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 Introduction to Rule. Base 7
Sugar - introduction • Extension of the branching time temporal logic CTL • Unwind state graph to obtain infinite computation tree FSM Infinite Computation Tree • Reason about (infinite) paths in the computation tree Introduction to Rule. Base 8
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. Uq - p holds until q holds • Temporal Operators AX, AF, AG, AU, EX, EF, EG, EU Introduction to Rule. Base 9
AX p Introduction to Rule. Base 10
AF p Introduction to Rule. Base 11
AG p (exercise) Complete the figure below Introduction to Rule. Base 12
A[p U q] (exercise) Complete the figure below (use different colors for p and q) Introduction to Rule. Base 13
EX p (exercise) Complete the figure below Introduction to Rule. Base 14
EF p (exercise) Complete the figure below Introduction to Rule. Base 15
EG p Introduction to Rule. Base 16
E[p U q] (exercise) Complete the figure below (use different colors for p and q) Introduction to Rule. Base 17
AG AF p Introduction to Rule. Base 18
Boolean operators • • & | ! -> - and - or - not - implies Introduction to Rule. Base 19
CTL (exercise) • Express in CTL: “if a request is received, it will be processed within 3 clocks” ________________ Introduction to Rule. Base 20
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” _____________________ Introduction to Rule. Base 21
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)[i](f), next_event(b)[i](f) Introduction to Rule. Base 22
Sugar - additional boolean operators • ^, xor, != • <->, = - logical xor (not equals) - logical xnor (equals) Introduction to Rule. Base 23
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 3 rd clock” _____________________ • “between two requests, there must be an ack” _____________________ • “whenever read is asserted, read_en must be asserted” _____________________ Introduction to Rule. Base 24
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” _____________________ Introduction to Rule. Base 25
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 Introduction to Rule. Base 26
Environment Introduction to Rule. Base 27
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; Introduction to Rule. Base 28
EDL - constants and variables • Numeric constants: – decimal (1276), binary (1011 B), hex (7 FFFH) • Enumerated constants: – var state: {idle, st 1, st 2, st 3, waiting}; • Variable reference: – name(i) – name(i. . j) -- simple variable/signal -- one bit of array -- a range of bits Introduction to Rule. Base 29
EDL - expressions • Boolean connectives: & | ! ^ • Relational operators: = != < <= > >= Introduction to Rule. Base 30
EDL - expressions (continued) • Arithmetic: + * / mod • Non-deterministic choice: {read, write, nop} i. . j - equivalent to {i, i+1, …, j} Introduction to Rule. Base 31
EDL - variable declarations var name 1, name 2, name 3 : type; • type is one of: boolean {enum 1, enum 2, …, enum. N} i. . j • examples: var read, write : boolean; var state : {idle, read, write, hold} var counter {1, 2, 3, 4, 5} var length 4. . 10 Introduction to Rule. Base 32
EDL - the assign statement assign init(sig 1) : = expression; assign next(sig 1) : = expression; assign sig 2 : = 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 Introduction to Rule. Base 33
EDL - if expression Syntax: sig : = if condition then expr else expr endif; Example: assign a : = if reset then 0 else b endif; Introduction to Rule. Base 34
EDL - case expression Syntax: sig : = case condition 1 : expr 1 ; condition 2 : expr 2 ; . . . else : expr. N+1 ; esac else is not mandatory, but if you "fall" into esac the value is undefined Introduction to Rule. Base 35
EDL - additional operators • expr in {e 1, e 2, . . . , e. N} equivalent to expr=e 1 | expr=e 2 |. . . | expr=e. N • fell(expr) • rose(expr) • prev(expr) expr was 1 and became 0 expr was 0 and became 1 value of expr in the last cycle Introduction to Rule. Base 36
EDL - define statement Syntax: define sig 1 : = expression 1; sig 2 : = expression 2; . . . • 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 & c 1 | !selected & c 2; define cc : = 3; Introduction to Rule. Base 37
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. _____________________ Introduction to Rule. Base 38
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 ___________________________________________________ Introduction to Rule. Base 39
EDL - arrays • declaration: var name ( index 1. . index 2 ) : type ; • actually declares name(index 1), . . . , name(index 2) • index 1 can be either greater or less than index 2 • examples: var addr(0. . 7) : boolean; counter(4. . 5) : 0. . 3; status(0. . 3) : {empty, notempty, full }; Introduction to Rule. Base 40
EDL - array operations • • • : = = != & | ^ ! -> <-> > >= < <= + - * (beware of *) • >> << -- boolean arrays only rhs is constant or integer Introduction to Rule. Base 41
EDL - more array operations • • ++ zeroes(n) ones(n) nondets(n) rep(expr, n) itobv(i) bvtoi(vec(i. . j)) -- concatenate bits or sub-vectors -- 0++0++. . . ++0 n times -- 1++1++. . . ++1 n times -- {0, 1}++. . . ++{0, 1} n times -- expr++. . . ++ expr n times -- convert integer expr to bit vector -- convert bit vector to integer expr • no need for itobv with numeric constants Introduction to Rule. Base 42
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) = 10 B : 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; Introduction to Rule. Base 43
EDL - more array examples assign co++sum(0. . 15) : = 0++op 1(0. . 15) + 0++op 2(0. . 15); prod(0. . 7) : = zeroes(4)++op 1(0. . 3) * zeroes(4)++op 2(0. . 3); var cmd(0. . 4): boolean; assign cmd(0. . 4) : = {5, 7, 13}; var cmd(0. . 4): {5, 7, 13}; -- totally different Introduction to Rule. Base 44
EDL- array exercise • cmd_lt(0. . 2) should be equal to the value of cmd(0. . 2) the previous cycle ________________________________ Introduction to Rule. Base 45
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. ________________________________ Introduction to Rule. Base 46
EDL - %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 aa(1) : = 1>2; define aa(2) : = 2>2; define aa(3) : = 3>2; define bb 0 : = 0>2; define bb 1 : = 1>2; define bb 2 : = 2>2; define bb 3 : = 3>2; Introduction to Rule. Base 47
EDL - %for example define parity : = %for i in 0. . 15 do data(i) ^ %end 0; Introduction to Rule. Base 48
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 Introduction to Rule. Base 49
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 Introduction to Rule. Base 50
EDL - exercises • from the time data_en is asserted until one cycle after it, data should be stable, elsewhere it can change. ________________________________ ________________ Introduction to Rule. Base 51
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. ________________ Introduction to Rule. Base 52
Rule. Base exercise 1 • Copy directory exercise 1 from $RBEXERCISES/exercise 1 • See file README Introduction to Rule. Base 53
Day 2 Introduction to Rule. Base
Overview - day 2 • • More Sugar Fairness More EDL Size problems (basics) Managing multiple environments Rule. Base options Design formal verification Exercise - a simple buffer Introduction to Rule. Base 55
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 Introduction to Rule. Base 56
Sugar - sequences {e 0, e 1, e 2, . . . }(f) • f must hold on the last cycle of all computations that agree with the sequence e 0 at cycle 0, e 1 at cycle 1, e 2 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) Introduction to Rule. Base 57
Sugar - sequence operators • e 1, e 2 • e 1~e 2 • • e 1||e 2 e 1&&e 2 e 1[*] e 1[+] e 1, then e 2 (e 2 starts the cycle after e 1 completes) e 1, then e 2 (e 2 starts the same cycle that e 1 completes) either e 1 occurs, or e 2 occurs both e 1 and e 2 occur e 1 occurs 0 or more times e 1 occurs 1 or more times Introduction to Rule. Base 58
Sugar - more sequence operators • e 1[i] e 1 occurs i times • e 1[i. . j] e 1 occurs at least i but not more than j times • e 1[i. . ] e 1 occurs i or more times • e 1[. . j] e 1 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], b[>j, <k], b[>=j, <k], etc. Introduction to Rule. Base 59
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) Introduction to Rule. Base 60
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) Introduction to Rule. Base 61
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. ” _____________________ Introduction to Rule. Base 62
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” __________________________________________ Introduction to Rule. Base 63
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” __________________________________________ Introduction to Rule. Base 64
Fairness req ack start Design under verification done start !start idle start done busy gen done problem - the env model can stay in state busy forever Introduction to Rule. Base 65
Fairness (continued) • fairness is used to filter out paths from the environment • Syntax: fairness expr; • requires that expr occur an infinite number of times Introduction to Rule. Base 66
Fairness (continued) start !start idle start done busy gen done • Be careful with fairness! What is wrong with the following? • fairness state=gen_done; Introduction to Rule. Base 67
Fairness (continued) start !start idle start done busy gen done • What is the correct fairness constraint? __________________ Introduction to Rule. Base 68
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 proc 1: proc(gnt 1)(req 1, cmd 1); instance proc 2: proc(gnt 2)(req 2, cmd 2); Introduction to Rule. Base 69
EDL - processes process { var a: boolean; a : = 0; if (b | c) a : = 1; } Introduction to Rule. Base 70
EDL - assign vs. define • assign requires a state variable • define is “for free” Introduction to Rule. Base 71
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 Introduction to Rule. Base 72
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); Introduction to Rule. Base 73
Size problems - strategies • (over) restrict the environment: define pipeline_enable : = 0; • design overrides: var override internal_sig 1: boolean; define override internal_sig 2 : = 0; var override internal_sig 3: boolean; assign init(internal_sig 3) : = …; assign next(internal_sig 3) : = …; Introduction to Rule. Base 74
Size problems - strategies (continued) • Safety on-the-fly • BDD reordering – enabling – configuring – toggling – bdd order pool Introduction to Rule. Base 75
Managing multiple environments foo (1) lowest priority define override foo : = …; mode read_only { define override foo : = …; } rule read_only_no_pipeline { envs read_only; define override foo : = …; } (2) (3) (4) highest priority Introduction to Rule. Base 76
Rule. Base options Introduction to Rule. Base
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 Introduction to Rule. Base 78
Rule. Base exercise 2 • Copy directory exercise 2 from $ $RBEXERCISES/exercise 2 • See file README Introduction to Rule. Base 79
Rule. Base exercise 3 • Copy directory exercise 3 from $ $RBEXERCISES/exercise 3 • See file README Introduction to Rule. Base 80
- Slides: 80