Token-Aware Completion Functions for Elastic Processor Verification

Abstract

We develop a formal verification procedure to check that elastic pipelined processor designs correctly implement their instruction set architecture (ISA) specifications. The notion of correctness we use is based on refinement. Refinement proofs are based on refinement maps, which—in the context of this problem—are functions that map elastic processor states to states of the ISA specification model. Data flow in elastic architectures is complicated by the insertion of any number of buffers in any place in the design, making it hard to construct refinement maps for elastic systems in a systematic manner. We introduce token-aware completion functions, which incorporate a mechanism to track the flow of data in elastic pipelines, as a highly automated and systematic approach to construct refinement maps. We demonstrate the efficiency of the overall verification procedure based on token-aware completion functions using six elastic pipelined processor models based on the DLX architecture.

1. Introduction

The impact of persistent technology scaling results in a previously ignored set of design challenges such as manufacturing and process variability and increasing significance of wire delays. These challenges threaten to invalidate the effectiveness of synchronous design paradigms at the system level. Several alternate design paradigms to deal with these challenges are being proposed. One popular trend is latency-insensitive designs, which allows for variability in data propagation delays [1]. Synchronous Elastic Networks (SENs) [2, 3] hav been proposed as an effective approach to design latency-insensitive systems.

One of the critical challenges for any design approach to succeed is verification. We present a novel highly automated formal verification solution for latency-insensitive pipelined microprocessors developed using the SEN approach (here on referred to as elastic processors). Note that correctness proofs for methods to synthesize elastic designs from synchronous designs have been provided [2], but this is not a substitute for verification. The idea with the verification approach is to show that the elastic processor correctly implements all behaviors of its instruction set architecture (ISA) model, which is used as the high-level specification for the processor. The notion of correctness that we use is Well-Founded Equivalence Bisimulation (WEB) refinement, a detailed description of which can be found in [4]. It is sufficient to prove that the elastic processor (implementation) and its ISA (specification) satisfy the following core WEB refinement correctness formula to establish that the elastic processor refines (correctly implements) its ISA.

Definition 1.1 (Core WEB Refinement Correctness Formula). One has ⟨∀𝑤∈𝐼𝑀𝑃𝐿→∶∶𝑠𝑠𝑣===𝑟𝑟𝐼𝑠((𝑣𝑤𝑡𝑒))𝑝∧∧(𝑤𝑟𝑢𝑎)𝑛=∧𝑘𝑆𝑢(𝑣𝑠≠)𝑡𝑒<𝑟𝑝((𝑣𝑟𝑠𝑎))𝑛∧𝑘(𝑤)⟩.(1)

In the formula above, IMPL denotes the set of implementation states, Istep is a step of the implementation machine, and Sstep is a step of the specification machine. The refinement map 𝑟 is a function that maps implementation states to specification states. In fact, the refinement map can be thought of as an instrument to view the behaviors of the implementation machine at the specification level, thereby allowing verification tools to easily compare the behaviors of the two systems. 𝑟𝑎𝑛𝑘 is used for deadlock detection. Our focus in this work is to check safety, that is, to show that if the implementation makes progress, then, the result of that progress is correct as specified by the high-level specification. We plan to address deadlock detection in future work, and we therefore ignore 𝑟𝑎𝑛𝑘 for the present.

The specific steps involved in a refinement-based verification methodology are (a) construct models of the specification and implementation, (b) compute the states of the implementation model that are reachable from reset (known as reachable states), (c) construct a refinement map, and (d) the models and the refinement map can now be used to state the refinement-based correctness formula (excluding deadlock detection) for the implementation model, which can then be automatically checked for the set of all reachable states using a decision procedure. Modeling and verification are performed using ACL2-SMT [5], a system developed by combining the ACL2 theorem prover (version 3.3) with the Yices decision procedure (version 1.0.10) [6].

The primary challenge in applying the refinement-based approach to elastic pipelines is as follows. The very attractive property of elastic systems is that they allow for the insertion of buffers (known as elastic buffers) in any place in the data path to deal with propagation delays of long wires, without altering the functionality of the system. The insertion of these buffers however can drastically change the data flow patterns of the system, making it hard to compute refinement maps for these systems. Our primary contribution is a procedure—we call token-aware completion functions—that computes refinement maps for elastic pipelined systems (described in Section 3) even after the insertion of elastic buffers in any place in the data path. The procedure allows for highly automated and efficient verification of elastic pipelined systems. The effectiveness of our verification method is demonstrated using 6 DLX-based elastic pipelined processor models. The models are described in Section 2. Verification results are given in Section 4, and we conclude in Section 5. Due to limited space, we request the reader to refer to literature for background on synchronous elastic networks [2, 3] and refinement [4].

