• No results found

Notifying Results at Equivalence Classes

4.3

Notifying Results at Equivalence Classes

EqvClasses permit to notify the results of the symbolic simulation. Equivalent terms are collected in EqvClasses. Therefore, checking whether two terms are equivalent consists of comparing their EqvClass. Furthermore, inequivalences are notified at the EqvClasses. If two terms are identified to be inequivalent then the inequivalence is marked at both corresponding EqvClasses. All other terms of the two EqvClasses are marked in this way as inequivalent, too.

Notifying the inequivalence of EqvClasses with constants is not necessary since two EqvClasses with constants are in any case inequivalent. Including the con- stant in the list of members of the EqvClass is not efficient. It is frequently tested during symbolic simulation if an EqvClass contains a constant. These tests would make it necessary to go through the list of members. Therefore, constants are separately marked at EqvClasses.

EqvClasses are created initially only for those constants which appear explicitly in the descriptions being compared. The dynamic creation of EqvClasses during the symbolic simulation can become necessary if the equivalence detection detects the equivalence of a term to a constant which does not appear explicitly.

Example 4.8

A description contains the clause if a=7 then x←a[1:0] . . . . The EqvClass for the constant 7 is created during pre-processing. The terms x and a[1:0] in the then-branch are equivalent to the constant 3. It is detected during symbolic simulation that an EqvClass with this constant has to be created if the constant does not appear explicitly elsewhere in the description.6

Constants, which are described as bit-vectors in LLS/IDS, are translated to in- tegers during pre-processing, e.g., (CONST 1 1 0) is transformed to 6. Avoiding the representation as a bit-vector reduces the size of the descriptions and permits a significantly faster comparison of constants during symbolic simulation.7

The unification of two EqvClasses is implemented as the elimination of one of the EqvClasses. The unification procedure guarantees that an EqvClass with a constant is never eliminated.8 The remaining EqvClass inherits from the elimi- nated EqvClass:

• the members;

6The creation of an EqvClass can be avoided by assigning the new constant to the Eqv-

Class of the terms x and a[1:0]. This approach is avoided since it violates the separation of equivalence detection and unification of EqvClasses in the implementation of the simulation tool.

7The length of the initial bit-vector need not be notified: a constant is either compared or

assigned to a term or a RegVal ; their length is available during symbolic simulation. Compa- tibility of the bit-vector length is checked during pre-processing.

52 CHAPTER 4 Symbolic Simulation Procedure • the list of inequivalent EqvClasses; it is not necessary to consider Eqv- Classes with a constant in this list if the remaining EqvClass contains a constant;

• the list of read-operations, which use one of the terms in the EqvClass as address, see section 5.9 and 4.2;

• restrictions concerning the range of the terms in the EqvClass. For exam- ple, if x<5 is decided to be true in a case-split, then the EqvClass of x has a restriction ”< 5”; Section 5.5 discusses how the information about these restrictions is used to detect equivalences and to decide conditions consistently;

• the list describing which bits of the terms in the EqvClass are identified to be equivalent to constants; this information is obtained basically if there is a concatenation term in the EqvClass; if one of the arguments of the concatenation is equivalent to a constant then the corresponding subvector of the concatenation term is notified as constant.9 For example, the term

x[2:0] & y[6:0] is constant at the bit positions 8 to 10 if x is equivalent to a constant. The unification with another EqvClass can reveal that all bits are equivalent to constants; another unification with the EqvClass of the resulting constant follows in this case.

After inheriting the properties of the eliminated EqvClass it is checked if one of the results of a previous dd-check can be reused, see section 4.2 and 6.6. Furthermore, read-or store-operations with addresses in the EqvClass are re- checked, see section 4.2 and 5.9.

Note that terms in the same EqvClass need not have the same bitvector-length. Example 4.9

The terms a[2:0] and b[1:0] are in the same EqvClass, if they are both equiv- alent to the same constant. The same holds for the concatenation 000&a[4:0] and the subterm a[4:0] although the length of the first term is greater.

This fact is considered in the dd-checks described in chapter 6 when substituting a term by another term in the same EqvClass during formula construction.

Practically, the union-operation of two EqvClasses caused by an assignment is very simple. The EqvClass of the RegVal on the left-hand side of the assignment is guaranteed to be unmodified. Therefore, it is sufficient to change the EqvClass of the RegVal and to mark it as an additional member of the EqvClass of the assigned term.

9This is redundant, if each subterm is equivalent to a constant; the concatenation is in the