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.

Content uploaded by Khaled Elleithy

Author content

All content in this area was uploaded by Khaled Elleithy

Content may be subject to copyright.

A

Production Based System

for Formal

Verification

of

Digital Signal

Processing Archtectures

Khled

A4

Elleithy

&

Mostafa

A.

Aref

King Fahd

University

of

Petroleum

and

Minerals

Dhahran

3

1262,

Saudi Arabia

Specification

2

Abstract

In

this paper a new formal hardware verification

approach for Digital Signal Processing Architectures

based on a production system environment is introduced.

The

PROPER

system (2?ROduction system for hardware

WRification) is implemented using CLIPS (C Language

Integrated Production S’tstem).

A

cell library of diferent

hardware components has been implemented.

Components

in

the cell library are described at the

transistor level, circuit level, gate level, logical level, and

functional level. An example

of

Carry Select Adder using

PROVEZR

is

given

in

the paper.

1:

Introduction

The design process is a transformation between

Merent specifications (Figure

1).

I

Verification

Specification

1

I1

Specification

N

r1

Implementation

N

Design

v

\1

Final Product

Figure

1.

A

Hierarchical Representation of Design

and Verification.

An

input algorithm may be specified using a specfic

algorithmic speclfication language.

An

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 speclfication language.

The objective

of

any design procedure is to produce an

architecture that correctly implements the required

behavior subject to a even set of constraints on area and

timing. It is very expensive to fabricate a design before

verrfylng the functional correctness of the design. There

are

two

approaches for verification; simulation and formal