Note that this is the first known approach that aims to verify the correctness of elastic pipelined processors against their high-level nonpipelined ISA specifications. In previous work, we have developed an equivalence checking approach that is used to verify elastic pipelines against their synchronous parent pipelines [7].

2. Elastic Processor Models

The elastic processor models are based on the 5-stage DLX pipeline. The elastic processor models and their nonpipelined ISA-level specifications are described using the ACL2 programming language and are defined at the term-level, because term-level abstractions make the verification problem tractable. We use the ACL2-SMT system for verification as it can be used to reason at the term-level. Note that bit-level versions of these models were used in [7]. The models were obtained by first elasticizing a synchronous 5-stage DLX processor using the Synchronous Elastic Flow (SELF) protocol approach [2]. The main idea is to replace all flip flops with elastic buffers (EBs) that are constructed from two elastic half buffers (EHBs), namely, a master EHB and a slave EHB. The clock network is replaced by a network of elastic controllers, where each controller is used to control the elastic buffers in a pipeline stage and synchronized with the controllers of adjacent pipeline stages. The controllers are synchronized with the clock and are connected in accordance with connections between pipeline stages in the data path. Each controller has three possible states, 𝑒𝑚𝑝𝑡𝑦, ℎ𝑎𝑙𝑓, and 𝑓𝑢𝑙𝑙, which indicate that the corresponding elastic buffer has 0, 1, and 2 valid data tokens, respectively.

We call the processor model obtained by elasticizing the synchronous DLX 𝑀0. The main advantage of the elastic processor is that it permits the insertion of additional elastic buffers at any place in the data path to break long wires. We therefore inserted additional elastic buffers 𝑙1,…,𝑙5 at various places in the model. We inserted 𝑙1 in model 𝑀0 to get model 𝑀1. We then inserted 𝑙2 in model 𝑀1 to get 𝑀2. We derived models 𝑀3, 𝑀4, and 𝑀5 in a similar manner. The model M5 is shown in Figure 1. The figure also shows the positions of the additional elastic buffers and how they are connected with the elastic buffers corresponding to the pipeline latches (namely 𝑝𝑐,𝑓𝑑,𝑑𝑒,𝑒𝑚, and 𝑚𝑚). The network of elastic controllers for the DLX processor with five additional elastic buffers in the data path is shown in Figure 2. These models are used to demonstrate the effectiveness of our verification approach.

Figure 1 

High-level organization of elastic 5-stage DLX processor with five additional elastic buffers 𝑙1,𝑙2,…,𝑙5.

Figure 2 

Network of elastic controllers for the elastic 5-stage DLX processor shown in Figure 1. The J and F blocks denote the join and fork circuits. Valid is used to indicate valid data in the datapath. Stop is used to indicate that EB cannot accept data at this time.

3. Token-Aware Completion Functions

Flushing [8] is one standard approach used to compute refinement maps for pipelined processors. In this approach, partially executed instructions in the pipeline latches are forced to complete, without allowing the machine to fetch any new instructions. Projecting out the programmer visible components—which include the program counter, register file, instruction memory, and data memory for the models we consider—in the resulting state will give the corresponding ISA state.

Completion functions [9] were proposed as a computationally efficient approach to construct flushing refinement maps. One completion function for each pipeline latch in the machine is used to compute the effect on the programmer visible components of completing any partially executed instruction in that latch. The completion functions are composed to form the flushing refinement map. Note that older instructions in the pipeline are completed before younger instructions. For the DLX example, let 𝑓𝑑𝑐, 𝑑𝑒𝑐, 𝑒𝑚𝑐, and 𝑚𝑚𝑐 be the completion functions for the latches 𝑓𝑑, 𝑑𝑒, 𝑒𝑚, and 𝑚𝑚, respectively. Let 𝑟𝑓, 𝑖𝑚, and 𝑑𝑚 be the register file, instruction memory, and the data memory of the processor model. The ISA state 𝑠 corresponding to a synchronous DLX processor state 𝑤 (⟨𝑝𝑐^𝑤,𝑓𝑑^𝑤,𝑑𝑒^𝑤,𝑒𝑚^𝑤,𝑚𝑚^𝑤,𝑟𝑓^𝑤,𝑖𝑚^𝑤,𝑑𝑚^𝑤⟩) is ⟨𝑝𝑐^𝑠,𝑟𝑓^𝑠,𝑖𝑚^𝑠,𝑑𝑚^𝑠⟩= fdc(dec(emc(mmc (⟨𝑝𝑐^𝑤,𝑟𝑓^𝑤,𝑖𝑚^𝑠,𝑑𝑚^𝑤⟩, 𝑚𝑚^𝑤),𝑒𝑚^𝑤),𝑑𝑒^𝑤),𝑓𝑑^𝑤).

