Arithmetic Unit

For the models of theArithmetic Logic Unit (ALU), we described a pipeline of length 3. The ALU has 4 registers that can store 3-bit values. It can handle three operations: ADD, SUB and NOP. The operations ADD and SUB add or subtract the values of two input registers and store the result in a target register.

3.4. EXPERIMENTS 51 Load inputs Compute result Writeback

(a) Detailed implementation

Nothing Nothing Do all

(b) Abstract implementation

Figure 3.6: Sketch of an implemented processors

The operation NOP does nothing. The implementations provide getter-methods for all registers and anextStep-method to load a new operation that is given as input and execute one step of the pipeline.

Like sketched in Figure 3.6, the more detailed implementation loads the values of the input registers in the first step and stores them in special registers in1andin2that do not exist in the abstract model. Afterwards, the result of the operation is computed in the second step and the result is stored in a register resultwhich also does not exist in the abstract model. The operation uses the values that are stored in in1andin2. Finally, the content of resultis written into the target register in the third step.

The abstract implementation executes an operation completely in its third step and acts as a queue. It does not load input values before or stores the result, but uses the values directly from the registers and writes them back immediately.

To ensure that these models behave equivalently, we block new operations that could lead to conflicts, i.e., use input or output registers that are currently used by other operations on the pipeline. When such an operation is used as input fornextStep, we put the operation NOP in the pipeline instead. Preventing conflicts is important as conflicts would cause different behavior in the two models due to their different implementation. Similarly, when an invalid operation is given, NOP is put in the pipeline instead.

An optimal candidate invariant for this example contains the following information:

1. Corresponding registers and pipeline operations need to be equal in both models.

2. All registers need to be 3-bit values, i.e., between 0 and 7.

3. All operations in the pipeline need to be valid.

4. There are no conflicts in the pipeline.

5. The registersin1,in2, andresultin the detailed model need to be correct.

Splitting the described candidate invariant into clauses leads to 95 clauses.

For the experiments, we modify the optimal candidate invariantalu-optimal by 1. Removing the equality of 1≤i≤4 registers: i-regNotEqual

2. Removing the correctness of the result in the detailed model: noResult 3. Adding a faulty equality of an input of the second operation and the output

of the third operation: wrongPipeEqual

52 CHAPTER 3. SYSTEM LEVEL EQUIVALENCE CHECKING Candidate Invariant NSMC EASY

Time #Calls Time #Calls

[s] [-] [s] [-]

alu-optimal 0.4 3 0.8 4

1-regNotEqual 10.0 62 12.4 50

2-regNotEqual 16.0 101 25.1 96

3-regNotEqual 31.0 175 33.7 142

4-regNotEqual 35.0 201 44.4 188

noResult T/O - T/O

-wrongPipeEqual T/O - 25.3 104

Table 3.1: Runtimes and CBMC calls on the processor models

The candidate invariantalu-optimaldescribes exactly all reachable states and therefore should support the equivalence check significantly. For the candidates i-regNotEqual, the algorithms need to detect the equality of the corresponding registers.

Removing the correctness of the result from the candidate invariant is a lot harder than removing equality of registers as the correctness of the result is very complex to describe. It depends on the operation in the third step as well as the values of the registers. The result needs to contain the sum or the difference of the values in the input registers of the operation and is therefore dependent on seven different variables: the four registers, the two input registers of the third operation, and the type of the third operation.

Table 3.1 shows the runtime and the number of CBMC calls of NSMC and EASY for the different candidate invariants.

Proving correctness foralu-optimaland the candidate invariantsi-regNotEqual takes longer with EASY compared to NSMC due to overhead like moving the clauses fromF₁ to F₂. Using a PDR-like implementation does not speed up the equivalence check in these cases, similar to the experiment with the optimal invariant and the counters. Even though EASY requires a smaller amount of CBMC calls for the candidate invariants i-regNotEqual, the total runtime is higher than NSMC as the specific checks like checking whether all clauses can be moved take more effort than the calls during generalization that are not done by EASY due to low level optimization. The larger number of initial and learned clauses compared to the example with the counters lead to an increased overhead.

On the other hand, the underapproximationwrongPipeEqual timed out when run by NSMC but is decided within 25.3 seconds by EASY as EASY can easily detect the wrong clause and will not propagate it.

However, both equivalence checkers cannot decide equivalence when more complicated parts of the candidate invariant are missing, like shown in the experiments with noResult. The currently used heuristics cannot learn this behavior but instead remove single assignments that cause unsafe states. As the number of those assignments is too large to remove them one by one, the algorithms time out.

The experiments with the simple processor models confirm the observation from Section 3.4.1. Both algorithms are able to handle the models with a good

3.4. EXPERIMENTS 53 hypothesis. The hypothesis does not need to be optimal, but a bad hypothesis leads to a timeout for both algorithms. While EASY can cause neglectable overhead, it can also decide equivalence for candidate invariants that NSMC cannot handle.