A New High Level Model Based on Integer Equations to Check CTL Properties in VHDL Environment

A New High Level Model Based on Integer Equations to Check CTL Properties in VHDL Environment BIJAN ALIZADEH, MOHAMMAD R. KAKOEE, ZAINALABEDIN NAVABI Electrical and Computer Engineering University of Tehran Building #2, North Kargar Ave, Faculty of Engineering IRAN Abstract: - This paper describes the use of integer equations for high level modeling of digital circuits for rule-based formal verification at this level. BDD operations are not applicable to a large datapath because of large CPU time and memory usage. In our method, a behavioral state machine is represented by a list of integer equations, and RT level properties are directly applied to this representation. Furthermore, this method is applied to circuits without having to separate their data and control sections. For this implementation, we use a canonical form of integer equations, which simplifies equations instead of solving them. This paper compares our results with those of the VIS verification tool that is a BDD based program. Key-Words: - Integer equation, Symbolic model checking, CTL, ILP solver Introduction As the size and functional complexity of digital designs increase, it has become important to verify the design at the early stages of design flow []. This means that the designer requires automated verification tools at higher levels of abstraction [2]. On the other hand, most of methods use BDDs to represent the set of states and the state transition functions [2, 3]. The BDD techniques may still suffer from the memory explosion problem when the application is a large datapath. Other high level data structures have been proposed to check equivalency of two circuits, but they have not been used to do property checking [4]. Biere et al. [5] proposed an alternative, symbolic model checking approach by using the Boolean satisfiability (SAT) techniques. Because of the low abstraction level BDDs, processing time of circuits represented as such becomes forbiddingly high for large circuits. Cheng et al. [6] propose a hybrid ATPG modular arithmetic constraint solving technique for assertion checking. However the arithmetic constraint solver is limited to linear constraints arising from adders, subtractors and multipliers with one constant input. Brinkmann et al. [7] have used Fallah s method [8] and proposed a method for transforming conjunctions of bitvector equalities and inequalities into equivalent conjunctions of equations and disequations in integer linear arithmetic. This method is just applied to datapath and there is necessary to use an ILP solver. Instead of using FSMs in low level, we present a high level model based on integer equations to model transition and output functions. The integer equations are extracted from the design and are at a higher level of abstraction than BDD based transition functions. Therefore we have to define some operations at a higher level than they were in BDD. For this work, we use VHDL to describe a design and CTL format to describe properties [3]. For evaluation of this work, we have developed a Visual C++ program that uses the CHIRE [9] intermediate format. The main advantages of our technique are as follows. First, our technique can be applied to behavioral level and therefore we do not have to

separate datapath and controller when the design becomes large. Second, our technique uses a high level model instead of an FSM, so we are able to check CTL based properties very efficiently in terms of CPU time and memory usage, as compared with the BDD based approaches. Third, our method not only does not need to solve Integer Equations explicitly but also does not have to do satisfiability as is done in [5, 6, 7]. This paper describes our work in five sections. Section 2 presents how we extract Data Flow Graph (DFG) as a model of the design and then in Section 3 we show how to extract integer equations as a canonical form. Section 4 presents algorithms to check some basic properties in our model. Section 5 gives experimental results of several examples. The last section presents a short conclusion of this work. 2 DFG Extraction The first task is the DFG extraction. We consider a design as an array of elements shown in Fig.. The first three fields are pointers to graphs as shown in Fig.2. These structures show list of graphs that model the design. In other words, we consider a design as a system D = (set of inputs, set of present states, set of next states, set of outputs, PF), where PF is a set of next state and output functions. Each DFG node includes BinaryOp, UnaryOp and Signal which indicate all required operators and operands. These structures show list of graphs that model the next state and output functions of the design. One of advantages of this model is its flexibility because it is possible to add other operators and statements to this model. A design is represented in terms of multiplexers, since it is more efficient to extract integer equations from this format. As an example of our DFG model, consider the Greatest Common Divisor (GCD) example that its algorithm is very simple: two arguments are mutually subtracted till they become equal each other. Fig.3 shows DFG nodes, which are extracted for the nxt and signals. As illustrated in this figure, the value field of nxt was constructed by a multiplexer based structure. Also the value field of shows a flip-flop node that is constructed by the nxt signal as input. NOT Target Value Condition Other Flags Fig.. General data structure DFG Node UnaryOperator DFG Signal BinaryOperator FlipFlop nxt Start AND OR ADD SUB MUL Equal Less LessEqual Fig.2. DFG Node structure Target Value Condition Other Flags Reset Equal b NULL IfFlip = NULL Less Flip Flop SUB Fig.3. DFG Structure of nxt and nxt 3 Integer Equations After DFG extraction, we are ready to translate it to integer equations. However, these equations must be viewed as a canonical form to enable us to handle arithmetic operations. In this phase PF in DFG model must be converted to a set of polynomial functions, which are related to the next state and output functions. In this manner next state and output functions will depend on present states and inputs, so any intermediate signals must be replaced by its value till next states and outputs just depend on present states and inputs. 3. Extracting Integer Equations One advantage of transforming all expressions to integer equations is that we will not have to work with two kinds of equations [7]. In this manner basic Boolean operators such as AND, OR and clk