When we try to apply the completion functions approach to elastic pipelined processors, two issues arise. First, in some states of the elastic processor, instructions can be duplicated in the data path; that is, an instruction can reside in two pipeline latches. Such a situation can occur at a fork when the instruction in a buffer before the fork has proceeded along one path of the fork, but the other path is blocked. The latch before the fork has to retain the instruction until both paths are cleared. A direct application of the completion functions-based map to such a state will result in completing the same instruction twice leading to an erroneous refinement map. Second, Elastic Half Buffers (EHBs) need not have valid tokens. The contents of such EHBs should be ignored and should not be used to update the programmer visible components.

We introduce token-aware completion functions as a method to compute flushing-based refinement maps for elastic pipelined processors. The idea being that EHBs which are either holding duplicate instructions or are in an empty state should not be completed. This is achieved by first computing the reachable states of the elastic controller network. We use token-flow diagrams proposed in [7] to compute the reachable states of the system. The reachability analysis is performed by simulating how tokens flow in the elastic architecture using a form of symbolic simulation. The output of the token-flow diagrams is a set of token-states, one token-state for each reachable state. In a token-state, each EHB is assigned a numbered token, which is essentially a natural number. A value of “0” indicates a bubble; that is, the EHB is empty. Also, EHBs with the same instruction will be assigned the same token numbers. Thus, using the token-state, duplicate instructions and empty EHBs can be identified.

The token-aware completion functions approach works by first computing a two-dimensional array; we call token-array. Each row in the array corresponds to a reachable state of the elastic controller network. Each element in a row is a binary value. The number of elements in a row is 2𝑛, where 𝑛 is the number of pipeline latches in the elastic system. If token-array (𝑖,𝑗)=1, then the contents of EHB 𝐻_𝑗 in the reachable state 𝑆_𝑖 should be completed. If token-array (𝑖,𝑗)=0, then the contents of EHB 𝐻_𝑗 in the reachable state 𝑆_𝑖 should be ignored when computing the refinement map. Given the set of token-states (which are the reachable states represented using numbered tokens) of the elastic controller network of an elastic system, Procedure 1 computes the token-array for the elastic system.

Procedure. In:𝑆_𝑅, set of token-states of the elastic controller network and 𝑃𝐻, the ordered set of pipeline half buffers. The number of token states (|𝑆_𝑅|) is 𝑟. The number of pipeline half buffers (|𝑃𝐻|) is 2𝑛, where 𝑛 is the number of pipeline latches. The order of the pipeline half buffers is determined by the position of the buffer in the pipeline; that is, buffers closer to the end of the pipeline have a higher index.Out:token-array for the elastic system.(1) Initialize 𝑖 to 𝑟.(2) Initialize 𝑉_𝑡 (the set of visited tokens) to {0}. The token number “0” represents a bubble. Note that initializing 𝑉_𝑡 to {0} causes the procedure to assign a “0” value to the empty EHBs in the token-array.(3) Initialize 𝑗 to 2𝑛.(4) Let 𝑡=token (𝑆_𝑖,𝑃𝐻_𝑗), where 𝑡𝑜𝑘𝑒𝑛 is a look-up function that gives the token number for EHB 𝑃𝐻_𝑗 in token-state 𝑆_𝑖.(5)token-array (𝑖,𝑗)=¬(𝑡∈𝑉_𝑡)(6) Assign 𝑉_𝑡=𝑉_𝑡∪{𝑡}: add the token number of EHB 𝑃𝐻_𝑗 to the visited token set.(7) If 𝑗−1≠0, decrement 𝑗 and go to step 4.(8) If 𝑖−1≠0, decrement 𝑖 and go to step 2. Procedure 2 takes as input the token-array and computes the flushing refinement map for the elastic system using completion functions.

