Unifying Traditional and Formal Verification Through Property Specification

DCC Grenoble April 6, 2002

Unifying Traditional and Formal Verification Through Property Specification

Designing Correct Circuits 2002

Harry FosterVerplex Systems

Harry Foster DCC Grenoble April 6, 2002

Agenda

Hewlett-Packard and Formal Verification Enhancing Functional Verification Enhancing Equivalence Checking Results Thoughts for Research Conclusion


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


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]



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)


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 ìfdef ASSERT_ON integer error_count; initial error_count = 0; always @(posedge clk) begin ìfdef ASSERT_GLOBAL_RESET if (ÀSSERT_GLOBAL_RESET != 1'b0) begin èlse if (reset_n != 0) begin // active low reset_n èndif if (test_expr == 1'b1) begin error_count = error_count + 1; ìfdef ASSERT_MAX_REPORT_ERROR if (error_count<=ÀSSERT_MAX_REPORT_ERROR) èndif $display("%s : severity %0d : time %0t : %m", msg, severity_level, $time); if (severity_level == 0) $finish; end end end èndif //synopsys translate_on

endmodule

RTLDesign

Assertion MonitorLibrary

assert_never underflow ( clk, reset_n, (q_valid==1’b1) && (q_underflow==1’b1));

Assertion Monitor Library


ìfdef 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

èndif



ìfdef 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));

èndif

assert_cycle_sequence #(0, 5) seq0 (clk, rst_n, {event1, 1, 1, event2, event3});



ASSERT_FRAMESYNOPSIS

assert_frame #(severity_level, min, max) inst ( ck, start_event, check_expr);

min

time0

start_event

check_event

max

req ack

width


assert_frame #(0, 3, 7) req_ack ( ck, req, ack);


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)); ‘endifendmodule



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 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%

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%

Results


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

180

260302

265 Without Assertions

With assertions

200,000 CPU hours50,000 CPU hours

simulation timeline

Bug

s Fo

und

..

..

.

.. .

.

.



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.


Two aspects of equivalence require validation Logical consistency Semantic consistency

GoldenGoldenRTLRTL

FinalFinalNetlistNetlist



What is Semantic Inconsistency?

RTL design RTL design simulates differentlysimulates differently than the gate-level model. than the gate-level model.

Yet, the two models are Yet, the two models are logically equivalencelogically equivalence!!

What causes semantic inconsistency?What causes semantic inconsistency? Misuse of Misuse of X assignmentsX assignments in the RTL (optimistic behavior) in the RTL (optimistic behavior) Misuse of synthesis Misuse of synthesis full_casefull_case and and parallel_caseparallel_case pragmas pragmas Range overflowRange overflow in variable indexing. in variable indexing.

What’s the problem?What’s the problem? Functional bugs missed in the RTL, Functional bugs missed in the RTL, requires gate-level simulation, bug usually found in silicon!requires gate-level simulation, bug usually found in silicon!


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; endcaseendendmodule

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 endend. . .

aaqqs[0]s[0] 00

11s[1]s[1]

11

00

bb

XX

XX

bb

11

00

bb


modulemodule encoder (y, z, a, b); encoder (y, z, a, b);outputoutput y, z; y, z;inputinput [1:0] a, b; [1:0] a, b;regreg y, z; y, z;

alwaysalways @(a or b) @(a or b) beginbegin {y, z} = 2'b00;{y, z} = 2'b00; casezcasez (({a, b}{a, b})) 4’b11??: z = 1'b1;4’b11??: z = 1'b1; 4’b??11: y = 1'b1;4’b??11: y = 1'b1; endcaseendcaseendendendmoduleendmodule

Parallel Case Semantic Inconsistency - Problem

Based on Bening and Foster 2001Based on Bening and Foster 2001

// parallel_case

Priority encodera[0]a[1]

b[0]b[1]

z

y

b[1:0]b[1:0]

RTL: yRTL: y

a[1:0]a[1:0]

Gate: yGate: y00

11

1111

1111

1010

1111

11

11

0101

1111

11

11

0000

1111

11

11

y

za[0]a[1]

b[0]b[1]

Synthesized gate


assert_never a_and_b (clk, rst_n, (a==2’b11 & b==2’b11));

IP picked up from other lab contained both X assignments IP picked up from other lab contained both X assignments and pragmas (Bad Stuff!)and pragmas (Bad Stuff!)

Added in assertions for IP pick up from other labAdded in assertions for IP pick up from other lab

Obviously, X assignment and pragma safe usage properties Obviously, X assignment and pragma safe usage properties lends itself to automatic extraction from the RTLlends itself to automatic extraction from the RTL



Thoughts for Research

Coverage associated with formal proofs – e.g., formal fault models – particularly related to bounded and limited cycle proofs


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.

Documents

Unifying Traditional and Formal Verification Through Property Specification