© 2014 IBM Corporation Formal Verification at IBM: Applications and Technology Overview Viresh...

© 2014 IBM Corporation

Formal Verification at IBM:

Applications and Technology Overview

Viresh Paruthi, Jason Baumgartner

IBM Systems and Technology Group, Austin TX, USA

© 2012 IBM Corporation2

Outline

Introduction

Formal Verification @ IBM

Technology

Conclusion

RuRu!!eBaseeBase S SiixthSensexthSense editionedition


Introduction to Hardware Verification

Numerous types of verification relevant to hardware design

Also timing analysis, circuit analysis, protocol analysis, …

always @(posedge clk) begin if ( r ) then p <= 0 else p <= p+1; end if; end

HDL Netlist Schematic Layout IC

EquivalenceChecking

EquivalenceChecking

Layout vsSchematic

WaferTest


Introduction to Hardware Verification

We focus upon functional verification and 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

always @(posedge clk) begin if ( r ) then p <= 0 else p <= p+1; end if; end

HDL Netlist

EquivalenceChecking

IEEEStandar

d754-2008

FunctionalVerification

…


Traffic Light Controller (TLC)

Avenue E

Ave

nue

N

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 )

NG

NY EY

EG

O=(G,R)

I=(--,nC)

I=(--,C)

O=(Y,R) O=(R,Y)

O=(R,G)

I=(--,--) I=(C,--)

I=(nC,--)

I=(--,--)


Verification Step 1

Unit testing, a.k.a. designer verification

– Check for intended behavior against a selection of input vectors

NG

NY EY

EG

O=(G,R)

I=(--,nC)

I=(--,C)

O=(Y,R) O=(R,Y)

O=(R,G)I=(--,--) I=(C,--)

I=(nC,--)

I=(--,--)

NG

NY EG

EY NG

NG

I=(--,C)

?

I=(--,--)

I=(C,--)

?

I=(--,--)

I=(--,nC)

– Investigate streams of state transitions and outputs– Light weight check, low “coverage”


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”


Verification Step 3

Simulation

– Systematically check the design satisfies its specification– Against directed or random input streams

NG

NY EY

EG

O=(G,R)

I=(--,nC)

I=(--,C)

O=(Y,R) O=(R,Y)

O=(R,G)I=(--,--) I=(C,--)

I=(nC,--)

I=(--,--)

NG

NY EG

EY NG

NG

NY

I=(--,C)

?

I=(--,--)

I=(C,--)

?

I=(--,--)

I=(--,nC)

?

I=(--,C)I=(--,--)

– A “(random) walk” of the state space of the design– Incomplete – cannot rule out presence of bugs


We done…?

Let’s take a simple real world ALU

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

A (32-bit) B (32-bit)

Add / Mul / Div / Rot…

C (64-bit)

Numberof State/Input Bits

Time need to visit all states

Model size

Model speed

Source: Comprehensive Functional Verification, Wile, Roesner, Goss


Verification Step (4)

Formal Verification

– Rigorously prove the design satisfies its specification

NG

NY EY

EG

O=(G,R)

I=(--,nC)

I=(--,C)

O=(Y,R) O=(R,Y)

O=(R,G)I=(--,--) I=(C,--)

I=(nC,--)

I=(--,--)NG

NY EGEY

NGI=(--,C)I=(--,--)

I=(C,--)

I=(--,--)

NG

EG

I=(--,nC) NY

NGI=(--,nC)

I=(--,--)

I=(nC,--)

EGI=(--,--)

EYI=(C,--)

EGI=(nC,--)

NY

NGI=(--,nC)

I=(--,--)

EGI=(--,--)

NY

NGI=(--,nC)

I=(--,--)

EYI=(C,--)

