1. art and entertainment
2. visual art and design
3. design

Viresh Paruthi, Jason Baumgartner
IBM Systems and Technology Group, Austin TX, USA
Formal Verification at IBM:
Applications and Technology Overview
© 2014 IBM Corporation
Outline
 Introduction
 Formal Verification @ IBM
 Technology
Ru!eBase
SixthSense edition
 Conclusion
2
© 2012 IBM Corporation
Introduction to Hardware Verification

Numerous types of verification relevant to hardware design
always @(posedge clk) begin
if ( r ) then p <= 0
else p <= p+1;
end if;
end
Netlist
HDL
Equivalence
Checking

Schematic
Equivalence
Checking
Layout
Layout vs
Schematic
IC
Wafer
Test
Also timing analysis, circuit analysis, protocol analysis, …
© 2012 IBM Corporation
Introduction to Hardware Verification

We focus upon functional verification and equivalence checking
IEEE
Standard
754-2008
always @(posedge clk) begin
if ( r ) then p <= 0
else p <= p+1;
end if;
end
Netlist
HDL
Functional
Verification

…
Equivalence
Checking
Though the techniques we discuss may also be applied to architectural models, protocol
models, software-like models, …
– As long as they are synthesizable
© 2012 IBM Corporation
Avenue N
Traffic Light Controller (TLC)
State
Input
(N/S,E/W)
Next-State
Output
(N/S,E/W)
NG
( -- , nC )
NG
(G,R)
NG
( -- , C )
NY
(G,R)
NY
( -- , -- )
EG
(Y,R)
EG
( nC , -- )
EG
(R,G)
EG
( C , -- )
EY
(R,G)
EY
( -- , -- )
NG
(R,Y)
Avenue E
I=(--,nC)
NG
I=(--,C)
I=(--,--)
O=(G,R)
O=(Y,R)
NY
EY
O=(R,Y)
O=(R,G)
I=(--,--)
EG
I=(C,--)
I=(nC,--)
© 2012 IBM Corporation
Verification Step 1
 Unit testing, a.k.a. designer verification
– Check for intended behavior against a selection of input vectors
I=(--,nC)
I=(--,C)
NG
I=(--,--)
?
O=(G,R)
O=(Y,R)
NY
EY O=(R,Y)
I=(--,--)
EG
I=(C,--)
NG
I=(--,C)
O=(R,G)
I=(--,nC)
NY
EY
I=(C,--)
NG
I=(--,--)
EG
I=(--,--)
NG
?
I=(nC,--)
– Investigate streams of state transitions and outputs
– Light weight check, low “coverage”
© 2012 IBM Corporation
Verification Step 2 – Specification
 Properties – True for every possible execution
– Safety – Nothing bad happens
• N/S and E/W lights should never be GREEN at the same time
• None of the lights should transition from GREEN directly to RED
– Liveness – Something good eventually happens
• Both N/S and E/W lights will turn GREEN eventually
“Verification is only as good as the specification”
© 2012 IBM Corporation
Verification Step 3
 Simulation
– Systematically check the design satisfies its specification
– Against directed or random input streams
I=(--,nC)
I=(--,C)
NG
?
I=(--,--)
?
O=(G,R)
I=(--,nC)
NG
I=(--,C)
O=(Y,R) NY
EY O=(R,Y)
I=(--,C)
O=(R,G)
I=(--,--)
EG
I=(C,--)
NG
NY
EY
I=(--,--)
NY
I=(--,--)
I=(--,--)
EG
I=(C,--)
NG
?
I=(nC,--)
– A “(random) walk” of the state space of the design
– Incomplete – cannot rule out presence of bugs
© 2012 IBM Corporation
We done…?
Let’s take a simple real world ALU
A (32-bit)
B (32-bit)
Time need
to visit all states
Model size
Add / Mul / Div / Rot…
Model speed
Number
of State/Input Bits
C (64-bit)
Source: Comprehensive Functional Verification, Wile, Roesner, Goss
Number of patterns to verify a single op: 18,446,744,073,709,551,616
A super-fast simulator running at 1 MHz or 1 million patterns/sec will take 584,942 years to
verify a single op!
June 1994: Pentium div bug costs $$$$$$$ in parts replacement cost to Intel
© 2012 IBM Corporation
Verification Step (4)
NG
 Formal Verification
