Introduction to Formal Verification using Rulebase April 18, 2001

1. Introduction to Formal Verification using Rulebase April 18, 2001 Rebecca Gott eServer I/O Development Hardware Verification Email: gott@us.ibm.com

2. Today's Topics • Brief review • Introduction to the GenBuff example • Modeling the environment • Formulating Rules • Running Rulebase

3. Review of Requirements for FV • A good, written functional specification • All block level I/Os should be described, with timing diagrams • Function (internal state machines, etc.) • Partition selection • Communication with Designer • FV engineer MUST have thorough understanding of the logic & signals driving the logic

4. design (HDL) spec (sugar) environ. (EDL) RuleBase RuleBase Model Checker pass/fail

5. STOB_REQ(0) BTOS_ACK(0) BTOR_REQ(0) DI_0_(0..31) RTOB_ACK(0) STOB_REQ(1) BTOS_ACK(1) DI_1_(0..31) STOB_REQ(2) BTOS_ACK(2) BTOR_REQ(1) DI_2_(0..31) RTOB_ACK(1) STOB_REQ(3) BTOS_ACK(3) DI_3_(0..31) GenBuf is a design block that queues words of data (32 bits) sent by four senders. GenBuf then transmits the data to two receivers. The four senders are equivalent and the two receivers are equivalent. GenBuf Example Sender0 G E N B U F Receiver0 Sender1 D0(0..31) Sender2 Receiver1 Sender3

6. Communication w/ Senders takes place by means of a 4-phase handshaking • When sender(x) has data to send, it initiates a transfer by asserting STOB_REQ(x) ("Server x to Buffer Request") • If the queue is not full, the sender will be serviced; GenBuf will read the data from x's bus, and will then assert BTOS_ACK(x) ("Buffer to Server x Acknowledge") one cycle after reading the data • Sender x will hold its request signal until it gets BTOS_ACK(x); after BTOS_ACK(x) has been asserted, the sender will release the data bus and deassert STOB_REQ(x) • To conclude the transaction, GenBuf will deassert BTOS_ACK(x) • A sender should wait until BTOS_ACK(x) is deasserted before starting a new transaction • GenBuf uses a fair scheme to select the Sender GenBuf Sender Description

7. Communication w/ Receivers takes place by means of a 4-phase handshaking • When GenBuf has data, it will choose a receiver (y=0 or 1) and will initiate a data transfer by asserting BTOR_REQ(y) ("Buffer to Receiver Requests y") • When the receiver is ready, it will assert RTOB_ACK(y) ("Receiver to Buffer Acknowledge") • One cycle after RTOB_ACK(y) is asserted, GenBuf will put the data on the data bus (DO(0..31)) • The receiver will indicate to GenBuf that it has read the data by deasserting RTOB_ACK(y) • GenBuf should wait for RTOB_ACK(y) to be deasserted before it starts a new transaction • GenBuf uses a fair scheme to select the Receiver GenBuf Recevier Description

8. I/O Specification for Sender Description STOB_REQ(0) Request Input for senders 0-3 Sender to GenBuf Signal Name DI_0_(0..31) Data in for Sender0 DI_1_(0..31) Data In for Sender1 DI_2_(0..31) Data In for Sender2 DI_3_(0..31) Data In for Sender3 GenBuf to Sender Signal Name Description BTOS_ACK(0..3) Acknowledgment for Senders 0-3

9. I/O Specification for Receiver Description RTOB_ACK(0..1) Acknowledgment from Receivers 0-1 Receiver to GenBuf Signal Name GenBuf to Receiver Signal Name Description BTOR_REQ(0..1) Request to Receivers 0-1 DO(0..31) Data out

10. Other Inputs Other inputs to GenBuf Signal Name Description RST Reset Signal: Active High (set to 1 for 2 cycles then to 0) CLK Clock (set to 1) ERROR_FOUND(1..6) Set to 0

11. Classification of Properties • Functional correctness - does the arbiter issue a grant within 4 cycles of receiving a request? • Safety properties - does the arbiter only issue a grant if a request is raised? • Liveness properties - does the arbiter eventually issue a grant for every request?

12. Sugar Basics • In the temporal logic CTL • Time is discrete • The world consists of a current state, mapped to a specific node in the computation tree, and of many possible futures (all computation paths emanating from this state) • CTL has no way to refer to the past • The only way to refer to the past is to have information stored in state variables

13. 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 CTL Operators

14. Sugar - Bounded-Range Operators • AX[i] • Shorthand for n times AX • AG(req -> AX[2](ack)) • AG(req -> AX AX ack ) • ABF[i..j](f) • Constrains AF between i and j clocks • AG(req -> ABF[1..2](ack)) • AG(req -> AX(ack | AX (ack)) )

15. Sugar Bounded Range Operators Cont. • ABG[i..j](f) • Constrains the future of the operator AG between i and j clocks from now • AG(req -> ABG[0..2](busy) ) • AG(req -> (busy & AX(busy & AX busy)) )

16. 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)

