1. Lach1MAPLD 2005/241-W Accessible Formal Verification for Safety-Critical FPGA Design BOF-W Presentation John Lach, Scott Bingham, Carl Elks, Travis Lenhart Charles L. Brown Department of Electrical and Computer Engineering University of Virginia Thuy Nguyen, Patrick Salaun Department of Research and Development Electricité de France

2. Lach2MAPLD 2005/241-W What Can Disrupt FPGA-Based System Safety? Random failures –SEU, defect, electromigration, etc. –Redundancy helps Deterministic failures –Specification, design, or implementation error –Redundancy does NOT help! Our focus

3. Lach3MAPLD 2005/241-W Combating Deterministic Failures Assure correctness and completeness of safety specifications –Including specification of failure modes Assure correctness of design with respect to safety specifications –Functional properties –Timing properties –Freedom from intrinsic design faults Assure correctness of manufactured items with respect to design –Tool and “naked” FPGA qualification Our focus

4. Lach4MAPLD 2005/241-W Assuring Design Correctness Formal evidence –A priori: systematic fault avoidance –A posteriori: formal verification Evidence based on sampling –Testing, simulation, fault injection,... –Coverage criteria and levels Development process Operational experience –Credibility, applicability, sufficiency Inspection, expert judgment Our focus

5. Lach5MAPLD 2005/241-W Formal Evidence We must PROVE that a design is correct for safety-critical applications Formal verification techniques highly mathematical in nature –Specification/design engineers shy away –Verification engineers called in

6. Lach6MAPLD 2005/241-W Dangerous Disconnect? Engineers who specify and design systems are not the same people who verify them.

7. Lach7MAPLD 2005/241-W Primary Focus of Work Incorporate formal verification into traditional FPGA design flow Enable those who specify and design systems to be the same people who verify them Independent V&V still necessary

8. Lach8MAPLD 2005/241-W Must Be Able To… Directly implement known functions Replace existing components –Implementation details may be unknown Properly use and verify IP cores Keep at vendor- and tool-independent level –RTL (e.g. VHDL, Verilog, etc.)

9. Lach9MAPLD 2005/241-W Accessible Formal Verification: Constructive Methodology

10. Lach10MAPLD 2005/241-W Accessible Formal Verification: Verification Methodology

11. Lach11MAPLD 2005/241-W Ongoing Accessible Formal Verification Issues Accessibility relies heavily on the library’s interface Must seamlessly fit within the existing (or only slightly altered) design flow to ensure acceptance and not alter regulator- and oversight committee-approved techniques Need input from safety-critical hardware engineers to determine how they design and specify their systems –Will drive design of library interface and component/operation set Must establish which properties can (and cannot) be verified with this methodology Embed into toolset

12. Lach12MAPLD 2005/241-W Summary Deterministic failures must be addressed in the design process Formal verification is required to PROVE safety properties, but many engineers shy away Accessible formal verification abstracts the formal domain –Enable those who specify and design systems to be the same people who verify them