I=(--,nC)
NG
– Rigorously prove the design satisfies its specification
NG
I=(--,--)
I=(--,nC)
I=(--,nC)
I=(--,C)
NG
I=(--,nC)
O=(Y,R) NY
NG
NY
I=(--,--)
I=(C,--)
EY O=(R,Y)
EG
NY
I=(nC,--)
EG
EY
I=(nC,--)
EY
EG
I=(--,--)
NG
EG I=(C,--)
EY
I=(--,--)
O=(R,G)
I=(--,--)
EG
EG
I=(--,--)
NG
I=(--,C)
NY I=(--,--)
I=(C,--)
I=(--,--)
O=(G,R)
NY
I=(--,--)
I=(--,nC)
I=(C,--)
I=(nC,--)
EG
I=(nC,--)
Step 0
Step 1
Step 2
Step 3
Step 4
– Exhaustive exploration of the state space of the design
– Complete – conclusively establishes correctness / absence of bugs
© 2012 IBM Corporation
Verification Step (5)
 Semi-formal Verification
– Alternate between visiting one-state-at-a-time and exhaustive search
– Resource bounded formal exploration amplifies simulation results
?
NG
I=(--,nC)
I=(--,C)
NG
NY
?
I=(--,--)
I=(--,nC)
O=(G,R)
O=(Y,R)
I=(--,nC)
EY O=(R,Y)
NG
NY
I=(--,--)
EG
I=(--,--)
I=(nC,--)
I=(C,--)
EG
EY
I=(--,--)
NG
NG
?
I=(nC,--)
EG I=(C,--)
EY
O=(R,G)
I=(--,--)
EG
I=(C,--)
I=(nC,--)
EG
I=(nC,--)
– Incomplete, high(er) coverage
– Happy medium
© 2012 IBM Corporation
Verification Step 6 – Debug!
 Liveness property fails
– Reveals a recurring path in the logic where E/W light never goes GREEN
• Because a legal path exists where no car arrives on E/W route
I=(--,nC)
I=(--,C)
NG
I=(--,--)
I=(--,nC)
O=(G,R)
O=(Y,R)
NY
EY O=(R,Y)
O=(R,G)
I=(--,--)
EG
I=(C,--)
NG
NG
I=(--,nC)
I=(nC,--)
– The driver needs to specify a “fairness” constraint
• The E/W light have a car (C) arrive every so often
© 2012 IBM Corporation
Formal Verification Concepts
Design-Under-Test
Driver
entity ....
end ...;
architecture....
....
Checker
...
end .....
 Randomness / Non-determinism
Testbench
– Foundation of the exhaustive exploration with considering all (legal) valuations
• Every input at every step of the evaluation
• In contrast to simulation which applies a single value at every step
 “Passive” Testbench
– Define legal behavior of the inputs
• Encode stimulus generator (logic’ally)
• Specify “constraints” (assumptions) to rule out illegal stimulus
• Risks “over constraining” – mask out valid stimulus compromising completeness
– In contrast to “active” testbench in simulation – applies stimulus every cycle
“Verification is only as complete as the driver”
© 2012 IBM Corporation
FV Task Life Cycle
Understand Design-Under-Test (DUT) function
Write the driver / environment (constraints)
Write checkers and verify to validate environment
Write checkers and assertions (spec) and verify DUT
Regress
© 2012 IBM Corporation
TLC is Arbitration!
 Arbiters
– Restrict access to a shared resource
• E.g. bus access where all requestors cannot be serviced concurrently
Requests
Arbiter
Fairness
Arbiter
Grants
– Verification goals:
• Starvation, Mutual Exclusion / Collision
© 2012 IBM Corporation
TLC “Systems”
 Tandem operation
– Dynamic coordinated
control
– Sensors, Adaptive
timers
 Traffic flow
– Synchronization
– Vehicles / Time
– Back-pressure
© 2012 IBM Corporation
System-level FV
Core #1
Core #2
L2 / L3
Cache
L2 / L3
Cache
Core #8
........
L2 / L3
Cache
Bus Arbiter
MC
MC
 Arbitration of large number of requests from various sources
 A multi-stage arbitration organized as a reduction trees
 Liveness check is insufficient, accurate request-to-grant delay crucial aspect