Procedure. In: Elastic processor state 𝑤: ⟨𝑃₁,…,𝑃_𝑚,𝐻₁,…,𝐻_2𝑛⟩. 𝑃₁,…,𝑃_𝑚 are the programmer visible components, and 𝐻₁,…,𝐻_2𝑛 are the half buffers in the pipeline latches of the elastic machine.Out: ISA state 𝑠 obtained by applying the flushing refinement map to 𝑤.(1) Let 𝑆_2𝑛+1=⟨𝑃₁,…,𝑃_𝑚⟩. (2) Initialize 𝑖 to 2𝑛.(3)𝑟=reachable-state (𝑤), gives the number of the reachable elastic controller network state of 𝑤, assuming that the reachable states are numbered.(4)One has 𝑆_𝑖=𝑐𝑜𝑚𝑝𝑙𝑒𝑡𝑖𝑜𝑛𝑆^𝑖+1𝑆,𝐻_𝑖,if𝑡𝑜𝑘𝑒𝑛-𝑎𝑟𝑟𝑎𝑦(𝑟,𝑖)=1,_𝑖+1,otherwise.(2)(5) If 𝑖−1≠0, decrement 𝑖 and go to step 3.(6)Then, 𝑠=𝑆₁.

Example 3.3. The elastic controller network of the 𝑀5 processor model has two reachable states 𝑆₁ and 𝑆₂. The token-states 𝑇₁ and 𝑇₂ (given as a vector of token numbers for the EHBs in 𝑀5 in the order ⟨𝑝𝑐∣𝑓𝑑∣𝑑𝑒∣𝑒𝑚∣𝑚𝑚∣𝑙1∣𝑙2∣𝑙3∣𝑙4∣𝑙5⟩) corresponding to these reachable states 𝑆₁ and 𝑆₂, respectively, are ⟨0,7∣0,6∣0,5∣0,4∣0,0∣0,0∣0,0∣0,3∣0,0∣0,3⟩ and ⟨0,0∣7,6∣0,5∣0,0∣0,4∣0,7∣0,4∣0,3∣0,3∣0,0⟩ [7]. Note that there are two tokens in the token-states for each EB, one corresponding to the master EHB and the other corresponding to the slave EHB. The completion function-based refinement map obtained using Procedures 3.1 and 3.2 for any state 𝑤 of processor model 𝑀5 whose elastic controller network is state 𝑆₁ is ⟨𝑝𝑐^𝑠,𝑟𝑓^𝑠,𝑖𝑚^𝑠,𝑑𝑚^𝑠⟩=𝑓𝑑𝑐(𝑑𝑒𝑐(𝑒𝑚𝑐(𝑚𝑚𝑐(⟨𝑝𝑐^𝑤,𝑟𝑓^𝑤,𝑖𝑚^𝑠,𝑑𝑚^𝑤⟩,𝑙5^𝑤𝑠),𝑒𝑚^𝑤𝑠),𝑑𝑒^𝑤𝑠), 𝑓𝑑^𝑤𝑠). The completion function-based refinement map obtained using Procedures 3.1 and 3.2 for any state 𝑤 of processor model 𝑀5 whose elastic controller network is state 𝑆₂ is ⟨𝑝𝑐^𝑠,𝑟𝑓^𝑠,𝑖𝑚^𝑠,𝑑𝑚^𝑠⟩= fdc(fdc(dec(mmc (⟨𝑝𝑐^𝑤,𝑟𝑓^𝑤,𝑖𝑚^𝑠,𝑑𝑚^𝑤⟩,𝑚𝑚^𝑤𝑠),𝑑𝑒^𝑤𝑠),𝑓𝑑^𝑤𝑠), 𝑓𝑑^𝑤𝑚).

4. Results

The token-aware completion functions approach was used to verify safety for six elastic pipelined processors 𝑀0,…,𝑀5. The results are shown in Table 1. Verification was performed using the ACL2-SMT system. The ACL2-SMT system incorporates a translator that reduces the correctness theorem to a decision problem in the form of a formula in a decidable logic that Yices can handle. The decision problem is then checked by Yices. Column “Bool Vars” gives the number of Boolean variables in the decision problem. The experiments were conducted on a 1.8 GHz Intel (R) Core(TM) Duo CPU, with an L1 cache size of 2048 KB. As can be seen from the table, each of the elastic 5-stage DLX-based processors was verified against the high-level instruction set architecture (ISA) within 25 seconds, thereby demonstrating the high efficiency of our approach.

Table 1 

Verification times and SMT statistics.

5. Conclusions

We have developed a method for checking the correctness of elastic pipelined processors against their high-level instruction set architectures. The approach was demonstrated by verifying 6 DLX-based elastic processor models. For future work, we plan to further explore the scalability of the verification method.