230 likes | 244 Views
This overview discusses improvements in combinational equivalence checking, covering terminology, previous approaches, and latest advancements. The proposed approach integrates intelligent simulation techniques, improved simulation algorithms, and use of fast logic synthesis to reduce runtime and enhance accuracy in equivalence checking processes. By leveraging advanced SAT solving methods, circuit-based information, and fast AIG rewriting, the approach aims to address hard cases more efficiently and improve the overall correctness of the CEC engine.
E N D
Alan Mishchenko, Satrajit Chatterjee, Robert Brayton UC BerkeleyNiklas Een Cadence Berkeley Labs Improvements to Combinational Equivalence Checking
Overview • Terminology • Previous work • Improvements • Experimental results • Conclusions
… N2 N1 X X Terminology M • 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 • 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
Subgraph 2 Subgraph 1 Subgraph 3 A A a a b c b a c a a c a b b c b c a Subgraph 2 Subgraph 1 B B a c b a c a b a c a b Subgraph 2 Subgraph 1 AIG Rewriting • Pre-computing subgraphs • Consider function f = abc • Rewriting subgraphs Rewriting node A Rewriting node B 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 ); if ( status != undecided ) break; // try fraiging status = DoFraiging( Miter, FraigingLimit + Iter * FraigingIncrease ); if ( status != undecided ) break; } 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: 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 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
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