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 constraintsOpen
  Verification Library (OVL)

6
Assertion Monitor Library
Assertion Monitor Library
assert_never underflow ( clk, reset_n,
(q_valid1b1) (q_underflow1b1))
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 _at_(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_countltASSERT_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_wr0 mqc_p1_wr0)
(mqc_p0_wr1 mqc_p1_wr1) )
assign p0_wr_p0_rd_broken (mqc_p0_wr_addr
mqc_p0_rd_addr) (
(mqc_p0_wr0 (p0_byp_even ! 2'b01))
(mqc_p0_wr1
(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
8
Enhancing Functional Verification
ifdef ASSERT_ON wire event1 (pdx_core_qpdxc_pio
bp_data_valid (qpdxd_data1512
XPTYPE_PIOB4) (pdx_core_qpdxd_data30
XTTYPE_WR_SHORT8) (qpdxd_data8167
KPDX_BLOCK_ADDR) (pdx_core_qpdxd_data8167
KPDX_FUNC_ID)) wire event2
(gfc_sync_ff) wire event3 ((rpdx_pi0_valid
pdx_core_rpdx_pi0_valid)
(rpdx_pdx_data1512
XPTYPE_PIOB2)
(pdx_core_rpdx_pdx_data30
XTTYPE_WRITE_DONE)
(qpdxd_data8167 KPDX_BLOCK_ADDR)

(pdx_core_qpdxd_data8167 KPDX_FUNC_ID))
endif
assert_cycle_sequence (0, 5) seq0 (clk, rst_n,
event1, 1, 1, event2, event3)
9
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-10 data_in output
fifo_width-10 data_out wire
fifo_width-10 data_out reg
fifo_width-10 fifofifo_depth-10 reg
fifo_cntr_w-10 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 cntfifo_depth)) // OVL Assert that
the FIFO cannot underflow assert_never
no_underflow (clk,(fifo_reset_n
fifo_clr_n), (push,pop2'b01 cnt0))
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
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
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.
• Whats the problem? Functional bugs missed in
  the RTL, requires gate-level simulation, bug
  usually found in silicon!

16
X-state Optimism
module mux (a,b,s,q) output q input a,
b input 10 s reg q always _at_(a or b or
s) begin case (s) //synopsys full_case
2b01 q b 2b10 q a
endcase end endmodule
. . . always _at_(posedge clk) begin if (rst)
s 2b0 else begin case (sel)
2b01 s 2b10 2b10 s 2b01
default s 2bx endcase end end . . .
17
Parallel Case Semantic Inconsistency - Problem
module encoder (y, z, a, b) output y, z input
10 a, b reg y, z always _at_(a or b) begin
y, z 2'b00 casez (a, b) 4b11?? z
1'b1 4b??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, (a2b11
b2b11))

• 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 todays
  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.