Improvements to Combinational Equivalence Checking Alan Mishchenko, Satrajit Chatterjee, Robert Brayton UC Berkeley Niklas Een Cadence Berkeley Labs

Overview Terminology Previous work Improvements Experimental results Conclusions

Terminology CEC Miter Mitering Fraiging (SAT sweeping) X … N1 N2 CEC combinational equivalence checking Miter two circuits to be compared are combined over the same inputs, while comparing their outputs Mitering trying to prove output M = 0 using a SAT solver Fraiging (SAT sweeping) trying to prove intermediate equivalences in topological order using a SAT solver M M SAT SAT-2 A B SAT-1 C D Mitering Fraiging

Previous Work Naïve approach simulate the miter while looking for assignments leading to M=1 construct BDDs for the miter and compare it with constant 0 assert output to be 1 and run SAT solver Efficient approach (A. Kuehlmann et al, TCAD 2002) perform simulation solves easy satisfiable problems detects potentially equivalent nodes Interleave mitering and BDD/SAT sweeping while increasing resource limits if mitering fails to prove, BDD/SAT sweeping may simplify the miter after some SAT sweeping, mitering may be easier use counter-examples to improve simulation

Our Contributions Intelligent simulation Passing circuit information to a CNF-based SAT solver Interleaving CEC on the miter with synthesis of the miter Addressing hard cases with no intermediate equivalences Capability to prove correctness of the CEC engine

Improved Simulation Input: miter M, successful pattern p Run random simulation till saturation A successful pattern is a pattern that resolved a pair of intermediate nodes, not resolved by random simulation Counter-examples from a SAT solver are successful patterns How to easily get other patterns that are more likely successful than random patterns? Idea: Use distance-1 patterns derived from successful patterns Example: 01001  successful pattern 11001  distance-1 in 1st var 00001  distance-1 in 2nd var 01101  etc 01011 01000 Improved simulation algorithm Input: miter M, successful pattern p Output: some potentially equivalent classes resolved ImprovedSimulation( M, p ) { patterns S = {p}; while ( S is not empty ) s = one pattern in S; remove s from S; simulate distance-1 from s; check if new pairs are resolved; add successful patterns to S; }

CNF-Based vs. Circuit-Based SAT Traditionally CEC uses circuit-based solvers Circuit is available and represents “high-level information” Faster constraint propagation, better decisions Substantial progress in CNF-based solvers (e.g. MiniSat-1.14) Constraint propagation became faster Efficient circuit-to-CNF conversion make CNF-solving faster Improved conflict analysis (clause minimization, etc) What is lacking, is the “high-level information” available in circuits There are hybrid solvers (Ganai et al, DAC ‘02; Jin et al, CAV ’04) They are more complicated and may take longer to catch up with the latest improvements in CNF-based solving (speculation)

Using Circuit Info in CNF-Based SAT Two types of SAT solvers circuit-based CNF-based Using circuit-based information is often crucial for solving hard SAT instances originating from circuits Two approaches to address this problem Use circuit-based solver in CEC (A. Kuehlmann et al, TCAD ’02) Communicate circuit-based information to CNF-based solver (J. P. Marques-Silva et al, IEEE D&T of Computers, ‘03) Simulating J-frontier in a CNF-based solver

Proposed Approach Drawbacks of previous approaches Circuit-based solvers do not use improvements in CNF-based solving J-frontier may be costly to support in a CNF-based solver We propose to modify variable activities in the CNF-based solver After each restart, increase activities of some variables Increase variable more if it is closer to the top of the miter M +3Δ +2Δ +Δ

Using Fast Logic Synthesis Experiments show that interleaving CEC and fast logic synthesis reduces total runtime Possible reasons: Detects shallow equivalences, leaving less work for fraiging to do Reduces the number of variables/classes, leads to faster SAT Reduces memory footprint by simplifying the miter Our logic synthesis engine performs several passes over the miter and applies fast AIG rewriting Avoids “zero-cost replacements” (can slow down SAT) Takes 5% of runtime of mitering/fraiging

AIG Rewriting   Rewriting subgraphs Pre-computing subgraphs Consider function f = abc Rewriting subgraphs Rewriting node A a b c A Subgraph 1 b c a A Subgraph 2 a b c Subgraph 1 b c a Subgraph 2 a c b Subgraph 3  Rewriting node B b c a B Subgraph 2 a b c B Subgraph 1  a b c In both cases 1 node is saved