– Ascertain performance, throughput…
 FV techniques are able to accurately measure worst case performance
– Decouple fairness logic from core arbitration
– Check grant of requests “boundedly”
© 2012 IBM Corporation
FV Scalability Smarts
 Reductions
– Include least amount of relevant logic
• E.g. L3 hangs – include a few CO/CI machines
– Localization – carve out logic sufficient to verify spec
• E.g. one-hot mux-selects need logic up to source
Vehicles/
Time
 Abstractions
– Replace actual logic with behavioral with sufficient detail to verify
• Caveat: Abstractions by definition are “leaky”
• E.g. verify overall bus arbitration with abstracting on-chip traffic
 Decomposition
– Divide-and-conquer
• Verify components in isolation and compose results
– Requires verifying interface protocol rigorously
Lower level
Black-boxed
Chip
Unit 1
Unit m
..
Wrapper 1
Macro 1
Macro 2
...
Design hierarchy
Macro n
Leaf level
© 2012 IBM Corporation
FV Planning
Candidates for FV application
 Protocol verification
 Mission-critical components/aspects
 Early-RTL debug and exploration
 Logic with low DV coverage
 Clock-domain crossings
 Logic with liveness, fairness requirements
 Control-intensive units
 Aiding DV to hit elusive coverage goals
 Sequential equivalence checking
 Recreating lab bugs
© 2012 IBM Corporation
Outline
 Introduction
 Formal Verification @ IBM
– Evolution
– Verification Methodology
– Sequential Equivalence Checking
Ru!eBase
SixthSense edition
 Technology
 Conclusion
20
© 2012 IBM Corporation
Formal Verification Evolution @ IBM
Paruthi FMCAD 2010
The Future…
Middle Ages
Early Times
Modern Era
2000
2002
2006
Advent of SFV, Parallel, SEC
Larger logics verified; higher coverage
Same “look and feel” as simulation
SEC key to many newer methodologies
Applied to small logics (~100s of registers)
Manual Intensive w/ dedicated resources
Required setting up of complex drivers
SFV: Semi-formal verification
SEC: Sequential Equivalence Checking
DLV: Designer-level Verification
21
2012
Avoid duplicate work
Reusable methodologies / IP
Automation, automation…
Stay tuned!
Large scale FV application
Integrated approach / DLV
Out-of-the-box methodologies
High speed, capacity toolsets
High tool capacity has enabled
profound methodology impact
FV Capacity =
Usability
© 2012 IBM Corporation
Formal Verification at IBM
 Vision: Bring FV to the masses
– Common infrastructure → Trivial learning curve, resource savings
– Shared / reusable verification IP → High ROI, tight integration
– High scalability → Improved productivity
Amortize development cost → Higher value proposition
 Synergistic application alongside other verification disciplines
– Focused on the same problems
22
© 2012 IBM Corporation
Verification Technology
RTL
(VHDL, Verilog)
Physical VLSI
Design Tools /
Custom Design
Driver/Checker
Assertions
PSL et al.
Language Compile
Model Build
Test Program
Generator
(GPro, X-Gen)
Cycle-Based
Model
C++
Testbench
Boolean
Equivalence
Check
(Verity)
23
(Semi-) Formal
Verification
(RuleBase SixthSense
Edition)
Constraint
Random
Testbench
Software Simulator
(MESA)
Hardware
Accelerator
(Awan)
Hardware
Emulator
© 2012 IBM Corporation
IBM Systems and Technology Group
Integrated Approach: Design
 Assertion-based Verification (ABV)
i1
Designer-level Verification (DLV)
in
– Require designers to capture assumptions as verif objects (checkers)
• Accelerated debug, faster IP integration, documentation…
..
.
MUX
o
...
s1 sn
One-hot
– …and perform basic verification leveraging those
• High ROI: Improved productivity / cost / schedule, efficient use of resources
– Reuse events (checkers, coverage)
• Proof design events with FV
FV events / assumptions cross-checked
Complete
Driver
Simple
Driver
Assertions
Enables
Integrated
Checking
Enables
Stimulus
Vhdl
Simulation
H/W
Accel
Semi- Formal
Verification
Assertion-Based Verification
Designer-Level Verification
Block-Level Verification
24
© 2012 IBM Corporation
Integrated Approach: Verification
 Better synergy with other verification disciplines
