INFORMACIONES LABORALES

5.10

Inequivalences Forcing Terms

to be Constant

Inequivalences can force a term to be constant. Since the domain of a n-bit-vector is restricted to 2n values, setting it∼=_C to 2n−1 values implies equivalence to the remaining value. Fig. 5.14 (a) gives an example for a bit-vector, where b∼=_C10 and b∼=_C00 and b∼=_C11 ⇒ b ∼=_C01 holds. Note that there can be intervening assignments and other conditions in Fig. 5.14.

(a) if b="10" then ... elsif b="00" then ... elsif b="11" then ... else _b="01" is true _ (b) if a[3] then if a[2:1]="11" then ... elsif a[2:1]="10" then ... else _a[3:2]="10" is true _ Fig. 5.14: Terms being constant due to decided inequivalences

Two EqvClasses are inequivalent either because of a decision in a case split or since they contain different constants which is not relevant here. Check- ing after each decision whether the EqvClass is set inequivalent to 2n_{− 1 con-}

stants is not sufficient. Also decisions about parts of a term have to be consid- ered, see Fig. 5.14 (b) where a[3]∼=_C1 and a[2:1]∼=_C11 and a[2:1]∼=_C10 ⇒ a[3:2]∼=_C10 has to be detected. Moreover, it is not relevant in this example whether the entire term a is equivalent to a constant but only the bits a[3:2].

Two counters ctrl-zero-bit and ctrl-one-bit are introduced for each bit of a term appearing in conditions. They are initialized during pre-processing with 2N−1

where N is the length of the term (not 2N _{− 1!). A bit i of a term is equivalent}

to 0 (1) if ctrl-zero-biti (ctrl-one-biti) is zero. The counters are decremented if:

• the term is set inequivalent to a constant. ctrl-one-bit and ctrl-zero-bit are decremented at all bit-positions, where this constant is 0 or 1, respectively; a table supports determining the relevant bit-positions for constants ap- pearing explicitly in the descriptions since all constants are expressed as integers during simulation, see section 4.3;

• a bit-selection of a term is set inequivalent to a constant. Not only the ctrl- one-bit-and ctrl-zero-bit-counters of the term representing the bit-selection, e.g., a[2:1] are decremented but also the corresponding counters of the entire term a are decremented according to the size of the bit-selection. Multiple selections, e.g., (a[10:2])[2:1] are considered by recursion. Every time a new constant bit is found it is checked whether the whole term is constant, too. The equivalence of the bit has to be marked if this test fails. If there exists a term representing the bit-selection of the relevant bit then the corresponding EqvClasses are unified. Otherwise equivalence of the bit to the constant 0 or 1 is marked directly at the term.

Chapter 6

Using Decision Diagrams to

Detect Equivalences

Section 6.1 gives an overview of the dd-checks. The construction of formulas which demonstrate the equivalence to be verified is described in section 6.2. Checking those formulas by vectors of OBDDs is compared to other techniques in section 6.3. The use of intermediate dd-checks for gate-level simulation is presented in section 6.4. Section 6.5 discusses how the decisions of conditions are considered during a dd-check. The results of a dd-check are reused during the following symbolic simulation of the remaining paths which is described in section 6.6.

6.1

Overview

The equivalence detection techniques presented in the previous chapter are not complete in order to provide a fast symbolic simulation. Therefore, checking the verification goal by a test for equivalence at the end of a path (line 11 in Algorithm 4.1) may fail. The more accurate tests called dd-checks based on decision diagrams are used at the end of a path in these cases. They have to reveal whether (i) computational equivalence is given in this path but was not detected (line 16), (ii) a condition has been decided inconsistently due to the incomplete equivalence detection on the fly (line 19), or (iii) a valid counterexample can be given (line 22).

Decision diagrams are used in the dd-checks to reveal special equivalences which are not considered by the techniques presented in the previous chapter either since they occur seldom or because they are hard to detect. Examples are given in section 6.4, 6.5, and 7.3. Two tests are provided:

• testing whether two terms are equivalent; note that checking the validity of a condition is the same as comparing it to the constant 1;

• testing whether a term is equivalent to a constant; this is a different case since the value of the constant is unknown.

98 CHAPTER 6 Using Decision Diagrams to Detect Equivalences

A formula demonstrating the equivalence is built for each test considering knowl- edge about path-dependent equivalences or inequivalences of intervenient terms. The Multiple-Domain Decision Diagram Package (the TUDD-package) [H¨or99, H¨or97, H¨or98] developed at Darmstadt University of Technology with an exten- sion for vectors of OBDDs is used to prove the formula. Each graph represents one bit of the two terms to be compared. The extension developed for the symbolic simulator permits to apply functions to vectors of OBDDs instead of manipulating separately single decision diagrams.1 _{Therefore, the formula con-}

sisting of function applications to bit-vectors is checked automatically by the TUDD-package without additional modifications. It is tested whether a similar formula has been built previously and stored in a hash-table before applying vectors of OBDDs.

The dd-checks testing the verification goal at the end of the path may fail if a false path is reached. All decided conditions (i.e., CondBits in C for which a case-split was performed) are checked in order of their occurrence in this case to search for a contradictory decision due to the incomplete equivalence detection on the fly. Using the information of the equivalence classes again facilitates considerably the construction of the required formulas.

A path is backtracked if at least one formula is valid (line 16 in Algorithm 4.1) or if a contradictory decision has been detected (line 19). Moreover, the relationship revealed by the dd-check is marked as described in section 6.5 so that it is checked during symbolic simulation of the remaining paths. Otherwise a valid counterexample is found which is reported for debugging.

Section 4.6 motivated the use of intermediate dd-checks at gate-level also dur- ing the path search (line 9 in Algorithm 4.2) instead of using them only at the end of a path. The intermediate tests are discussed in section 6.4.

The dd-checks do not make the equivalence detection complete, since some functions like multiplication or memory operations are not interpreted during the dd-check to avoid extensive computation times and/or graph explosion. These terms are represented by dd-cutpoints (described in the next section) during OBDD-construction. Additional dd-cutpoints are used to speed up the dd-checks. In spite of these simplifications, the dd-checks provide a substantial improvement of the equivalence detection. No corner-case has been found during our experi- ments which was not detected by the implemented dd-checks. Note that the dd- checks need not be incomplete in principle in our symbolic simulation approach. The incompleteness is caused by the dd-cutpoints which are only introduced be- cause of the practical limitations of current OBDD-packages.

1_{For example, the application of the function ADD to two vectors of OBDDs{a}

0, . . . , an}

and {b0, . . . , bn} is implemented using the basic functions and, or, and xor of the TUDD-