DCC Grenoble April 6, 2002 Unifying Traditional and Formal Verification Through Property Specification Designing Correct Circuits 2002 Harry Foster Verplex Systems Designing Correct Circuits 2002 Harry Foster Verplex Systems

Harry Foster DCC Grenoble April 6, 2002 Agenda u Hewlett-Packard and Formal Verification u Enhancing Functional Verification u Enhancing Equivalence Checking u Results u Thoughts for Research u Conclusion u Hewlett-Packard and Formal Verification u Enhancing Functional Verification u Enhancing Equivalence Checking u Results u Thoughts for Research u Conclusion

Harry Foster DCC Grenoble April 6, 2002 Formal Verification at HP u In 1999, follow-on project to the Superdome begins u Challenges: l Management wanted significant-measurable improvement in the overall verification process l Resources were not allocated for a team of formal experts l Desire a more strategic solution u Success depended on close designer involvement u Needed a way of adding properties to the RTL design that would benefit both simulation and formal verification u In 1999, follow-on project to the Superdome begins u Challenges: l Management wanted significant-measurable improvement in the overall verification process l Resources were not allocated for a team of formal experts l Desire a more strategic solution u Success depended on close designer involvement u Needed a way of adding properties to the RTL design that would benefit both simulation and formal verification

Harry Foster DCC Grenoble April 6, 2002 Enhancing Functional Verification Monitor-based specification u Monitor-Based Formal Specification of PCI [Shinmizu et al. FMCAD 2000] u A Specification Methodology by a Collection of Compact Properties as Applied to the Intel Itanium Processor Bus Protocol [Shimizu et al. CHARME 2001] Monitors generated from specification u FoCs-Automatic Generation of Simulation Checkers from Formal Specification [Abarbanel, et al. CAV 2000]. Specification driven simulation u Modeling Design Constraints and Biasing in Simulation Using BDDs [Yuan et al. ICCAD 1999] Monitor-based specification u Monitor-Based Formal Specification of PCI [Shinmizu et al. FMCAD 2000] u A Specification Methodology by a Collection of Compact Properties as Applied to the Intel Itanium Processor Bus Protocol [Shimizu et al. CHARME 2001] Monitors generated from specification u FoCs-Automatic Generation of Simulation Checkers from Formal Specification [Abarbanel, et al. CAV 2000]. Specification driven simulation u Modeling Design Constraints and Biasing in Simulation Using BDDs [Yuan et al. ICCAD 1999]

Harry Foster DCC Grenoble April 6, 2002 Enhancing Functional Verification HP Methodology Objectives: u Need a simple and systematic method of expressing interface properties for IP. u Same mechanism desired for internal properties. u Reduce cost for tool evaluations. u Need to re-target properties to multiple internal and commercial tools. u Desired low-cost solution. u Result: monitor-based approach to specifying design properties and constraints—Open Verification Library (OVL) HP Methodology Objectives: u Need a simple and systematic method of expressing interface properties for IP. u Same mechanism desired for internal properties. u Reduce cost for tool evaluations. u Need to re-target properties to multiple internal and commercial tools. u Desired low-cost solution. u Result: monitor-based approach to specifying design properties and constraints—Open Verification Library (OVL)

