dcc grenoble april 6, 2002 unifying traditional and formal verification through property...

DCC Grenoble April 6, 2002

Unifying Traditional and Formal Verification Through Property Specification

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

AgendaAgenda

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

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


Formal Verification at HPFormal 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

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 VerificationEnhancing 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]

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)

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

RTLDesign

Assertion MonitorLibrary

Assertion MonitorLibrary

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

Assertion Monitor LibraryAssertion Monitor Library


`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



`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});



ASSERT_FRAME

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

min

time0

start_event

check_event

max

reqreq ackack

widthwidth


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%

ResultsResults


ResultsResults

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

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

Bu

gs

Fo

un

d

....

..

....

....

..

..

..



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.

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

Two aspects of equivalence require validation Logical consistency Semantic consistency

GoldenGoldenRTLRTL

FinalFinalNetlistNetlist



What is Semantic Inconsistency?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 OptimismX-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. . .

aaqq

s[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 - ProblemParallel Case Semantic Inconsistency - Problem

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

// parallel_case

Priority encoder

a[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: y

00

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 ResearchThoughts for Research

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

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


ConclusionConclusion

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.

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.

dcc grenoble april 6, 2002 unifying traditional and formal verification through property...

Documents

formal verification

u need

u results u thoughts

u challenges

functional verification

agenda u hewlettpackard

research u conclusion

strategic solution u