NOT are converted to integer as illustrated in the following. Other binary operators, like OR, are converted to these basic operators [4]. a AND b; a, b : Boolean a * b; a, b : Integer a OR b; a, b : Boolean a + b a * b; a, b : Integer NOT a; a : Boolean - a; a : Integer Arithmetic operators will remain without changing, but relational operators are changed to Less Than and Equality operators. The nodes will be converted to integer equations based on Equation (). Notice that we will not convert a bit-vector if it is used as a condition, because some of bits may be used elsewhere. However, if a bit-vector is used on the right hand side of some expressions we convert it to an integer. MU( In, In, Sel) Sel* In + ( Sel)* In () For the GCD example, integer equations for the nxt signal are shown below. T_29 <= ( == ); T_35 <= ( < ); T_43 <= ( < ); T_47 <= ( ); T_48 <= T_43 * T_47 + ( - T_43) * ; T_49 <= T_35 * + ( - T_35) * T_48; T_52 <= T_29 * + ( - T_29) * T_49; T_25 <= Reset * b + ( - Reset) * T_52; Nxt <= Start * b + ( - Start) * T_25; 3.2 Canonical Form A general integer formula f is a sum of products P where each p P consists of nodes. At the top level of formula f we have Add and Sub nodes. All nodes consist of two terms Left-Child and Right-Child, on the left hand side and the right hand side respectively. In order to be able to manipulate integer formulas, we have to transform them into a canonical form. For this, we first transfer nodes to leaves of the tree and then convert Sub nodes to Add nodes and coefficients are shifted to the edges. On the other hand, we transform Add nodes to a unique form which only includes another Add node on it s Left-Child sub term, and there will be a or Constant node on it s Right-Child sub term. Also, for a default ordering of propositions, we order propositions in nodes and products P in Add nodes because of comparison. During this phase, some product terms which are equal, will be simplified. At the end, complement terms which are in nodes will be removed and constant values are shifted to the edge of that node. In other words, simplification procedure has been hidden in phase of canonical form translation. For example * and (-4)** will be located at the same position, so they will be simplified to (-3**). Also some simplifications are performed when Add nodes in Right-Child are moved to Left-Child and some simplifications will be done during removing complement terms or transforming constant values to edges in nodes. - Add Add Z Z Fig.4. Sum of products representation For example, Fig.4 indicates F= Z** + Z* *, where ordering of propositions is Z > >. First of all, Sub node is converted to Add node. After that, we consider terms which include highest order propositions in each step. Also nodes are ordered according to the number of propositions and order of their propositions. This view is canonical because we consider all sums and products as ordered. 4 CTL Property Checking in Design We consider a property as a general form of P => Q where assumption part (P) and commitment part (Q) are defined by the following rules: P::=(P) P P P P=P Variable Integer Value Q ::= P E(Q) EG(Q) The most advantage of this form of property is that there is not necessary to take into account the reachable state space while proving the existence of a path satisfying certain conditions. This is because the designer specifies some conditions as initial states in assumption part of property and

