Unifying Traditional and Unifying Traditional and Formal Verification Through Formal Verification Through Property Specification Property Specification Designing Correct Circuits 2002 Designing Correct Circuits 2002 Harry Foster Harry Foster Verplex Systems Verplex Systems DCC Grenoble April 6, 2002
Agenda Agenda � Hewlett-Packard and Formal Verification � Hewlett-Packard and Formal Verification � Enhancing Functional Verification � Enhancing Functional Verification � Enhancing Equivalence Checking � Enhancing Equivalence Checking � Results � Results � Thoughts for Research � Thoughts for Research � Conclusion � Conclusion Harry Foster DCC Grenoble April 6, 2002
Formal Verification at HP Formal Verification at HP � In 1999, follow-on project to the Superdome begins � In 1999, follow-on project to the Superdome begins � Challenges: � Challenges: � Management wanted significant-measurable improvement � Management wanted significant-measurable improvement in the overall verification process in the overall verification process � Resources were not allocated for a team of formal experts � Resources were not allocated for a team of formal experts � Desire a more strategic solution � Desire a more strategic solution � Success depended on close designer involvement � Success depended on close designer involvement � Needed a way of adding properties to the RTL � Needed a way of adding properties to the RTL design that would benefit both simulation and formal design that would benefit both simulation and formal verification verification Harry Foster DCC Grenoble April 6, 2002
Enhancing Functional Enhancing Functional Verification Verification Monitor-based specification Monitor-based specification � Monitor-Based Formal Specification of PCI � Monitor-Based Formal Specification of PCI [Shinmizu et al. FMCAD 2000] [Shinmizu et al. FMCAD 2000] � A Specification Methodology by a Collection of Compact � A Specification Methodology by a Collection of Compact Properties as Applied to the Intel Itanium Processor Bus Properties as Applied to the Intel Itanium Processor Bus Protocol [Shimizu et al. CHARME 2001] Protocol [Shimizu et al. CHARME 2001] Monitors generated from specification Monitors generated from specification � FoCs-Automatic Generation of Simulation Checkers from � FoCs-Automatic Generation of Simulation Checkers from Formal Specification [Abarbanel, et al. CAV 2000]. Formal Specification [Abarbanel, et al. CAV 2000]. Specification driven simulation Specification driven simulation � Modeling Design Constraints and Biasing in Simulation � Modeling Design Constraints and Biasing in Simulation Using BDDs [Yuan et al. ICCAD 1999] Using BDDs [Yuan et al. ICCAD 1999] Harry Foster DCC Grenoble April 6, 2002
Enhancing Functional Enhancing Functional Verification Verification HP Methodology Objectives: HP Methodology Objectives: � Need a simple and systematic method of expressing � Need a simple and systematic method of expressing interface properties for IP. interface properties for IP. � Same mechanism desired for internal properties. � Same mechanism desired for internal properties. � Reduce cost for tool evaluations. � Reduce cost for tool evaluations. � Need to re-target properties to multiple internal and � Need to re-target properties to multiple internal and commercial tools. commercial tools. � Desired low-cost solution. � Desired low-cost solution. � Result: monitor-based approach to specifying design � Result: monitor-based approach to specifying design properties and constraints—Open Verification Library properties and constraints—Open Verification Library (OVL) (OVL) Harry Foster DCC Grenoble April 6, 2002
Assertion Monitor Library Assertion Monitor Library Assertion Assertion assert_never underflow ( clk, reset_n, (q_valid==1’b1) && (q_underflow==1’b1)); Monitor Monitor module assert_never ( clk, reset_ Library Library input clk, reset_n, test_expr; parameter severity_level = 0; parameter msg="ASSERT NEVER VIOLATION"; // ASSERT: PRAGMA HERE //synopsys translate_off RTL RTL `ifdef ASSERT_ON integer error_count; initial error_count = 0; Design Design always @( posedge 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 end end `endif //synopsys translate_on endmodule Harry Foster DCC Grenoble April 6, 2002
Enhancing Functional Enhancing Functional Verification Verification `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 Harry Foster DCC Grenoble April 6, 2002
Enhancing Functional Enhancing Functional Verification Verification `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)); assert_cycle_sequence #(0, 5) seq0 (clk, rst_n, {event1, 1, 1, event2, event3}); `endif Harry Foster DCC Grenoble April 6, 2002
Enhancing Functional Enhancing Functional Verification Verification ASSERT_FRAME SYNOPSIS assert_frame #(severity_level, min, max) inst ( ck, start_event, check_expr); req ack req ack assert_frame #(0, 3, 7) req_ack ( ck, req, ack); width width start_event max min 0 check_event time Harry Foster DCC Grenoble April 6, 2002
Enhancing Functional Enhancing Functional Verification Verification 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 Harry Foster DCC Grenoble April 6, 2002
Results Results Percentage of bugs detected Assertion Monitors34% Cache Coherency Checkers 9% using assertion monitors. 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% � Studies were on simulation-based Other 8% assertion checking Kantrowitz and Noack [DAC 1996] � Lack systematic assertion methodology Assertion Monitors 25% Register Miscompare 22% � Specify Once then reuse assertions Simulation "No Progress” 15% PC Miscompare 14% seamlessly between simulation and Memory State Miscompare 8% Manual Inspection 6% formal and semi-formal verification Self-Checking Test 5% Cache Coherency Check 3% SAVES Check 2% Taylor et at. [DAC 1998] Harry Foster DCC Grenoble April 6, 2002
Results Results . . With assertions 302 . 260 . . . 265 Without Assertions Bugs Found . . . . . . 180 . . . . . .. . 50,000 CPU hours 200,000 CPU hours simulation timeline � 4300 OVL assertion monitors added to a 10M gate ASIC � 4300 OVL assertion monitors added to a 10M gate ASIC � Reach stable model quicker than previous method � Reach stable model quicker than previous method � Bug report open rate increased between projects � Bug report open rate increased between projects � Bug report close rate decreased between projects � Bug report close rate decreased between projects � 85% of bugs in simulation found using assertions � 85% of bugs in simulation found using assertions � Turn random on sooner � Turn random on sooner Harry Foster DCC Grenoble April 6, 2002
Recommend
More recommend