– Formal plans drawn collaboratively with design and simulation teams
– Optimized testplans via detailed reviews with simulation team
• Unified view of verification “coverage” inclusive of simulation and formal
 Minimize duplicate work in verif disciplines
Book verification of logics in formal
– LRUs, Arbitration, Debug Bus, Mux-based networks…
25
© 2012 IBM Corporation
Verification Progression
VPO Level
Hardware
Emulation
Hardware /
Firmware
Verification
VBU Level
Inter-chip interactions
System Level
Hardware
Acceleration
Chip Level
Element Level
Software
Simulation
Unit Level
Formal
Verification
Starvation free arbitration
Defined interfaces
End-to-end check (e.g. FPUs)
Block Level
VBU = Virtual Bring-Up (chip)
VPO = Virtual Power-On (system)
26
Hardware
Verification
Pervasive verification
Protocol analysis
Recreate bring-up fails
“Deep dive” FV
Obtain proofs
Find corner case bugs
© 2012 IBM Corporation
Scaling Formal Testbenches
 Wide-spread adoption of FV requires scalability to simulation-sized testbenches
– Easier to specify well-documented functional units vs. components thereof
• Simpler (constraints-based) drivers – higher productivity
 Create “Templates” – blueprint to verify a certain type of logic
– A cook-book approach / recipe to check complex RTL implementations
– Predictable, portable, repeatable, teachable…
– L2, MC, LSU, ISU…
Driver
Block 1
Driver
Driver
Block 1 Checker
(Properties)
Block 2
Driver
Block 2 Checker
(Properties)
(Sub-) Unit
Driver
Block 1
Block 2
Driver
Testbench
Components
Design
Components
Block 1 Checker
(Properties)
Block 2 Checker
(Properties)
© 2013 IBM Corporation
High-level Modeling Support
entity e1 is
port (i1: in std_ulogic_vector(0 to 3);
we,re: std_ulogic;
o1: out std_ulogic_vector(0 to 3));
end;
 Raise level of abstraction of the testbench specification
 Provide rich set of convenience functions as VHDL support library
 Parameterized functions encapsulate commonly used logic constructs
architecture e1 of e1 is
signal ff: hl_fifo(fifo(0 to 3)(0 to 3));
begin
process (ALL)
begin
if (we = '1') then
fifo_push(ff, i1);
end if;
if (re = '1') then
fifo_pop(ff, o1);
end if;
end process;
end;
– Clocks generation (e.g., oscillator), edge detection (falling, rising)
– Vector processing functions – one hot, parity, hamming distance…
– Waveform drivers (wave, pulse), counters, delays, FIFO…
 PSL (VHDL) events managed as part of unified event management support
28
© 2012 IBM Corporation
Formal Verification IP
Off-the-shelf IP to improve verification productivity and quality
– Code reusability – faster verification times
– Formalization of the spec – improved accuracy and coverage
– Standardization – implementation independent
package arbiter_rules_and_driver_pkg is
property not_bounded_starve (const N; boolean request, grant) is
never {request; not grant[*N]}!;
Sequence start
Next clock
N repetitions
Sequence end
…
end package arbiter_rules_and_driver_pkg;
Checker VHDL:
use vhdl_packages.arbiter_rules_and_driver_pkg.all;
…
assert not_bounded_starve(N, request, grant);
29
© 2012 IBM Corporation
IBM Systems and Technology Group
Equivalence Checking
Combinational Equivalence Check (CEC)
Sequential Equivalence Check (SEC)
Logic
1
Logic
1
x
s
d1
0?
init
d1
{x0, x1, …}
Logic
2
Logic
2
0?
d2
 Requires 1:1 state elements mapping
 Cannot handle sequential behavior
• Validates next-state functions and outputs
{0, 0, …}?
d2
init
 Supports arbitrary design changes (I/O equivalent)