therefore each property will be checked from initial conditions which were specified explicitly. VHDL Code DFG Extraction of Next state and Output functions Boolean Equations To Integer Equations Convertion Add P to Equations as Constraints Call required Procedure in Figure 6, 7 or 8 CheckCombinational (Q). Convert Q to Integer Equations 2. Add them to other Equations 3. Do Replacement and Simplification 4. If there is an invalid Equation Verification Fail! 5. Else Verification O.K. CTL Property (P=>Q) Extract Parse Tree of Q Fig.5. Flowchart of the CTL property checking An overall view of our work is shown in Fig.5. First, we extract integer equations, i.e. PF, from a synthesized design and then, to these equations, we add the P part of properties the design is being checked for. On the other hand, we extract tree structure of the Q part to specify what verification procedures need to be called at each level of the tree. Three procedures, CheckCombinational, CheckE, and CheckEG perform the task of verification in this flowchart. Fig.6 shows the CheckCombinational procedure in the flowchart of Fig.5. We must convert the Q part to integer equations and add it to the other equations from set of polynomial equations related to output and intermediate signals. These equations are simplified when they are converted to canonical form, and at the end of the procedure, equations that indicate conditions needed to satisfy the property will be returned. It is clear that integer equations solving with integer solutions, is a Hard-Problem. So one of advantages of our method, compared to Brinkmann s method [7] and Cheng s method [6], is to simplify equations based on canonical form, instead of solving them (see Section 3.2). Fig.6. Combinational part Fig.7 shows the CheckE procedure in the flowchart of Fig.5. Correctness of the property is checked in two major steps. First, all present state variables in Q are replaced by next state equations which were extracted as a set of polynomial equations. For example if signal is in Q part then it will be replaced by nxt equation in Fig.. Second, computed equations are simplified during canonical form translation. At the end of the procedure, equations that show conditions for satisfying a property will be returned. For example E( = 3) is converted to nxt = 3 and polynomial equation of nxt, from PF set, replaces nxt in equation nxt = 3 and the result will be converted to canonical form to simplify it. CheckE(Q). Convert state variables to next state variables in Q 2. Convert them to Integer Equations 3. Add them to other Equations, i.e. PF 4. Simplify them, i.e. canonical form convertion 5. Return Computed Equations Fig.7. Next State() operator Fig.8 illustrates the CheckEG procedure in the flowchart of Fig.5. We should compute Equation (2). Zi + = Q E ( Zi ); Z = Q (2) In each iteration we will compute E( Z ) in i two major steps as previously described. Completion of the procedure is indicated by Z i = Z i+. When this happens, equations will be returned that indicate conditions needed to satisfy the property being verified. The Limitation parameter is number of states of the design. Important point in this algorithm is that new equations are computed by the product of Q and the computed equations. We can define the product of Q and the computed equations because they are both in terms of integer equations. If Q includes relational operators, it will be applied to equations computed in previous step as a constraint.

As mentioned in Section 3.2, all product and sum terms in Z i and Z have been ordered, so i + comparison of them just need to compare product terms in same positions. For example consider two equations F = * Z* + 4*Z* and F2 = 4*Z* Z* + *, where ordering is Z>>. After translating to canonical form, Z*, Z* and * product terms will have same positions in two canonical forms and can compare easily. As an example, EG( = 3) will be converted to Equation (3) which indicates first, second and third iterations. In second iteration, = 3 is applied to equation of nxt from PF set as a constraint and then Equality operator is considered to make Z 2 and the result will be converted to canonical form to simplify it. If Z equals to Z, then algorithm will finish. 2 Otherwise, in third iteration, = 3 is applied to equation of Z 2 as a constriant and Z 3 is made. This iterative algorithm continues until Z i = Z i+ or number of iterations exceeds from Limitation parameter. Z = ( = 3); Z = ( = 3) E( Z ) 3 CheckEG (Q, Limitation) Z = Q (i = ) For i= to i <Limitation. exzi = E( Z ) i 2. Z = exzi * Q i + 3. IF Z == i + Z i 4. Verification Fail! Z = ( = 3) E( 3= ); 2 2 RETURN Z i + Fig.8. All States (G) operator 5 Experimental Results (3) We will verify different properties on five examples including the Traffic Light Control (TLC), Greatest Common Divisor (GCD), Elevator (EL), 2-Client Arbiter (2CA) and a Special Counter (SC) which is a 3 bit counter with a feedback from state 5 to state 4 when input I is []. TLC Properties:. start = & yellow_expire = & farm_light = ELLOW => E(hwy_light = GREEN). This property means that if farm_light is yellow and the yellow timing has been expired, then a path exists where hwy_light will be green at the next state. 2. start = & farm_light = RED & hwy_light = GREEN & car_present = => EG(hwy_light = GREEN). This indicates that if farm_light is red, hwy_light is green and there is not any car on the farm road, then a path exists where hwy_light always stays green. GCD Properties:. Reset = & Start = & = => E(Reset = ). This property says that if Reset and Start are zero and equals to then a path exists where Reset will be in the next state. 2. Reset = & Start = & = 5 & = 5 => E 2 ( = ). This means that if Reset and Start are zero and = 3 then a path exists that will becomes equal to two states later. SC Properties:. I = & Count = 5 => E 2 (Count = 5). This property indicates that if Count is 5, a path exists where Count will be 5 two states later. 2. I= & Count=5 => E(Count = 4). This says that a path exists that Count will become 4 at the next state. EL Properties:. Start = & door = CLOSED => EG(door = CLOSED). This property means that if Start is not active and door is closed, then a path exists where door always stays closed. 2. Start = & door = CLOSED => EG(movement = MOVING). This indicates that if Start is not active and door is closed, then a path exists where movement always stays moving. 2CA Properties:. Start = & (req or req2 = ) => EG(clin = A). This property says that if Start is not active and client or client2 has a request, then a path exists where client is always selected. This property must be fail because client2 never takes token. 2. Start = & req = => EG(pass_token = ). This means that if Start is not active and client has a request, then a path exists where client2 is always active. This property must be failed because of liveness property. Table compares our results with those of the VIS verification tool as a BDD based model checking []. As shown in the table, we have achieved less memory usage and CPU time. In the TLC example, Property took 3 seconds in

