The Benefit of Concurrency in Model Checking

ion phase. The next phase employs abstractions. Usually, the CB/PB localization abstractions [8] are done first followed by refinement using a verify phase. Then speculation [3] is done, again followed by refinement using a verify phase. 1 In some rare cases, the forward diameter of the design is know, in which case BMC can be considered a complete method. 2 In theory, if the synthesis algorithms were powerful enough and the property holds, this would be all that is needed since the circuit can be reduced to a constant. Sometimes this happens. Speculation is the process where equivalences between signals in the circcuit are postulated based on extensive random or semi-formal simulation. By simplifying the circuit using the speculated equivalences, a “speculatively reduced model” is produced with additional outputs representing proof-obligations for the speculations. These obligations can be dispatched all at once or individually. Each of these sub-problems can be attacked as a separate MC problem using any of the sequence of MC engines in the arsenal. As can be imagined, the orchestration of the use of these engines and their variations becomes quite complex requiring intricate code or use of expert systems [30] [Ziv]. 4 Concurrent verify phase If there are initially many properties to be proved for the same design, the obvious way to exploit multi-cores is just to solve each property separately. However, as soon as all easy properties have been solved, we are left with the hard ones, and we claim that CPU power is better used by a welltuned concurrent engine. In the following, we describe our efforts along these lines and some experimental results. The scripting layer of our model checker 3 was modified to use a concurrent verify phase, which can fork off a subset of basic MC engines. These run concurrently as separate processes. 4 At the time of the fork, the global state of the Python interpreter and the current AIG for the problem are copied for each process. The list of basic engines that we use are: 1. Four different versions of BDD reachability, reachx, reachm, reachn, reachp 2. Four different versions of property directed reachability 5 , pdr, pdrs, pdrm, pdrmm 3. Two different implementations of bounded model checking, bmc, bmc3 4. Interpolation, interpolate 5. Repeated random simulation, simulate Each engine is given the same timeout. The fork terminates when any algorithm returns a definitive result, SAT or UNSAT, or when all engines have timed out. Only the winning result (which may include a counter-example (CEX), used for refinement) is kept. In the verify phase, the AIG is not changed, but the transformation engines used in the next section may also return a new AIG. The Python function call is “verify(list, time)”, where list is a list of engines to be run concurrently, and time is the timeout in seconds for each engine. In contrast to a sequential verify phase, the code for this is markedly simpler. 5 Deployment of a concurrent verify A rough outline of our hybrid concurrent MC algorithm called c_prove, which uses the concurrent verify is shown in Figure 1. 3 The ABC model checker is scripted in Python with the capability of orchestrating ABC or ZZ/BIP commands which are written in C or C++. 4 In our experiments we used an 8-core server running Ubuntu Linux. 5 PDR is based on Bradley’s method and program, which he called IC3.