1. FEV’s Greatest Bloopers: False Positives in Formal Equivalence
Erik Seligman
CS 510, Lecture 7, January 2009
(Adapted from Seligman/Kim paper in DVCon 2007)

2. Agenda Introduction: FEV and False Positives Danger #1: Constraints
Danger #2: Libraries
Danger #3: Unreachables
Danger #4: Black Boxes
Danger #5: RTL Language Usage
Danger #6: Obscure Tool Behaviors
Advice and Conclusions

3. Agenda Introduction: FEV and False Positives Danger #1: Constraints
Danger #2: Libraries
Danger #3: Unreachables
Danger #4: Black Boxes
Danger #5: RTL Language Usage
Danger #6: Obscure Tool Behaviors
Advice and Conclusions

4. What is a False Positive?
False Positive: FEV incorrectly labels designs equivalent
Very costly
FEV typically gates 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

5. Agenda Introduction: FEV and False Positives Danger #1: Constraints
Danger #2: Libraries
Danger #3: Unreachables
Danger #4: Black Boxes
Danger #5: RTL Language Usage
Danger #6: Obscure Tool Behaviors
Advice and Conclusions

6. Constraints in FEV Constraints: Reduce 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: $constraint(foo | !bar | baz);
Conformal: add ‘-define CONSTRAINT’ to read design command to enable
Within one-many mapping: “a -> b c d”
Or combo of mapping + ‘add pin eq’ in Conformal

7. Example Where Constraint Needed
Block 1
Block 2 A C B
INVERSE (A,B) needed to prove C==0 in Block 2

8. Bad Constraints  False Positive
Conflicting pair of constraints
INVERSE(a,b)
Mapping: “a b -> c”
Why is this a problem?

9. 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
Vacuous pass: all inputs illegal
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) ?

10. Review & Formally Verify Your Constraints
Recommendation #1
Review & Formally Verify Your Constraints

11. Agenda Introduction: FEV and False Positives Danger #1: Constraints
Danger #2: Libraries
Danger #3: Unreachables
Danger #4: Black Boxes
Danger #5: RTL Language Usage
Danger #6: Obscure Tool Behaviors
Advice and Conclusions

12. 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

13. Example Of Library Assumption
out
Need OR here? a
Shorting together two wires– contention?
Cell is legal IF we guarantee INVERSE (a,b)
Save some transistors, power, area

14. Unproven Assumptions  False Positive
Processor FEV flow has ‘schematic assumption’ step
Required to prove assumptions on library cell inputs
Separate step from equivalence verification
Actually an FPV run embedded in the FEV flow, since proving an assertion rather than proving equivalence
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!

15. Make Sure Library Requirements are Verified and Understood
Recommendation #2
Make Sure Library Requirements are Verified and Understood

16. Agenda Introduction: FEV and False Positives Danger #1: Constraints
Danger #2: Libraries
Danger #3: Unreachables
Danger #4: Black Boxes
Danger #5: RTL Language Usage
Danger #6: Obscure Tool Behaviors
Advice and Conclusions

17. 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
So ‘unreachables’ may be important!

18. Reachable and Unreachable Flops
in1
out1 A
misc logic
A: Reachable
in1
misc logic B
B: Unreachable (logic tieoff) C
C: Unreachable (bonus flop)

19. Unreachables in Conformal
Default: reported, not mapped/compared
Be careful: two stages for elimination
Some unreachables eliminated on load
Some eliminated & reported during mapping
My preference: do a best-effort mapping
Compare any that were mapped
Review unmapped ones & signoff
Conformal commands
read design … -keep_unreach
set mapping method … –unreach

20. Lost Unreachables  False Positive
Bonus logic placed in ASIC design
RTL-netlist FEV, 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 late inspection

21. Monitor Unreachable Points Carefully
Recommendation #3
Monitor Unreachable Points Carefully

22. Agenda Introduction: FEV and False Positives Danger #1: Constraints
Danger #2: Libraries
Danger #3: Unreachables
Danger #4: Black Boxes
Danger #5: RTL Language Usage
Danger #6: Obscure Tool Behaviors
Advice and Conclusions

