Conference PaperPDF Available

HOOVER: Hardware Object-Oriented Verification

Authors:

Abstract and Figures

In this paper a new formal hardware verification approach based on object oriented techniques is presented. The HOOVER system (Hardware Object Oriented VERification) is described. A cell library of different hardware components has been implemented as classes. Components in the cell library are described at the transistor level, gate level, logical level, and functional level. The verification of a CMOS inverter and 1-bit CMOS adder using HOOVER is given in the paper
Content may be subject to copyright.
HOOVER: Hardware Object-Oriented Verification
Mostafa M. Aref Khaled M. Elleithy
Information And Computer Science Dept. Computer Engineering Department
aref@dpc.kfupm.edu.sa
elleithy@dpc.kfupm.edu.sa
King Fahd University of Petroleum and Minerals
Dhahran 3 1261, Saudi Arabia
Abstract
In this paper a new formal hardware verification
approach based on
object oriented techniques is
presented. The HOOVER sysrem (Hardware Object
Orienfed VERification) is described. A cell library of
different hardware componenrs has been implemented as
classes. Components in the cell library are described at
the transistor level, gate level, and logical level, and
functional level. The verrficafion of a CMOS inverter and
I-bit CMOS adder using HOOVER is given in the paper.
1. Introduction
The design process is a transformation between different
specifications (Figure I). An input algorithm may be
specified using
a specific algorithmic specification
language. Architecture may be specified using a
realization specification language. The role of design can
be viewed as a transformation process between the
algorithm specification language and the realization
specification language. The objective of any design
procedure is to produce an architecture that correctly
implements the required behavior subject to a given set of
constraints on area and timing. It is very expensive to
fabricate a design before verifying the functional
correctness of the design. There are hvo approaches for
verification;
simulation
and formal veritication.
Simulation is efficient for small size architectures where it
is possible to exhaustively run the simulator. Formal
verification is suitable for large size architectures.
A verification methodology is formal if it satisfies the
following characteristics [l]:
.
There is a formal framework to describe the
architecture.
.
There is a formal technique to prove that
implementation and specifications are equivalent
without physically construct or simulate the design.
.
It is possible to manipulate and study the design’s
performance without the physical implementation.
‘critic
Specification I
ki
Implementation I
Specification I
on
Implementation N-
:sign
Final Product
Figure 1: A Hierarchical Representation of Design and
Verification
The heart of any formal verification methodology,
then, is the availability of a formal specification language
where formal proofs can be driven. Logic is one of the
most widely used specification languages for verification.
First order logic has been used in a number of systems [2-
41. Higher order logic has been used in a number of
applications [S-S]. Joyce [7-S] used HOL system to verify
a microprocessor. Temporal logic is an appropriate
approach for specifying timing characteristics of a design.
Temporal logic has been successfully used for verification
in [9-IO]. Productions systems have been used in formal
verification [I I].
Object Oriented Paradigm (OOP) have been proven
successful in software engineering due to its reusability
which increases design productivity. Object oriented
techniques provide a number of features, discussed in
section 2, which fit hardware verification. In [l2], Nebel
argued the suitability of object oriented techniques in
hardware system design. Several proposals where
introduced to
adopt OOP in hardware description
languages such as VHDL [l3-151. In [l6], Schumacher
discussed the problems in these approaches.
In this paper we are introducing a novel approach for
hardware verification based on OOP. The HOOVER
(Hardware Object Oriented VERitication) system is
introduced. In section two an overview to object oriented
techniques is given. In section 3 the HOOVER system is
discuused. Examples using the HOOVER for verification
are given in
section 4. Finally, section 5 offers
conclusions and future extensions.
2. Object Oriented Techniques
The characteristics of an object-oriented language are:
.
abstraction: is a higher level, more intuitive
representation for a complex concept;
.
encapsulation: is the process whereby the
implementation details of an object are masked by
a well-defined external interface;
.
inheritance: where classes may he described in
terms of other classes by use of inheritance;
.
polymorphism: is the ability of different objects
to respond to the same message in a specialized
manner; and
.
dynamic binding: is the ability to defer the
selection of which specific message-handlers will
be called for a message until run-time.
In HOOVER, a Cell Class Library is build based on
the description
of hardware components. These
components are organized in a hierarchy that allows
inheritance of common attributes hehwen different
components. The behavior description is the only
accessible
attribute of these components (i.e.
encapsulation). The hierarchy structure of the Cell Class
Library allows the component of common attributes to be
on the top level (i.e. abstraction). Dealing with these
components description would be only through messages.
The same message may he passed to two different
components that results two different responses (i.e.
polymorphism).
3. HOOVER System
HOOVER is a hardware object oriented verification
system. The circuit structural and behavioral descriptions
are HOOVER inputs. The circuit description would be
one or a combination of different hardware descriptions.
These descriptions include transistors, gates, logical,
functional, and module descriptions. HOOVER has a class
hierarchy contains Cell Class Library. The Cell Class
Library contains a predetined set of hardware
components. It consists of five subclass libraries represent
the five level of hardware descriptions. These subclass
libraries are Transistor-level Class Library (TCL), Gate-
level Class Library (CCL), Logic-level Class Library
(LCL), Function-level Class Library (FCL), Module-
level Class Library (MCL). The block diagram of
HOOVER is shown in Figure 2
TCL
inputs:
outputs:
diagram:
methods:
GCL
LCL
FCL
MCL
Figure 2: The Block Diagram of HOOVER
Each cell class contains several properties describe its
inputs, outputs and behavior. The behavior ofthe cells is
described through methods that may be inherited to (or
override by) the subcells. Some examples of these classes
are shown below.
Examples of Classes
Connection class
inputs: i outputs: 0
Transistor class
inputs: b, s
diagram: , s
outputs: d
IS
b
b
d d
methods: Tr&h,s,d)
send d depends on tbe logical level of the
base h and s
4. EXAMPLES
An n-type transistor is an instance of the transistor class.
The method is overridden by:
NTrans(b,s,d)
send d = s if logical level of the base b is 0
An p-type transistor is an instance of the transistor class.
The method is overridden by:
send d = s if logical level of the base b is I
OR class
inputs: il,i2, . . . i.
outputs: 0
I
diagram: i,
i2
3+
0
1.
methods: 0r(i,,i2, i.,o)
sendo=i,vi,v...v i.
AND class
inputs: i&, i.
output: 0
diagram: i,
i2
a
0
i.
methods: And(i&, i.,o)
send o = i, A iz A . . . A i.
The cell class library is a hierarchy structure. The top
class represents a simple hardware component; connection
class. In the same cell library, there exist different
transistor level components. As we move down the
hierarchy, more
specific hardware components are
described. These components may inherit some
characteristic from the upper ones.
Several circuit examples are used as input to
HOOVER.
These examples include transistor/gate circuit
(e.g. invert@, transistor/logic circuit (e.g. l-bit full adder)
and logic/function circuit (n-bit full adder). Here, two
examples are presented. The first one is a CMOS inverter.
The second one is a l-bit full adder.
Exam& I :
A CMOS inverter consists of power, ground, p-transistor
and n-transistor components as shown in Figure 3.
PI power
,J
input i
P2 Power
Figure 3: A CMOS lnverter
The circuit description of the inverter is described as a
set of instances from the exiting classes as follows.
Ntransistor,(bl,pl,o)
Ptransistor,(b2,p2,0)
Connection,(i,b,) Connection,(i,b,)
The behavioral description of the inverter is as follows
output = invert(input)
For i = 0, HOOVER sends 0 to Connection, and
Connection,. Their methods Comm(i,b,) and Comm(i,b*)
send b, and b2 equal 0 to Ntransistor, and Ptransistor,.
The method ofNhansistor,, NTrans(b,,p,,o), sends o = p,.
That means the output equals 1.
Similarly, for i = 1, HOOVER sends I to Connection,
and Connection2. Their methods Comm(i,b,) and
Comm(i,b2) send b, and bz equal 1 toNtransistor, and
PI
-I
I
P4
a
-I
P5
PI
1
Ptransistor,. The method of Ptransistor,, PTrans(b2,p2,0).
send o = pz. That means the output equals O.This show
that the circuit description verities the behavioral
description.
Exan& 2:
A l-bit CMOS full adder consists of oower. eround.
12 p-type transistors and 12 n-type transistdrs, as shown ii
Figure 4.
Is I
round
Figure 4: A l-bit CMOS Full Adder
The circuit description of the adder circuit is as follows.
Ptransistor,(cin,po,p~)
Ptransistor~(a,pz,p4)
Ptransistor6(a,p,,p,)
For a = 0. b = 0, ck = 0
The following classes receive inputs:
Ptransistor8(p4,po,sum)
Ptransistorlo(cj.,p,,p,)
Pamsistorlz(b.p,.pJ
Ntransistorz(b,p5,p6)
Ntransistor4(p,,ps,pI1)
Ntransistoq(ci..pI,pg)
Ntransistors(b,p,,p,,)
Ntransistor,,(a,p9,pI I)
N*msistor&,plo,pI I)
The behavioral description of the adder circuit is given in
a logical level as follows.
sum = aOb@c;?i
cou= (anb)u(anci~)u(bnci~)
Ntransistor2(b,p,,p,),
NtransistorS(ci,.pG,p, I),
Ntra”sistor6(ci,,pI,pg),
Ntransistor,(a,p4,ps),
Ntransistor,(b,p,,p,u),
Ntransistor,o(a.p,.p,,),
Ntransistor,,(b,pB,pII) and Ntransistor,,(a,plo,p,,)
They send the following:
Ps = PO, Pb = PII3 PI = Ps, Ph = Ps, Pi = PIi13
PS=PII. P~=PII.~“~PIO=PII
which means that p& = 0, p, = 0, pu = 0. Then the class
Ntransistor3(p,,c,,,,p,,) send c,,, = p,, which means c,“~
equals 0. The final HOOVER’s output indicates that the
behavioral description is equivalent to the circuit
description.
5. Conclusions
The verification of large-scale systems is no more a
straightforward process that can be completely achieved
using traditional approaches of simulation. In this paper
we aie describing a novel formal verification approach
based on object-oriented paradigm. A cell class library
that supports the HOOVER has been analyzed at different
specification levels. Examples of the transistor, gate,
logical, functional cell class libraries have been
implemented in HOOVER 1.0 using Java. To illustrate the
idea, a number of small size examples have been
presented in this paper.
Currently, we are working to complete the cell class
library in HOOVER to be able to test complex examples.
A module level class library will be implemented. The
new class library will support specifications at the module
level. Further work will be done for supporting timing
verification.
Acknowledgments
The authors wish to acknowledge King Fahd University of
Petroleum and Minerals for utilizing the various facilities
in preparation and presentation of this paper.
References
I. Elleithy, K. M. “Formal Hardware Verification of VLSI
Architecture Current Status and Future Directions,” Fifth
International Conference on Microelectronics, Dhahran, pp.
197-201,Dec. 1993.
2. Uehara. T.. et al.. “DDL Verifier and Temooral Loeic.”
,,
Proc. CHDL 83: IFIP 6th lnt’l Symp. Computer Hard&e
Description Languages and their Applications, Pittsburgh,
May 1983, pp. 91.
3. Eveking.
“Formal Veritication of Synchronous Systems,”
Formal Aspects of VLSI Design: Proc. 1985 Edinburgh
Conf. VLSI, G. J. Milne and P. A. Subrahmanyam,eds.,
North Holland Publishing, Amsterdam, 1986, pp. 137.151.
4. Hoot, W. A., “FM850l: A verified Microprocessor,” IFIP
WG 10.2 Workshop, From HDL Descriptions to Guaranteed
Correct Circuits Design, North Holland Publishing,
Amsterdam, Sept. 1986, pp. 85-l 14.
5. Hanna, F. K. and Daeche, “Specification and Verilicalion of
Digital Systems Using Higher order Logic,” IEE proc.. Vol.
133, Pt. E. No. 5, Sept. 1986, pp. 242-254.
6. Gordon, M. J. C.. “Why High-Order Logic is a Good
Formalism for Specifying and Verifying Hardware,” Formal
Aspects of VLSI Design: Proc. 1985 Edinburgh Conf.
VLSI. G. J. Milne and P. A. Subrahmanyam, eds., North
Holland Publishing, Amsterdam, 1986, pp. 153.177.
7. Joyce, 1.. Birtwistle, and Gordon, M. “Proving a Computer
Correct in Higher Order Logic,” Tech. Rept. No. 100,
Computer Laboratory, The Univ. of Cambridge. Cambridge,
England, 1986.
8. Joyce, J., “Formal Verification and Implementation of a
Microprocessor,” VLSI Specification, Verification, and
Synthesis, Birtwistle, G. and Subrahmanyam, P.A., eds.,
North Holland, Amsterdam, The Netherlands, 1988, pp.
371-378.
9. Bochmann, G. V., “Hardwarr Specification with Temporal
Logic: An Example,” IEEE ‘Trans. Computers. Mar. 1982.
pp. 223-23 I.
IO.Fujita, M., et al., “Logic Design Assistance with Temporal
Logic,” Proc. CHDL 85: IFIP 7th Int’l Symp. Computer
Hardware Description Languages and their Applications,
Aug. 1985, pp. 129-137.
I I.Elleithy, K. M. and Aref, M., “A Production Based System
for Formal Verification of Digital Signal Processing
Architectures.” Twenty-Seventh Annual Asilomar
Conference on Signals, Systems and Computers, Pacific
Grove, California. pp. 161X-1622, Nov. l-3, 1993.
12.Nebel, W. and Schumacher, G.. ‘*Ob.jcct-Oriented Hardware
Modeling Where to Apply and what arc the ob,jccts?,”
Proc. of the Euro-Dac 1996 with Euro-VHDL 96. IEEE
Computer Society Press 1996.
13.Glunr, W., et al.. “System Level Synthesis ‘I in Michcl, P.
and et al. (eds): ‘The Synthesis Approach to Digital System
Design, Kluwer, pp. 221-260, 1992.
14.Zippelius, R. et al.
“An Ob.jrct Oriented Extension to
VHDL,” Proceedings of the VHDL-Forum, Spring’92
Meeting, 1992.
I5,Willis, J., et al.“A Proposal for Minimally Extending VHDL
to Achieve Data Encapsulation and Multiple Inheritance.
Proceedings of the VHDL International User’s Forum, 1994.
16.%humacher, G. and Nebel, W.. “Inheritance Concept For
Signals in Object-Oriented Extensions to VHDL,” Proc. of
the Euro-Dac 1995 with Euro-VHDL 95, IEEE Computer
Society Press 1995.
ResearchGate has not been able to resolve any citations for this publication.
Conference Paper
Full-text available
Several proposals were made in the last few years to extend the hardware description language VHDL and to add mechanisms like inheritance from the object oriented domain to the language. This paper illuminates the principle problems arising when an inheritance concept for data types is added to VHDL. Solutions to these problems are proposed with an example of an inheritance mechanism for signals within an object-oriented extension to VHDL
Book
VLSI Specification, Verification and Synthesis Proceedings of a workshop held in Calgary from 12-16 January 1987. The collection of papers in this book represents some of the discussions and presentations at a workshop on hardware verification held in Calgary, January 12-16 1987. The thrust of the workshop was to give the floor to a few leading researchers involved in the use of formal approaches to VLSI design, and provide them ample time to develop not only their latest ideas but also the evolution of these ideas. In contrast to simulation, where the objective is to assist in detecting errors in system behavior in the case of some selected inputs, the intent of hardware verification is to formally prove that a chip design meets a specification of its intended behavior (for all acceptable inputs). There are several important applications where formal verification of designs may be argued to be cost-effective. Examples include hardware components used in "safety critical" applications such as flight control, industrial plants, and medical life-support systems (such as pacemakers). The problems are of such magnitude in certain defense applications that the UK Ministry of Defense feels it cannot rely on commercial chips and has embarked on a program of producing formally verified chips to its own specification. Hospital, civil aviation, and transport boards in the UK will also use these chips. A second application domain for verification is afforded by industry where specific chips may be used in high volume or be remotely placed.
Article
Mike Gordon has described the specification and verification of a microcoded computer using the LCF_LSM hardware verification system [8]. We have subsequently redone this example in higher-order logic using the HOL system [10]. In this paper we present the specification of Gordon’s computer in higherorder logic and a brief explanation of its formal verification. A more detailed discussion of the formal verification may be found in [16]. We also describe several related examples of hardware verification based on Gordon’s computer and other microprocessor designs. Finally, we report experience in using a formal specification to implement Gordon’s computer as a 5,000 transistor CMOS microchip.
Article
The paper describes how higher-order predicate logic may be used to specify both the structure and the behaviour of a digital system, and to reason about their interrelationship. The overall approach is named VERITAS; the paper concentrates particularly on describing its methodological aspects. The behaviour of a system is specified by a predicate on the analogue waveforms at the ports of the system. In general, behavioural specifications are partial. The internal structure of a system is defined by a set of projection functions that yield its component parts, together with a set of equations describing their interconnections. Reasoning about the behavioural properties of digital systems is carried out within the framework of an axiomatic theory that describes relevant properties of arithmetic, time, waveforms and structures. The logic is embedded within a programming language, MV, whose data types include signature, term and derivation. This allows inferencing to be carried out computationally, which in turn guarantees its correctness.