Content uploaded by Khaled Elleithy
Author content
All content in this area was uploaded by Khaled Elleithy
Content may be subject to copyright.
Content uploaded by Khaled Elleithy
Author content
All content in this area was uploaded by Khaled Elleithy
Content may be subject to copyright.
Formal Verification
of
DSP
VLSI
Architectures: A Tutorial
Khaled
M.
Elleithy
&
Muhammad A. Hummaigani
Computer Engineering Department
King Fahd University of Petroleum and Minerals
Dhahran
3
1262,
Saudi Arabia
AbstractIn this tutorial paper the area of formal verification
of
DSP
VLSI architectures is presented. The paper discuses the
following topics: production systems, formal logic, the
equational approach, and the signal
flow
graph approach. Each
approache is explained using one or more of the current
available systems.
I.
INTRODUCTION
The production of DSP Very Large Scale Integration
chips is very expensive and time consuming. It is very
important to design correct DSP VLSI architectures before
any production phase. Simulation is
a
popular method that is
used to prove the correctness of systems for specific sets of
inputs and outputs. With the current advances in VLSI
circuits, there is no testing procedure that is capable of
accomplishing an exhaustive simulation of complex circuits.
Formal verification is another approach to prove correctness
of a DSP VLSI architecture without going through exhaustive
testing.
The design process is a transformation between
specifications at different levels of abstractions. An
algorithm may be specified using a specific algorithmic
specification language. A DSP VLSI architecture may be
specified using a realization specification language. The role
of formal verification is to prove using a mathematical
framework that the realization is equivalent to the
specification. The components of any formal verification
framework are: a formal algorithmic specification language,
a
formal realization specification language, and
a
mathematical
framework
.
A
verification methodology is formal if it is[l]:
0
There is a formal framework to describe the architecture.
0
There is a formal technique to prove the equivalency of
the implementation and the specification without
physically construct or simulate the design.
0
It is possible to manipulate and study the design's
performance without the physical implementation.
formal verification ofDSP
VLSI architectures is presented. In section
2,
production
systems are discussed. In section
3,
two examples of higher
order logic are presented. In section 4, the equational
approach
is
discussed.
In
section
5,
signal
flow
graph
approach
is
presented. In section
6,
a
discussion on the
current and future directions is presented.
In this paper an overview
2.
PRODUCTION
SYSTEMS
Production systems are efficient in proving the
correctness in large scale architectures where the proof of
correctness is done automatically. A novel approach for
formal verification based on a production system has been
presented in
[231.
The PROVER (PROduction system for
hardware VERification) is implemented using CLIPS (C
Language Integrated Production System)[4]. CLIPS is written
in C to support the goal of high portability, extendibility,
lowcost and ease of integration with external systems
[5].
CLIPS,
as
a production system
[6],
provides patterndirected
control of a problemsolving process.
PROVER'S input has
two
components for the verifiable
circuit: implementation description and behavioral
description. The implementation description would be one or
a combination of different hardware descriptions. These
descriptions include transistors, gates, logical, functional, and
module descriptions.
As
shown in Figure
1,
PROVER has a
knowledge base consists of a formal Cell Library and Rules.
Cell library contains a predefined set of hardware
components. It consists of five sub libraries to represent the
five levels of hardware descriptions. These sub libraries are
Transistorlevel Library
(TL),
Gatelevel Library
(GL),
Logiclevel Library
(LL),
Functionlevel Library
(FL),
and
Modulelevel Library
(ML).
The incremental approach is
used in developing PROVER. In this approach, a subset of
the domain is considered first and a prototype is built. Then
this prototype
is
expanded to other subsets
of
the domain.
Knowledge
Base
Figure
1.
PROVER'S
Block
Diagram
0780324285195
$4.00
0
1995
IEEE
35
1
Authorized licensed use limited to: University of Bridgeport. Downloaded on February 24,2010 at 13:24:04 EST from IEEE Xplore. Restrictions apply.
A formal verification methodology based on
transformation rules between different levels is used.
Verification rules are required to prove that a given
specification at level
X
is equivalent to specification at level
X+1.
The following verification rules are implemented:
Tto6
rules:
transform from transistor level to gate level,
0
GtoL
rules:
transform from gate level to logical level,
0
LtoF
rules:
transform from logical level to functional
e
FtoM
rules:
transform from functional level to module
level, and
level.
The rules define possible transformation from one level to
another. Also, they reflect the semantic
of
each level
description.
Any
DSP
VLSI system can be verified using preverified
constructs from the cell library. Verified components at any
level are added to the cell library in the appropriate level. For
ease of expandability, verified components are made modular
so
that they can be used for verifying modules of different
word length, e.g., a definition of a Conditional Sum adder
can be used for verification in cases of
16,
32, and
64
bits.
3.
FORMAL
LOGIC
Logicians have proposed different formalisms to represent
the branch of knowledge concerned with truth and inference.
The most important ones in the area of formal verification
are: first order logic, higher order logic, and temporal logic.
the following connectives are used:
negation
(
),
conjunction
(
n),
disjunction
(U),
and
then
(
3).
The existential
(3)
and universal
(v)
quantifiers are used.
In the higher order logic the domains of variables range
over functions and predicates, and functions can take
functions as their arguments.
Temporal logic is used to specify properties
of
all possible
execution times that may evolve from the present state. The
following operators are defined:
In first order logic
Henceforth(0): means that an assertion is true in the
present state and a11 future states.
Eventually(
V
):
means that an assertion will be true at
some state in the future (possibly the current) state, but
not necessarily remains true.
Next(0
):
means that an assertion will be true
in
the next
instant of time. This operator introduces the concept
of
discrete time and
a
transition that occurs between
subsequent time instants.
While(E
):
a statement like AE
B
means that if B is true
at the present, then A is true at the present and remains
true
as
long
as
B
remains true.
A.
Cathedral4 Environment
Verkest, Claesen, and Man developed a methodology for
the correctness proof of parametrized module generators
using BoyerMoore logic[
10,111.
The methodology is
illustrated with the proof of a specific module generator for
the ALU module, based on the MeadConway ALU[
121
of
the
CATHEDRALI1
environment
[7,8,9],
While modules' layouts are generated starting from the
textual description in the module generator file, the
description used for the formal verification of the module is
written in BoyerMoore logic. Therefore, these two
descriptions have
to
be equivalent. An automatic translation
of the Module GEnerator (MGE) text to BoyerMoore text is
not feasible because
of:
1.
In
case of the
ALU,
the module generator describes the
structure directly in terms of the leaf cells (general
function blocks, even carry blocks,
...).
This does not
allow performing a proof using BoyerMoore without
frst proving the behavior of the various functional bars
(propagate,
kill,
carry and result bar). These bars form a
necessary intermediate level of hierarchy for the proof
which can not be found in the module generator code.
2. Even when an intermediate level of hierarchy is not needed
in the proof (in simple module generators such as an
adder), automatic translation would result in an
unstructured description in BoyerMoore. This does not
enable the construction of proofs in a reasonable
efficient way.
As a result, the structure part of the module generators is
translated manually into BoyerMoore code. The manually
translated BoyerMoore code has to be equivalent to the
original code. Figure 2 shows the approach used for the
verification steps.
Moore
pecification
Moore
structural
escription
Comparison
Layout netlist
extraction
netlist
Figure
2.
Verification
steps
in
CATHEDRAL
I1
352
Authorized licensed use limited to: University of Bridgeport. Downloaded on February 24,2010 at 13:24:04 EST from IEEE Xplore. Restrictions apply.
As shown in Figure 2,
two
proofs must be carried
out:
1.
By means of the BoyerMoore theorem prover, the
parametrized structural description in BoyerMoore
corresponds to the parametrized specification of the
module in BoyerMoore.
2. The proof that the structural part of module generator, in
the MGE text which describes the module
in
a
parametrized way, corresponds to the parametrized
BoyerMoore structural description.
While the first proof is done only once for each module,
the second proof
is
done for every generated instance of each
module. Every time a specific module instance is generated
for the use in CATHEDRAL
I1
environment, we obtain a
layout from the MGE environment. From this layout, a
transistor net list is extracted. Then, an expert system called
DIALOG [13], which can recognize leaf cells, is used to get a
net list of leaf cells from the transistor net list. On the other
hand, the BoyerMoore module text is expanded after
instansiating the parameters with particular values. This
expansion results in a net list of leaf cells.
This net list of leaf cells is then compared with the net list
of leaf cells obtained from the layout. The comparison is
done using a net list comparison program such as WOMBAT
[14].
If discrepancies occur, they must have resulted from
errors in the translation of the MGE description to the Boyer
Moore description.
B.
PIRAMID
Silicon
Compiler
Many DSP devices can be specified concisely by
describing their functional behavior. There is, however, a
large gap between specification and silicon implementation.
In
the prototype silicon compiler for Digital Signal
Processing PIRAMID[ 171, the SILAGE[9] behavior
description is mapped onto an architecture of Execution
Units (EXU's), busses connecting the EXU's, and a controller
for regulating the bustraffic and making EXU's work
together.
Kalker introduced an approach to improve the
specification language SILAGE using (HOL) system in order
to obtain correct designs in PIRAMID.
The time instances in the SILAGE level consists of cycles
in the implementation level. The number
of
cycles needed to
implement one SILAGE timestep depends critically on the
number of busses and EXU's chosen for the realization.
So,
the speed requirements can not be solved solely on the
SILAGE level. The cleverness
of
the PIRAMID scheduler,
the building blocks of the layout generating backend, and
the technology used also have their large influence in this
respect.
The syntactic form of a SILAGE program determines,
to
a
large extent, the architecture realized on silicon. Also,
meeting
the speed and
/
or area restrictions and requirements
sometimes can not be solved by the PIRAMID system only.
Therefore, transformations on the SILAGE program are
needed, provided that these transformations have to be
behavior preserving. This can be achieved by utilizing HOL
system for the purpose of producing a better (with respect to
specification/verification)
version of SILAGE, called
SILAGE+.
4.
EQUATIONAL
APPROACH
Narendran and Stillman described a method that
implements an equational approach for theorem proving of
firstorder predicate calculus [18] to verify an image
processing chip, called the Sobel chip.
The equational approach involves taking a set of first
order formulae, performing necessary operations to remove
existential quantifiers, then translating the resulting formulae
into equivalent set of polynomials over a Boolean ring whose
operators are "exclusive or" and "and", in which the atoms
appearing in the original formulae make up the intermediates
of the polynomial equations. The original set of formulae is
satisfiable if and only if the resulting system of polynomials
has a solution.
specified in a firstorder predicate calculus with equality. The
approach is refutational in nature. The statements describing
the structure are assumed to hold and the statements
describing the behavior are assumed not to hold and an
attempt is made to reach a contradiction.
The behavioral description of the chip is obtained from
the highlevel statements in the chip document [19]. The
structural description of the chip supplied in the form of a
VHDL code. The firstorder statements used in the theorem
prover are then extracted from the VHDL code.
Both the structural and behavioral definitions are
5.
SIGNAL
FLOW
GRAPH
APPROACH
Genoe, Claesen, Verlind, Proesmans, and Man developed
a methodology for the correctness proof of CATHEDRALI1
[7] circuits that is based on Signal Flow Graph (SFG)
Tracing[20]
SFGTracing is a general multilevel design verification
methodology that aims at bridging the gap between higher
level specifications down
to
lower level implementations. It
uses the concept of Ordered Binary Decision Diagrams
(OBDD's)[2
11.
Any design, starting from a behavioral description,
passes through several levels of abstraction with growing
amount of information [20], before obtaining a final layout.
As shown in Figure
3,
these levels are the Signal Flow Graph
(SFG)
level, the behavioral Register Transfer (bRT) level, the
structural Register Transfer (sRT) level, and the transistor
switch (SWITCH) level.
353
Authorized licensed use limited to: University of Bridgeport. Downloaded on February 24,2010 at 13:24:04 EST from IEEE Xplore. Restrictions apply.
Behavioral
Speciticatior
.
Signal
Flow
behavioral
structural Transistor
Graph Level Register
Register Switch Level
Transfer
Transfer (SWITCH)
WG)
(bRT) (sRT)
Figure
3.
SFG
Verification
Approach
Levels
The goal is to prove the correctness of an implementation
(a transistor switch net list extracted from final layout) at the
SWITCH level and a specification (behavioral SILAGE
language
[9]
description) at SFG level. Intermediate levels,
however, are used to get additional information. Furthermore,
in case of bugs or errors, correctness between other levels has
to
be checked.
The final verification between different abstraction levels
is done by symbolic evaluation and Boolean comparison.
Two Boolean expressions are identical if their OBDD
representations are identical for the same variable ordering.
Figure
4
shows the integration of the SFGTracing
verification methodology in the CATHEDRAL I1 CAD
environment.
Starting from a SILAGE description, the basic SFG is
derived. This basic SFG is then partitioned into several
pSFG's. This partitioning is caused by the fact that real
designs are, in general, too complex to verify. This means
that the specification (the basic SFG) has to be split up into
several partitions. The input and output signals of each
partition are called reference signals.
In order
to
verify the behavior of a single partition,
mapping functions are generated during the high level
synthesis to express the correspondence of the reference
signals in space and time on the implementation. The optimal
partitioning depends on the abstraction level.
The interface signals between all these pSFG's (the
reference signals) and the corresponding mapping functions
are generated by the high level synthesis tools.
In addition, a script has to be generated for the successive
verification of each partition. The script generator collects the
pSFG's, reference signals, and mapping functions and
prepares the evaluation and verification process
in
a
systematic way.
A transistor net list
of
the circuit is extracted from the
fial layout using CAD tools. This transistor net list can then
be modeled by switchlevel analysis.
High Level
Tnthesis
J,w
Register Transfer
m
7
ppin
7
fun
. ~
tions
.
p
I
description
II
1
Systematic Script Generator
Silicon
Implementation
I
CATHEDRAL

II
SFG

Tracing
Synthesis System Verification Environment
I
JI
Figure
4.
SFG
Verification
Integrated
with
CATHEDRALI1
In case of inconsistencies during the verification of
specific pSFG's on the analyzed circuit, a bug report is
generated during the symbolic evaluation and Boolean
comparison process, by which it is possible to indicate
precisely where the eventual errors took place.
6.
DISCUSSION
Currently, the area of formal hardware verification is of
intensive research and development. Although major
activities are still in academia, a number of industries are
entering this domain.
It
is interesting to note that some
industries have incorporated formal verification tools into
their Computer Aided Design(CAD) systems.
The Royal Signals and Radar Establishment
(RSRE)
of
the British Ministry
of
Defense applied formal verification
techniques to design a microprocessor suitable for realtime
control of safetycritical systems. The Viper microprocessor
has been specified, designed and verified by RSREusing
automated theorem provers[
151.
The formal methods
developed by RSRE have been endorsed by the industrial
manufacturers of the VIPER.
Regularly held conferences devote part of their programs
to
the
active
research in
this area. We
mention
here:
Symposium on Computer Hardware Description Languages
(CHDL), Intemational Conference
on
Computer Design
(ICCD), Intemational Conference on Computer Aided Design
(ICCAD), Design Automation Conference (DAC), and
European Design Automation Conference (EDAC). In
addition, the
major
part
of
a number of international
workshops
is
devoted to formal hardware verification
research.
354
Authorized licensed use limited to: University of Bridgeport. Downloaded on February 24,2010 at 13:24:04 EST from IEEE Xplore. Restrictions apply.
Although research in the area
of
formal hardware
verification
is
very promising, academia and industry still
have a long way to go before formal methods
of
hardware
specification and verification become common and widely
used[
181.
ACKNOWLEDGMENTS
The authors wish to acknowledge
King
Fahd University
of
171 Meerbergen, J. and Man, H., "A Real Silicon Compiler for the Design
of
Complex Integrated Circuits for Digital Signal Processing,"
Philips
Technical Journal
44,
no. 7, February 1989.
181 Kapur,
D.
and
Narendran,
P.,
"An Equational Approach to Theorem
Proving in FirstOrder Predicate Calculus,"
In Proceedings ofthe
9th
Ind Joint Conference on Artijkial Intelligence,
Los Angeles,
California, 1985.
191 Vasanthavada, N., Baker, R., and Kanopoulos,
N.,
"A
Monolithic
Image Edge Detection Filter,"
In
Proceedings
of
the
IEEE
Custom
Integrated Circuits Conference,
1987.
Petroleum and Minerals for utilizing the various facilities in
preparation and presentation of this paper.
[201 Claesen, L.,
Genae,
M.,
Proesmans, F., Verlind,
E.,
and Man, H.,
"SFGTracing: a Methodology for the Automatic Verification of
MOS
Transistor Level Imolementations from Hieh Level Behavioral
REFERENCES
Elleithy, K.
M.,
"Formal Hardware Verification: of VLSI
Architectures: Current Status and Future directions,"
5th International
Conference
on
Microelectronics,
Dhahran, Saudi Arabia, 1993, pp.
Arec M.
A.
and Elleithy,
K.
M., "PROVER: A Production System for
Formal Hardware Verification,"
F$th International
Con!
on
Microelectronics,
Dhahran, Dec. 1993,
pp.
210213.
Elleithy, K. M. and Mostafa Aref,
M.
A.,
"A Production Based
System for Formal Verification of Digital Signal Processing
Architectures,"
TwentySeventh Asilomar
ConJ:
on Signals, Systems
&
Computers,
Pacific Grove, California, Nov. 13, 1993.
CLIPS Reference Manual,
Version 6, Software Technology Branch,
Lyndon B. Johnson Space Center, June 1993.
Mettrey, "A Comparative Evaluation of Expert System Tools,"
IEEE
Computer,
Vol.
24,
No.
2,
Feb. 1991, pp. 1931.
George F. Luger, William
A.
Stubblefield,
Artificial Intelligence and
the design
of
Expert System,
The BenjaminKummings publishing
Company, 1989.
Man,
H.,
Rabaey, J., Six, P., and Claesen, L., "Cathedral11: A Silicon
Compiler for Digital Signal Processing,"
IEEE Design and Test of
Computers,
December 1986, vol. 3, no. 6, pp. 7385.
Man, H., "Evolution of CAD tools Towards Third Generation Custom
197201.
VLSI Design,"
Revue Phys.
Appl., vol. 22, January 1988, pp. 3145.
Hilfinger, P., "SILAGE: a High Level Language and Silicon Compiler
for Digital Signal Processing,"
Proceedings IEEE
1985
Custom
Integrated Circuits Conference,
Portland, May 1985, pp. 213216.
[lo] Boyer, R. and Moore, J.,
A
Computational Logic.
Academic Press,
1979.
[ll] Hunt, W. and Brock, B., "FM8501:
A
verified Microprocessor,"
Technical Report
47,
Inst. for Comp. Science, Univ.
of
Texas, Austin,
Feb. 1986.
[12] Mead,
C.
and Conway, L.
Introduction
to
VLSISystems.
Addison
Wesley, 1980, pp. 150154.
[13] Man,
H.,
Bolsens,
I.,
Meersch,
E.,
and Cleynenbreughel,
J.,
"DIALOG: An Expert Debugging System for
MO§
VLSI Designs,"
IEEE Transactions
on
Computer Aided Design,
CAD4, no. 3, June
[14] Spickelmier, R. and Newton,
A.,
"WOMBAT:
A
New Netlist
Comparison Program,"
Digest
of
Technical Papers
ICCAD83,
pp.
1701 7
1.
[15] Cohn,
A.,
"A Proof of Correctness of the Viper Microprocessor: The
First Level,"
Technical Report
no.
104,
University of Cambridge
Computer Laboratory, 1987.
[16] Gordon, M., "A Proof Generating System for Higher Order Logic,"
Technical
Report
no.
103,
University
of
Cambridge Computer
Laboratory, 1987.
1985,
pp.
30331
1.

Specifications,:"
In
Lecture Notes
in
Computer Science,
ed. Springer
Verlag, 1991.
Manipulation,"
IEEE Transactions on Computers,
vol. C35, no.
8,
[22]
A
D&T Roundtable, "Formal Verification is it Practical for Real
World Design,"
IEEE Design and Test OfComputers,
Dec. 1989, pp.
[21] Bryant, R., "Graph Based Algorithms for Boolean Function
August 1986, pp. 667691.
5058.
355
Authorized licensed use limited to: University of Bridgeport. Downloaded on February 24,2010 at 13:24:04 EST from IEEE Xplore. Restrictions apply.