• Retiming, power saving, redundant logic…
 Explores sequential behavior of the designs
• Computationally more complex than CEC
 Verify transistor- / gate-level design against RTL
30
© 2012 IBM Corporation
Sequential Equivalence Checking
Sequential Equivalence Check (SEC)
:
OLD Design
Simulation
Assertions
Sequential
Equivalence
Checker
NEW Design
Initialization
Data
Input
Constraints
Mismatch
Trace
Initialized
OLD Design
Inputs
Supports arbitrary design changes (I/O equivalent)
Proof of
Equality
Outputs
Explores sequential behavior of designs
Retiming, power saving, redundant logic…
=?
Initialized
NEW Design
Hierarchical application scales to large enough design partitions
Lower levels
black boxed
Chip
Game changing application of the technology
Unit 1
Unit m
...
Wrapper 1
Macro 1
Macro 2
Macro 3
Macro n
Lower levels
black boxed
End-2-end verification of entire chips
Lower levels
black boxed
Invaluable productivity advantage, resource savings
Leaf level
...
Design hierarchy
31
© 2012 IBM Corporation
Outline
 Introduction
 Formal Verification @ IBM
 Technology
– Core proof / falsification techniques
– Transformation-Based Verification (TBV)
– Research and development
– Supported languages and environments
Ru!eBase
SixthSense edition
 Conclusion
32
© 2012 IBM Corporation
Netlist-Based Verification
A state is a valuation to the latches / registers in the design
Input
stimulus
Combin
ational
logic
0
1
0
Initial values define the initial states
Next-state functions define the state transitions
Reachable states: which may be transitioned to from initial states
A bad state refers to one violating a property: a bug
33
© 2012 IBM Corporation
Netlist-Based Verification: Goals
1) A counterexample trace, from an initial state to a bad state
Initial
States
2) Or a proof that no such trace exists
 Proofs generally requires a reachable state computation
34
© 2012 IBM Corporation
Verification with RuleBase SixthSense Edition
Environment,
Driver
DUV
Assertions,
Properties
+
Fail
+
Counter example
35
+
Pass
+
Witness
?
Pass vacuously
[1:n]
Bounded pass
© 2013 IBM Corporation
Supported languages
 Hardware description languages
– Verilog, VHDL, Mixed
– GDL (mainly for protocol verification)
 Assertion languages
– PSL: standalone checker or embedded in HDL
– SVA
 Verification directives
– Assertions, Coverage points
– Assumptions
– Full liveness, fairness, restrict support
 Support for various trace browsers
 High capacity via Transformation-Based Verification
36
© 2013 IBM Corporation
Simulation (Validation vs Verification)
 A “random walk” through the state space of the design
Stimulus can be random (constrained, biased); from manual
testcases; from testcase generators
Incomplete
+ Very robust set of tools & methodologies available
coverage
 The original method for functional verif; FV came decades later of huge
designs
+ Scalable: applicable to designs of any size
– Explicit one-state-at-a-time nature severely limits attainable coverage
– Cannot yield proofs; fails to expose all bugs, tedious to cope with
37
© 2013 IBM Corporation
Acceleration
 Like simulation, though uses reconfigurable hardware (eg FPGAs) vs
software-interpreted models
+ Often 10000+ faster than simulation
+Enables deep evaluation such as virtual power-on
- Though accelerators are expensive ($1M+)
- Somewhat size-gated: model must fit available architecture
- Performance degrades if testbench cannot be evaluated purely in
synthesized model
38
© 2013 IBM Corporation
Formal Verification (FV)
FV refers to exhaustive verification: proof capable
 Use symbolic vs explicit analysis, e.g. BDDs or SAT solvers
 Enables astronomically higher coverage than simulation: 2>>1000 vs 2<40
Complete
Generally requires analysis of reachable states: size limited
coverage
of smaller
 Though many advanced techniques exist to overapproximate reachable
designs
states, reduce design size, abstract irrelevant behavior
Great capacity gains over past decades, though still size-limited
39
© 2013 IBM Corporation
Semi-Formal Verification (SFV)
Refers to using symbolic algorithms in an incomplete way
1) Bounded model checking: any bug within k steps of initial states?
2) Semi-formal extensions: within k steps of other reachable states?
Offers astronomical coverage of symbolic algos on larger designs
 Powerful bug-hunter