compared with 95 seconds by VIS on a Pentium III system with 256MB RAM. Also memory usage in our method is 3.2MB that is less than.mb used by VIS. Notice that we have used Windows-based VIS and CPU time in VIS is just related to some parts of VIS that calls E or EG functions and is not CPU time of all parts of VIS. In order to compute these times, we have added appropriate VIS functions to VIS source codes to report execution time of E or EG function calls. Table. Comparison with VIS Circuit TLC GCD SC EL 2CA P HLM 3.44 26 9 VIS 95 6. 72 58 P2 HLM 34.5.35 28 5 VIS 42.9 84 49 N HLM 2495 345 66 84 86 VIS 25246 5764 3 2337 692 M HLM 3.2.525.22.3.25 VIS. 7.5 4.7 5.2 4.8 P-P2: Cpu Time Property-Property2 (second) N: Number of Nodes (DFG, BDD) M: Memory Usage (MegaByte) HLM: our High Level Method 6 Conclusions In order to overcome problems related to the use of BDDs and other representations [3, 4], we use a high level of representation. As a result, we are able to manipulate complex designs in much less time and memory than FSM models using BBDs. Unlike FSM models, our representation treats data and control units together and is not limited to controller circuits or datapath circuits individually [3, 4]. Also there is performed simplification during canonical form translation instead of solving integer equations explicitely [6, 7, ]. [3] K. McMillan, Symbolic Model Checking, Kluwer Academic Publishers, Boston, 993. [4] R. Drechsler, Formal Verification of Circuits, Kluwer Academic Publishers, 2. [5] A. Biere, A. Cimatti, E.M. Clarke, M. Fujita and. Zhu, Symbolic Model Checking Using SAT Procedures Instead of BDDs, In Proceedings DAC, June 999, pp. 37-32. [6] C.-. Huang and K.-T. Cheng, Assertion Checking by Combined Word-level ATPG and Modular Arithmetic Constraint-Solving Techniques, In Proceedings of DAC 2, pp. 8-23. [7] R. Brinkmann and R. Drechsler, RTL-Datapath Verification using Integer Linear Programming, In Proceedings of IEEE VLSI Design & Asia and South Pacific Design Automation Conference, Bangalore, 22, pp. 74-746. [8] F. Fallah, Coverage Directed Validation of Hardware Models, PhD thesis, MIT, 999. [9] M.H. Reshadi, A.M. Gharehbaghi and Z. Navabi, Intermediate Format Standardization: Ambiguities, Deficiencies, Portability issues, Documentation and Improvements, HDLCon2, March 2. [] Robert K. Brayton, A. Sangiovanni, A. Aziz and et al, VIS: A system for Verification and Synthesis, Proceedings of the Eighth International Conference on Computer Aided Verification, 996. [] James C. Corbett and George S. Avrunin, Using Integer Programming to Verify General Safety and Liveness Properties, Formal Methods in system Design, No. 6, Jan. 995, pp.97-23. References: [] R.P. Kurshan, Formal Verification In a Commercial Setting, Design Automation Conference 997, pp. 258. [2] C. Kern and M.R. Greenstreet, Formal Verification In Hardware Design, ACM Transactions on Design Automation of Electronic Systems, Vol. 4, No. 2, April 999, pp. 23.