As hardware designs grow in size and complexity, current
design methods are proving less adequate. Current
methods for specification, design, and test are typically
empirical or informal, that is, they are based on experience
and argument. Formal methods are solidly based
on mathematical logic systems and precise rules of inference.
Formal methods offer a discipline which complements
current methods so designers can successfully meet
the demand for high performance systems.

Formal methods covers a broad and diverse set of techniques
aimed at improving computer correctness. This
paper explains the role of specifications and implementation
models in formal methods, and different approaches
to proving their correspondence. We refer to excellent
overview papers and cite some recent successful examples
of using formal methods in hardware design.

Introduction

Current hardware and software designs are orders of
magnitude larger and more complex than they have been.
It is therefore more difficult to design correct systems using
only informal techniques and practices. The term formal
methods includes a set of techniques based on mathematical
foundations and analysis. Formal methods [10]
improve computer design by reducing design errors when
used as a complement to empirical techniques currently
used. This paper provides a brief introduction to formal
methods for hardware design.1 We discuss what they are,
describe different methodologies grouped under the heading
formal methods, and suggest where they can be used
successfully. Due to space considerations, the bibliography
is not extensive, but it was carefully chosen to provide
a good starting place for further exploration.

?This work was sponsored by the National Science Foundation
under NSF grant MIP{9412581 and the Department of Defense under
contract MDA904-94-C-6115.
1This paper focuses exclusively on formal methods in hardware
design. Formal methods can also be used in broader system design,
including software, but such discussion is beyond the scope of this
paper.

What are Formal Methods?

Formal methods are an analytical approach relying on
mathematical models for excluding design errors in hardware.
Other approaches to design fault exclusion, such
as simulation, are empirical in nature. The chief benefit
of analytical techniques is that they offer 100% coverage
of the design space. That is, with a precise mathematical
model, one can reason about all possible cases. The
chief drawback is the difficulty of building models and
conducting analysis. The precise nature of formal methods
precludes informal hand waving to dismiss difficult,
extreme cases.
All formal methods involve one or more of the following
three parts:

1. a mathematical model of the design's intended behavior
or properties, called the specification,

2. a mathematical model of the design's structure,
called the implementation model, or more briefly, the
implementation, and

3. mathematical expressions stating relationships between
the models established using analysis (proof)
to demonstrate that the relations hold.

Formal methods begin with a specification, an implementation
model, and a mathematical expression stating the
relationship between them. They finish by demonstrating
the relationship via precisely defined rules. However, formal
methods need not include all three aspects. Benefits
accrue from simply writing a formal specification which
then serves as an unambiguous reference for implementation,
simulation, and testing.

A. Simple Example of Formal Methods

As an example of the activities and models discussed
above, we might specify the behavior of an exclusive{or
gate with the following mathematical formula:

`def xor2_spec a b out = (out = :(a = b))

That is, the behavior of an exclusive{or relates inputs, a
and b, and the output, out. Note that the above formula
can easily be assigned a rigorously defined meaning. The
implementation model could be described using a netlist:

This implementation is four interconnected NAND gates. In
addition, we must have rigorous definitions of the meaning
of MODULE, .nand2, BEGIN, etc., so that the above implementation
model also has an unambiguous meaning.

We wish to show that the implementation satisfies the
specification. We can express this with the mathematical
relation implies and express rigorous definitions of the
netlist (not given here for brevity) as a function INTERP
in the following manner :

` 8 a b out. INTERP(out .xor2_imp a b) )
xor2_spec a b out

One can also read the formula as, for all a, b and out,
the interpretation of an XOR2 implementation (as defined
above) on a, b and out implies the XOR2 specification
(also defined above) on a, b and out. Using mathematical
analysis and the definitions of .xor2 imp, xor2 spec,
and INTERP, we can prove that the implementation satisfies
the specification.

Notice that the relationship covers all values of the inputs
and output (a, b, and out), not just some test values.
Of course, in this simple example an exhaustive simulation
is trivial, but many formal methods can be applied
to circuits with 10100 states or more and still show that
the relationship holds for all possibilities.

How Do I Put Formal Methods to Work?

Various formalisms and techniques are applicable to
each part of the process described in the previous section.
To write a formal specification, one must make choices
about which formalism to use (first order logic, higher order
logic, temporal logic, state machines, automata, trace
specifications, etc.) and the kinds of criteria to specify
(functional correctness, liveness, safety, timing, and so
on). To model a circuit, one must decide which level of
abstraction (gate level, switch level, circuit level, registertransfer
level, or higher) is appropriate as well as which
formalism to use (first order logic, higher order logic, automata,
etc.). The relationship of implementation and
specification may be equivalence, implication, etc. How
one handles each of the three parts forms a taxonomy of
formal methods tools and techniques [3].

A. The Specification

Writing a specification for a design is perhaps the most
difficult aspect of the formal methods process. Formal
specifications require the designer to clearly, concisely,
and unambiguously state what a circuit must do. To
be of any benefit, the specification must be an abstract
representation of the implementation. That is, it should
state what a circuit must do, not how. The abstractions
may be any combination of structural (an ALU instead
of gates), data (numbers instead of bit vectors), temporal
(instruction cycles instead of clock cycles), or behavioral
(a page from memory is saved to disk instead of which
page is saved to which cylinder). Specifications may be
quite comprehensive, or they may include relatively few
fundamental requirements such as a request is eventually
granted or two communicating devices never deadlock.
Specifications can also indicate timing properties, load
characteristics, and other properties of the device.

The idea of formal methods is to show that the implementation
meets the specification; but how does one
ensure that the specification is correct? Ultimately it
must be validated by the designers: they must examine
the specification and decide that it expresses what they
want. Higher level abstractions help by making it easier
to state desired properties and behaviors. More powerful
representations can more easily and concisely express the
designer's desires. A specification of a few fundamental
properties may be easy to judge correct, but leaves other
important properties only informally specified. Some representations
are executable, allowing designers to validate
the specification by simulation in addition to review.

One of the most important choices to make is the level
of abstraction in the specification. Higher level abstractions
tend to allow more concise specifications, since less
detail is included. Abstraction causes the specification
to be more easily modified and validated. On the other
hand, an abstract specification is more difficult to relate
to the implementation. Multi-level verification treats the
one level's specification as the next higher level's implementation.
Thus several simple abstractions can be independently
verified to yield the overall proof.

Related to the level of abstraction is the expressiveness
of the language. A simple language, such as state
machines or first order logic, is easy to reason about |
in fact, many simple languages are decidable: they have
completely automatic algorithms for calculating the correctness
of statements. More expressive languages, such
as higher-order logic, can more concisely express a wide
range of specifications, but they are more difficult to reason
about.

More abstract and expressive languages are more powerful
in the long run, but tend to require more initial investment
since they are more mathematical and less like
representations with which designers are familiar.

B. The Implementation Model

Creating a model of the implementation is a standard
task for hardware designers. Implementation models are
similar to simulation models in use by designers now. An
implementation model may be extracted from the simulation
model, or, potentially, the same model may be used
for both verification and simulation. The implementation
model must have a well defined interpretation or meaning.
A model with simple primitives is easier to reason
about, but is a poor representation of the circuit. A more
detailed model is a better representation of the circuit,
but it is more difficult to use in a verification.

How does one ensure that the implementation model
actually represents the physical device? As with the specification,
validating the implementation can not be done
by machine. Since the model only represents certain characteristics
of the device, the final design must be checked
to ensure that it has those characteristics.

Few formal methods tools accept models written for
standard simulation tools without significant syntactic
changes to the model. Most tools require a completely
new model expressed in a different modeling framework.
Thus, a designer often must construct multiple models of
their circuit, one for each design tool (simulator, formal
methods tool, etc.). Multiple versions raise the cost of
design maintenance and can lead to version skew problems.
Current research in formal methods is aimed at
using standard HDLs for implementation modeling and
providing increased simulation capability.

C. Relating the Implementation and the Specification

There are several methods currently being used for relating
implementations to specifications. These include
theorem proving, model checking, equivalence checking,
and language containment. Among these, the most commonly
used are model checking and theorem proving.

In the model-checking approach, the specification is expressed
as a formula in temporal logic. Such logics make
statements about a world that changes through time, and
they allow reasoning about dynamically changing situations.
Implementation models are usually in the form of
state transition graphs. They can be compared with the
specification automatically. The system may verify that
the models are valid, or it may provide counter-examples
for any specifications falsified by the implementation.

Since model checking typically uses state-based hardware
descriptions, it is better suited for checking control
structures, as it expresses things such as concurrency and
synchronization. Also, by modeling a particular kind of
logic and world, model checkers aren't excessively complex.
Of course, this means that they are not readily
used on other types of problems.

As an example, the well known model checker SMV [6]
uses specifications written in the temporal logic CTL and

implementation models written in a VHDL-like language
for creating state machines.

Theorem proving, in contrast, is a more interactive
technique. When one uses a theorem prover to verify
hardware the usual process is to design a specification and
implementation as logic descriptions first-order predicate
logic, higher-order logic, etc. The designer then guides the
proof assistant tool through rigorous proof steps showing
that the implementation model satisfies the logical specification.
The level of interaction required of the user varies
widely between theorem prover tools: some tools demand
much detail but offer great flexibility (e.g., HOL); other
tools are more automatic at the expense of flexibility (e.g.,
PVS, NQTHM).

Theorem provers ultimately rely on the designer to create
an appropriate model of the hardware, and even to
guide the system (sometimes explicitly) along the path
to a proof. This can be a complex process, but theorem
provers are very general and can be employed in a wide
range of applications. Theorem provers are not as useful
for reasoning about temporal aspects of hardware. But
theorem provers are well suited for hierarchical methods
of development (due to their abstraction mechanisms) as
well as reasoning about functional specifications and parameterized
descriptions.

Formal methods will ensure that an implementation
meets a specification, but they will not guarantee that
the final product will always operate perfectly. What formal
methods can do is limited by the philosophical limits
on what can be proven, informally defined description languages
and extra-logical factors. These limitations ought
to be kept in mind when describing and discussing the
results of a formal verification project. A more complete
discussion of what formal methods will and will not do
can be found in [2].

There are aspects of the design process to which the notions
of specification and implementation simply do not
apply. Specifications can not convey design intentions and
implementation models can not describe physical properties.
Consequently, the verifier is forced to choose a level
of abstraction for the specification and a sufficiently concrete
level for the implementation model. These decisions
are part of the process, but should be explicitly stated
when making a claim about verification. For example,
claiming that a microprocessor has been verified at the
gate-level implementation to meet a functional block specification
more completely conveys the scope of the veri-

fication than simply stating that the processor has been
verified.

In practice, the designer, verifier and each manufacturer
use different, informally defined languages to describe the
design. Often, the translations between these languages
requires a combination of experience, intuition and luck.
This is especially true of low-level design descriptions
which may consist of nothing more than annotated diagrams
and a few paragraphs of text. Without mathematically
precise definitions of the design-description language,
it is impossible to know if the verifier's interpretation
of the design is the same as the designer and if the
design manufactured is the same as the one described by
the verifier. These gaps can be bridged by using a common,
formally defined language at all three levels. Work
on these types of languages is underway at Computational
Logic, Inc. and Brigham Young University [11].

Claims about verified devices, especially in safety or security
critical applications, should be strictly limited to
factors covered by the logic. Faulty communication, social
hierarchies, political climates, and so forth are usually
not covered in the verification process. For example, verification
demonstrating that the low-level model of a chip
prevents unauthorized users from accessing data does not
guarantee that a passer-by could not read sensitive data
on a monitor. Consideration of these factors ought to
temper broad guarantees about verified devices.

Formal methods have been successfully used in commercial
and academic designs. We mention a few to suggest
the wide applicability and utility of formal methods.
Johnson, Miner, and Camilleri[5] compare several formal
tools by implementing a simple circuit in each of
them. They contrast how the underlying formalisms influence
one's perspective on design and verification."

Windley and Coe[8] verified the correctness of a simple
pipelined microprocessor using HOL, and Srivas and
Miller[7] report the formal verification of a commercial
microprocessor. Bainbridge, Camilleri, and Fleming[1] relate
verifying memory protocols in an industrial setting.
They point out formal methods can be used even with a
short time to market.

Conclusion

Formal methods are a useful addition to the hardware
design process. To make use of formal methods, first a
specification must be written which expresses the design
criteria, then an implementation model must be written
or captured which represents the design. Formal verification
demonstrates that an implementation model meets
a specification for all cases. However formal methods are
not a silver bullet which prevents all errors. Rather formal
methods are a complement to good design methodology
and testing. The chief benefit of formal methods is not
the final true from the tool, but rather the process that is
required to get the final result.

While the wide variety of specification and implementation
modeling techniques and the many ways of relating
them can make the choice of how and when to apply formal
methods sound daunting, in fact there are relatively
few tools to choose from. Of these tools, the best criteria
for choosing is how they handle the task of relating the
implementation model and the specification. Once a particular
tool is chosen, many of the options for creating the
implementation model and specification are eliminated.