Though still size-limited vs. simulation and acceleration
40
© 2013 IBM Corporation
Transformation-Based Verification

Encapsulates engines against a modular API
– Transformation engines, proof engines, falsification engines

Modular API enables maximal synergy between engines
– Each (sub)problem may be addressed with an arbitrary sequence of algos
– Motivation: every problem is different; different algorithm sequences may be
exponentially more / less effective on a given problem

Incrementally chop complex problems into simpler problems, until tractable for
core verification algos
– Recall exponential relation between verification complexity and design size
41
© 2012 IBM Corporation
Transformation-Based Verification
140627
registers
Design +
Driver +
Checker
Counterexample
consistent with
original design
119147
regs
Combinational
Optimization
Engine
Problem
decomposition
via synergistic
transformations
79302Transformations
optimized,
Phase Abstraction are completely
transparent
Engineto the user – internally
regs
phase abstracted
used to enable exponential
trace
speedups!
Induction
All
Engine
Semi-Formal
Engine
Parallel algo
exploration,
(sub)problem
solution
42
optimized
trace
Semi-Formal
Engine
1320results
verification
areEngine
in terms optimized,
Localization
phase abstracted,
of regs
original design
localized trace
Interpolation
Engine
…
189
regs
…
Retiming Engine
…
© 2012 IBM Corporation
Example Engines
 Combinational rewriting
 Unfolding
 Sequential redundancy removal
 Speculative reduction
 Min-area retiming
 Symbolic sim: SAT+BDDs
 Sequential rewriting
 Semi-formal search
 Input reparameterization
 Random simulation
 Localization
 Bit-parallel simulation
 Target enlargement
 Symbolic reachability
 State-transition folding
 Property-directed reachability
 Circuit quantification
 Induction
 Temporal shifting + decomp
 Interpolation
 Isomorphic property decomp
 Invariant generation
 Array abstraction

Expert System Engine orchestrates parallel optimal engine selection

If there's a useful model checking algorithm in the world, RuleBase SixthSense Edition
probably has it
© 2012 IBM Corporation
Example Transform 1: Retiming

Retiming eliminates state elements by moving them across gates
– Moving a state element across a gate time-shifts its behavior

Very effective at reducing overhead of pipelined designs
– 62% reduction attained on POWER4 netlists
44
© 2012 IBM Corporation
Example Transform 2: Redundancy Removal
 Redundancy is prevalent in verification testbenches, e.g.:
– Deliberate logic replication to reduce delay (due to placement issues)
– Disabled pervasive logic such as scan-chains
– Redundancies between design + checker
 May be eliminated through redundancy removal
45
© 2012 IBM Corporation
Example Transformation 3: CEGAR-Based Localization
Abstraction that reduces netlist size via cutpointing internal gates
Counterexample-Guided Abstraction Refinement
1) Begin with an arbitrary small abstraction
2) Perform verification on the abstraction
3) Proof obtained on abstract model? Pass
4) Counterexample found? Check if valid w.r.t. original netlist
 Yes? Fail
 No? Refine the abstraction; goto 2
46
© 2012 IBM Corporation
Misc Transforms
Refactoring
Input Reparameterization
47
Lookup-Table Based
Rewriting
ODC-based reductions
“Dependent register” reductions
BDD-based rewriting
Speculative reductions
Constraint-based simplification
Target enlargement
Time-shifting abstraction
Property decomposition
…
© 2012 IBM Corporation
Transformation-Based Verification Generality

Allows arbitrary sequencing of engines
– Localization followed by retiming, rewriting, redundancy removal – then localization!
– Many of these are synergistic, e.g.
• Localization cutpoints enhance retiming
• Transforms qualitatively alter the localized design, enabling improved reductions

Some transforms have no counterpart to original netlist, e.g.
– Retiming a localized netlist yields reductions unachievable in original netlist

