ACL2 Panel: What is the Future of Theorem Proving? Arvind

1. 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. 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) http://csg.csail.mit.edu/arvind

3. 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 http://csg.csail.mit.edu/arvind

4. 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) http://csg.csail.mit.edu/arvind

5. 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 http://csg.csail.mit.edu/arvind

6. 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! http://csg.csail.mit.edu/arvind

7. http://csg.csail.mit.edu/arvind

8. 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 … http://csg.csail.mit.edu/arvind

9. 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 http://csg.csail.mit.edu/arvind

10. 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 http://csg.csail.mit.edu/arvind

11. 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 http://csg.csail.mit.edu/arvind

12. 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 http://csg.csail.mit.edu/arvind