Synchronization Verification in System-Level Design with ILP Solvers Thanyapat Sakunkonchak Satoshi Komatsu Masahiro Fujita VLSI Design and Education Center (VDEC), University of Tokyo 2–11–16, Hongo, Bunkyo, Tokyo, 113–0032, Japan Phone & Fax:+(81)–3–5841–6764 E–mail: {thong,komatsu}@cad.t.u-tokyo.ac.jp, fujita@ee.t.u-tokyo.ac.jp Abstract Concurrency is one of the most important issues in system-level design. Interleaving among parallel processes can cause an extremely large number of different behav- iors, making design and verification difficult tasks. In this work, we propose a synchronization verification method for system-level designs described in the SpecC language. In- stead of modeling the design with timed FSMs and using a model checker for timed automata (such as UPPAAL or KRONOS), we formulate the timing constraints with equal- ities/inequalities that can be solved by integer linear pro- gramming (ILP) tools. Verification is conducted in two steps. First, similar to other software model checkers, we compute the reachability of an error state in the absence of timing constraints. Then, if a path to an error state exists, its feasibility is checked by using the ILP solver to evalu- ate the timing constraints along the path. This approach can drastically increase the sizes of the designs that can be verified. Abstraction and abstraction refinement techniques based on the Counterexample-Guided Abstraction Refine- ment (CEGAR) paradigm are applied. The proposed verifi- cation flow is introduced and some preliminary results are presented here. 1. Introduction Building reliable hardware and software systems is a major challenge, and the system design process is made even more difficult by continual increases in design com- plexity. As semiconductor technology advances, entire sys- tems can be realized within single LSIs as Systems-on-a- Chip (SoCs). At the same time, competitive pressures have been pushing system designers to shorten the design cycle and reduce time-to-market. To cope with these compet- ing demands, new design paradigms that offer more lev- els of abstraction have been proposed. Designing an SoC is a process of both hardware and software development, and requires a uniform design flow from specification to implementation. Recently, there has been a lot of interest in approaches built around the C/C++ programming lan- guages. Since C/C++ are commonly used in software de- velopment, C-based SoC design (using languages like Sys- temC or SpecC) is a promising approach to cover both hard- ware and software design with a single design/specification language. Model checking is the formal verification technique most-commonly used in the verification of RTL or gate- level hardware designs. Due to the success of the model checking technique in the hardware domain [6, 5, 24, 7, 9], over the last few years, model checking methods have been applied to the software domain, and we have seen the birth of software model checkers for programming languages such as C/C++ and Java. Software model checking poses its own challenges, as software tends to be less structured than hardware. In ad- dition, concurrent software contains processes that execute asynchronously, and interleaving among these processes can cause a serious state-space explosion problem. Several techniques have been proposed to reduce the state-space explosion problem, such as partial-order reduction and ab- straction. In the software verification domain, predicate ab- straction [18, 2, 20] is widely applied to reduce the state- space by mapping an infinite state-space program to an ab- stract program of Boolean type while preserving the behav- iors and control constructs of the original. Counterexample- Guided Abstraction Refinement (CEGAR) [8] is a method to automate the abstraction refinement process. More specifically, starting with a coarse level of abstraction, the given property is verified. A counterexample is given when the property does not hold. If this counterexample turns out to be spurious, the previous abstract programs are then re- fined to a finer level of abstraction. The verification process is continued until there is no error found or there is no solu- tion for the given property.