Establishing PCI Compliance Using Formal Verification: A Case Study Ilan Beer (*), Shoham Ben-David, Cindy Eisner, Yechiel Engel, Raanan Gewirtzman and Avner Landver IBM Science and Technology, Haifa Research Laboratory Haifa, Israel (*)
[email protected]
Introduction
This paper presents a case study in the practical application of formal verification. Specifically, we describe our experience in applying the formal verification technique of symbolic model checking to the verification of PCI bus bridges. During the last 2 years, we have used symbolic model checking to verify more than 12 hardware designs, including a number of PCI bus bridges. This use of formal verification has led to the better understanding of formal verification capabilities and the establishment of formal verification techniques as a standard verification tool in the Haifa Design Group at IBM’s Haifa Research Laboratory. More than 5 PCI bus bridge designs have been verified using formal verification, including a design in which formal verification was used to do all checks at the unit level. A PCI bus bridge design that was verified with formal verification was announced as an IBM product and became available to customers after a single tape-out. Background and motivation
Functional verification of complex hardware designs is usually performed using test-based techniques (cf. [LMA 94]). These include behavioral, RTL and gate-level simulation, and fast prototyping using FPGAs and other techniques. The main problem with this approach is well known: how do we know that the test suite adequately tests the functionality of the chip, and how do we generate these tests? Formal verification attempts to provide a solution to functional verification that bypasses these problems by proving (or disproving) correctness of the design with respect to the specification. A formal proof of a property
is equivalent to exhaustive testing of the design with respect to that property. Our work is based on the symbolic model checker SMV developed at Carnegie-Mellon University (cf. [McM93]). We have developed various enhancements that considerably increase the size of designs the SMV can handle (cf. [GB94]), and have added an interface that integrates formal verification into an industrial design environment. Format of this presentation
This presentation will cover the practical aspects of formal verification, and will show its efficiency in the verification of real designs. Focusing on the formal verification of PCI bus bridges, we will discuss the process of modelling the environment, present typical rules of a PCI bus bridge and discuss reusability of those rules from design to design. We will take a look at the results of the process, including the number of bugs discovered and the effort required to discover bugs/prove a property. Finally we will discuss our interface to SMV, and show by example how it converts symbolic model checking from an exotic point tool requiring specialized knowledge into a verification tool suitable for day-to-day use by hardware designers. A typical PCI bus bridge
A typical PCI bus bridge consists of two units, a PCI Master and a PCI Slave, coded in VHDL or in another HDL. These units consist of many state machines, some of which are quite large, which communicate with one another. The control logic is complicated and errorprone. Data also exists in the form of queues, buffers, etc. The interfaces of these units are characterized by the PCI
standard as well as by the specification of the particular design.
and AX, as “for every path at every point in time” and “for every path at the next point in time”, respectively):
Each unit is checked separately, due to size limitations. The first step is to compile the VHDL into a technologyindependent gate-level representation. Since this step is functional only (no constraints and no optimizations), the synthesis is fast. The resulting netlist is readable by our formal verification environment. The size of a typical design is shown in Table 1.
AG (!FRAME -> (AX (FRAME -> !I_RDY)))
TABLE 1.
Typical Design Size
Unit size (gates)
Size after automatic reductions
No. of Rules
Time per rule
A
1650
560
45
5m
3h
B
3000
1000
120
1-4 h
3d
C
5400
1400
350
1-2 h
3d
D
5000
2000
400
1-4 h
6d
E
7180
1630
120
10 m 1h
1d
Total Time
The rules
For a typical PCI bus bridge unit hundreds of rules are written, each of which describes the expected behavior of the unit with respect to its interface. It is important to note that model checking with SMV is best suited to verifying complex control logic, but is not particularly suited to the flow of data. For this reason we concentrate on the control logic, and leave data to simulation. A rule is a fragment of a specification, written in the temporal logic CTL. The rule describes what the design must do, but not how to test it. That is the job of the symbolic model checker. A rule which can be described in one line of temporal logic would frequently have required hundreds if not thousands of simulation runs to prove in the traditional simulation-based approach to verification. Herein lies the beauty of symbolic model checking. For instance, a standard PCI rule states that: “When FRAME rises, IRDY must be active.” Here is the rule in CTL (read the two temporal logic operators, AG
Nothing is said about how FRAME got asserted. Had we used simulation, we would have had to think of all possible cases, or worse, to choose a representative set of tests that cover (we hope) all possible cases. Formal verification frees us from such effort. Since PCI rules (and, indeed, spec-derived rules for any design) talk mainly about the interface of the chip, they are easily transportable from one design to the next. And whereas the quality of a test suite is dependent on the implementation of a design (that is, a test suite that completely tests one implementation may not completely test another implementation which has more internal states), a set of PCI rules equally covers any implementation of the PCI specification. The PCI Specification Version 2.0 (cf. [PCI93]) includes some 40 rules and guidelines, including command usage, arbitration, signal stability, exclusive access, 64-bit PCI, performance and others. Most of the specification is covered by a standard “bucket” of formal verification rules. Additionally, for a PCI-to-PCI bus bridge, there are further rules in the PCI-to-PCI Bridge specification, most of which were also modeled in the verified PCI-to-PCI bus bridge. Modelling the environment
A typical PCI bus bridge environment contains between 100 and 800 lines of code, and requires a few personweeks to model. Typical environments modeled in the formal verification of a PCI bus bridge include the arbiter, alternate PCI master/slaves, and PCI “Central Resource”. Theoretically, all that is needed for formal verification is the design and the rules. However, in real life things are not so simple. The fact that in symbolic model checking we do not have to supply input vectors as in simulation can be a disadvantage. The problem lies in the fact that the symbolic model checker will want the rules we present to it to hold for all possible input sequences. However, some input sequences are illegal or will never appear, and the function of the hardware for these input sequences is a don’t care. We need some way to communicate this information to the model checker. This
is done by modelling the environment, and is written in SMV’s input language, also called SMV. The following code fragment illustrates the restriction of the environment of input ‘data_bit’ to change only when the output ‘FRAME_fall | Data_Phase’ allows it:
Figure 1.
A counter-example
VAR data_bit: boolean; ASSIGN init(data_bit) := 0; next(data_bit) := case FRAME_fall | Data_Phase : {0,1}; 1 : data_bit; esac;
The assignment of the expression ‘{0,1}’ to the input ‘data_bit’ is a non-deterministic assignment. It means that the value of ‘data_bit’ can be either 0 or 1. In the above code fragment, the non-determinism is used to express the fact that whenever ‘FRAME_fall | Data_Phase’ is active the value of ‘data_bit’ can change, and otherwise it must hold steady. In this way we have compactly expressed all possible legal input sequences. The verification of a real hardware design typically involves modelling multiple environments for each input. The main reason for this is to allow the reduction of the full model into something more manageable. A simple example of this is creating three environments for a PCI bus bridge - one performing only reads, one only writes, and the third doing both reads and writes. We will concentrate our efforts on the two simple environments before running tests on the bigger environment which takes more time and space to run. Our designs usually include up to 20 different environments.
Results of the process
The following table summarizes our experience in applying formal verification to a number of real hardware designs.
TABLE 2.
Counter-examples
If a rule passes, all is well and good. However, the information that a rule fails is not very useful unless a counter-example is provided. A counter-example is a waveform which describes a violation of the rule. For instance, the waveform shown in Figure 1 is a counterexample re-produced as a waveform.
Design
Results of Formal Verification Bugs found by formal verif.
Personeffort
Elapsed time
A
22
2m
4m
B
20
3m
4m
C
40
3m
5m
D
35
3m
3m
E
17
2m
3m
Our Formal Verification Tool
Our formal verification tool provides automatic translation of VHDL and other HDLs into SMV. It also provides the waveform display as shown above. Both of these, as well as the graphical user interface we provide, are necessary but not sufficient to make SMV a tool that is easy to use in day-to-day design work. This section focuses on enhancements to the temporal logic CTL that we use in order to make SMV more accessible to the general designer. Simplifying coding in CTL
CTL is very powerful as a language to describe design rules. We will not go into a general description of the language here, but suffice it to say that the rules can often get quite complicated. For instance, consider the following PCI rule: “When latency timer is off and grant is de-asserted, end transaction as soon as possible (for read transactions).” The expression of this rule in CTL is: AG ((FRAME_fall & READ) -> AX !E[!(((((DATA_PHASE & I_PGNT_N) & !LATENCY) & AX I_FRAME_N) | I_FRAME_N)) U (!(((((DATA_PHASE & I_PGNT_N) & !LATENCY) & AX I_FRAME_N) | I_FRAME_N)) & !(!((DATA_PHASE & I_PGNT_N) & !LATENCY)))])
We allow the easy expression of this rule using additional language constructs. In our tool, this rule would be expressed simply as: SPEC AG ((FRAME_fall & READ) -> AX within[now,I_FRAME_N] (next_event(DATA_PHASE & I_PGNT_N & !LATENCY) (AX I_FRAME_N)))
where “within” gives the scope of the rule, and “next_event(a)(b)” means that the next time that “a” occurs, “b” should be true. Future Directions
The verification of the PCI bus bridges we have described was done by specialists in formal verification. This work has been cost-effective and has made a positive impact on time-to-market. Since our use of formal verification is
at the unit level, the next logical step is to make this tool a part of the accepted methodology of verification by the hardware designers themselves. The future development of our tool will be in making the tool easier to use by accepting environments described in a language familiar to the hardware designer, in further simplifying the coding of rules in CTL by developing more expressive constructs, and in exploiting every available technique to allow us to verify bigger and bigger designs. Acknowledgments
We would like to thank Daniel Geist, whose work has been instrumental in continually increasing the size capacity of our tool. We would also like to thank the designers at the Haifa Design Group, who designed the hardware described in this paper, and whose cooperation has contributed to the development of our formal verification system. References
[Bee92]
I. Beer, “Formal Verification of Hardware“, M.Sc. Thesis, EE Department, Technion, 1992 (in Hebrew). [Bry86] R.E. Bryant, “Graph-Based Algorithms for Boolean Function Manipulation”, IEEE Trans. Computers, Vol. C-35, August 1986. [BYBG94]I. Beer, M. Yoeli, S. Ben-David, D. Geist, “Methodology and System for Practical Formal Verification of Reactive Hardware”, in proceedings of Sixth Conference on Computer-Aided Verification (CAV ‘94), Stanford, California, 1994. [CE81] E.M. Clarke and E.A. Emerson, “Design and Synthesis of Synchronization Skeletons using Branching Time Temporal Logic”, in: Proceedings of the Workshop on Logic of Programs, LNCS 131, 1981. [CES83] E.M. Clarke, E.A. Emerson and A.P. Sistla, “Automatic Verification of Finite-state Concurrent Systems using Temporal Logic Specifications: A Practical Approach”, Tenth ACM Symposium on Principles of Programming Languages, Austin, Texas, 1983. [Cli73] M. Clint, “Program Proving: Coroutines”, Acta Informatica, 2(1), 50-63, 1973. [Eme89] E.A. Emerson, “Temporal and Modal Logic”, in: Handbook of Theoretical Computer Science, J. van Leeuwen, ed., North-Holland,
1989. D. Geist and I. Beer, “Efficient Model Checking by Automated Ordering of Transition Relation Partitions”, in proceedings of Sixth Conference on Computer-Aided Verification (CAV ‘94), Stanford, California, 1994. [GL91] O. Grumberg and D.E. Long, “Model Checking and Modular Verification”, in: LNCS 527, 1991. [Kur87] R.P. Kurshan, “Reducibility in Analysis of Coordination”, in: LNCS 103, 1987. [LMA94] Y. Lichtenstein, Y. Malka and A. Aharon, “Model-Based Test Generation for Processor Design Verification”, Innovative Applications of Artificial Intelligence, AAAI Press, 1994. [Lon93] D.E. Long, “Model Checking, Abstraction and Compositional Verification”, Ph.D. Thesis, CMU, 1993. [McM93] K.L. McMillan, “Symbolic Model Checking”, Kluwer Academic Publishers, 1993. [MP91] A. Manna and A. Pnueli, “The Temporal Logic of Reactive and Concurrent Systems; Specification”, Springer-Verlag, 1991. [PCI93] “PCI Local Bus Specification, Revision 2.0”, PCI Special Interest Group, 1993. [Pnu86] A. Pnueli, “Applications of Temporal Logic to the Specification and Verification of Reactive Systems: A survey of current trends”, in: Current Trends in Concurrency, J.W. de Bakker et al., eds., LNCS 224, 1986. [SG90] G. Shurek and O. Grumberg, “The modular Framework of Computer-Aided Verification: Motivation, solutions and Evaluation Criteria”, CAV ‘90. [GB94]
