Upload
barney
View
50
Download
0
Embed Size (px)
DESCRIPTION
Unifying Traditional and Formal Verification Through Property Specification. Designing Correct Circuits 2002 Harry Foster Verplex Systems. Agenda. Hewlett-Packard and Formal Verification Enhancing Functional Verification Enhancing Equivalence Checking Results Thoughts for Research - PowerPoint PPT Presentation
Citation preview
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
Harry Foster DCC Grenoble April 6, 2002
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
Harry Foster DCC Grenoble April 6, 2002
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]
Harry Foster DCC Grenoble April 6, 2002
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)
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; 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
RTLDesign
Assertion MonitorLibrary
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_FRAMESYNOPSIS
assert_frame #(severity_level, min, max) inst ( ck, start_event, check_expr);
min
time0
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)); ‘endifendmodule
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 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
Harry Foster DCC Grenoble April 6, 2002
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
..
..
.
.. .
.
.
Harry Foster DCC Grenoble April 6, 2002
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.
Harry Foster DCC Grenoble April 6, 2002
Two aspects of equivalence require validation Logical consistency Semantic consistency
GoldenGoldenRTLRTL
FinalFinalNetlistNetlist
Enhancing Functional Verification
Harry Foster DCC Grenoble April 6, 2002
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!
Harry Foster DCC Grenoble April 6, 2002
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
Harry Foster DCC Grenoble April 6, 2002
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
Harry Foster DCC Grenoble April 6, 2002
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
Enhancing Functional Verification
Harry Foster DCC Grenoble April 6, 2002
Thoughts for Research
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
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.