1. May 11, 2009 1 http://csg.csail.mit.edu/arvind ACL2 Panel: What is the Future of Theorem Proving? Arvind Computer Science & Artificial Intelligence Laboratory Massachusetts Institute of Technology Eighth International Workshop On The ACL2 Theorem Prover and Its Applications, Boston, MA, USA May 11-12, 2009

2. May 11, 2009 2http://csg.csail.mit.edu/arvind What is the Future of Theorem Proving? ATP will continue to exist Has already proved its utility ATP in its present form is unlikely to be used widely Very few systems requires the level of correctness guaranteed by ATP ATP is currently unsuitable for evolving designs (all useful designs)

3. May 11, 2009 3http://csg.csail.mit.edu/arvind Widespread Use of ATP Technology Integrate it into design flow (not post-facto) ATP as debugging aid Use in the development of rock-solid components which can be used without concern for correctness reduces space of possible design bugs Use ATP with synthesis methodologies correct by construction High-Level Synthesis

4. May 11, 2009 4http://csg.csail.mit.edu/arvind Cost Matters The goal is to design systems that meet cost, performance, power, correctness, compatibility, robustness, etc. Design time  $$$ Designers will use any technique that increases their confidence in the system provided it: gives useful feedback quickly is better than manual debugging doesn’t require learning a “foreign language” is not elitist (No PhD requirement)

5. May 11, 2009 5http://csg.csail.mit.edu/arvind Some “Do”s and “Don’t”s Most successful formal techniques (e.g. types) help the designer, not just the verifier Separation of design and verification languages is a non-starter what are you verifying? manual abstraction, changing specs, … Writing specs is a good idea, but it rarely happens error prone time consuming incomplete incomprehensible changing requirements

6. May 11, 2009 6http://csg.csail.mit.edu/arvind What is needed High-level notation with precise semantics capable of expressing nondeterminism and parallelism amenable to synthesis of actual implementation Powerful tools for proving properties of such designs Automatic extraction of abstract models from designs expressed in Verilog or C or SystemC is a lost cause Thanks!

7. May 11, 2009 7http://csg.csail.mit.edu/arvind

8. May 11, 2009 8http://csg.csail.mit.edu/arvind A personal anecdote My student Xiaowei Shen designed an adaptive protocol called Caché Very difficult for me to understand and be sure of its correctness We used TRS to give a precise definition and TLAs to prove its correctness This was not enough …

9. May 11, 2009 9http://csg.csail.mit.edu/arvind Realization The proof was so long that we could have made a mistake easily Nobody else was going to read the proof – “it is not interesting” Even though the protocol correctness is of extreme importance the burden of its correctness is solely on its designers. Different from a math theorem Mechanical theorem proving

10. May 11, 2009 10http://csg.csail.mit.edu/arvind It took Joe Stoy more than 6 months to learn PVS and show that some of the proofs in Xiaowei Shen’s thesis were correct This technology is not ready for design engineers

11. May 11, 2009 11http://csg.csail.mit.edu/arvind Model Checking CC is one of the most popular applications of model checking The abstract protocol needs to be abstracted more to avoid state explosion For example, only 3 CPUs, 2 addresses There is a separate burden of proof why the abstraction is correct Nevertheless model checking is a very useful debugging aid for the verification of abstract CC protocols

12. May 11, 2009 12http://csg.csail.mit.edu/arvind Implementation Design is expressed in some notation which is NOT used directly to generate an implementation The problem of verification of the actual protocol remains formidable Testing cannot uncover all bugs because of the huge non-deterministic space Proving the correctness of cache coherence protocol implementations remains a challenging problem