Lach 1 MAPLD 2005/241-W

Accessible Formal Verification for Safety-Critical FPGA Design

BOF-W Presentation

John Lach, Scott Bingham, Carl Elks, Travis LenhartCharles L. Brown Department of Electrical and Computer Engineering

University of Virginia

Thuy Nguyen, Patrick SalaunDepartment of Research and Development

Electricité de France

Lach 2 MAPLD 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!O

ur f

ocus

Lach 3 MAPLD 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

foc

us

Lach 4 MAPLD 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

foc

us

Lach 5 MAPLD 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

Lach 6 MAPLD 2005/241-W

Dangerous Disconnect?

Engineers who specify and design systems are not the same people who verify them.

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

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

Lach 9 MAPLD 2005/241-W

Accessible Formal Verification:Constructive Methodology

Lach 10 MAPLD 2005/241-W

Accessible Formal Verification:Verification Methodology

Lach 11 MAPLD 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

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