Improved Integrated Approach to CEC status IntegratedCEC( Miter, VariousResourceLimits ) { status = undecided; for ( Iter = 1; Iter <= IterLimit; Iter++ ) { // try mitering status = DoMitering( Miter, MiteringLimit + Iter * MiteringIncrease ); if ( status != undecided ) break; // try rewriting status = DoRewriting( Miter, RewritingLimit + Iter * RewritingIncrease ); // try fraiging status = DoFraiging( Miter, FraigingLimit + Iter * FraigingIncrease ); } if ( status != undecided ) status = DoMitering( Miter, FinalMiteringLimit ); if ( status == satisfiable ) Miter->CounterExample = GenerateCounterExample( Miter ); return status;

Addressing Hard CEC Cases M Typically, a CEC instance is hard if (a) the circuit is deep and (b) there are few or no internal equivalences SAT sweeping has no “foothold” for climbing up to the outputs Such cases cannot be handled effectively by current methods Brute-force SAT runs are used (till timeout) Ad-hoc, semi-manual methods are developed for specialized circuits (multipliers) We propose to perform additional logic synthesis to synthesize internal equivalent points, then use a standard CEC engine M A = B

Resolvent A resolvent is a clause implied by two clauses in a SAT instance 1. A SAT instance C 1. (~p + a) 2. (~p + b) 3. (p + ~a + ~b) 4. (~q + a) 5. (~q + b) 6. (q + ~a + ~b) 7. (p + q + ~z) 8. (p + ~q + z) 9. (~p + q + z) 10. (~p + ~q + ~z) 11. (z) 2. Resolvent of clauses 3 and 4 (w.r.t. a) is the clause (p + ~b + ~q) 3. Adding the resolvent to the original set does not alter satisfiability: This is not a definition of resolvent, but a property 1. (~p + a) 2. (~p + b) 3. (p + ~a + ~b) 4. (~q + a) 5. (~q + b) 6. (q + ~a + ~b) 7. (p + q + ~z) 8. (p + ~q + z) 9. (~p + q + z) 10. (~p + ~q + ~z) 11. (z) 12. (p + ~b + ~q) C’ It can be checked that C’ is satisfiable if and only if C is.

Resolution Proofs A resolution proof is a sequence of resolvents until the empty clause 1. Original set of clauses C 1. (~p + a) 2. (~p + b) 3. (p + ~a + ~b) 4. (~q + a) 5. (~q + b) 6. (q + ~a + ~b) 7. (p + q + ~z) 8. (p + ~q + z) 9. (~p + q + z) 10. (~p + ~q + ~z) 11. (z) 2. Sequence of resolvents 12. (p + ~b + ~q) (from 3 and 4) 13. (p + ~q) (from 5 and 12) 14. (~p + q + ~a) (from 2 and 6) 15. (~p + q) (from 1 and 14) 16. (~p + ~q) (from 10 and 11) 17. (p + q) (from 7 and 11) 18. (~q) (from 13 and 16) 19. (q) (from 15 and 17) 20. () (from 18 and 19) If the empty clause i.e. () is derived by resolution then the original set of clauses is UNSAT A resolution step indicates which clauses were resolved Empty clause can only be derived from two contradictory clauses such as (q) and (~q) Therefore, if the empty clause is derived, then the instance is UNSAT Thus the sequence of resolution steps 12-20 forms a proof of unsatisfiability of C if () is derived at the end.

Certifying the CEC Engine When SAT solver returns “unsat”, the result can be verified using a resolution proof (Goldberg, DATE 2003) In additional to SAT solver runs, CEC engine performs several tasks: structural hashing, logic synthesis, etc A resolution proof can be produced in these cases, too The resolution proofs are composable! A single resulting resolution proof can be used to verify the result of the CEC engine It can checked by a very simple resolution proof checker

Experimental Setup Benchmarks are generated using the following script in ABC: read <input_file>; resyn2; sfpga; miter -c; frames -i -F <num>; orpos; write_blif <output_file.blif> The resulting miters are publicly available in BLIF and in BENCH formats: http://www.eecs.berkeley.edu/~alanmi/cec Resource limits used in the experiments (for iteration number N) mitering - at most 1000*2N conflicts AIG rewriting - 3 iterations fraiging - at most 2*8N conflicts at a node

IWLS Benchmark Statistics and Results

AIG Size Reduction and Breakdown of Runtime

Comparison with CSAT (UCSB)

Industrial Benchmarks AIG size is the number of two-input ANDs after structural hashing prove is the runtime of the improved approach prove –r is the runtime without fast logic synthesis prove –j is the runtime without J-frontier heuristic sat is the runtime of brute-force mitering alone 1.6Ghz CPU, 1Gb RAM

Recent Improvements Old results reported in ICCAD 2006 paper New results after recent improvements * Indicates the benchmark, which was not used in computing ratios 1.6Ghz CPU, 1Gb RAM

Conclusions Introduced CEC Proposed several improvements that reduce runtime Showed that logic synthesis plays important role in CEC Publicly available source code Commands “prove” and “cec” in the latest release of ABC: http://www.eecs.berkeley.edu/~alanmi/temp2/ Future work: Improving CEC Synthesizing equivalences Developing new applications based on CEC Detecting useful function properties (such as NPN-equivalence, etc) Sequential equivalence checking Closely related to efficient CEC