Accessible Formal Verification for SafetyCritical FPGA Design John

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

Questions to be Addressed • Why use FPGAs in safety-critical systems? – SW-based systems have been the norm • What can disrupt FPGA-based system safety? – Random failures (SEU, defect, electromigration, etc. ) – Deterministic failures (specification/design error) • How can formal verification be incorporated into the traditional FPGA design flow? – Required for safety assurance, but engineers shy away Lach 2 2

Why Use HW in Safety-Critical Applications? • Lower complexity than SW – Lower probability of designer (and tool? ) error – Easier verification and validation (V&V) • Cheaper – Especially important given required redundancy • Auxiliary functions can be designed so that they will not interfere with main safety functions Lach 3 3

Why Use FPGAs in Safety-Critical Applications? • Implementation portability – Across vendors, platforms, and time • Physical design issues abstracted • Qualification of one “naked” FPGA device applies to all functions Lach 4 4

Complexity: SW vs. FPGA Main Safety Functions Main Safety + Auxiliary Functions Elementary Functions Operating System Lower potential for adverse interference between functions Lower potential for digital common cause failure µ-Processor “Naked” FPGA SW-based solution Lach FPGA-based solution 5 5

Portability: Vendor Independence Application Specific Language Application Functions Translation Tools Vendor Independent Elementary Functions IP Cores Formal Verification Tools RTL Interface Vendor Specific Vendor’s Tool Set “Naked” FPGA HW Multiple vendors Lach 6 Gate Level 6

What Can Disrupt FPGA-Based System Safety? • Random failures Our focus – SEU, defect, electromigration, etc. – Redundancy helps • Deterministic failures – Specification, design, or implementation error – Redundancy does NOT help! Lach 7 7

Combating Deterministic Failures • Assure correctness and completeness of safety specifications Our focus – 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 Lach 8 8

Our focus 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 Lach 9 9

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 Lach 10 10

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

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

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. ) Lach 13 13

Properties for Verification • Functional • System/context • Temporal – Note: only for sequential circuits • Inherent/intrinsic Lach 14 14

Accessible Formal Verification: Constructive Methodology Abstract the formal domain with a verified library of operations and components (at various levels of abstraction and targeting different implementation platforms) from which designers can specify their designs Lach 15 15

Accessible Formal Verification: Constructive Methodology Semi-formal specifications in traditional input formats (e. g. functional diagrams) can be converted by the library into the formal domain Lach 16 16

Accessible Formal Verification: Constructive Methodology The library can then convert the formal specification into a formal hardware design model Lach 17 17

Accessible Formal Verification: Constructive Methodology This model can then be used to generate HDL that has been formally verified via the library abstraction Lach 18 18

Accessible Formal Verification: Verification Methodology The operations and components in the library must be verified with traditional verification methodology Lach 19 19

Accessible Formal Verification: Verification Methodology Boxes are the same as with the Constructive Methodology, but designer is responsible for creating them Lach 20 20

Accessible Formal Verification: Verification Methodology IP blocks can be verified in the same manner Lach 21 21

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 Lach 22 22

Summary • FPGAs are appropriate (and even desirable) to use in safety-critical systems • 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 Lach 23 23