verification. Simulation is efficient with 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[ 11:

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.

The heart of any

formal

verification methodology, then, is

the availability of a formal specrfication language where

formal proofs

can

be dnven. Logic is one of the widely

used specification languages for verification. First order

logic

has

been used in a number of systems[2-4]. Higher

order logic has been used in a number of applications[5-

81.

Joyce[7-81 used the

HOL

system

to

venfy a

microprocessor. Temporal logic

is

an appropriate

approach for speclfylng timing characteristics of a design.

Temporal logic has been successfully used for verification

in[9-101.

Automated Theorem Provers are efficient in proving

the correctness in large scale architectures where the proof

of correctness is done automatically. In this paper we are

1618

1058-6393193

$03.00

0

1993

IEEE

Authorized licensed use limited to: University of Bridgeport. Downloaded on February 24,2010 at 13:30:08 EST from IEEE Xplore. Restrictions apply.

introducing a novel approach for formal verification based

on a production system. The PROVER (PROduction

system for hardware VER&ation) is implemented using

the CLIPS[11] (C Language Integrated Production

System). The paper is organized

as

follows: in section

two

an introduction to the CLIPS environment is given, in

section

3

the PROVER system is introduced, a DSP

example using the PROVER for verification is given in

section

4.

Finally, section

5

offers conclusions and future

extensions.

2:

CLIPS

Environment

CLIPS was developed in 1985

by

NASA

at the Lyndon

B.

Johnson Space Center

[

1 11. It is designed to overcome

a number of difficulties in using lisp based tools. CLIPS is

written in

C

to support the goal of high portability,

extendibility, capabilities, lowcost and ease of integration

with external systems [12]. CLIPS version 5.1, been

used

in this work, does provide object oriented features,

including defining classes, multiple inheritance and

message handlers.

CLIPS uses rules

as

its primary knowledge

representation approach with a lisp-like

syntax.

CLIPS

supports a rich pattern-matching language for speclfylng

rule conditions. CLIPS, as a production system [13],

provides pattem-directed control of a problem-solving

process. CLIPS consists

of

knowledge base, fact list,

agenda, and cycle of execution. Knowledge base contains

a set of production rules. Fact list (working memory)

contains a description of the current state

of

the problem.

Cycle of execution is the control structure of CLIPS.

Once a knowledge base is built and the fact list is

prepared, CLIPS is ready to execute rules. The basic cycle

of

execution

of

CLIPS

is

as

follows:

1. The knowledge base is examined to see if the

conditions

of

any rule have been met.

2.All

rules whose conditions currently are met

are activated and placed on the agenda.

3. The top rule on the agenda is selected, and its

actions are executed.

As

a result of actions execution, new rules can

be

activated or deactivated. This cycle is repeated until all

rules that can

be

fired have done

so

or the rule limit is

reached. The number

of

rule firings allowed in a cycle

may

be

set by the programmer.

3:

PROVER

System

PROVER is a production system for

formal

hardware

verification. PROVER gets its inputs as a circuit

description and a behavioral description

of

that circuit to

be verified. The circuit description would be one or a

combination of different hardware descriptions. These

descriptions include transistors, gates, logical, functional,

and module descriptions. PROVER

has

a knowledge base

consists of a Cell Library and Rules.

Cell

library

contains

a preddned

set

of hardware components. It Consists of

five sub libraries represent the five level of hardware

descriptions. These sub libraries are Transistor-level

Library

(TL),

Gate-level Library

(GL),

Logic-level

Library

(LL),

Function-level Library

(FL),

Module-level

Library

(ML).

The block diagram of PROVER is shown

in Figure

2.

The rules define possible transformation from

one level to another.

Also,

they reflect the semantic of

each level description.

Verified/

Control

Structure

ot

Verified

Behaviora

Circuit

Knowledge Base

Figure

2.

An overview

of

the

PROVER

Environment

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 the other subsets of the domain.

Currently, the knowledge base of PROVER

has

transistor,

gate, logical, and functional level sub libraries and rules

handling these levels.

4:

Case

Study

The performance of DSP processors depends heavily on

the

speed

of adders

used

in the core.

Carry

select adder is

a fast asynchronous adder based

on

a

cany acceleration

approach. In this section a

two

stage carry select adder

shown in Figure

3

is verified using PROVER. The

methodology

can

be

applied to venfy

an

n-bit adder.

4.1:

Input

The PROVER’S input consists

of

the modules functional

description and interconnections of modules represented

using CLIPS. This input is

as

follows:

1619

Authorized licensed use limited to: University of Bridgeport. Downloaded on February 24,2010 at 13:30:08 EST from IEEE Xplore. Restrictions apply.

Inputs(A0-7, BO-7,

C-1)

Outputs(Sum0-7, Cout)

s4-7

<

,'

~~

sm4-7

-<

p

I

MPX

1

1

Figure

3.

An

8-bit Carry

Select

Adder.

functional correctness of the adder:

Section Adder Rule

Section-A dder-Size(4)

Section-Addergo-3 BO-3

0

SO-3-0

C3-0)

Section-Addergo-3 BO-3

1

SO-3-1

C3-1)

Section-Adder(A4-7 B4-;'

0

S4-7-0 C7-0)

Section-Adder(A4-7 B4-7

1

S4-7-1 C7-I)

Mux(SO-3-0 SO-3-1 C-1 SO-3)

Mux(S4-7-0 S4-7-1

C3

5'4-7)

And(C-1

C3-1

Csl)

Or(Cs1 C3-0 C3)

And(C3-0 C7-1 Cs2)

A

nd(C-

1

C3-

1

C7-

1

Cs3)

Or(Cs2

Cs3

C7-0

C7)

4.2:

Output

It is required in this example to prove that the given

circuit realizes the following function:

n-1

YaZue(S,n

+

1)

=

(2"

*

carry-out)

+

C

2'

*

Si

i=O

4.3:

Proof

Strategy

PROVERuses the following rules for proving the

If

then

there

is

a section adder of size

n

delete the section adder description

and

express the

n

outputs in terms of the inputs

This rule

is

fired

4

times generating 16 logcal

expressions which includes

SO-

7-0

assuming the input

carry is

0

and

SO-7-1

assuming the input carry is 1. For

example,

SO-0

=

A0

+

BO

+

0,

and

SO-1

=

A0

+BO

+

1.

Multidexer Rule

If

then

a 2-input multiplexer

is

used

express the output as

two

implications.

This rule is fired

8

times converting the 16 logical

expression into 16 implications. For example,

not C-l=> A0

+

BO

+

0,

and

C-l=> A0

+BO

+

1.

Reduction Rules

If

two

implications are in the form:

E

=>

y

=

f(xl,x2

,...,

l,.) and

not

E

=>

y

=

f(xl,x2

,...,

O,.)

1620

Authorized licensed use limited to: University of Bridgeport. Downloaded on February 24,2010 at 13:30:08 EST from IEEE Xplore. Restrictions apply.

then

remove these

two

implications and add the fact

y

=

f(xl,x2

,...

E,.).

This

rule is fired 8 times which reduces the 16

implications into eight equations for the eight outputs of

the adder.

If

then

there is And or Or gate

express the output

of

terms of the inputs.

This rule is fired several times and

two

expression for C3

and Cout are formed.

If

an

output expression contains internal terms

and

the internal terms are expressed to the input

terms

replace these internal terms by the expression of

the input terms.

Then

This rule

is

fired several times to include the expression of

C3

in the Sum expressions as follows.

SO

=

sum@O,BO,C-I),

SI

=

sum@

1,

Bl,carry(A

0,

BO,

C-I)),

S2

=

sum(A2, B2,carry(A

1,

BI,

carry@

0,

B0,C-I))),

S3

=

sum@ 3, B3,carry@f,B2,carry(A

I,

BI,

carry@ O,BO,

C-l)))),

S4

=

sum@4,B4,carry@ 3, B3,carry(A2, BZ,carry@

1,

B1,

carry@

0,

BO,

C-I))))),

S5

=

sum@5,B5,carry@4,B4,carry(A3,B3,carry(A2,B2,

carry64 I,BI,carry(AO,

BO,

C-l)))))),

