Accessible Formal Verification for Safety-Critical FPGA Design BOF-W Presentation

1. Accessible Formal Verification for Safety-Critical FPGA DesignBOF-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 1

2. 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 2

3. 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 3

4. 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 4

5. 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 5

6. Dangerous Disconnect? Engineers who specify and design systems are not the same people who verify them. 6

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

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

9. Accessible Formal Verification:Constructive Methodology 9

10. Accessible Formal Verification:Verification Methodology 10

11. 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 11

12. 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 12