1. Lach1MAPLD 2005/241 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

2. Lach2MAPLD 2005/241 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

3. Lach3MAPLD 2005/241 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

4. Lach4MAPLD 2005/241 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

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

6. Lach6MAPLD 2005/241 Portability: Vendor Independence “Naked” FPGA HW Vendor’s Tool SetVendor Specific Vendor Independent Interface IP Cores Translation Tools Application Specific Language Application Functions Gate Level Formal Verification Tools RTL Elementary Functions Multiple vendors

7. Lach7MAPLD 2005/241 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

8. Lach8MAPLD 2005/241 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

9. Lach9MAPLD 2005/241 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

10. Lach10MAPLD 2005/241 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

11. Lach11MAPLD 2005/241 Dangerous Disconnect? Engineers who specify and design systems are not the same people who verify them.

12. Lach12MAPLD 2005/241 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

13. Lach13MAPLD 2005/241 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.)

14. Lach14MAPLD 2005/241 Properties for Verification Functional System/context Temporal –Note: only for sequential circuits Inherent/intrinsic

15. Lach15MAPLD 2005/241 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

16. Lach16MAPLD 2005/241 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

17. Lach17MAPLD 2005/241 Accessible Formal Verification: Constructive Methodology The library can then convert the formal specification into a formal hardware design model

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

19. Lach19MAPLD 2005/241 Accessible Formal Verification: Verification Methodology The operations and components in the library must be verified with traditional verification methodology

20. Lach20MAPLD 2005/241 Accessible Formal Verification: Verification Methodology Boxes are the same as with the Constructive Methodology, but designer is responsible for creating them

21. Lach21MAPLD 2005/241 Accessible Formal Verification: Verification Methodology IP blocks can be verified in the same manner

22. Lach22MAPLD 2005/241 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

23. Lach23MAPLD 2005/241 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