Harry Foster DCC Grenoble April 6, 2002 module assert_never ( clk, reset_ input clk, reset_n, test_expr; parameter severity_level = 0; parameter msg="ASSERT NEVER VIOLATION"; // ASSERT: PRAGMA HERE //synopsys translate_off `ifdef ASSERT_ON integer error_count; initial error_count = 0; clk) begin `ifdef ASSERT_GLOBAL_RESET if (`ASSERT_GLOBAL_RESET != 1'b0) begin `else if (reset_n != 0) begin // active low reset_n `endif if (test_expr == 1'b1) begin error_count = error_count + 1; `ifdef ASSERT_MAX_REPORT_ERROR if (error_count<=`ASSERT_MAX_REPORT_ERROR) `endif $display("%s : severity %0d : time %0t : %m", msg, severity_level, $time); if (severity_level == 0) $finish; end `endif //synopsys translate_on endmodule RTL Design RTL Design Assertion Monitor Library Assertion Monitor Library assert_never underflow ( clk, reset_n, (q_valid==1’b1) && (q_underflow==1’b1)); Assertion Monitor Library

Harry Foster DCC Grenoble April 6, 2002 `ifdef ASSERT_ON //synopsys translate_off wire p0_wr_p1_wr_broken; wire p0_wr_p0_rd_broken; // Check that the conflict and bypass logic is working correctly. assign p0_wr_p1_wr_broken = (mqc_p0_wr_addr == mqc_p1_wr_addr) & ( (mqc_p0_wr[0] & mqc_p1_wr[0]) | (mqc_p0_wr[1] & mqc_p1_wr[1]) ); assign p0_wr_p0_rd_broken = (mqc_p0_wr_addr == mqc_p0_rd_addr) & ( (mqc_p0_wr[0] & (p0_byp_even != 2'b01)) | (mqc_p0_wr[1] & (p0_byp_odd != 2'b01)) ); // Check that the conflict and bypass logic is working correctly. assert_never p0_wr_p1_wr (clk, reset_n, p0_wr_p1_wr_broken ); assert_never p0_wr_p0_rd ( clk, reset_n, p0_wr_p0_rd_broken ); //synopsys translate_on `endif Enhancing Functional Verification

Harry Foster DCC Grenoble April 6, 2002 `ifdef ASSERT_ON wire event1 = (pdx_core_qpdxc_piobp_data_valid & (qpdxd_data[15:12] == `XPTYPE_PIOB4) & (pdx_core_qpdxd_data[3:0] == `XTTYPE_WR_SHORT8) & (qpdxd_data[81:67] == `KPDX_BLOCK_ADDR) & (pdx_core_qpdxd_data[81:67] == `KPDX_FUNC_ID)); wire event2 = (gfc_sync_ff); wire event3 = ((rpdx_pi0_valid | pdx_core_rpdx_pi0_valid) & (rpdx_pdx_data[15:12] == `XPTYPE_PIOB2) & (pdx_core_rpdx_pdx_data[3:0] == `XTTYPE_WRITE_DONE) & (qpdxd_data[81:67] == `KPDX_BLOCK_ADDR) & (pdx_core_qpdxd_data[81:67] == `KPDX_FUNC_ID)); `endif assert_cycle_sequence #(0, 5) seq0 (clk, rst_n, {event1, 1, 1, event2, event3}); Enhancing Functional Verification

Harry Foster DCC Grenoble April 6, 2002 ASSERT_FRAME SYNOPSIS assert_frame #(severity_level, min, max) inst ( ck, start_event, check_expr); min time 0 start_event check_event max req ack width Enhancing Functional Verification assert_frame #(0, 3, 7) req_ack ( ck, req, ack);

Harry Foster DCC Grenoble April 6, 2002 module fifo (clk, fifo_clr_n, fifo_reset_n, push, pop, data_in, data_out); parameter fifo_width = `FIFO_WIDTH; parameter fifo_depth = `FIFO_DEPTH; parameter fifo_cntr_w = `FIFO_CNTR_W; input clk, fifo_clr_n, fifo_reset_n, push, pop; input [fifo_width-1:0] data_in; output [fifo_width-1:0] data_out; wire [fifo_width-1:0] data_out; reg [fifo_width-1:0] fifo[fifo_depth-1:0]; reg [fifo_cntr_w-1:0] cnt; // count items in FIFO... // RTL FIFO Code Here... ‘ifdef ASSERT_ON // OVL Assert that the FIFO cannot overflow assert_never no_overflow (clk,(fifo_reset_n & fifo_clr_n), ({push,pop}==2'b10 && cnt==fifo_depth)); // OVL Assert that the FIFO cannot underflow assert_never no_underflow (clk,(fifo_reset_n & fifo_clr_n), ({push,pop}==2'b01 && cnt==0)); ‘endif endmodule Enhancing Functional Verification

Harry Foster DCC Grenoble April 6, 2002  Studies were on simulation-based assertion checking  Lack systematic assertion methodology  Specify Once then reuse assertions seamlessly between simulation and formal and semi-formal verification Percentage of bugs detected using assertion monitors. Kantrowitz and Noack [DAC 1996] Taylor et at. [DAC 1998] Assertion Monitors34% Cache Coherency Checkers 9% Register File Trace Compare 8% Memory State Compare 7% End-of-Run State Compare 6% PC Trace Compare 4% Self-Checking Test 11% Simulation Output Inspection 7% Simulation hang 6% Other 8% Assertion Monitors 25% Register Miscompare 22% Simulation "No Progress” 15% PC Miscompare14% Memory State Miscompare 8% Manual Inspection 6% Self-Checking Test 5% Cache Coherency Check 3% SAVES Check 2% Results

Harry Foster DCC Grenoble April 6, 2002 Results u 4300 OVL assertion monitors added to a 10M gate ASIC u Reach stable model quicker than previous method u Bug report open rate increased between projects u Bug report close rate decreased between projects u 85% of bugs in simulation found using assertions u Turn random on sooner u 4300 OVL assertion monitors added to a 10M gate ASIC u Reach stable model quicker than previous method u Bug report open rate increased between projects u Bug report close rate decreased between projects u 85% of bugs in simulation found using assertions u Turn random on sooner Without Assertions With assertions 200,000 CPU hours50,000 CPU hours simulation timeline Bugs Found

Harry Foster DCC Grenoble April 6, 2002 Enhancing Functional Verification u One super-block was identified for formal and semi-formal. u Worked close with engineers to develop good constraint for partitioned blocks. u Internal tool operation and debug issues still difficult. u Demonstrated that a methodology could be construct cheaply benefiting traditional verification while providing a path to FV. u One super-block was identified for formal and semi-formal. u Worked close with engineers to develop good constraint for partitioned blocks. u Internal tool operation and debug issues still difficult. u Demonstrated that a methodology could be construct cheaply benefiting traditional verification while providing a path to FV.

Harry Foster DCC Grenoble April 6, 2002 u Two aspects of equivalence require validation l Logical consistency l Semantic consistency u Two aspects of equivalence require validation l Logical consistency l Semantic consistency GoldenRTL FinalNetlist Enhancing Functional Verification

Harry Foster DCC Grenoble April 6, 2002 What is Semantic Inconsistency? uRTL design simulates differently than the gate-level model. uYet, the two models are logically equivalence! uWhat causes semantic inconsistency? l Misuse of X assignments in the RTL (optimistic behavior) l Misuse of synthesis full_case and parallel_case pragmas l Range overflow in variable indexing. uWhat’s the problem? Functional bugs missed in the RTL, requires gate-level simulation, bug usually found in silicon!

Harry Foster DCC Grenoble April 6, 2002 module mux (a,b,s,q); output q; input a, b; input [1:0] s; reg q; or b or s) begin case (s) //synopsys full_case 2’b01: q = b; 2’b10: q = a; endcase end endmodule X-state Optimism... clk) begin if (rst) s = 2’b0; else begin case (sel) 2’b01: s = 2’b10; 2’b10: s = 2’b01; default: s = 2’bx; endcase end... a q s[0] 0 1s[1] 10b XXb 10b

Harry Foster DCC Grenoble April 6, 2002 module encoder (y, z, a, b); output y, z; input [1:0] a, b; reg y, z; or b) begin {y, z} = 2'b00; {y, z} = 2'b00; casez ({a, b}) casez ({a, b}) 4’b11??: z = 1'b1; 4’b11??: z = 1'b1; 4’b??11: y = 1'b1; 4’b??11: y = 1'b1; endcase endcaseendendmodule Parallel Case Semantic Inconsistency - Problem Based on Bening and Foster 2001 // parallel_case Priority encoder a[0] a[1] b[0] b[1] z y b[1:0] RTL: y a[1:0] Gate: y y z a[0] a[1] b[0] b[1] Synthesized gate

Harry Foster DCC Grenoble April 6, 2002 assert_never a_and_b (clk, rst_n, (a==2’b11 & b==2’b11)); uIP picked up from other lab contained both X assignments and pragmas (Bad Stuff!) uAdded in assertions for IP pick up from other lab uObviously, X assignment and pragma safe usage properties lends itself to automatic extraction from the RTL Enhancing Functional Verification

Harry Foster DCC Grenoble April 6, 2002 Thoughts for Research u Coverage associated with formal proofs – e.g., formal fault models – particularly related to bounded and limited cycle proofs

Harry Foster DCC Grenoble April 6, 2002 Conclusion u Successful integration of formal into today’s design flow requires a clear ROI. u Work required to specify properties and constraints must be leveraged seamlessly between traditional and formal. u Gain for the pain clearly demonstrated, and designers willing to participate. u Equivalence checking (specifically related to verifying semantic consistency) can benefit from property specification and verification. u Successful integration of formal into today’s design flow requires a clear ROI. u Work required to specify properties and constraints must be leveraged seamlessly between traditional and formal. u Gain for the pain clearly demonstrated, and designers willing to participate. u Equivalence checking (specifically related to verifying semantic consistency) can benefit from property specification and verification.