TBV is a unique, patented capacity benefit of RuleBase SixthSense Edition! No other
tool is as flexible
48
© 2012 IBM Corporation
Example Experiments
MMU
Initial*
BRN
AXE
CUT
AXE
CUT
RET
BRN
CUT
ESE
Registers 124297
67117
698
661
499
499
133
131
125
PASS
9901
8916
5601
6605
16831
4645
1300
1883
809
472
337
1004
287
54
1038
sec
386 MB
ANDs
763475 397461
Inputs
1377
162
ERAT
Initial*
BRN
EQV
RET
BRN
SEQ
AXE:50
Registers
45637
19921
419
337
273
257
FAIL
ANDs
316432
167619
3440
2679
1851
1739
2831 sec
Inputs
6874
68
63
183
126
126
884 MB
BRN: Combinational Rewriting
RET: Min-area retiming
AXE: Localization
CUT: Reparameterization ESE: Reachability
EQV: Sequential Redundancy Removal
49
© 2012 IBM Corporation
Model Checking Capacity vs Time*
10
1
1980
1985
1990
2000
InvariantBased IC3
Interpolation
TransformationBased Verif
SAT-Based BMC
1995
Scalable
Equivalence Invariants
100
Semi-Formal Verif
1000
Partitioned
BDDs
#Registers
10000
Explicit-State Model
Checking
100000
BDD-Based Model
Checking
1000000
Abstraction-Refinement
Model Checking Capacity
2005
2010
2015
Year
RuleBase: SixthSense Edition has the highest capacity of any tool on the market
Property checking and sequential equivalence checking
* Not guaranteed capacity;1) some tiny problems are unsolvable! 2) includes bounded proofs Very incomplete list; cumulative
50
© 2012 IBM Corporation
capacity trend leverages earlier innovations + SW engineering
RuleBase SixthSense Edition: R&D Team
 World-class R&D team
 Joint development by IBM Research and IBM EDA (STG)
 Active development since 1993
 Unique transformation-based verification architecture
 >100 granted patents
 >50 technical conference papers
 Numerous key verification innovations developed through this project
– Equivalence checking, on-the-fly checking, And / Inverter Graphs,
time-sliced simplification vs SAT solving,Transformation Based Verification,
cone-of-influence reduction, speculative reduction, …
– Incubator of PSL, IEEE 1850
51
© 2012 IBM Corporation
RuleBase: SixthSense Edition R&D Team
Sweden
Massachusetts
External collaborations
Austria
Minnesota
New York
California
Colorado
India
Austin,
Texas
Ireland
Israel
Italy
52
© 2012 IBM Corporation
Outline
 Introduction
 Formal Verification @ IBM
 Technology
Ru!eBase
SixthSense edition
 Conclusion
53
© 2012 IBM Corporation
FV @ IBM: Impact Highlights

FV has become essential to IBM’s business
 Successful FV deployment mandates high capacity; drives R&D
 Tight synergy between formal and informal verification teams + design teams
 Several FV users / month; >>100k sessions / month
 Technology of choice to reproduce post-si bugs, and verify fixes

Designer-level applications are a huge “intangible win”
 Critical to shift bug-count left / first-time correct silicon mantra

Accelerates successful higher-level verification bring up
 Used for exploration of design optimization opportunities
54
© 2012 IBM Corporation
FV @ IBM: Impact Highlights
 Verification teams migrating from small blocks to larger blocks / units
 Verify against more stable and meaningful design interfaces
 Scalability is enabling FV to verify functionality vs verify small-enough blocks
 SEC has become a huge “commercial win”
 Technology remaps, “IP import” projects completely forgo functional verification
 Timing takedown, sequential synthesis, power optimization…
 Enables late / aggressive changes that otherwise would not be tolerated
© 2012 IBM Corporation
Open Problems: Call for Research Focus

Many open problems in design + verification
 HW verification is not a solved problem
 Many unsolvable problems; manually-intensive to cope with these

Old open problems:
 Improve bit-level verification, falsification, synthesis algorithms

Newer open problems
 Improve higher-level verification algorithms (e.g. SMT)
 Improve higher-level synthesis techniques
 Optimize integrated theory solvers due to heterogenous nature of HW
56
© 2012 IBM Corporation
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
– Viresh Paruthi
57
[email protected]
[email protected]
© 2013 IBM Corporation