17. CTL A[q U r] • r must occur eventually • strong operator: makes demand on terminating condition • r can occur in the current state, in which case q may not appear at all • q need not hold at the time r holds • AG(req -> A[busy U ack] ) • Sugar q until r • Weak version: does not require r eventually occur • Sugar q until! r • Strong version - equivalent to AU Sugar - until

18. rule check_ack { formula "An ack should be issued one cycle after a request is asserted." {AG ( req -> AX(ack) ) } formula "An a req is not raised this cycle, then an ack cannot be asserted upon the next cycle." {AG ( !req -> AX(!ack) ) } } rule check_waddr { formula 'If an ack has been issued, then on the next cycle the write address should be incremented' {AG ( ack -> AX(wp_incr) ) } } Rule Partitioning

19. Modeling the Environment • Study block interfaces in detail • Plan hierarchical structure of environment models, grouping related signals & reusing components where possible • Decide how to model each input - which inputs should be nondeterministic • Code the logic in EDL • Take time to verify environment model - especially if complex

20. Key Environment Concepts • Fairness • Invariants

21. var req : boolean; assign init(req) := 0; assign next(req) := case req & !ack : req; ack : 0; else : {0,1} esac; Problem - What if we are not interested in the path where req is never asserted? Consider the rule: {AG ( AF(req) ) } Fairness

22. Fairness • To be used when we are only interested in the correctness along fair computation paths • Using a fairness constraint restricts the search to fair paths • A path is fair if each fairness constraint is true infinitely often along the path

23. Fairness Constraints • Syntax: • fairness expr; • Example: • fairness req; • {AG ( AF (req) ) } • would fail without a fairness constraint • would pass with the constraint: • fairness req;

24. EDL - invariants • Allows you to specify a boolean formula that you want to be true at every cycle • Restricts the analysis to states in which expr holds • Can be used to model the environment or to (over) restrict the design • Syntax: • invar expr;

25. 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);

26. var req : boolean; assign init(req) := 0; assign next(req) := case req & !ack : req; ack : 0; else : {0,1} esac; Consider this invariant - what is wrong with it?: invar req; EDL - invariant example

27. RuleBase options

28. BDD Order • Rulebase uses a data structure called a Binary Decision Diagram (BDD) • Every state variable (flip-flop) has a distinct level from 1 to n, where n is the number of state variables • The order in which the levels are allocated to the state variables has a large impact on the size of the BDD • The smaller the BDD, the less machine memory consumed

29. BDD Ordering • Rulebase performs BDD ordering during model checking • Extremely CPU intensive • Turn it on for initial runs, and then use resulting order for consecutive runs

30. Reductions • Eliminates logic that is not in the cone of influence • Propagates constants from the environment forward • Eliminates redundant logic

31. SMV Reductions • Over-reductions to find constant flip-flops; applies reductions based on constants search results • Used when a size problem is encountered • Any constants found will be added to the orders pool • no need to activate if no new constants may be added • Parameter sets effort level

32. Safety On-The-Fly • In normal mode of operation, Rulebase computes reachable state space before checking any formula • reachable state space is the set of all states of the design that can be reached from the initial state • Rulebase (in many cases) can determine the falsity of the formula before it has completed the search of the reachable state space - counter-example produced earlier

33. Safety On-The-Fly • Formulas that do not suit Safety On-The-Fly • Formulas mixing A and E path quantifiers • Formulas that use AF, AU, EG or any strong Sugar operator • Formulas in which there is a '|' (or) between temporal subformulas • Specify trade off btw memory and time consumption during run • Larger this parameter is, the less memory consumed, but counter examples will take longer • Suggest small parameter value if expect failure

34. Liveness On-The-Fly • Liveness formulas can be checked during reachability • May take a long time • If formula is likely to pass, this option is not recommended

35. Other Options • Reachability • Determines if a search of the reachable state space of the circuit is to be the first step of verification • For most designs, this should be enabled • Stop after iteration • Integer indicating how far into the reachability analysis should go • Rulebase will not examine states that are further than X steps from the initial state

36. Rulebase Results • Fail • Tautology • Vacuous Pass • AG (req -> AX (ack) ) • when is this formula meaningless? • solution: vacuity check • Pass with witness or non-vacuously

37. How does Rulebase work? • Load the environment & rules; checks syntax • Loads the design, builds a module that includes the design and relevant enviroment • Perform the first phase of optimization and reports how many flip-flops in the design influence the rule & how many env variables influence the rule • Searches for best order file, or takes the rule_name.order • Performs a 2nd phase of optimization if SMV reduction is set to 'on' • Checks if the formula is a tautolgy

38. How does Rulebase work? • Checks formulas using the light proof algorithm (if enabled) • Checks formulas on the fly • If a bug is found, creates a counter example; if not, creates a witness if not vacuous • For a liveness formula, stops every several steps and performs additional reduction phases with an attempt to evaluate the formula

39. Summary • GenBuf Example • Environment Modeling • Sugar • Running Rulebase