EGI=(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


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

NGI=(--,nC) NY

NGI=(--,nC)

I=(--,--)EG

I=(--,--) EGI=(nC,--)EY

NGI=(C,--) I=(--,--)

EG EYI=(C,--)

EGI=(nC,--)

I=(nC,--)?

?

?

NG

NY EY

EG

O=(G,R)

I=(--,nC)

I=(--,C)

O=(Y,R) O=(R,Y)

O=(R,G)I=(--,--) I=(C,--)

I=(nC,--)

I=(--,--)

– Incomplete, high(er) coverage– Happy medium


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

NG

NY EY

EG

O=(G,R)

I=(--,nC)

I=(--,C)

O=(Y,R) O=(R,Y)

O=(R,G)I=(--,--) I=(C,--)

I=(nC,--)

I=(--,--)

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


Formal Verification Concepts

Randomness / Non-determinism

– 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”

Checker

entity ....

end ...;architecture....

.... ...

end .....

Driver

Design-Under-Test

Testbench


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


TLC is Arbitration!

Arbiters

– Restrict access to a shared resource• E.g. bus access where all requestors cannot be serviced concurrently

Arbiter

ArbiterFairness

Requests

Grants

– Verification goals:• Starvation, Mutual Exclusion / Collision


TLC “Systems”

Tandem operation– Dynamic coordinated

control– Sensors, Adaptive

timers

Traffic flow– Synchronization– Vehicles / Time– Back-pressure


System-level FV

Bus Arbiter

L2 / L3Cache

Core #1

L2 / L3Cache

Core #2

MC MC

L2 / L3Cache

Core #8

........

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”


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

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 rigorouslyMacro 1 Macro 2 Macro n

Wrapper 1

Unit 1 Unit m

Chip

. . .

. .

Lower levelBlack-boxed

Leaf level

Design hierarchy

Vehicles/ Time


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


Outline

Introduction

Formal Verification @ IBM– Evolution– Verification Methodology– Sequential Equivalence Checking

Technology

Conclusion



Formal Verification Evolution @ IBM Paruthi FMCAD 2010

2000 2002 2006 2012

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


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


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

ConstraintRandom

Testbench

PSL et al.

(Semi-) Formal Verification

(RuleBase SixthSense Edition)

Verification Technology


Integrated Approach: Design

SimpleDriver

EnablesStimulus

Vhdl

Assertions

EnablesIntegratedChecking

SimulationH/WAccel

Semi-

Assertion-Based Verification

Formal

Designer-Level Verification

CompleteDriver

Block-Level Verification

Verification

IBM Systems and Technology Group

...i1

in

o

...MUX

s1sn

One-hot

Assertion-based Verification (ABV) Designer-level Verification (DLV)

– Require designers to capture assumptions as verif objects (checkers) • Accelerated debug, faster IP integration, documentation…

– …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


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…


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


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…

Block 2 Checker(Properties)

DriverDriverTestbench

Components

DesignComponents


Block 2Driver DriverBlock 1Driver Driver

(Sub-) UnitBlock 1 Block 2




High-level Modeling Support

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

– 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

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;

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;


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]}!;

…

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);

Sequence start Next clock N repetitions Sequence end


Equivalence Checking

IBM Systems and Technology Group

{0, 0, …}?

d2

d1

{x0, x1, …}

Logic1

Logic2

init

initd2

d1x

Logic1

Logic2

s

0?

0?

Combinational Equivalence Check (CEC) Sequential Equivalence Check (SEC)

Requires 1:1 state elements mapping

Cannot handle sequential behavior• Validates next-state functions and outputs

Verify transistor- / gate-level design against RTL

Supports arbitrary design changes (I/O equivalent)

• Retiming, power saving, redundant logic…

Explores sequential behavior of the designs• Computationally more complex than CEC


Sequential Equivalence Checking

Hierarchical application scales to large enough design partitions

Sequential Equivalence Check (SEC)

Supports arbitrary design changes (I/O equivalent)

Explores sequential behavior of designs

Retiming, power saving, redundant logic…

Macro 1 Macro 3Macro 2 Macro n

Wrapper 1

Unit 1 Unit m

Chip

. . .

. . .

Lower levelsblack boxed

Leaf level

Design hierarchy



Game changing application of the technology

