Viresh Paruthi Jason Baumgartner IBM Systems and Technology

Outline § Introduction § Formal Verification @ IBM § Technology Ru!e. Base Sixth. Sense

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

Traffic Light Controller (TLC( Next-State Output (N/S, E/W) ( -- , n. C ) NG (G, R) NG ( -- , C ) NY (G, R) NY ( -- , -- ) EG (Y, R) EG ( n. C , -- ) EG (R, G) EG Avenue E Input (N/S, E/W) NG Avenue N State ( C , -- ) EY (R, G) EY ( -- , -- ) NG (R, Y) I=(--, n. C) NG I=(--, C) I=(--, --) O=(G, R) O=(Y, R) EY NY O=(R, Y) O=(R, G) I=(--, --) EG I=(C, --) I=(n. C, --) © 2012 IBM Corporation

Verification Step 1 § Unit testing, a. k. a. designer verification – Check for intended behavior against a selection of input vectors I=(--, n. C) 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=(C, --) I=(--, n. C) NY EY EG I=(--, --) NG NG ? I=(n. C, --) – 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=(--, n. C) I=(--, C) NG ? I=(--, --) ? O=(G, R) O=(Y, R) NY EY O=(R, Y) I=(--, --) EG I=(C, --) NY EY EG I=(--, --) NG I=(--, C) I=(C, --) NG I=(--, C) O=(R, G) I=(--, n. C) I=(--, --) NG NY I=(--, --) ? I=(n. C, --) – 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) Add / Mul / Div / Rot… 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=(--, n. C) NG – Rigorously prove the design satisfies its specification NG I=(--, --) I=(--, n. C) I=(--, C) NG I=(--, n. C) O=(Y, R) NY NG I=(--, --) NY EY I=(--, C) O=(R, Y) EG NY I=(C, --) I=(n. C, --) EG EG NY I=(--, --) I=(C, --) I=(n. C, --) EY I=(--, --) O=(R, G) I=(--, --) NY EY EG I=(--, --) NG O=(G, R) I=(--, --) I=(--, n. C) EG I=(C, --) EG NG EY I=(C, --) I=(n. C, --) Step 0 Step 1 Step 2 Step 3 EG 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=(--, n. C) I=(--, C) NG I=(--, n. C) ? I=(--, --) I=(--, n. C) O=(G, R) O=(Y, R) NY EY O=(R, Y) NG I=(--, --) NY EG I=(--, --) I=(n. C, --) EG I=(C, --) EY I=(--, --) NG NG ? I=(n. C, --) EG I=(C, --) O=(R, G) I=(--, --) EG EY I=(C, --) I=(n. C, --) EG I=(n. C, --) – 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=(--, n. C) I=(--, C) NG I=(--, --) I=(--, n. C) O=(G, R) O=(Y, R) NY EY O=(R, Y) O=(R, G) I=(--, --) EG I=(C, --) NG NG I=(--, n. C) I=(n. C, --) – 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 §

System-level FV Core #1 Core #2 L 2 / L 3 Cache Core #8 L 2 / L 3 Cache . . . . L 2 / L 3 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. L 3 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 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!e. Base Sixth. Sense edition § Technology § Conclusion 20 © 2012 IBM Corporation

Formal Verification Evolution @ IBM Paruthi FMCAD 2010 Middle Ages Early Times The Future… 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 (~100 s 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 (Rule. Base Sixth. Sense 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) i 1 Designer-level Verification (DLV) in – Require designers to capture assumptions as verif objects (checkers) • Accelerated debug, faster IP integration, documentation… . . . MUX . . . s 1 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 o © 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 Software Simulation Element Level 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… – L 2, MC, LSU, ISU… 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 e 1 is port (i 1: in std_ulogic_vector(0 to 3); we, re: std_ulogic; o 1: 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 e 1 of e 1 is signal ff: hl_fifo(0 to 3)(0 to 3)); begin process (ALL) begin if (we = '1') then fifo_push(ff, i 1); end if; if (re = '1') then fifo_pop(ff, o 1); 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 x s d 1 0? d 1 {x 0, x 1, …} Logic 2 0? d 2 § Requires 1: 1 state elements mapping § Cannot handle sequential behavior • Validates next-state functions and outputs § Verify transistor- / gate-level design against RTL 30 init {0, 0, …}? d 2 § Supports arbitrary design changes (I/O equivalent) • Retiming, power saving, redundant logic… § Explores sequential behavior of the designs • Computationally more complex than CEC © 2012 IBM Corporation

Sequential Equivalence Checking Sequential Equivalence Check (SEC) : OLD Design Simulation Assertions Sequential Equivalence Checker NEW Design Initialization Data Input Constraints Initialized OLD Design Inputs Proof of Equality Mismatch Trace Outputs Supports arbitrary design changes (I/O equivalent) 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 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!e. Base Sixth. Sense 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 Rule. Base Sixth. Sense Edition Environment, Driver pec S + Fail + Counter example 35 DUV Assertions, Properties + 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 + Scalable: applicable to designs of any size designs – 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 ($1 M+) - 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 79302 Transformations are completely optimized, Phase Abstraction transparent to the user – internally Engine 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 1320 Localization in terms optimized, verification results are. Engine 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, Rule. Base Sixth. Sense 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 POWER 4 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 Rule. Base Sixth. Sense Edition! No other tool is as flexible 48 © 2012 IBM Corporation

Example Experiments MMU Initial* BRN AXE CUT RET BRN CUT ESE 67117 698 661 499 133 131 125 PASS 763475 397461 9901 8916 5601 6605 16831 4645 1300 1883 809 472 337 1004 287 54 1038 sec 386 MB Registers 124297 ANDs 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 884 MB BRN: Combinational Rewriting RET: Min-area retiming AXE: Localization CUT: Reparameterization ESE: Reachability EQV: Sequential Redundancy Removal 49 © 2012 IBM Corporation

Invariant. Based IC 3 Interpolation Scalable Equivalence Invariants Transformation. Based Verif Semi-Formal Verif SAT-Based BMC Abstraction-Refinement Partitioned BDDs BDD-Based Model Checking Explicit-State Model Checking Capacity vs Time* Rule. Base: Sixth. Sense 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

Rule. Base Sixth. Sense 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

Rule. Base: Sixth. Sense Edition R&D Team Sweden Massachusetts External collaborations Austria Minnesota New

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; >>100 k 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/Sixth. Sense – https: //www. research. ibm. com/haifa/projects/verification/RB_Homepage/publications. html § Contact: – Jason Baumgartner – Viresh Paruthi 57 baumgarj@us. ibm. com vparuthi@us. ibm. com © 2013 IBM Corporation