Model-checking based Verification for Hardware Designs specified using Bluespec System

Model-checking based techniques are widely employed to the RTL and gate-level models of a hardware design for verification of its desired properties. In case of complex designs, such techniques are associated with the state-explosion problem when many components of a design make transition in parallel. Thus, using such low-level models for the verification of a complex design involves reducing the state space of the design by applying various abstraction techniques. These techniques ignore the irrelevant details in the description of the design while maintaining its desired behavior. Recently, high-level synthesis has emerged as an efficient way of generating hardware designs from high-level (above RTL) behavioral models of these designs. Applying verification techniques on such high-level models avoids the need for using various abstraction techniques since such models already ignore various low-level details which are irrelevant for verifying a design’s behavioral properties. We consider one such high-level model in which atomic transactions are used to describe the behavior of a design, which can then be synthesized to the corresponding RTL code. In such a model, each transaction is composed of a collection of operations, and is atomic in the sense that all its operations are executed without being interleaved or interrupted by operations of other transactions of the design. Bluespec System Verilog is an example of such a high-level specification language. Formal verification tools such as SMV and Spin can be used to verify the correctness properties of such high-level behavioral models. In this paper, we propose a model checking approach which uses the transactions-based models of hardware designs for faster and easier verification early in the design cycle. Since Spin (which is a model checking tool used for formal verification of distributed software systems) inherently supports the notion of atomicity, we demonstrate the usefulness of our approach by using Spin to verify such transactions-based models. As part of the proposed approach, we present a technique to convert a transactions-based description of a design into an appropriate model suitable for model checking using Spin. We demonstrate the applicability of our proposed technique by using it to verify the correctness of various realistic designs. Atomic Transactions-based Hardware Descriptions Most existing high-level or behavioral synthesis techniques take the input specification of the hardware at an abstraction level which is slightly higher than the RTL level, namely CDFGs or composition of CDFGs such as MTGs [1]. In this work, we consider a different model where the behavior of the target hardware is described using atomic transactions. Such a model can be expressed using any high-level modeling language 2 such as SystemC or Bluespec System Verilog (BSV). At this abstraction level, behavioral description of the design consists of various atomic transactions, each of which has an associated guard. A transaction is executed only when its guard evaluates to True. Figure 1 shows an example of transaction-oriented description of a simple Packet Processor. Transaction1 corresponds to the operations that the processor executes when a packet arrives. Then, operations in Transaction2 process that packet. And finally, Transaction3 corresponds to the departure of the packet. Transaction1: Transaction2: Transaction3: true → { //Receive packet. ∧ (a > 0) → { //Process packet. ∧ (b > 0) → { //Send packet. ∧ a := a + 1}; b := b + 1 ∧ b := b 1}; a := a 1}; Fig. 1. Transactions-based Description of Packet Processor. Such a transactions-based model then undergoes synthesis to generate the RTL code. In the generated hardware, two transactions conflicting with each other are not allowed to execute concurrently in the same clock cycle. For example, for the Packet Processor shown in Figure 1, Transaction1 and Transaction2 conflict with each other because they both update the same state element a. In such cases, a higher priority transaction is chosen for execution. For the Packet Processor, Transaction2 is always chosen over Transaction1 whenever both can execute in the same clock cycle. Thus, in a transactions-based model, maximal subset of non-conflicting transactions of a design are allowed to execute concurrently in each clock cycle. Concurrent transactions shown in Figure 1 do not necessarily reflect the amount of parallelism that can be exploited through such a synthesis process because it is an over simplified example for illustrating the transaction-oriented specification style. However, large examples of similar kind may be found in [2], [3], [4] where such modeling is explained in more details. Bluespec Inc.’s high-level synthesis tool named Bluespec Compiler is based on this technique [5], [6], [7].