1. Writing, Verifying and Exploiting Formal Specifications for Hardware Designs Chapter 3: Verifying a Specification Presenter: Scott Crosby

2. The problem Specifications have problems –Incorrect –Buggy –No hardware to compare

3. What they have ‘Spell check’ a specification Check for correctness properties Automatically generate test sequences Proof it can be implemented –With no explicit state machine

4. Reminders Specification: –No explicit state machine –Monitor Judge Deterministic

5. Mealy Machine

6. Properties of Properties List of properties –Grouped by the agent Correct i = agent i is correct –ANTECEDENT  CONSEQUENT Consequent –Λ,V,¬, prev() Antecedent –Λ,V,¬, prev() –prev(trdy Λ stop)  stop

7. Temporal or Causal Cause  Effect –prev(trdy)  ¬prev(stop) V stop Past Conditions  Current State –prev(trdy Λ stop)  stop

8. Property Representation Restricted linear time – prev(ANTECEDENT)  CONSEQUENT Consequent –Λ,V,¬, and this agents outputs variables Antecedent –Λ,V,¬, prev(), any agents output variables

9. Properties of Properties Separable –Only describes outputs of one agent –Eg, mutual exclusion not explicit No nondeterminism Implementable Correctness only function of own outputs

10. Correctness of Specifications Problems –Too strict –Too loose What we want –No implementation –No state machines –Avoid state explosion –Easy to verify

11. Past Solutions Model checking –Huge state explosion –What to check? Abstract representation –How abstract?

12. What this offers Checking specifications for correctness Generating sample outputs Proof of implementability

13. Checking Specifications Specification –Restricted LTL Model checker –CTL Three ‘Spell Checks’ Human written characteristics

14. CTL Branching time logic Logic operators –Λ,V,¬ Temporal –EX, EG, E[a U b] Derived –AX, EF, A[a U b], AF

15. ‘Spell Check’ of a specification Dead state

16. ‘Spell Check’ of a specification Dead state address_phase=true irdy=false trdy=true stop=false

17. ‘Spell Check’ of a specification Under-restriction

18. ‘Spell Check’ of a specification Vacuous property –Every property is used

19. Characteristic Check Characteristics –User written properties –CTL formula –Human designed Requires debugging –Reusable

20. Results Will see details next friday Bugs found in PCI Bugs found in Itanium bus protocol

21. Generator Constraint solver Traces

22. Sample output

23. Generator Find missing properties Found bug –Eg, signal must remain constant –Wasn’t discovered Nobody thought to check

24. Receptiveness Proof What is receptiveness? Implementability –Can the spec be implemented? Receptiveness –Can the whole spec be implemented? –Every choice?

25. A note Spec with dead states is implementable

26. Property Representation Seperability – prev(ANTECEDENT)  CONSEQUENT Consequent –Λ,V,¬, and this agents outputs variables Antecedent –Λ,V,¬, prev(), any agents output variables

27. Theorem Any specification with –Separability –No dead states Is receptive –Whole thing is implementable –Behaves correctly, regardless of environment

28. Setup of proof Mealy machine You vs Environment

30. Separability Other agents My choice

31. No dead states Other agents

32. This Means: My correctness doesn’t depend on other’s behavior at the current time step. I always have a choice where I will be correct.

33. Corollary 1: Implementability If –No dead states for anyone –Separability Exists a set of machines that implement the specification.

34. Corollary 2: Receptiveness If –No dead states for anyone –Separability Exists a set of agent implementations that will go to every reachable state in system.

35. Conclusion Debug a specification Generate a sample run Prove that it is implementable