S6

=

sum(A

6,

Bd, carry(A5, B5,carry@4, B4,cariy@3, B3,

carry@2,B2,carry@ I,BI,

carry@

0,

BO,

C-

1)))))))

and

carry(A3,B3,carry@2,B2,carry(AI,Bl,

C~YY@

0,

B

0,

C-

1)))))))).

S7

=

sum@ 7,B7,carry(A6,B6,carry@5,B5,carry@4,84,

To

summarize the proof strategy, the interconnections

between modules are checked for correctness as well as

the modules. Section Adders (SA) are assumed to

be

functionally correct. Therefore,

sum

and carry functions

are used directly for substitution.

A

proof for the

multiplexers

functionality

is

carried out.

Carry selector

blocks are functionally proved from the logcal level. The

final output is to verify that the circuit is an

implementation

of

the function

value.

4.4:

Analysis

The previous proof can be easily extended to n-bit

carry select adder through the general definitions of the

used modules. Table 1 shows PROVER results for

venfylng

8,

16, and

32

bits

carry

select adders.

Table

1.

Results

for

8,16,

and

32

bit

Carry

select

adders

5:

Conclusions

Vemng large scale systems is no more a straight

forward process that can

be

completely acbeved using

traditional approaches of simulation. In

this

paper a

formal verification approach based on the

CLIPS

production system as a host environment has been

introduced. An example of Carry select adder has been

PROVER for

8,

16 and 32 bits. Results show the a 32 bit

Carry Select Adder can be verified functionally in less

than five seconds. Currently we are investigating the

applicability of PROVER to large size problems.

Acknowledgment

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

[lIDasgupta,

S.,

The Design and Description

of

Computer Architectures,

John Wiley

&

Sons, Inc.,

1984.

[2]Uehara,

T.,

et

al.,

"DDL Verifier and Temporal

Logic,"

Proc. CHDL

83:

IFIP

4th Int'l

Symp.

Computer Hardware Description Languages

and

theirllpplzcations,

Pittsburgh, May 1983, pp. 91-102.

[3] Eveking, "Formal Verification

of

Synchronous

Systems,"

Formal Aspects

of

VLSI

Design: Proc.

1985

Edinburgh

Con$

WSI,

G.

J.

Milne and P. A.

Subrahmanyam, eds., North Holland Publishmg,

Amsterdam, 1986, pp. 137-151.

[4]

Hunt,

W.

A., "FM8501: A verified Microprocessor,''

lFIP

WG

10.2

Workshop, From HDL Descriptions

to

1621

Guaranteed Correct Circuits Design,

North Holland

Publishing, Amsterdam, Sept. 1986, pp. 85-1 14.

[5]Hanna,

F.

K.

and Daeche, "Specrfcation and

Verification of Digital Systems Using Higher order

Logic,"

IEEproc.,

Vol. 133,

Pt.

E,

No.

5,

Sept.

1986,

pp. 242-254.

[6] Gordon,

M.

J. C., "Why High-Order Logc is

a

Good

Formalism for Speclfylng and

Verifying

Hardware,"

Formal Aspects

af

VLSI

Design: Proc.

1985

Edinburgh Con$

KLSI,

G.

J. Milne and

P.

A.

Subrahmanyam,

eds.,

North

Holland Publishing,

Amsterdam, 1986, pp. 153-177.

[7]Joyce, J., Birtwistle, and Gordon,

M.

"Proving

a

Computer Correct

in

Higher Order Logic,"

Tech.

Rept.

No.

100,

Computer Laboratory, The University

ofcambridge,

Cambridge, England, 1986.

[8] Joyce, J.,

"Formal

Verification and Implementation

of

a

Microprocessor,"

VWII

Specification, Verification,

and Synthesis,

Birtwistle,

G.

and Subrahmanyam,

P.A., eds., North Holland, Amsterdam, The

Netherlands, 1988, pp. 371-378.

[9]Bochmann,

G.

V.,

"Hardware Specification

with

Temporal Logic:

An

Example,"

IEEE Trans.

Computers,

Mar.

1982, pp. 223-23 1.

[lOlFujita,

M.,

et al., "Logic Design Assistance

with

Temporal Logic,"

Proc. CHDL

85:

IFIP

7th Int?

Symp. Computer Hardware Description Languages

and their Applications,

Aug. 1985, pp. 129-137.

Clips Reference Manual,

version 5.1, Software

Technology Branch, Lyndon B. Johnson Space

Center, September 1991.

Mettrey, "A Comparative Evaluation of Expert

System

Tools,"

IEEE Computer,

pp. 19-3 1, Vol.

24,

No.

2,

Feb. 1991

1131 George F. Luger,

William

A. Stubblefield,

Artificial

Intelligence and the design

of

Expert System,

The

BenjamidCummings publishing Company, 1989.

1622