1 / 13

Enhancing Model Checking Engines for Multi-Output Problem Solving

Enhancing Model Checking Engines for Multi-Output Problem Solving. Alan Mishchenko Robert Brayton Berkeley Verification and Synthesis Research Center Department of EECS UC Berkeley. Motivation. Multi-output miters arise in practical applications

venetia-natasha
Download Presentation

Enhancing Model Checking Engines for Multi-Output Problem Solving

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Enhancing Model Checking Engines for Multi-Output Problem Solving Alan Mishchenko Robert Brayton Berkeley Verification and Synthesis Research Center Department of EECS UC Berkeley

  2. Motivation • Multi-output miters arise in practical applications • Solving one output at a time is not efficient • A new multi-output solver is being developed • Motivated by industrial benchmarks • Also, HWMCC added a multi-output track in 2012

  3. Contributions • Enhancing formal engines to keep running even if some properties have failed • New switches added to several ABC commands (bmc3, sim3, and pdr) • Memory reduction in BMC engines (bmc2, bmc3) • Constant-memory unfolding manager is developed • Improving scalability of ABC command &iso used for structural isomorphism detection • Too slow for AIGs with 1M nodes and 1K properties

  4. Enhancing ABC Commands • By default, all model checking engines stop as soon as a bug (property failure) is found • Switch ‘-a’ was added to prevent the following commands from stopping • Bounded model checking (“bmc3”) • Rarity-based random simulation (“sim3”) • Property directed reachability (“pdr”) • A vector of counter-examples is available when an engine terminates

  5. Reducing BMC Memory Footprint • Memory footprint of BMC includes • Initial AIG • Unfolded AIG • Mapping from initial AIG into unfolded AIG • SAT solver • Typically, memory is dominated by the SAT solver • However, the mapping can also be a bottleneck if • The design is large • The initial state propagates far into the unfolding • As a result, the unfolding is performed for many timeframes before SAT solving kicks in

  6. Mapping Between The Two AIGs • The mapping contains, for each initial AIG object in each time frame, a literal of the unfolded AIG • A literal is node ID + complemented attribute • When naïve implementation is used, the mapping memory requirements grow linearly with the unfolding depth • An “unfolding manager” has been implemented that uses constant memory footprint for unfolding of any depth

  7. New Unfolding Manager • The manager maintains the mapping from a pair (node, timeframe) into a literal of the unfolded AIG, as long as some of its fanouts are not yet constructed • As soon as the last fanout is constructed, the memory is recycled • This is similar to efficient memory management in bit-parallel simulation of a sequential AIG (or in wavefront mapping)

  8. Experiment: Original BMC UC Berkeley, ABC 1.01 (compiled Apr 2 2013 22:23:17) abc 01> ex1.aig; ps; bmc3 -v ex1 : i/o =10315/ 1 lat =112625 and =1271690 lev =408 Running "bmc3". PI/PO/Reg = 10315/1/112625. And =1271690. Lev = 408. ObjNums =791333. Sect = 31. Params: FramesMax = 0. Start = 0. ConfLimit = 0. TimeOut = 0. SolveAll = 0. 0 + : Var = 1. Cla = 0. Cnf = 0. Uni = 0. 3 MB 0 MB 2.20 sec 1 + : Var = 1. Cla = 0. Cnf = 0. Uni = 0. 6 MB 0 MB 2.20 sec 2 + : Var = 1. Cla = 0. Cnf = 0. Uni = 0. 9 MB 0 MB 2.20 sec 3 + : Var = 1. Cla = 0. Cnf = 0. Uni = 0. 12 MB 0 MB 2.20 sec 4 + : Var = 1. Cla = 0. Cnf = 0. Uni = 0. 15 MB 0 MB 2.20 sec 5 + : Var = 1. Cla = 0. Cnf = 0. Uni = 0. 18 MB 0 MB 2.21 sec 6 + : Var = 1. Cla = 0. Cnf = 0. Uni = 0. 21 MB 0 MB 2.21 sec ... 1410 + : Var = 1. Cla = 0. Cnf = 0. Uni = 0. 4259 MB 0 MB 65.62 sec 1411 + : Var = 1. Cla = 0. Cnf = 0. Uni = 0. 4262 MB 0 MB 65.66 sec 1412 + : Var = 1. Cla = 0. Cnf = 0. Uni = 0. 4265 MB 0 MB 65.70 sec 1413 + : Var = 1. Cla = 0. Cnf = 0. Uni = 0. 4268 MB 0 MB 65.74 sec 1414 + : Var = 1. Cla = 0. Cnf = 0. Uni = 0. 4271 MB 0 MB 65.80 sec 1415 + : Var = 1. Cla = 0. Cnf = 0. Uni = 0. 4274 MB 0 MB 65.84 sec 1416 + : Var = 979410. Cla = 1257619. Cnf = 0. Uni = 0. 4277 MB 111 MB 66.61 sec 1417 + : Var = 979580. Cla = 1258180. Cnf = 0. Uni = 1. 4281 MB 111 MB 66.66 sec 1418 + : Var = 979616. Cla = 1258229. Cnf =2619245. Uni = 1. 4551 MB 132 MB 337.29 sec Runtime: CNF = 62.2 sec (18.5 %) UNSAT = 0.0 sec (0.0 %) SAT = 270.5 sec (80.2 %) UNDEC = 0.0 sec (0.0 %) Buffs = 1572789. Dups = 0. Hash hits = 738390. Hash misses = 254997. Hash overs = 38495. UniProps = 0. Output 0 of miter "ex1" was asserted in frame 1418. Time = 337.98 sec

  9. Experiment: Unfolding Manager abc 01> &r ex1.aig; &ps; &test ex1 : i/o = 10315/ 1 ff = 112625 and = 1271690 lev = 408 mem =18.40 MB 0 : 1370514 ( 90.93 %) 1 : 119763 ( 7.95 %) 2 : 2781 ( 0.18 %) 3 : 5189 ( 0.34 %) 4 : 4649 ( 0.31 %) 5 : 1221 ( 0.08 %) 6 : 945 ( 0.06 %) 7 : 341 ( 0.02 %) 8 : 643 ( 0.04 %) 9 : 406 ( 0.03 %) 10 : 461 ( 0.03 %) 11 : 115 ( 0.01 %) 12 : 122 ( 0.01 %) 13 : 45 ( 0.00 %) 14 : 17 ( 0.00 %) 15 : 16 ( 0.00 %) 16 : 4 ( 0.00 %) 17 : 3 ( 0.00 %) 18 : 0 ( 0.00 %) 19 : 10 ( 0.00 %) 20 : 1 ( 0.00 %) 21 : 0 ( 0.00 %) 22 : 1 ( 0.00 %) 23 : 0 ( 0.00 %) 24 : 0 ( 0.00 %) 25 : 1 ( 0.00 %) 26 : 0 ( 0.00 %) 27 : 2 ( 0.00 %) 28 : 2 ( 0.00 %) 29 : 4 ( 0.00 %) 30 : 1 ( 0.00 %) Extra space = 191478 ( 12.70 %) Memory usage = 28.24 MB Time = 1.01 sec

  10. Improving Scalability of ISO • Command &iso detects and removes structurally isomorphic properties • Currently, this command is slow because • It computes unique structural signatures by repeatedly iterating over the circuit • Incremental approach is needed • It performs structural analysis of sequential bounded COI independently for each output • Processing output groups could be useful

  11. Faster Signature Computation • When refinement begins, there are many changes • Makes sense to update signatures of the whole AIG • In the later stages, there are few changes • Helpful to switch to incremental signature computation • Incrementality is achieved by maintaining a record of nodes that recently acquired unique signatures • Sequential TFI and TFO cones of these nodes are traversed to updated structural signatures of nodes • New nodes with unique signatures are detected and added to the record

  12. Analyzing Property Groups • Forward signature computation is performed for all properties at once • Because a node depends on all of its fanins • Backward signature computation requires isolating the COI of each property • Because a node may have spurious fanouts (that is, fanouts not in the COI of the property) • A tradeoff between accuracy and speed should be investigated

  13. Conclusions • Presented several recent developments geared to solving multi-output properties (some of them still in the works) • Added non-stop solving to individual engines • Improved memory footprint of BMC engine • Currently work on improving scalability of structural isomorphism detection

More Related