23. 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

24. “Analog” Black Box?  False Positive
FEV-able Glue Logic
True Analog Logic
Black Boxed Module

25. Be Very Careful About Black Boxing Logic
Recommendation #4
Be Very Careful About Black Boxing Logic

26. Agenda Introduction: FEV and False Positives Danger #1: Constraints
Danger #2: Libraries
Danger #3: Unreachables
Danger #4: Black Boxes
Danger #5: RTL Language Usage
Danger #6: Obscure Tool Behaviors
Advice and Conclusions

27. Odd Corners of Verilog What does this mean if WIDTH=2?
wire foo = {a, {(2-WIDTH){1’b0}}, b};
Why is this confusing?

28. Odd Corners of Verilog What does this mean if WIDTH=2? Does it mean
wire foo = {a, {(2-WIDTH){1’b0}}, b};
Why is this confusing?
Does it mean
{a,b}
{a,0,b} {}

29. Odd Corners of Verilog What does this mean if WIDTH=2? Does it mean
wire foo = {a, {(2-WIDTH){1’b0}}, b};
Why is this confusing?
Does it mean
{a,b}
{a,0,b} {}
Verilog standard was ambiguous, tools disagree!
This particular issue fixed in SystemVerilog: {a,b}

30. Language Ambiguity  False Positive
Originally synthesized with vendor tool
FEV tool from same vendor said design fine
Both tools had same interpretation
FEV tool from other vendor revealed diff
Embedded in huge logic cone, hard debug
Pressure to waive based on vendor FEV
Finally root-caused with vendor AEs
Designer intent disagreed with synthesis!

31. Preventing Language Issues
RTL Coding standards
Enforce thru linting tools
Examples: Synopsys LEDA, Atrenta Spyglass
Correct linting would flag ambiguous RTL
+ Avoid Synthesis & FEV from same vendor
Increases chance of catching these cases
Vendors try to push integration though!

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

33. Ensure Synthesis-FEV Independence
Recommendation #6
Ensure Synthesis-FEV Independence

34. Agenda Introduction: FEV and False Positives Danger #1: Constraints
Danger #2: Libraries
Danger #3: Unreachables
Danger #4: Black Boxes
Danger #5: RTL Language Usage
Danger #6: Obscure Tool Behaviors
Advice and Conclusions

35. Multi-Driven Nets Many ways to get driven in Verilog
assign statements
Input port to module
Connect to output of submodule
What if a net has multiple drivers?
Combine with some logic function (AND,OR)?
Report error?

36. Surprising Default Multi-driven nets treated as Wired AND
 result is AND of all drivers
Copied from common synthesis default
But is this always the intent?
Maybe it’s an error
Maybe user expected an OR
Maybe input accidentaly defined as output
This really happened in a design near tapeout
Incorrect logic treated as AND, only caught luckily thru late inspection!

37. Multiple Drivers in Conformal
set wire resolution [AND|OR|WIRE]
AND, OR = use logical function
WIRE = create special node (‘E’) and report
E points become standalone key points
Usually any occurrence is an error!
Default is AND
My recommendation: set to WIRE
Unless actively intending multi-drives

38. Understand your FEV tool, including obscure options.
Recommendation #7
Understand your FEV tool, including obscure options.

39. Agenda Introduction: FEV and False Positives Danger #1: Constraints
Danger #2: Libraries
Danger #3: Unreachables
Danger #4: Black Boxes
Danger #5: RTL Language Usage
Danger #6: Obscure Tool Behaviors
Advice and Conclusions

40. Recommendations See paper for details
Review and formally verify constraints.
Make sure libraries are verified & understood.
Monitor unreachable points carefully.
Be very careful about black boxing logic.
Make sure RTL is high-quality & fully linted.
Understand your FEV tool, including obscure options.
Ensure Synthesis-FEV independence.
Sanity-check FEV with at least some GLS (gate-level simulation) runs.
See paper for details

41. 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!

42. References / Further Reading