fev’s greatest bloopers: false positives in formal equivalence · 1 february 21-23, 2007 fev’s...

1

February 21-23, 2007

FEV’s Greatest Bloopers: False Positives in Formal Equivalence

Erik Seligman, Joonyoung Kim

Digital Enterprise Group

Erik Seligman, Joonyoung Kim, Intel Corporation 2

Agenda

• Introduction: FEV and False Positives

• Danger #1: Constraints

• Danger #2: Unreachables

• Danger #3: Libraries

• Danger #4: Black Boxes

• Advice and Conclusions


Agenda








What Is Formal Equivalence Verification? (FEV / LEC)

• Formally verify: Design A == Design B

– Design Models: RTL or netlists

– Check synthesis, netlist edits

– Formal = mathematical proofs, not simulation

• No dependence on test vectors

• FEV is widely available & fully deployed

– Efficient: FEV feasible for vast majority of designs

• State matching (mostly) required

• Break logic at latches/flops for comparison

– Reliable: Mathematical proofs == 100% accurate


What is a False Positive?

• False Positive: FEV incorrectly labels designs equivalent

– Very costly

• FEV typically gates transition to next design phase

• Wrong FEV answer at tapeout � silicon respin

• Not just theoretical– seen in Intel processors & ASICs

• Not discussing FEV tool bugs

– Many dangers for misuse when tool is OK


Agenda








Constraints in FEV

• Constraints: Reduce the set of possible values

• Turn off scan

• Known conditions on inputs

• Eliminate unused state encodings

• Numerous types can be defined

• Explicit: “add pin constraint 0…”

• RTL construct: $constraint(foo | !bar | baz);

• Within one-many mapping: “a -> b c d”


Bad Constraints � False Positive

• Conflicting pair of constraints

– INVERSE(a,b)

– Mapping: “a b -> c” � EQUAL(a,b)

• Result: no valid input space, so module passed

– INVERSE(a,b) && EQUAL(a,b) ???

– Dead silicon in processor A0 stepping!

• New tool feature would catch contradiction

– But what if first constraint was !(A & B)


Bad Constraints � False Positive

• Conflicting pair of constraints

– INVERSE(a,b)

– Mapping: “a b -> c” � EQUAL(a,b)

• Result: no valid input space, so module passed

– INVERSE(a,b) && EQUAL(a,b) ???

– Dead silicon in processor A0 stepping!

• New tool feature would catch contradiction

– But what if first constraint was !(A & B)

• Recommendation #1: Review & Formally Verify Your Constraints


Agenda








Library Cells and FEV

• Libraries of common cells used in designs

– AND, OR, Flip-Flops, etc.

– Often developed by remote team

• Library collateral supplied for FEV

– Logic representations trusted for higher-level FEV

• Analyze at transistor level every run? Too hard.

– Library team FEVs logic vs. actual circuits

– May come with assumptions on inputs

• Must prove for library to be valid


Example Of Library Assumption

• Shorting together two wires– contention?

• Cell is legal IF we guarantee INVERSE (a,b)

– Save some transistors, power, area

a

~a b

~b

out

Need OR here?


Unproven Assumptions � False Positive

• Processor FEV flow has ‘schematic assumption’ step

– Required to prove assumptions on library cell inputs

– Separate step from equivalence verification

• Design engineer didn’t understand requirement

– Formal Property Verification (FPV) optional in other areas

– Schematic Assumption step not run for one block

�Another false positive & broken A0 processor silicon!


Unproven Assumptions � False Positive

• Processor FEV flow has ‘schematic assumption’ step

– Required to prove assumptions on library cell inputs

– Separate step from equivalence verification

• Design engineer didn’t understand requirement

– Formal Property Verification (FPV) optional in other areas

– Schematic Assumption step not run for one block

�Another false positive & broken A0 processor silicon!

� Recommendation #2: Make Sure Library Requirements are Verified and Understood


Agenda








Unreachable Points in FEV

• Unreachable: flop/latch that cannot affect output

� can be logically ignored

– Must be ignored, if not in both models

• Common causes

– Synthesis optimizations

– Tied off no-longer-relevant logic

• But be careful about backend logic

– Some flows (scan, bonus cells) connect later


Reachable and Unreachable Flops

in1

in1

A out1misc logic

misc logicB

C

A: Reachable

B: Unreachable (logic tieoff)

C: Unreachable (bonus flop)


Lost Unreachables � False Positive

• Bonus logic placed in ASIC design

• RTL-netlist FEV passed, backend net-net passed– Bonus cells lost somewhere

– Intermediate FEV owners did not notice

• Problem aggravated by tool feature– Two places for unreachables: loading, mapping

– “Simple” bonus cells removed during loading

• Missing cells discovered at last minute inspection

Recommendation #3: Monitor Unreachable Points Carefully


Lost Unreachables � False Positive

• Bonus logic placed in ASIC design

• RTL-netlist FEV passed, backend net-net passed– Bonus cells lost somewhere

– Intermediate FEV owners did not notice

• Problem aggravated by tool feature– Two places for unreachables: loading, mapping

– “Simple” bonus cells removed during loading

• Missing cells discovered at last minute inspection

• Recommendation #3: Monitor Unreachable Points Carefully


Agenda








Black Boxes in FEV

• Some logic usually must be excluded

– IP received as-is from remote teams

– Pure analog blocks

• FEV tools allow black boxing

– Logic to boundaries of black box is verified

– But be careful!

• Audit to ensure everything is verified somewhere


“Analog” Black Box? � False Positive

FEV-able Glue Logic

True Analog Logic

Black Boxed Module


“Analog” Black Box? � False Positive

FEV-able Glue Logic

True Analog Logic

Black Boxed Module

• Recommendation #4: Be Very Careful About Black Boxing Logic


Agenda








Recommendations

1. Review and formally verify constraints.

2. Make sure libraries are verified & understood.

3. Monitor unreachable points carefully.

4. Be very careful about black boxing logic.

5. Make sure RTL is high-quality & fully linted.

6. Understand your FEV tool, including obscure options.

7. Ensure Synthesis-FEV independence.

8. Sanity-check FEV with at least some GLS (gate-level simulation) runs.

• See paper for details on issues not in presentation


Conclusions

• FEV is a powerful tool, reliable if used correctly!

• But false positives are a real danger– Issues seen in many projects at Intel

– Very costly, sometimes requiring new stepping

• Useful to recognize common causes– Misuse of constraints

– Library misunderstandings

– Excluded unreachable points

– Incorrect Blackboxing

• Understand your tools, library, and design!


Questions?


Backup Slides


Example Where Constraint Needed

A

B C

Block 1 Block 2

INVERSE (A,B) needed to prove C==0 in Block 2

fev’s greatest bloopers: false positives in formal equivalence · 1 february 21-23, 2007 fev’s...

Documents