Unifying Traditional and Formal Verification Through Property Specification

1. Unifying Traditional and Formal Verification Through Property Specification Designing Correct Circuits 2002 Harry Foster Verplex Systems

2. Agenda • Hewlett-Packard and Formal Verification • Enhancing Functional Verification • Enhancing Equivalence Checking • Results • Thoughts for Research • Conclusion

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

4. Enhancing Functional Verification Monitor-based specification • Monitor-Based Formal Specification of PCI [Shinmizu et al. FMCAD 2000] • 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 • FoCs-Automatic Generation of Simulation Checkers from Formal Specification [Abarbanel, et al. CAV 2000]. Specification driven simulation • Modeling Design Constraints and Biasing in Simulation Using BDDs [Yuan et al. ICCAD 1999]

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

6. Assertion Monitor Library Assertion Monitor Library assert_never underflow ( clk, reset_n, (q_valid==1’b1) && (q_underflow==1’b1)); moduleassert_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; 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 RTL Design

7. Enhancing Functional 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_neverp0_wr_p1_wr (clk, reset_n, p0_wr_p1_wr_broken ); assert_neverp0_wr_p0_rd ( clk, reset_n, p0_wr_p0_rd_broken ); //synopsys translate_on `endif

8. Enhancing Functional Verification `ifdef ASSERT_ON wireevent1= (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});

9. width min start_event max 0 check_event time Enhancing Functional Verification ASSERT_FRAME SYNOPSIS         assert_frame#(severity_level, min, max) inst ( ck, start_event, check_expr); req ack assert_frame#(0, 3, 7) req_ack ( ck, req, ack);

10. Enhancing Functional 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

11. Results Percentage of bugs detected using assertion monitors. Assertion Monitors 34% 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% • 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 Kantrowitz and Noack[DAC 1996] Assertion Monitors 25% Register Miscompare 22% Simulation "No Progress” 15% PC Miscompare 14% Memory State Miscompare 8% Manual Inspection 6% Self-Checking Test 5% Cache Coherency Check 3% SAVES Check 2% Taylor et at.[DAC 1998]

12. . With assertions 302 . 260 . 265 Without Assertions . . . 180 Bugs Found . . . . 50,000 CPU hours 200,000 CPU hours simulation timeline Results • 4300 OVL assertion monitors added to a 10M gate ASIC • Reach stable model quicker than previous method • Bug report open rate increased between projects • Bug report close rate decreased between projects • 85% of bugs in simulation found using assertions • Turn random on sooner

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

14. Golden RTL Final Netlist Enhancing Functional Verification • Two aspects of equivalence require validation • Logical consistency • Semantic consistency

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

16. s[1] 0 0 X 1 s[0] 0 X 1 1 q a b b b X-state Optimism . . . always @(posedge 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 end . . . module mux (a,b,s,q); output q; input a, b; input [1:0] s; reg q; always @(a or b or s) begin case (s) //synopsys full_case 2’b01: q = b; 2’b10: q = a; endcase end endmodule

17. Priority encoder a[0] a[1] z b[0] Synthesized gate y b[1] a[0] z a[1] b[0] y b[1] 00 01 10 11 a[1:0] 11 11 11 11 b[1:0] 1 1 1 0 RTL: y 1 1 1 Gate: y 1 Parallel Case Semantic Inconsistency - Problem module encoder (y, z, a, b); output y, z; input [1:0] a, b; reg y, z; always @(a or b) begin {y, z} = 2'b00; casez({a, b}) 4’b11??: z = 1'b1; 4’b??11: y = 1'b1; endcase end endmodule // parallel_case Based on Bening and Foster 2001

18. Enhancing Functional Verification assert_never a_and_b (clk, rst_n, (a==2’b11 & b==2’b11)); • IP picked up from other lab contained both X assignments and pragmas (Bad Stuff!) • Added in assertions for IP pick up from other lab • Obviously, X assignment and pragma safe usage properties lends itself to automatic extraction from the RTL

19. Thoughts for Research • Coverage associated with formal proofs – e.g., formal fault models – particularly related to bounded and limited cycle proofs

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