Formal Hardware Verification @ IBM · If there is a useful verification algorithm, RuleBase...
20
© 2014 IBM Corporation Formal Hardware Formal Hardware Verification @ IBM Verification @ IBM DVClub Bangalore 3rd July 2014, Bangalore, India Pradeep Kumar Nalla Srobona Mitra Sudhakar R A
Transcript of Formal Hardware Verification @ IBM · If there is a useful verification algorithm, RuleBase...
© 2014 IBM Corporation
Formal Hardware Formal Hardware Verification @ IBMVerification @ IBM
DVClub Bangalore
3rd July 2014, Bangalore, India
Pradeep Kumar NallaSrobona MitraSudhakar R A
© 2014 IBM Corporation2
Agenda
Verification at IBM (Background and History)
Formal Verification using RuleBase SixthSense
Formal Verification: Execution/Adoption to IBM designs
© 2014 IBM Corporation3
Putting things in perspective
Courtesy : DAC’14 article/Mentor Graphics
© 2014 IBM Corporation4
Verification Techniques
Simulation and Acceleration– Explicit-state guided random walk
Scalable to HUGE designsMature methodology + tools for high coverage%Coverage inherently very limited
Misses bugs; never complete
Formal Verification (FV)– Exhaustive state coverage via symbolic algos
Yields (corner-case) bugs or proofsCapacity-limited to moderately-sized designs
Semi-formal Verification (SFV)– Combine symbolic + explicit search
Exposes corner-case bugs on large designsOnly yields bounded proofs
© 2014 IBM Corporation5
Model Checking Capacity
1
10
100
1000
10000
100000
1000000
1980 1985 1990 1995 2000 2005 2010 2015
Year
#R
eg
iste
rs
Design size at which some useful results could be expected from FV tool
Caveat: not guaranteed capacity;1) some tiny problems are unsolvable! 2) includes bounded proofsVery incomplete list; cumulative capacity trend leverages earlier innovations + SW engineering
BD
D-B
ased M
od
el Ch
ecking
Exp
licit-State M
od
el Ch
ecking
Ab
straction
-Refin
emen
t
SA
T-B
ased B
MC
Interp
olatio
n
Tran
sform
ation
-Based
Verif
Invarian
t-Based
IC3
Model Checking Capacity vs Time
Scalab
le E
qu
ivalence
Invarian
ts
Sem
i-Fo
rmal V
erif
Partitio
ned
BD
Ds
© 2014 IBM Corporation6
Formal Verification Evolution @ IBM
2000 2002 2006 2014
Early Times
Applied to small logics (~100s of registers)Manual Intensive w/ dedicated resourcesRequired setting up of complex drivers
Middle Ages
Advent of SFV, Parallel, SECLarger logics verified; higher coverageSame “look and feel” as simulationSEC key to many newer methodologies
Modern Era
Large scale FV applicationIntegrated approach / DLVOut-of-the-box methodologiesHigh speed, capacity toolsets
The Future…
Avoid duplicate workReusable methodologies / IPAutomation, automation…Stay tuned!
SFV: Semi-formal verificationSEC: Sequential Equivalence CheckingDLV: Designer-level Verification High tool capacity has enabled
profound methodology impact
FV Capacity = Usability
© 2014 IBM Corporation7
RTL(VHDL, Verilog)
Language Compile
Model Build
Physical VLSI Design Tools / Custom Design
Cycle-BasedModel
Boolean Equivalence
Check(Verity)
Software Simulator(MESA)
Hardware Accelerator
(Awan) Hardware Emulator
Driver/Checker
Assertions
Test Program
Generator(GPro, X-Gen)
C++Testbench
ConstrainedRandom
Testbench
PSL etc.
(Semi-) Formal Verification
(RuleBase SixthSenseEdition)
Verification Flow at IBM
© 2014 IBM Corporation8
Hierarchical Verification Progression
VPO Level
Block Level
Unit Level
Element Level
Chip Level
System Level
VBU Level
FormalVerification
SoftwareSimulation
HardwareAcceleration
HardwareEmulation
HardwareVerification
Hardware /Firmware
Verification
VBU = Virtual Bring-Up (chip)VPO = Virtual Power-On (system)
© 2014 IBM Corporation9
Agenda
Verification at IBM (Background and History)
Formal Verification using RuleBase SixthSense
Formal Verification: Execution/Adoption to IBM designs
© 2014 IBM Corporation10
Model checking with RuleBase SixthSense Edition
Spec
DUVEnvironment,Driver
Assertions, Properties
+ + ? [1:n]Fail+
Counter example
Pass+
Witness
Pass vacuously Bounded pass
© 2014 IBM Corporation11
Sequential Equivalence Checking
Hierarchical application enables high scalability
Sequential Equivalence Checking (SEC) Supports arbitrary changes that preserve IO behavior E.g., does Design1 behave identically to Design2? 1. RTL vs RTL (non-functional changes) 2. RTL vs netlist 3. Netlist vs Nestlist
Retiming, power optimization, logic minimization, …
Macro 1 Macro 3Macro 2 Macro n
Wrapper 1
Unit 1 Unit m
Chip
. . .
. . .
Lower levelsblack boxed
Leaf level
Design hierarchy
Lower levelsblack boxed
Lower levelsblack boxed
Game changing application of FV
End-to-end verification of entire chips
Invaluable productivity advantage, resource savings
Unbounded proofs are critical in SEC!
OLD Design
NEW Design
Initialization Data
InputConstraints
Simulation Assertions
Proof of Equality
MismatchTrace
:
SequentialEquivalence Checker
Initialized OLD Design
Initialized NEW Design
Inputs =?
Outputs
d1
Design1
initd2
Design2
init
?==
© 2014 IBM Corporation
Combinational rewriting
Sequential redundancy removal
Min-area retiming
Sequential rewriting
Input reparameterization
Localization
Target enlargement
State-transition folding
Circuit quantification
Temporal shifting + decomposition
Isomorphic property decomposition
Unfolding
Speculative reduction
Symbolic sim: SAT+BDDs
Semi-formal search
Random simulation
Bit-parallel simulation
Symbolic reachability
Property-directed reachability
Induction
Interpolation
Invariant generation
Array abstraction
Example Engines for internal designs
Expert System Engine orchestrates parallel optimal engine selection
If there is a useful verification algorithm, RuleBase SixthSense Edition likely has it!
Much innovation: necessity is the mother of invention; IBM has deep verification needs!
Also much collaboration!
© 2014 IBM Corporation13
140627registers
Design + Driver + Checker
Combinational Optimization
Engine
119147
regs
1320regs
79302
regs
Phase Abstraction Engine
189regs
Retiming EngineSemi-Formal Engine
Interpolation Engine
Localization Engine
Semi-Formal Engine
Induction Engine
… … …
Problemdecomposition via synergistic
transformations
Transformation-Based Verification
optimized, phase abstracted, localized trace
optimized, phase abstracted trace
optimized trace
Counterexample consistent with original design
Transformations are completely transparent to the user – internally
used to enable exponential speedups!
All verification results are in terms of original design
Parallel algo exploration,
(sub)problem solution
© 2014 IBM Corporation14
Example Transformations
Retiming
Localization
Forward
Backward
Redundancy removal
Logic Rewriting
© 2014 IBM Corporation15
Agenda
Verification at IBM (Background and History)
Formal Verification using RuleBase SixthSense
Formal Verification: Execution/Adoption to IBM designs
© 2014 IBM Corporation16
Hierarchical Verification Progression
VPO Level
Block Level
Unit Level
Element Level
Chip Level
System Level
VBU Level
FormalVerification
SoftwareSimulation
HardwareAcceleration
HardwareEmulation
HardwareVerification
Hardware /Firmware
Verification
VBU = Virtual Bring-Up (chip)VPO = Virtual Power-On (system)
“Deep dive” FVObtain proofsFind corner case bugs
Defined interfacesEnd-to-end check (e.g. FPUs)
Starvation free arbitration
Pervasive verificationProtocol analysisRecreate bring-up fails
Inter-chip interactions
FV brings value across
hierarchy
© 2014 IBM Corporation17
Quality Refinement Process
Because controllability, state coverage is higher, and cost of a bug is lower, at lower levels :
Every major bug find at higher level is treated as escape of lower level
Lower level team gets feedback to reproduce problems
– Harden lower level environments
– Reproduce with targeted block-level checkers• Prove fixes with formal verification
VPO Level
Block Level
Unit Level
Element Level
Chip Level
System Level
VBU Level
© 2014 IBM Corporation18
Liveness Checks
Liveness property asserts that something good eventually will hold
Example: request eventually should get a grant
Trace consists of infinite length
Simulation inherently incapable of proving liveness:– Checking is ad-hoc– Keeps no record of visited states
Formal suitable for both proof and bug – but added complexity
Liveness is a desirable property to verify off a variety of logics– Arbitration – check requests are eventually granted– FSM – a final state is eventually reached /there is no hang in the FSM– LRUs – every entry has a path to LRU
In practice may be approximated by bounded safety checking– Check for the event occurring within a bound (time steps)– If we get a proof, we are done; counterexample may be spurious
reqArbiter
gnt
19
Things to solve in formal
In design/verification
Absence of detailed design documentation
Getting designers bandwidth
FV team not involved during early phases of design/verification
PACKs
In tools
Improve bit-level verification, falsification algorithms !
Improve bit-level synthesis algorithms !
Improve high-level verification algorithms (e.g. SMT)
© 2014 IBM Corporation20
References
Project homepage– http://www.haifa.il.ibm.com/projects/verification/RB_Homepage
Technical publications– https://www.research.ibm.com/haifa/projects/verification/SixthSense– https://www.research.ibm.com/haifa/projects/verification/RB_Homepage/publications.html
Contact:– Jason Baumgartner [email protected]– Viresh Paruthi [email protected]– Sudhakar R Amireddy [email protected]– Pradeep Nalla [email protected]– Eli Arbel [email protected]– Srobona Mitra [email protected]
