North-Holland Microprocessing and Microprogrammlng 30 (1990) 537-544
537
On the Formal Specification and Verification of Digital Circuits Peter J. de Graa~" Eindhoven University of Technology, Dept. of Electrical Engineering, Digital Systems Group
Abstract: This paper presents a design technique for digital circuits at register-transfer level (RTL). The two most important notions within the design trajectory are the formal specification of the circuit and the formal verification of an implementation, that a designer comes up with, against this specification. A mathematical description formalism is presented that can be used to describe both the specification and the implementation of RTL-circuits and, furthermore, to formally verify the implementation against the specification. As an example, the design of an n-th order infinite impulse response (IIR) filter is presented. It is shown that several different implementations are possible and that the trade-off between speed and chip area can be made very precisely.
1
INTRODUCTION
With the advent of increasingly more advanced technologies and more sophisticated CAD tools, todays IC designers are confronted with unprecedented possibilities and freedom of choice during the design trajectory. During the days of printed circuit boards (PCBs) the designer's emphasis used to be on an efficient use of the available resources. The circuits that were designed then were usually simple enough to allow for a verbal specification. The only verification that was done was the structural test, to see if all the required connections were there and if there were no stuck-at faults. Nowadays, VLSI designers are much more confronted with the issue of complexity control. In order to give a precise and unambiguous high-level specification of a VLSI circuit one needs a language which is both formal and concise. With formal we mean that both the syntax and the semantics of the language are well defined. With concise we mean, on the one hand, that it must not be too difficult for a de-
signer to translate his informal ideas to a formai description and, on the other hand, that the formal descriptions are easy to interpret and to manipulate. The description formalism that we use is based on higher-order logic. Higher-order logic is an extension of the standard predicate logic. Predicate logic allows the use of the quantifiers V ('for all') and 3 ('there exists'). Higher-order logic extends first-order logic in several ways, such as the possibility to write down function-denoting terms and the possibility to quantify over functions and predicates. The idea to use higher-order logic as a hardware description language originated from Mike Gordon and his hardware verification group at Cambridge University. The aim of this paper is to show that higherorder logic can be used to specify and verify digital circuits at register-transfer level. The circuits that we want to verify consist of a number of input-cha~nels, a number of output-channels, a number of state holding elements such as
538
P.J. de Graaff / Formal specification and verification of digital circuits
flip-flops and registers, and some combinational logic. We will assume that, for each inputchannel, the values offered by the environment at that channel are given as a function of time, where time is discrete (i.e. integers). For each of the registers and each of the output-channels the value in that register or at that output-channel can now also be given as a function of time. The correctness concern when verifying a circuit at register-transfer level is to prove that the functions of time describing the register contents and the outputvalues satisfy a given predicate (the specification). The rest of the paper is organized as follows: S e c t i o n 2 gives a short introduction to higherorder logic. It is shown how both combinational circuits and state holding circuits such as registers and flipflops can be specified in this formalism. it is also shown how circuits can be composed into larger circuits and how the specification of the larger circuit can be obtained from the specifications of its parts. Since circuit specifications are predicates, the verification of a circuit against a specification boils down to a mathematical proof that the predicate describing the circuit implies the specification predicate. Section 3 starts with the specification of an n-th order IIR filter. It will turn out that the computations done by the circuit during each clock cycle can be done in a more parallel or a more sequential way. The more parallel solution will turn out to be the fastest, but also the most expensive in terms of chip area. The more sequential solution requires less hardware, but is also slower than the more parallel solution. Section 4 gives some conclusions.
ble to reason about gate-delays and about asynchronous feedbacks (cf. [5]), we will only consider synchronous cicuits with a central clock. Within this synchronous world, the only notion of time that we have is an integer variable, representing a clock that ticks. Our goal is merely to show the applicability of higher-order logic to the specification and verification of register-transfer level synchronous hardware, and not so much to add any new features to the formalism. 2.1
Higher-order logic
Higher-order logic is an extension of first-order predicate logic and it uses the same notation. First-order predicate logic has the standard propositions and connections between them: • " P ( x ) " means "x has property P", • ' % P " means "not P", • "P v Q" means " P or Q",
• "P A Q" means " P and Q", • "P D Q " means "P implies Q", • "P = Q" means "P if and only if Q", • "(P ---*' Q I l Q 2 ) " means "if P then Q1 else
Q2" The use of quantifiers is also allowed in first-order logic: • " V x . P ( x ) " means "for all x it is the case that
x has property P", • " 3 x . P ( x ) " means "for some x it is the case
that x has property P ' . 2
TItE DESCRIPTION FORMALISM
The introduction to higher-order logic and its application to hardware specification that is given in this section was to a large extent inspired by [1]. Our introduction does not intend to show all the possible applications of higher-order logic to digital circuit design. It is possible, for instance, to reason about time at several different levels within the formalism, but we will have only a very simple notion of time. Although it is possi-
Higher-order logic extends first-order logic in three important ways: 1. Apart from predicates, there are also special function-denoting terms, called Aexpressions. These have the form Ax.t where x is a variable and t is an expression. The A-term Ax.t denotes the function with value t[a/x] (i.e. the result of substituting a for x in t) in each element a of its domain. For example Ax.x-/-i is the function that adds 1
P.J. de Graaff / Formal specification and verification of digital circuits
to its argument. )~-Expressions can also be used as arguments to higher-order functions. 2. Variables can range over functions and predicates. Such variables are called higherorder and can also occur in quantified expressions. An example of such a higherorder predicate is:
VfNg.(Vx.f(x)=g(x))D (f=g), saying that two functions are equal when they yield equal results for equal arguments.
539
• An and element
An and element has two inputwires, it and i2, and one outputwire, o. It is specified by the predicate And: And (il, i2, o) =__ o = ix Ix i2 • A multiplexer
A multiplexer has one control input, cntl, two data inputs, il and i2, and one output o. It is specified by the predicate Mux: Mux(cntl, il, i2, o) =
o=(cntl~itli2) 3. Functions and predicates can be the arguments and results of other functions and predicates. A predicate Stable can be defined so that Stable(tt,t2)(f) is true if and only if the value of fis constant from tt until just before t2. This is formally denoted by: Stable(h, t 2 ) ( f ) -
Vt.h < t A t < t2 D (f(t) = f ( h ) ) . 2.2
Hardware specification in higher-order logic
We will look upon a piece of hardware as a 'blackbox' with a number of peripherals to its environment. These peripherals are the communication channels of the environment and they can be used for communication with other devices. The values transported on such a communication channel can be simple booleans, when the channel is a wire, but they can also be more abstract data types such as integers. The behaviour of device Dev with communication channels a l , . . . , a n is specified by a predicate 13ev with n arguments, such that Dev(al,... ,an) holds if, and only if, ( a l , . . . ,a,,) is an allowed combination of values on the channels of the device (notice that we take the freedom to use the same names for the channels and the values communicated via those channels). We show some simple examples of combinational circuitry specified in the way sketched above. • An inverter
An inverter has one inputwire, i, and one outputwire, o. The wires carry boolean values, the specification is given by the predicate Inv: Inv(i,o)
-
o=-,i.
In the examples treated above there was not yet any notion of time. If one wants to specify the dynamic behaviour of a circuit, the values at the communication channels will be functions of time instead of constants. The specifications will then be predicates whose arguments are functions of time. Let us assume that the inverter shown above has a delay of 8 time units. It can then be specified by a slightly changed predicate Inv given below:
Inv(i,o) = Vt.o(t+5)=~i(t). As already mentioned in the introduction, we want to specify synchronous, (i.e. clocked) hardware. Therefore, time is modeled by an integer variable that represents the clock. The circuits that we are interested in consist of state holding elements, such as flipflops and registers, and combinational circuitry. This combinational circuitry has no asynchronous feedbacks (i.e. every feedback within a circuit passes at least one state holding element). The combinational circuitry is assumed to stabilize within every clock-cycle and is therefore assumed to have zero delay. Only the state holding circuitry is assumed to have a fixed delay of one or more clock-cycles. A simple register can be specified as follows: Reg(/,o)= Yt.o(t+ l ) = i ( t ) . The parallel composition of a number of devices I is obtained by connecting communication channels with the same name. The specification of the parallel composition is obtained by 'and-ing' the specifications of the component devices. The set of communication channels of the composition is the union of the sets of communication channels of the components. Communication channels can be made internal ('hided') by binding
P.J. de Graaff / Formal specYicatlon and verification of digital circuits
540
the corresponding channel name to the quantifier 3. As an example, consider the following picture: i
cntl
O
The behaviour of the circuit is specified by the predicate Creg.
Creg(cntl, i,o) = ql.Mux(cntl, i,o,l) ^ Reg(l,o) It is now easy to derive the behaviour of this circuit:
Creg(cntl, i,o) = {definition of Mux and Reg} 1
31.Vt. l(t)=(cntl(t)--*i(t)l o(t)) ^ o(t÷l)=l(t)
same specification. On the other hand, an implementation Impl will generally satisfy more than one specification. The strongest specification that Impl will satisfy is Impl itself. The verification techniques that can be applied here are the verification techniques that are available in predicate logic. As an example, let us consider two specifications, Multl and Mult2, for a multiplier. The multiplier has two inputs, il and i2, and two outputs, done and o. An informal specification could be as follows: "If done is true at time tl and if the inputvaiues offered at il and i2 remain stable until done becomes true again then, at the moment that done becomes true again, the value il(ti) × i2(tl) is offered at o." The predicates Multl and Mult2 given below are both formal specifications for such a multiplier (a circuit that satisfies both these specifications is given in [3]). Multl(il, i2, o, done) =(Vtl, t2.
done(t1) A Next(tl, t2)(done) A Stable(tl,t2)(il) A stabJe(tl,t2)(i2) ^
- {substitution}
ql.Vt. l(t)=(cntl(t)--*i(t)lo(t)) ^ o(t ÷ l )=(cntl(t)--+ i(t)l o(t)) =_ {predicate calculus}
o(t2) = i1(t1) × i2(tl)) Mult2(il, i2, o, done) =-
V t.o(t ÷ l )=(cntl(t)-* i(t)l o(t))
(vta.
Obviously, Creg is a new type of register (compared to Reg). The boolean value at inputline cntl determines if a new inputvalue is read into the register, or if it keeps its old value. 2.3
done(t1) D
(3t . Stable(ta, t2)(il) A Stable(tl, t2)(i2)
Hardware verification using higher-order logic
Verification of the correctness of a piece of hardware w.r.t a specification boils down to the proof of a mathematical theorem
D Next(t1, t2)(done) A o(t2) = il(tl) X i2(tl))) Where: Next(t1, t2 ) ( done ) --
tl < t2 ^ done(t2)^ (Vt.tl < t A t < t 2 D -~done(t))
Impl D Spec, where Irnpl is the predicate describing the implementation and Spec is the specification predicate. Since D is transitive and asymmetric, there may be several implementations that satisfy the
ahints to proof steps aze given between set braces
and: Stable(Q, t2 )( done) Vt.tl < t A t < tg D done( t )=done( tl ) It is easy to verify (using ordinary predicate calculus) that: Mult2DMultl, whereas MultlT~Mult2.
P.J. de Graaff / Formal specification and verification of digital circuits
Hence a circuit that implements Mult2, also implements Multl. A circuit implementing Multl, however, does not have to be correct w.r.t Muir2. There is an easy informal explanation for this phenomenon. Muir2 requires that, whenever two new inputs are read from il and i2 and they remain stable long enough, done becomes true within a finite amount of time and that the product of the inputs is offered at o the next time that done becomes true. Multl only requires that when done becomes true, and the inputs have been stable long enough, the required product is offered at o. Hence a circuit that keeps its done line low, whatever happens at its input lines, is an implementation of Multl, but (luckily) not of Mult2. 3 3.1
AN N-TH ORDER IIR FILTER Specification of the filter
A first specification of an n-th order infinite impulse response (IIR) filter can best be given by means a picture, as shown below. input
output
541
detav[i](t+ l)=delav[i+ l](t))). The picture above gives a straightforward implementation of this specification. The registers delay[I],...,delay[n] are simple registers of the type Reg that we treated in the previous section. Furthermore the circuit has two n+l input adders and 2n+1 multipliers. Both the adders and the multipliers are assumed to be combinational, i.e. the required outputvalues are assumed to occur at the output channels within the same clock cycle that the input values are offered at the input channels. The constants a[1],...,a[n+l] and b[1],...,bin] are stored in ROM and the 2n+1 multipliers actually have two inputs, instead of one as shown for convenience in the picture. The verification of the circuit against the specification is very straightforward and consists of the following steps: • give names to the internal channels of the circuit (for convenience, let the output of a register have the same name as its originating register) • specify the values at these channels as a function of time by looking at the functional blocks (adder, multiplier or register) that they originate from • compose the specifications of the individual channels by 'and-ing' them together
0
r\
The circuit has one input channel, input, one output channel, output and n registers delay[1],...,delay[n]. Furthermore, the circuit has the fixed internal variables a[1],...,a[n+l] and b[1],...,b[n]. The higher-order logic specification for this filter is: (Vt.
output(t)= (input(t)+ (F~i:l < i< n:b[i]x delay[i] (t)))x a[n + l] + (~ i: 1< i< n:a[i]x delay[i](t)^ delay[hi(t+1)= input(t)+(Ei:l< i< n:b[i]x delay[i](t))^ (Vi.l
• hide non-interesting internal channels by binding their names to an existential quantifier. This procedure automatically yields the required correctness proof. The circuit that we have just treated is a rather trivial implementation of an n-th order IIR filter because all the computations that have to be done for processing one inputvalue are done in parallel and each has its own piece of hardware. In the following two sections we will show two different implementations of an n-th order IIR filter that use fewer multipliers than the 2n+1 needed here. A consequence of having less than 2n+1 multipliers is that the processing of one new inputvalue takes more than
P.J. de Graaff / Formal specification and verification of digital circuits
542
one one internal clock cycle of the circuit. The first implementation that we show has n multipliers. Hence the processing of one inputvalue takes three internal clock cycles and the internal clock of the circuit has to run three times as fast as the external clock which determines when new inputvalues are offered. The second implementation has only one multiplier, so here the internal clock has to run 2n+1 times as fast as the external clock. 3.2
input_r:---input, aec: =output_r + (~ i: l < i< n:mult_i) , mult_l:=r[1]× b[1], mult_n:=r[n]× b[n], state:=stl stx : output_r:=acc, acc: =input_r + (~ i:1< i< n:mult_i) , mult_l :=r[1]× at1],
The first implementation
The circuit has three internal states: init, st1 and st2. The circuit state is held in the register state which is specified by: (Vt.
(tmod3=O -+ state(t)=init ]tmod3=l ---* state(t)=stl Itmod3=2 ---* state(t)=st2)). Furthermore the circuit has the registers
input_r, output_r,
rill,...,r[n] and mult_l,...,mult_n. The register acc has n+l inputs and one output aud it is specified by: acc(il,...,in+l,O) =
(Vt. o(t + l)=(~j: I <_j<_n+1:ij (t)). The registers mult_j, l_
is(t)).
Hence, the registers acc and mult differ from ordinary registers because they store the sum and product of their inputvalues, instead of the inputvalues themselves. All other registers are ordinary registers of type Reg. In the rest of the paper we shall use the names of the registers for identifying their o u t p u t channels. The behaviour of the circuit is given by the following program text: DO forever CASE state OF
init:
stg.:
output_r:=mult_l, mult_l:=a[n+ l]x acc, r[n]: =acc, r[n-1]:=r[n],
r[ll::-r[el, state:=init end CASE
acc,
(Yt.o(t+l) = il(t)
mult_n:=r[n]× a[n], state:=st2
The comma's between tile assignment statements denote that, in each of the three circuit states, the assignments must be done simultaneously. The interpretation of an assignment statement is that if the assignment statement is executed at time t (i.e. it is listed under state(t) in the program above) then the value of the lhs at time t+l is the value of the rhs at time t. Under this interpretation we can derive: (Vt.
output_r(3t+5)= (input(3t)+ (Ei:l
r[i] (St)x bH))x ate+l] + (E i:1< i< n:r[i](3t)X a[i])A
r[nl( t +S)= input(3t) + (E i: l < i< n:r[i] (3t)x b[i])A ~/i.l
r[i](St +
q(St))).
If we assume the internal clock of the circuit to run three times as fast as the external clock, then the above predicate comes reasonably near the specification given in the previous section. The
P.J. de Graaff / Formal specification and verification of digital circuits
only difference is that the output is delayed five internal clock cycles (the output is read from output_r when the circuit is in state st2, right after state st1 where the required value was assigned to output_r). The registers r[1],...,r[n] are the delay registers of the specification. The program that describes the required circuit is easily translated to an RTL circuit. The circuit consists of a controller that contains and updates the state register. The task of the controller is to make the right connections between the register output channels and the input channel on the one hand, and the input channels of the registers on the other hand. Apart from the register state, the controller is a purely combinational circuit. Its input channels are: input, input_r, output_r, acc, r[1],...,r[n], mult_l,. . .,mult_n, all],...,a[n+l] and b[1] .... ,b[n]. The output channels of the controller are: aeeops, m u l q o p s , . . . , m u l t n o p s , nezti, nezto and nextrp],...,neztr[n], which are connected to the inputs of the registers acc, mult_l ..... mult.n, input_r, ouput_r, and r[1],...,r[n] respectively. The specification of the controller is directly derived from the program text: a c c o p s =-
(state=init --+ (output_r, mult_l,...,mult_n) Istate=sq -+ (input_r, mult_l. . . ,mult_n)
Istate=stz ~ (ace, O,..., 0)) nexti=(state=init ~ inputlinput_r ) nezto=(state=init ~ output_r Istate=stl ~ acc Istate=sh --+ mult_1) l
543
consisting of the controller and the registers, can easily be verified against the specification given earlier in this section. Hence we can give a completely formal proof of correctness for a rather complicated RTL circuit. 3.3
The second implementation
In the second implementation the circuit has only one multiplier and therefore the circuit needs to have 2n+1 internal states. These states are: init, s t l , . . . , stn. The circuit state is held in register state specified by:
(Vt. (tmod(2n+ i)=O ~ state(t)=init [tmod (2n+1)¢ 0 ~ state(t)=sttmod(2n+l) ). The other registers are input_r, output_r, acc,
mult, and r[q,... ,r M The registers acc and mult both have two inputs and they store the results of additions and multiplications respectively. The behaviour of the circuit is given by the following program text: DOforever CASE state OF init: mult:=r[1]xb[1], input_r:=input, acc:=acc+mult, state:=sl Sl :
acc : =input_r + mult, mult:=r[2]× b[2], output_r:=aee, state:=s2 sl (2< i< n-I): acc :=acc + mult, mult:=r[i+ l]× b[i+ l], state:=si+l Sn:
acc: =acc+mult,
mult:=r[1]×a[1], ~tate:=Sn+l
P.J. de Graaff / Formal specification and verification of digital circuits
544
8n+l :
input_r:=acc, aee:=mult, mult:=r[2]× a[2], state:=sn+2 sl (n+e
acc:=ace-t-mult, mult:=input_r× a[n + l], r[n]:=input_r,
r[.-ll:=rM, r[1]:=r[2], state:=init end CASE Just like we did for the first implementation, we can derive a predicate that gives the behaviour of the circuit through time:
(Yr. output_r( (2n-I-1)t ÷ Zn-F2) = (input((2n+ l) t)+ (Ei:l
CONCLUSIONS
We have presented a simple mathematical formalism that has turned out to be useful for reasoning about the behaviour of RTL circuits. Especially reasoning about the behaviour of a circuit through time can be done in a very elegant
way within the formalism. The digital filter example has shown that the ability to formally specify and verify RTL circuits is indispensible when the design under consideration becomes more complex, since the programs given as a first specification are very difficult to interpret. The strenght of the higher-order logic formalism is that it helps the designer to structure his reasoning about the behaviour of the circuit that he is designing. An aspect of the formalism that needs futher consideration, if we want to use it as the basis for a design method, is the idea of stepwise refinement and guided design. 5
REFERENCES
[1 ] M.J.C. Gordon, "LCF-LSM", University of Cambridge Computer Laboratory Technical Report No. 41, 1983. [2 ] --, " Proving a computer correct", University of Cambridge Computer Laboratory Technical Report No. 42, 1983. [3 ] - - , " Why higher-order logic is a good for-
malism for specifying and verifying hardware", in: Proceedings of the 1985 Edinburgh workshop on VLSI, Edinburgh,1985. [4 ] W. Hatcher, "The logical foundations of mathematics", Pergamon press, 1982. [5 ] John Herbert, "Formal reasoning about the timing and function of basic memory devices, in: Proceedings of the IMEC-IFIP
International Workshop on Applied Formal methods for correct VLSI design, Leuven, 1989. [6 ] Charles S. Williams, "Designing digital filters", Prentice-Hall information and system sciences series, 1986.