Upload
ondrea
View
53
Download
1
Tags:
Embed Size (px)
DESCRIPTION
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). Agenda. Introduction: FEV and False Positives Danger #1: Constraints Danger #2: Libraries Danger #3: Unreachables - PowerPoint PPT Presentation
Citation preview
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)
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
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
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
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
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
Example Where Constraint Needed
A
B C
Block 1 Block 2
INVERSE (A,B) needed to prove C==0 in Block 2
Bad Constraints False Positive Conflicting pair of constraints
• INVERSE(a,b)
• Mapping: “a b -> c” Why is this a problem?
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) ?
Recommendation #1
Review & Formally Verify Your Constraints
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
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– 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!
Recommendation #2
Make Sure Library Requirements are Verified and Understood
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
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!
Reachable and Unreachable Flops
in1
in1
A out1misc logic
misc logicB
C
A: Reachable
B: Unreachable (logic tieoff)
C: Unreachable (bonus flop)
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
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
Recommendation #3
Monitor Unreachable Points Carefully
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
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
Recommendation #4
•Be Very Careful About Black Boxing Logic
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
Odd Corners of Verilog
What does this mean if WIDTH=2?wire foo = {a, {(2-WIDTH){1’b0}}, b};
• Why is this confusing?
Odd Corners of Verilog
What does this mean if WIDTH=2?wire foo = {a, {(2-WIDTH){1’b0}}, b};
• Why is this confusing?
Does it mean• {a,b}
• {a,0,b}
• {}
Odd Corners of Verilog
What does this mean if WIDTH=2?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}
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!
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!
Recommendation #5
Make sure RTL is high-quality & fully linted
Recommendation #6
Ensure Synthesis-FEV Independence
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
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?
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!
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
Recommendation #7
Understand your FEV tool, including obscure options.
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
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
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!
References / Further Reading
http://www.aracnet.com/~eseligma/docs/dvcon_2007.pdf