End-2-end verification of entire chips

Invaluable productivity advantage, resource savings

OLD Design

NEW Design

Initialization Data

InputConstraints

Simulation Assertions

Proof of Equality

MismatchTrace

:

SequentialEquivalence Checker

Initialized OLD Design

Initialized NEW Design

Inputs =?

Outputs


Outline

Introduction


Technology– Core proof / falsification techniques– Transformation-Based Verification (TBV)– Research and development– Supported languages and environments

Conclusion



Netlist-Based Verification

010

Input stimulus


Netlist-Based Verification: Goals

Initial States


Verification with RuleBase SixthSense Edition

Spec

DUVEnvironment,Driver

Assertions, Properties

+ + ? [1:n]Fail+

Counter example

Pass+

Witness

Pass vacuously Bounded pass


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


A “random walk” through the state space of the designStimulus can be random (constrained, biased); from manual testcases; from testcase generators

+ Very robust set of tools & methodologies available The original method for functional verif; FV came decades later

+ 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

Simulation (Validation vs Verification)

Incomplete coverage of huge designs


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

Acceleration


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

Generally requires analysis of reachable states: size limited

Though many advanced techniques exist to overapproximate reachable states, reduce design size, abstract irrelevant behavior

Great capacity gains over past decades, though still size-limited

Complete coverage of

smaller designs


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


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


140627registers

Design + Driver + Checker

Combinational Optimization

Engine

119147regs

1320regs

79302regs

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


Combinational rewriting

Sequential redundancy removal

Min-area retiming

Sequential rewriting

Input reparameterization

Localization

Target enlargement

State-transition folding

Circuit quantification

Temporal shifting + decomp

Isomorphic property decomp

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

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


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


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


Example Transformation 3: CEGAR-Based LocalizationAbstraction 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


Misc Transforms

Refactoring

Lookup-Table Based Rewriting

Input Reparameterization

ODC-based reductions

“Dependent register” reductions

BDD-based rewriting

Speculative reductions

Constraint-based simplification

Target enlargement

Time-shifting abstraction

Property decomposition

…


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


Example Experiments

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: LocalizationCUT: Reparameterization ESE: Reachability EQV: Sequential Redundancy Removal

MMU Initial* BRN AXE CUT AXE CUT RET BRN CUT ESE

Registers 124297 67117 698 661 499 499 133 131 125 PASS

ANDs 763475 397461 9901 8916 5601 6605 16831 4645 1300 1038 sec

Inputs 1377 162 1883 809 472 337 1004 287 54 386 MB


M odel Checking Capacity

1

10

100

1000

10000

100000

1000000

1980 1985 1990 1995 2000 2005 2010 2015

Ye a r

#R

eg

iste

rs

RuleBase: SixthSense Edition has the highest capacity of any tool on the marketProperty checking and sequential equivalence checking

BD

D-B

ased

M

odel

C

heck

ing

Exp

licit-

Sta

te

Mod

el

Che

ckin

g Abs

trac

tion-

Ref

inem

ent

SA

T-B

ased

B

MC In

terp

olat

ion

Tra

nsfo

rma

tion-

Bas

ed V

erif

Inva

riant

-B

ased

IC

3

Sca

lab

le

Equ

iva

lenc

e In

varia

nts

Sem

i-For

mal

V

erif

Par

titio

ned

BD

Ds

Model Checking Capacity vs Time*

* Not guaranteed capacity;1) some tiny problems are unsolvable! 2) includes bounded proofs Very incomplete list; cumulative 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


RuleBase: SixthSense Edition R&D Team

External collaborations

Israel

India

New York

Austin, Texas

Minnesota

California

Colorado

MassachusettsSweden

Ireland

Austria

Italy


Outline

Introduction


Technology

Conclusion



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


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


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


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]

© 2014 IBM Corporation Formal Verification at IBM: Applications and Technology Overview Viresh...

Documents

Transcript of © 2014 IBM Corporation Formal Verification at IBM: Applications and Technology Overview Viresh...