SLIDE 1
DCC Grenoble April 6, 2002
Harry Foster DCC Grenoble April 6, 2002
Unifying Traditional and Unifying Traditional and Formal - - PowerPoint PPT Presentation
Unifying Traditional and Unifying Traditional and Formal - - PowerPoint PPT Presentation
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
SLIDE 2
SLIDE 3
Harry Foster DCC Grenoble April 6, 2002
Formal Verification at HP 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
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
SLIDE 4
Harry Foster DCC Grenoble April 6, 2002
Enhancing Functional 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] 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]
SLIDE 5
Harry Foster DCC Grenoble April 6, 2002
Enhancing Functional Verification 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) 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)
SLIDE 6
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
RTL Design RTL Design
Assertion Monitor Library Assertion Monitor Library
assert_never underflow ( clk, reset_n, (q_valid==1’b1) && (q_underflow==1’b1));
Assertion Monitor Library Assertion Monitor Library
SLIDE 7
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 Enhancing Functional Verification
SLIDE 8
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 Enhancing Functional Verification
SLIDE 9
Harry Foster DCC Grenoble April 6, 2002
ASSERT_FRAME
SYNOPSIS assert_frame #(severity_level, min, max) inst ( ck, start_event, check_expr);
min time start_event check_event max
req req ack ack width width
Enhancing Functional Verification Enhancing Functional Verification
assert_frame #(0, 3, 7) req_ack ( ck, req, ack);
SLIDE 10
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;
- utput [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
Enhancing Functional Verification Enhancing Functional Verification
SLIDE 11
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 Monitors34%
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
SLIDE 12
Harry Foster DCC Grenoble April 6, 2002
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 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 260 302 265 Without Assertions With assertions 200,000 CPU hours 50,000 CPU hours simulation timeline
Bugs Found
. . . . . . . . . . . .. . . . . . . .
SLIDE 13
Harry Foster DCC Grenoble April 6, 2002
Enhancing Functional Verification 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.
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.
SLIDE 14
Harry Foster DCC Grenoble April 6, 2002
Two aspects of equivalence require validation
Logical consistency Semantic consistency
Two aspects of equivalence require validation
Logical consistency Semantic consistency
Golden Golden RTL RTL Final Final Netlist Netlist
Enhancing Functional Verification Enhancing Functional Verification
SLIDE 15
Harry Foster DCC Grenoble April 6, 2002
What is Semantic Inconsistency? What is Semantic Inconsistency?
- RTL design
RTL design simulates differently simulates differently than the gate-level model. than the gate-level model.
- Yet, the two models are
Yet, the two models are logically equivalence logically equivalence! !
- What causes semantic inconsistency?
What causes semantic inconsistency?
- Misuse of
Misuse of X assignments X assignments in the RTL (optimistic behavior) in the RTL (optimistic behavior)
- Misuse of synthesis
Misuse of synthesis full_case full_case and and parallel_case parallel_case pragmas pragmas
- Range overflow
Range 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!
SLIDE 16
Harry Foster DCC Grenoble April 6, 2002
module mux (a,b,s,q);
- utput 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
X-state Optimism 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 . . .
a a
q q
s[0] s[0]
1 1
s[1] s[1]
1 1 b b
X X
X X
b b 1 1 b b
SLIDE 17
Harry Foster DCC Grenoble April 6, 2002
module module encoder (y, z, a, b); encoder (y, z, a, b);
- utput
- utput y, z;
y, z; input input [1:0] a, b; [1:0] a, b; reg reg y, z; y, z; always always @(a or b) @(a or b) begin begin {y, z} = 2'b00; {y, z} = 2'b00; casez casez ( ({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; endcase endcase end end endmodule endmodule
Parallel Case Semantic Inconsistency - Problem Parallel Case Semantic Inconsistency - Problem
Based on Based on Bening Bening and Foster 2001 and Foster 2001
// parallel_case Priority encoder
a[0] a[1] b[0] b[1] z y
b[1:0] b[1:0] RTL: y RTL: y a[1:0] a[1:0] Gate: y Gate: y
1 1 11 11 11 11 10 10 11 11
1 1 1 1
01 01 11 11
1 1 1 1
00 00 11 11
1 1 1 1
y z a[0] a[1] b[0] b[1]
Synthesized gate
SLIDE 18
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 and pragmas pragmas (Bad Stuff!) (Bad Stuff!)
- Added in assertions for IP pick up from other lab
Added in assertions for IP pick up from other lab
- Obviously, X assignment and
Obviously, X assignment and pragma pragma safe usage properties safe usage properties lends itself to automatic extraction from the RTL lends itself to automatic extraction from the RTL
Enhancing Functional Verification Enhancing Functional Verification
SLIDE 19
Harry Foster DCC Grenoble April 6, 2002
Thoughts for Research Thoughts 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
SLIDE 20
Harry Foster DCC Grenoble April 6, 2002