Formal Design of a Modulo-N Counter

Max Fuchs Institut fur Informatik Technische Universitat Munchen D-80290 Munchen, Arcisstr. 21 e-mail: fuchs@informatik.tu-muenchen.de
Abstract
We illustrate the use of functional system speci cations and their re nement in the formal development of hardware systems by a small electronic device, an asynchronous modulo N counter. The development includes modular speci cation, re nement and veri cation. We start with an intuitive abstract requirements speci cation and re ne this into a non-trivial concrete bit-level implementation. The re nement steps comprise behavioral, structural and interface re nement. The emphasis of this study is laid on the modeling at di erent levels of abstraction and the veri cation conditions obtained by the re nement relations between this versions.

1 Introduction
The formal design of hardware systems is a subject of remarkable interest in the area of computer science MT90]. The complexity of electronic systems in both area and functionality requires modular speci cation and re nement techniques. Moreover an appropriate design method for hardware systems should o er techniques for precise and clean interface descriptions. A speci cation method with these properties is Focus BDD+92]. It is based on a functional setting and modularity allows Focus to scale up quite well with speci cations of non-trivial complexity. For an overview of case-studies carried out so far in Focus see BFG+94]. To illustrate the use of Focus we choose a small, but non-trivial example, namely an asynchronous modulo N counter. On many occasions in hardware systems counters capable of counting from state 0 through state N ; 1 and then cycle back to the state 0 are needed. We refer to such counters as modulo N counters NCI75, EP92]. There are synchronous and asynchronous modulo N counters. The synchronous ones are controlled 1

by a common clock signal and in general they are slower than the asynchronous versions. This paper concentrates on the formal design of an asynchronous modulo N counter. In a number of straightforward re nement steps a non-trivial bit-level implementation is re ned from an intuitive abstract requirement speci cation. In the speci cation method Focus a system is modeled by a network of functional components working concurrently, and communicating asynchronously via unbounded FIFO channels Kah74, Del87, BDD+ 92]. A number of reasoning styles and techniques are supported. Focus provides mathematical formalisms which support the formulation of highly abstract, not necessarily executable speci cations with a clear semantics. Moreover, Focus o ers powerful re nement calculi which allow distributed systems to be developed in the same style as the methods presented in Jon90], Bac88], Mor90] allow for the development of sequential programs. The re nement steps comprise behavioral, structural and interface re nement Bro92]. Focus is modular in the sense that design decisions can be checked at the point where they are taken, that component speci cations can be developed in isolation, and that already completed developments can be reused in new program developments. This paper is organized as follows. In Section 2 we introduce the underlying formalism. In Section 3 it is explained, what we mean by speci cation and re nement. The formal design of the modulo N counter is performed in Section 4. Here we start with an intuitive abstract speci cation and re ne it into a non-trivial network of subcomponents at the bit-level. Section 5 summarizes and draws some conclusion.

2 Underlying Formalism
N denotes the set of natural numbers including 0 and B denotes the set of binary numbers f0 1g. A stream is a nite or in nite sequence of actions. It models the history of a
communication channel, i.e. it represents the sequence of actions sent along the channel. Given a set of actions D, D denotes the set of all nite streams generated from D D1 denotes the set of all in nite streams generated from D, and D! denotes D D1 . If d 2 D, r s 2 D! and j 2 N, then: denotes the empty stream #r denotes the length of r, i.e. 1 if r is in nite, and the number of actions in r otherwise ft:r denotes the rst action of a stream r (unde ned if r is empty) rt:r denotes the rest of stream r (r without the rst action) d & s denotes the result of appending d to s 2

r _ s denotes the concatenation of r and s, i.e. r _ s is equal to r if r is in nite, and is equal to s pre xed with r otherwise r v s denotes that r is a pre x of s, i.e. 9p 2 D! : r _ p = s rj denotes a j -tuple of streams r only. The stream operators de ned above are overloaded to tuples of streams in a straightforward way. If d 2 D, t is an n-tuple of actions, r s are n-tuples of streams and j 2 f1 : : : ng, then #r denotes the length of the shortest stream in r t & s denotes the result of applying & pointwisely to the components of t and s d &j s denotes the result of appending d to the j 'th stream in s only r _ s and r v s are generalized in the same pointwise way. A chain c is an in nite sequence of stream tuples c1 c2 : : : such that for all j 2 N, cj v cj+1. tc denotes c's least upper bound. Since streams may be in nite such least upper bounds always exist. A function f 2 (D! )n ! (D! )m is called a (n m)-ary stream processing function i it is monotonic which means that for stream tuples i and i0 in (D! )n : i v i0 ) f (i) v f (i0)
and continuous which means that for all chains c generated from (D! )n : f (tc) = tff (cj )jj 2 Ng: That a function is monotonic implies that if the input is increased then the output may at most be increased. Thus what has already been output can never be removed later on. Continuity, on the other hand, implies that the function's behavior for in nite inputs is completely determined by its behavior for nite inputs.

3 Speci cation, Re nement and Networks

A speci cation of an agent with input channels and output channels is written in the form
spec

S :: g : T1 ! T2 F:

S is the speci cation's name and g is a variable ranging over the domain of stream processing functions characterized by T1 ! T2 where T1 and T2 are domains of stream tuples for input and output and F is a formula with g as its only free variable. The variable g characterizes the interface of the component we want to design. A speci cation's denotation S ] is the set of all stream processing functions which satisfy F .
3

A speci cation S2 re nes another speci cation S1, if S2 ] S1 ] , i.e. if any stream processing function which satis es S2 also satis es S1. We choose here the most simple and most basic logical notion of re nement for speci cations, namely logical implication. If F1 and F2 are the corresponding formulae to S1 and S2, respectively, then S1 re nes S2 i F1 ) F2. This re nement concept is compositional and introduced in Bro92]. We distinguish between three di erent styles of re nement, namely behavioral re nement, structural re nement and interface re nement. Behavioral re nement allows to add properties and consequently restrict the number of models. Structural re nement performs a splitting of a single speci cation into a network of speci cations. Interface re nement changes the number of input and output channels of a component as well as the granularity of the actions coming along the channels { the latter is also called action re nement. The de nition of a network of speci cations is the main structuring mechanism. A network can either be de ned by equational de nitions or by special composition operators. In this paper we choose equational de nitions to describe networks of speci cations. In an equational de nition a network is de ned by a set of mutually recursive stream equations. The semantics is the least function that ful lls the de ning equations for all input values Ded92]. To give an example, the semantics of the network shown in Figure 1 is given by the least function, which ful lls the following equation: S1:f1 ^ S2:f2 ^ 8i r 9x y o s : f1(i x) = (o y) ^ f2(y r) = (x s) Note that for di erent functions f1 and f2, which ful l S1 and S2, respectively, a di erent xpoint is calculated { this phenomena re ects underspeci cation.

i
.. .. .. .. . . . .

r
. . .. .. .. . . . .

S1

. . . . . . . . . . . . .. . .. . . . . .. . . . .. .. .. . . .. . . .. .. .. . . . . . .. . .. .. .. . . . . .. .. . . ... ... .. . . .. . .. . .. . . . . . . . . . . . . . . . . . . .. . .. . .. . .. .. . .. . . . . . . . .. . . . . .

. . .. .. .. . . . .

S2

.. . .. . .. . . . .

.. .. .. .. . . . .

.. .. .. .. . . . .

Figure 1: Mutual feedback composition of two speci cations.

4 Design of a Modulo N counter

In this section we re ne an abstract speci cation of a modulo N counter into a non-trivial bit-level implementation. Before going through the di erent design steps in detail we 4

give an overview of the entire development process. As shown in Figure 2 we start with a black box speci cation MNC that characterizes the external behavior of the counter.
. . . . . .. .. .. .. . . . . . . . . . . . .. .. .. . . . .

MNC
. . . . .. .. . .. . . . . . . . . . . . . . . . .. . . . . .. .. .... .... .... .. .. .. .. . .. .. .. . . . . .. .. . .. . . . . . .. .. .. .. .. .. .. . . . . . .. . . .. .. .. . . . . .. .. .. .. .. . . . . . . .. . .. . . .. . . . . . .. . . .. . . . .. . . .. . . . ... . .. .. .. . . . . .. .. .. . . . . .. . . .. .. . .. .. . .. . .. . .. . . . .. .. . . .. . . . . .. . .. .. . ... . .. .. .. . .. .. . .. .. . . . . . . .. . . . . . .. . . . . . . .. .. . . . .

(1) Structural Re nement

. . . . . .. .. . .. . . . . . . . . . .. .. . .. . . .

. . . . . .. .. .. .. . .

. . . . . .. .. . .. . . .

. . . . . .. .. . .. . . . .

COL

CNT
. . . . . .. .. .. .. . . . . . . . . . . . . . . . . . . . . . . . . . .... .... . .. .. ... .. . .. . . .

(2) Interface Re nement

. . . . . .. .. .. . . . . .

. . . . . .. .. .. . . . . .

. . . . . .. .. .. .. . . . .

CNT ::: :::

. . . . . .. .. .. .. . . . . . . . . . .. .. .. .. . . . .

. . . . . .. .. .. .. . . . .

. . . . .. .. .. . . . . .

. . . . . .. .. .. .. . . . .

C NT ::: :::
. . . . . .. .. .. .. . . . . . . . . . .. .. .. .. . . . . . . . . . . . . . . . . . . . . . . .. .. .... .... ... ... . .. . . .. .

\
. . . . .. .. .. .. . . . . . . . . . .. .. . .. . . .

. . . . . . . . . . . . . . . . . . . .... .... .. .... ... .. .. . .. .

(3) Action Re nement

. . . . .. .. .. . . . .

. . . . . .. .. .. .. . . . .

..... ...... .. .. ...... ..... . . . . .. .. . .. .. . . ...... ...... . . ...... ......

::: :::
...... ...... . . ...... ..... .

(4) Structural and Behavioral Re nement

. . . . .. .. .. .. . . . .

CTBIT
. . . . . .. .. . .. .. . . . . . . . .. .. . .. .. . .

...... ..... . .. . ..... . ......

CTBIT
. . . . . .. .. . .. . . . .

...... ...... . . ...... ..... .

CTBIT
. . . . . .. .. . .. .. . . . . . . . .. .. . .. .. . .

...... ...... . . ...... ......

Figure 2: An overview about the design of a modulo N counter. 5

The input lines carry streams of bits and the output line carries natural numbers between 0 and N ; 1. In the rst design step (1), a so called structural re nement, the black box speci cation is re ned into a speci cation of a controller COL and a counter CNT . The controller is responsible for resetting the counter whenever the counter's most recent output was N ; 1 and a new count signal is received. The counter itself increases or resets the output value on demand. In the following we restrict ourself to the development of the counter only. The second design step (2), a so called interface re nement, replaces each output line which carries natural numbers by an appropriate number of output lines carrying bits. The necessary number of lines is of course a function of N. The third design step (3) is a so called action re nement. To allow hardware implementations based on master/slave ip ops, where only impulses and not signals (sequence of 1's) are counted, we have to re ne the bits on the input lines in an adequate way. The interesting action re nement is the re nement of a 1, which is represented by a 1 followed by a 0 { consequently a sequence of 1's is replaced by a sequence of impulses. The fourth design step (4) is a combination of a structural and a behavioral re nement step. The speci cation of the counter achieved during the third design step is split into a network of identical component speci cations. Each speci cation describes a bit-slice of the counter and could be implemented by a master/slave ip op. Note that the development of the modulo N counter would of course also include the corresponding re nement steps for the controller to ensure that both components, the controller and the counter, work properly together.

4.1 Requirement Speci cation

i1
.. . .. .. .. . . . . .. . .. .. .. . . . .

i2

MNC
.. . .. .. . . . . .

Figure 3: A modulo N counter. We start with an abstract speci cation of a modulo N counter. The modulo N counter has two external input channels, which corresponds to the count (i1) and to the clear (i2) input, and one external output channel, which carries natural numbers 2 f0 : : : N;1g, as indicated by Figure 3. The counter counts from state 0 through state N;1 and than cycles back to state 0. Regardless of the count input, a 1 at the clear input resets the counter to 0. On the other hand a 1 at the count input increments the counter with respect to modulo N. The formal speci cation is given in Figure 4. 6

spec

MNC :: f : B! B! ! N! 8i1 i2 2 B! : f (i1 i2) = g(i1 i2 0) where 8co cl 2 B! z 2 N : g(co 1&cl z) = 0&g(rt:co cl 0) g(0&co 0&cl z) = z&g(co cl z) g(1&co 0&cl z) = if z = N ; 1 then 0&g (co cl 0) else z + 1&g (co cl z + 1)
Figure 4: Speci cation of a modulo N counter.

The counter is speci ed in terms of a function g which has an additional state parameter to store the last output value. Whenever the signal received on the second input line, which corresponds to the clear input, is a 1, a reset is performed and 0 is output. If a 0 is received on both input lines the counter's state does not change and it's current state value, which represents the last output value, is output. When a 1 is received on the rst input line, which represents the count input, and a 0 is received on the second there are two cases to consider. If the counter's state is equal to N ; 1 the counter is reset and 0 is output, otherwise the state is incremented and the incremented state value is output. Note that N is a constant which can be instantiated as needed.

4.2 First Structural Re nement

.. . .. .. .. . . . .

i1 i2 COL
.. . .. .. . . . . .

.. . .. .. . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . .. . . .. . . . . . . . . . . . .. . .. . .. . . .. . . . . . . . .. . .. . . . . .. . . . . . . . . . .. . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

.. . .. .. . . . . .

x1 x2 CNT

.. . .. .. . . . . .

.. .. .. .. . . . .

Figure 5: First structural re nement of a modulo N counter. The rst re nement step is a structural decomposition. As indicated in Figure 5, the modulo N counter MNC is decomposed into two component speci cations { a controller COL and a counter CNT . The counter, which is speci ed in Figure 6, di ers from the modulo N counter in the sense that it does not reset itself whenever a count request is received and the upper limit N ; 1 has already been reached. This task has been 7

transferred to the controller, which is informed about the counter's current state via y. The speci cation of the latter is given in Figure 7.

spec CNT :: f : B! B! ! N! N! 8x1 x2 2 B! : f (x1 x2) = 0&1g(x1 x2 0)2 where 8co cl 2 B! z 2 N :

g(co 1&cl z) = 0&g(rt:co cl 0) g(0&co 0&cl z) = z&g(co cl z) g(1&co 0&cl z) = z + 1&g(co cl z + 1)

Figure 6: Speci cation of the counter CNT . Note that the expression g(x1 x2 0)2 used in the speci cation of CNT in Figure 6 represents the tuple (g(x1 x2 0) g(x1 x2 0)) and that an initial value 0 is output on y via the &1-operator.

spec COL :: f : B! B! N! ! B! B! 8i1 i2 2 B! y 2 N! :

f (i1 1&i2 y) = (0 1)&f (rt:i1 i2 rt:y) f (0&i1 0&i2 y) = (0 0)&f (rt:i1 i2 rt:y) f (1&i1 0&i2 y) = if ft:y = N ; 1 then (0 1)&f (i1 i2 rt:y ) else (1 0)&f (i1 i2 rt:y )

Figure 7: Speci cation of the controller COL. The controller only resets the counter whenever there is an external reset signal or there is a count signal and the current state of the counter is already N;1 (seen via y). The correctness of this decomposition, i.e. that 8f1 f2 :COL:f1 ^ CNT:f2 )9f : MNC:f ^ 8i1 i2 x1 x2 y o : f1(i1 i2 y) = (x1 x2) ^ f2(x1 x2) = (y o) ) f (i1 i2) = o, follows by xpoint induction and straightforward predicate calculus. Note that the xpoint concept re ects the characteristics of feedback in communication in an appropriate manner. If further output requires more input (via feedback) than available this way no more output is generated. This is properly modeled by the assumption that the xpoint is the least one. The initial value 0 in the speci cation of CNT indicates, that the counter's internal state is 0 at the very beginning and allows the calculation of an non-trivial xpoint (6= ). 8

In the following we restrict ourself to the development of the counter CNT only. Note that of course all interface re nements of CNT , which would a ect the controller's interface, would also require re nements of COL.

4.3 Interface Re nement

..... ..... ....... ...... ..... ..... ....... ...... .. .. .. .. . . . . .. .. .. .. . . . .

CNT
.. .. .. .. . . . .

..... . ..... ...... ......

....... ..... ..... ...... .. .. .. .. . . . .

R0

.. . .. .. .. . . . .

.. . .. .. .. . . . .

..... . ..... . ... .. ...... ..... ..... ...... .......

CNT

. . .

.. . .. . .. .. . . .. . .. .. .. . . . .

..... ...... ....... .....

..... . ...... ...... .....

Figure 8: Interface re nement of the counter CNT . The CNT component we have so far consists of two input channels of type B and two output channels of type N. To go a step further towards hardware implementation, we replace the channels of type N by an adequate number of channels of type B. As indicated by Figure 8, we conduct an interface re nement in the sense that the interface of the counter is re ned modulo to representation speci cations R and R0 . More explicitly, ~ ~ each channel of type N is re ned into N channels of type B, where N is the bandwidth required for a modulo N counter. The auxiliary function ntb (nat-to-bin)
~ ntb :: N ! BN

i < N ) ntb(i) = b
~ where i i = PN=1 bj 2(j;1) and bj represents the j 'th bit of the binary word b, yields j the binary representation of any natural number i less than N. The new counter speci cation CNT , given in Figure 9, is a straightforward adaptation of CNT, and the corresponding representation speci cations are trivial. The latter are given in Figure 10.

~ ~ spec CNT :: f : B! B! ! (B! )N (B! )N 8x1 x2 2 B! : f (x1 x2) = ntb(0)&1g(x1 x2 0)2 where 8co cl 2 B! z 2 N

g(co 1&cl z) = ntb(0)&g(rt:co cl 0) g(0&co 0&cl z) = ntb(z)&g(co cl z) g(1&co 0&cl z) = ntb(z + 1)&g(co cl z + 1)

Figure 9: Speci cation of the counter CNT . Note that the speci cation CNT just di ers from CNT in the sense that it simply converts the output into a bit representation by applying the auxiliary function ntb. The representation speci cation R0 also converts natural numbers coming along the input lines into their corresponding bit representation and R simply speci es the identity function.

spec R :: f : B!! B! ! B! B! 8i1 i2 2 B : f (i1 i2) = (i1 i2)

~ ~ spec R0 :: f : N!! N! ! (B! )N (B! )N 8y o 2 N : f (y o) = (ntb(ft:y) ntb(ft:o))&f (rt:y rt:o)

Figure 10: Representation speci cations R and R0. The correctness of this interface re nement, i.e. that 8g1 f1 :R:g1 ^ CNT:f1 )9f g : R0:g ^ CNT:f ^ 8i1 i2 : f1(g1(i1 i2)) = g(f (i1 i2)), again follows by xpoint induction and straightforward predicate calculus.

4.4 First Action Re nement

So far CNT already counts on every single count message, which is represented by a single \1". We now re ne the counter to only count on impulses. This is closer to a hardware implementation based on master/slave ip ops. Each occurrence of a 0 and a 1 in the input streams is represented by 0&0 and 1&0, respectively. The new counter speci cation di ers from the old one in the sense that it only assures to give the correct count value for every second output.

10

..... ...... ....... ..... ...... ...... ...... ..... .. .. .. .. . . . . .. .. .. .. . . . .

CNT

. . .
.. .. .. .. . . . .

....... ...... ..... .....

..... ..... ...... ....... .. .. .. .. . . . .

. . .. .. .. . . . .

.. .. .. .. . . . .

..... . ..... ...... ...... ..... . ..... ...... ......

C NT

R0

. . .

.. .. .. .. .. . . . . .. .. .. . . . .

..... ...... ....... .....

..... ..... ....... ......

Figure 11: First action re nement. Given the two auxiliary functions :: B! ! B! (0&s) = 0&0& (s) (1&s) = 1&0& (s)
~ ~ :: (B! )N ! (B! )N

(a&b&c) = b& (c) we now conduct an action re nement in accordance with Figure 11. Note that does exactly the expansion of the input data required. The function allows us to take care only of every second element in a stream { this property is needed to specify C NT . The speci cation of C NT is given in Figure 12.
~ ~ spec C NT :: f : B! B! ! (B! )N (B! )N 8x1 x2 2 B! : :f!(x1 x2) = ntb(0)&1 :g(x1 x2 0)2 where 8co cl 2 B z 2 N

\ \

g(co 1&cl z) = ntb(0)&g(rt:co cl 0) g(0&co 0&cl z) = ntb(z)&g(co cl z) g(1&co 0&cl z) = ntb(z + 1)&g(co cl z + 1)

Figure 12: Speci cation of the counter C NT . Note that in principle the speci cation C NT is de ned for arbitrary input { however if it receives input expanded by , it performs on every second output the same counting 11

CNT performs on non-expanded input. Taking only every second output value into consideration is necessary for the correctness of the next structural re nement step of section 4.5. Here C NT still counts on every 1 whereas on 0's the output is kept stable. In the next structural re nement step however, we split up C NT into a network of components, each working just on one bit-slice like in a master/slave ip op implementation. In this network the counting takes only place on a 0 following immediately after a 1, which is in fact counting based on impulses. Consequently on every second output value the more abstract and the more concrete speci cations correspond. On the other values however, there can be a mismatch, which is handled by underspeci cation via the -operator in the speci cation of C NT { every value is allowed for the not speci ed output values. Again the representation speci cations are straightforward. They are given in Figure 13. R is responsible for the transformations of 1 and 0 into 1&0 and 0&0, respectively. The functions speci ed by R0 must have the property that ltering out every second value in the output streams returns the input streams.

spec R :: f : B!! B! ! B! B! 8i1 i2 2 B : f (i1 i2) = ( :i1 :i2)

~ ~ ~ ~ spec R0 :: f : (B! )N (B! )N ! (B! )N (B! )N ~ 8t1 t2 2 (B! )N : :f (t1 t2) = (t1 t2)

The correctness is once more straightforward. It must be shown that 8g1 f1 :R:g1 ^ C NT:f1 )9f g : R0:g ^ CNT:f ^ 8i1 i2 : :f1(g1(i1 i2)) = :g(f (i1 i2)).

\
. . . . . . .. .. .. . . . . . . . . .. .. .. . . . .

Figure 13: Representation speci cations R and R0.

4.5 Second Structural Re nement

i2 i1
...... ..... . . . . ...... ......

CTBIT y1
. . . . . .. .. .. . . . .

x1

. . . . . . .. .. .. . . . ...... ..... . . ...... ......

CTBIT
. . . . . .. .. .. . . . . .

x2

...... ...... . . ....... ......

:::

. . . . . . .. .. .. . . . ...... ..... . . . . ...... ......

CTBIT
. . . . . .. .. .. . . . . .

xn

...... ..... . . ...... ......

o1

y2

. . . . . .. .. .. .. . . .

o2

yn

. . . . . .. .. .. . . . .

on

Figure 14: Second structural re nement of the counter. 12

~ The counter is now decomposed into N identical components whose speci cation is given in Figure 15. The speci cation describes a bit-slice of the counter which could be nally implemented by a master/slave ip op.

spec CTBIT ::!f : B! B! ! B! B! B! 8i1 i2 2 B : f (i! i2) = 0&10&1g(i1 i2 0 0)3 1 where 8co cl 2 B z o 2 B :

g(co 1&cl z o) = 0&g(rt:co cl 0 0) g(1&co 0&cl z o) = o&g(co cl 1 o) g(0&co 0&cl z o) = if z = 1 then :o&g (co cl 0 :o) else o&g (co cl z o)

Figure 15: Speci cation of CTBIT . The two state variables in function g represent the last read value at the count input (z) and the last output value (o), respectively. Note that a 1 at the count input does not change the current output value of CTBIT , but a 0 right after a 1 changes the output and nally increments the counter. To increment a bit slice means simply to invert the previous output. The correctness of this decomposition, i.e. that

8g f1 : : : fn :R:g ^ (jV CTBIT:fj ) ) 9f : C NT (n):f ^ 8i1 i2 c d o1 : : : on : =1 g(i1 i2) = (c d) ) (( :f1(c d) = (o1 )3 ^ :f2(o1 d) = (o2)3 ^ : : : ^ :fn(on;1 d) = (on )3) ) :f (c d) = (o1 : : : on )2),
n

can be shown by induction and straightforward predicate calculus where n is a short~ hand for N. For the detailed proof we refer the reader to the Appendix. The re nement applied here also includes behavioral re nement. It xes the entire output values and not only every second value as it is done in C NT .

5 Conclusion
A functional style for the formal development of an asynchronous modulo N counter has been applied. Based on this case study it has been shown that the modular design method Focus can be used to specify and stepwisely re ne an intuitive abstract requirement speci cation of a hardware component into a non-trivial bit-level implementation. Because our method is modular and we conduct our reasoning at a very abstract level 13

we believe that our technique scales up quite well with speci cations of a non-trivial complexity.

6 Acknowledgments
I would like to thank Ketil St len for fruitful discussions and valuable comments which led to many improvements. I would like to thank also Manfred Broy for a careful reading of a previous version. Financial support has been received from the Sonderforschungsbereich 342 \Werkzeuge und Methoden fur die Nutzung paralleler Rechnerarchitekturen".

References
Bac88] R. J. R. Back. A calculus of re nments for program derivations. Acta Informatica, 25:593{ 624, 1988. BDD+ 92] M. Broy, F. Dederichs, C. Dendorfer, M. Fuchs, T. F. Gritzner, and R. Weber. The Design of Distributed Systems | An Introduction to focus. SFB-Bericht 342/2/92 A, Technische Universitat Munchen, January 1992. + 94] M. Broy, M. Fuchs, T. F. Gritzner, B. Schatz, K. Spies, and K. St len. Summary of case BFG studies in Focus - a design method for distributed systems. Technical Report SFB 342/13/94 A, Technische Universitat Munchen, 1994. Bro92] M. Broy. Compositional Re nement of Interactive Systems. Technical Report 89, Digital Systems Research Center, Palo Alto, California 94301, July 1992. Ded92] F. Dederichs. Transformation verteilter Systeme: Von applikativen zu prozeduralen Darstellungen. SFB-Bericht 342/17/92 A, Technische Universitat Munchen, August 1992. Doktorarbeit. Del87] C. Delgado Kloos. Semantics of Digital Circuits. Springer, 1987. LNCS 285. EP92] C. Ebergen and M. G. Peeters. Modulo-N Counters: Design and Analysis of Delay-Insensitive Circuits. In J. Staunstrup and R. Sharp, editors, Second Workshop on Designing Correct Cicuits, January 1992. Fuc95] M. Fuchs. Formal Design of a Modulo-N Counter. SFB-Bericht 342/06/95 A, Technische Universitat Munchen, April 1995. Jon90] C. B. Jones. Systematic Software Development Using VDM, Second Edition. Prentice-Hall, 1990. Kah74] G. Kahn. The semantics of a simple language for parallel programming. In Proc. Information Processing 74, pages 471{475. North-Holland, 1974. Mor90] C. Morgan. Programming from Speci cations. Prentice-Hall, 1990. MT90] K. McEvoy and J. Tucker. Theoretical Foundations of Hardware Design. In K. McEvoy and J. Tucker, editors, Theoretical Foundations of VLSI Design, volume 10 of Cambridge Tracts in Theoretical Computer Science, chapter 1, pages 1 { 62. Cambridge University Press, 1990. NCI75] H. Nagle, B. Carroll, and J. Irwin. An Introduction to Computer Logic. Prentice-Hall, 1975.

14

7 Appendix
In this section the proof of the re nement step applied in section 4.5 is carried out in detail. Due to the fact that the two output streams of CNT and the three output streams of any CT BIT are identical for each component, we simplify these components by taking just one output stream into consideration. The corresponding proof obligation is as follows: : : : fn : R:g ^ ( CTBIT:fj ) ) 9f : CNT(n):f ^ 8i1 i2 c d o1 : : : on : j =1 g(i1 i2) = (c d) ) (( :f1 (c d) = o1 ^ :f2(o1 d) = o2 ^ : : : ^ :fn (on;1 d) = on) ) :f(c d) = (o1 : : : on)) The proof is carried out by induction on n: Base case: n = 1 Must be shown that: 8g f1 :R:g ^ CTBIT:f1 ) 9f : CNT(1):f ^ 8i1 i2 c d : g(i1 i2) = (c d) ) :f1(c d) = :f(c d) To show this we refer to the internal functions f~1 and f~ used to de ne f1 and f. The proof for the initial values, which are only covered by f1 and f, is trivial. The functions f~1 and f~ are based on states. To relate the concrete states in f~1 to the abstract state in f~ we introduce a function
8g f1

V
n

(1) m 2 Bn Bn ! N where (2) 8z z 2 Bn : m(z z) = btn(z) We then get the following proof-obligation: (3) 8g f1 : R:g ^ CTBIT:f1 ) 9f : CNT(1):f ^ 8i1 i2 c d z : ~ ~ g(i1 i2) = (c d) ) :f 1(c d 0 z) = :f(c d m(0 z)) The proof of (3) is by induction on the sum of the lengths of i1 and i2. The base case #i1 + #i2 = 0 follows trivially because of monotonicity. We assume that (3) holds for #i1 + #i2 = n. We want to show that (3) holds for #i1 + #i2 = n + 1. Assume (4) g(i1 i2) = (c d) There are ve cases to consider:
Case 1: \count"

(5) ft:i1 = 1 ^ ft:i2 = 0 (4) and (5) imply: (6) g(i1 i2) = (1&0 0&0)_g(rt:i1 rt:i2) (4) and (6) imply: :f~1 (c d 0 z) = :f~1 ((1&0 0&0)_g(rt:i1 rt:i2) 0 z) (7) (7) and the de nition of f~1 imply: (8) :f~1 (c d 0 z) = :f~1 (1&0 0&0 0 z)_ :f~1(g(rt:i1 rt:i2) 0 :z)

15

(8) and induction hypothesis imply: ~ (9) :f~1 (c d 0 z) = :f~1 (1&0 0&0 0 z)_ :f(g(rt:i1 rt:i2) m(0 :z)) (9) and the de nition of and f~1 imply: ~ (10) :f~1 (c d 0 z) = :z_ :f(g(rt:i1 rt:i2) m(0 :z)) (10) and (2) imply: ~ (11) :f~1 (c d 0 z) = ntb(m(0 :z))_ :f(g(rt:i1 rt:i2) m(0 :z)) (11) and de nition of f~ imply: ~ ~ (12) :f~1 (c d 0 z) = :f(1&0 0&0 0 z)_ :f(g(rt:i1 rt:i2) m(0 :z)) (4) and (12) imply: ~ (13) :f~1 (c d 0 z) = :f(c d m(0 z)) which ends the proof
Case 2: \no change"

(14) ft:i1 = 0 ^ ft:i2 = 0 (4) and (14) imply: (15) g(i1 i2) = (0&0 0&0)_g(rt:i1 rt:i2) (4) and (15) imply: (16) :f~1 (c d 0 z) = :f~1 ((0&0 0&0)_g(rt:i1 rt:i2) 0 z) (16), the de nition of f~1 and the fact that g applied to an element yields 0&0 or 1&0 imply: (17) :f~1 (c d 0 z) = :f~1 (0&0 0&0 0 z)_ :f~1(g(rt:i1 rt:i2) 0 z) (17) and induction hypothesis imply: ~ (18) :f~1 (c d 0 z) = :f~1 (0&0 0&0 0 z)_ :f(g(rt:i1 rt:i2) m(0 z)) (18) and the de nition of and f~1 imply: ~ (19) :f~1 (c d 0 z) = z_ :f(g(rt:i1 rt:i2) m(0 z)) (19) and (2) imply: ~ (20) :f~1 (c d 0 z) = ntb(m(0 z))_ :f(g(rt:i1 rt:i2) m(0 z)) (20) and de nition of f~ imply: ~ ~ (21) :f~1 (c d 0 z) = :f(0&0 0&0 0 z)_ :f(g(rt:i1 rt:i2) m(0 z)) (4) and (21) imply: ~ (22) :f~1 (c d 0 z) = :f(c d m(0 z)) which ends the proof

16

Case 3: \clear"

(23) ft:i1 6=? ^ft:i2 = 1 (ft:i1 = 0 is taken here ; ft:i1 = 1 is analagous) (4) and (23) imply: (24) g(i1 i2) = (0&0 1&0)_g(rt:i1 rt:i2) (4) and (24) imply: (25) :f~1 (c d 0 z) = :f~1 ((0&0 1&0)_g(rt:i1 rt:i2) 0 z) (25) and the de nition of f~1 imply: (26) :f~1 (c d 0 z) = :f~1 (0&0 1&0 0 z)_ :f~1(g(rt:i1 rt:i2) 0 0) (26) and induction hypothesis imply: ~ (27) :f~1 (c d 0 z) = :f~1 (0&0 1&0 0 z)_ :f(g(rt:i1 rt:i2) m(0 0)) (27) and the de nition of and f~1 imply: ~ (28) :f~1 (c d 0 z) = 0_ :f(g(rt:i1 rt:i2) m(0 0)) (28) and (2) imply: ~ (29) :f~1 (c d 0 z) = ntb(m(0 0))_ :f(g(rt:i1 rt:i2) m(0 0)) (29) and de nition of f~ imply: ~ ~ (30) :f~1 (c d 0 z) = :f(0&0 1&0 0 z)_ :f(g(rt:i1 rt:i2) m(0 0)) (4) and (30) imply: ~ (31) :f~1 (c d 0 z) = :f(c d m(0 z)) which ends the proof (32) ft:i1 =? ^ft:i2 6=? which is trivial because of monotonicity (33) ft:i1 6=? ^ft:i2 =? which is trivial because of monotonicity
Induction hypothesis (Induction on

Case 4: \still waiting for i1 "

Case 5: \still waiting for i2 "

2
n)
n

8g f1

=1 g(i1 i2) = (c d) ) (( :f1 (c d) = o1 ^ :f2(o1 d) = o2 ^ : : : ^ :fn (on;1 d) = on) ) :f(c d) = (o1 : : : on))
j

: : : fn : R:g ^ (

V CTBIT:f ) ) 9f : CNT(n):f ^ 8i1 i2 c d o1 : : : o

n j

17

Inductive case (Induction on

n)

Must be shown that:

8g f1

: : : fn+1 : R:g ^ ( CTBIT:fj ) ) 9f : CNT(n + 1):f ^ 8i1 i2 c d o1 : : : on+1 : j =1 g(i1 i2) = (c d) ) (( :f1(c d) = o1 ^ :f2(o1 d) = o2 ^ : : : ^ :fn+1(on d) = on+1) ) :f(c d) = (o1 : : : on+1 )) To show this we refer to internal functions f~1 : : : f~n+1 and f~ used to de ne f1 : : : fn+1 and f. The proof for the initial values, which are only covered by f1 : : : fn+1 and f, is trivial. The functions f~1 : : : f~n+1 and f~ are based on states. To relate the concrete states in f~1 : : : f~n+1 to the abstract state in f~ we again use the function declared in (1) and (2). Assume: (34) 0 = (0 : : : 0) We then get the following proof-obligation: : : : fn+1 : R:g ^ ( CT BIT:fj ) j =1 ) 9f : CNT(n + 1):f ^ 8i1 i2 c d o1 : : : on+1 z1 : : : zn+1 : (35) g(i1 i2) = (c d) ) (( :f~1 (c d 0 z1 ) = o1 ^ : : : ^ :f~n+1(on d 0 zn+1 ) = on+1 ) ~ ) :f(c d m(0 (z1 : : : zn+1 ))) = (o1 : : : on+1)) To prove (35) we rst of all show that the lemma (36) holds: (36)
n n 8g fn+1 f~ : R:g ^ CTBIT:fn+1 ^ CNT(n):f~ ~ : CNT(n + 1):f~ ^ 8i1 i2 c d o1 : : : on+1 z1 ) 9f g(i1 i2) = (c d) )

+1 V

8g f1

+1 V

: : : zn+1 :

~ :f(c d m(0 (z 1 : : : z n+1 ))) = L :f~n (c d m((0 : : : 0) (z1 : : : z n))) :f~n+1 (on d 0 zn+1 ) The proof of (36) is by induction on the sum of the lengths of i1 and i2 . The base case #i1 + #i2 = 0 follows trivially because of monotonicity. We assume that (35) holds for #i1 + #i2 = n. We want to show that (36) holds for #i1 + #i2 = n + 1. Assume (37) g(i1 i2) = (c d) (38) Z = (z 1 : : : z n+1) There are six cases to consider:
Case 1: \count but not transmitted beyond on " { Z must not be (1 : : : 1 zn+1 )

(39) ft:i1 = 1 ^ ft:i2 = 0 (37) and (39) imply: (40) g(i1 i2) = (1&0 0&0)_g(rt:i1 rt:i2) (37) and (40) imply: ~ ~ (41) :f(c d m(0 Z)) = :f((1&0 0&0)_g(rt:i1 rt:i2) m(0 Z))

18

(41) and de nition of f~ imply: ~ ~ :f(c d m(0 Z)) = :f(1&0 0&0 m(0 Z))_ (42) ~ :f(g(rt:i1 rt:i2) m(0 ntb(btn(Z) + 1))) We assume: (43) ntb(btn(Z) + 1) = (y 1 : : : y n+1) (43) and (42) and Induction hypothesis imply: ~ ~ :f(c d m(0 Z)) = :f(1&0 0&0 m(0 Z))_ L (44) ~n (g(rt:i1 rt:i2) m((0 : : : 0) (y1 : : : yn ))) :f~n+1(g(rt:on rt:i2) 0 zn+1) :f L (44) and de nition of f~ and of imply: L ~ :f(c d m(0 Z)) = (y 1 : : : y n) (z n+1)_ L (45) :f~n (g(rt:i1 rt:i2) m((0 : : : 0) (y1 : : : yn ))) :f~n+1(g(rt:on rt:i2) 0 zn+1) (45) and de nition of m and ntb imply: L ~ :f(c d m(0 Z)) = ntb(m((0 : : : 0) (y1 : : : yL))) (z n+1 )_ n (46) :f~n (g(rt:i1 rt:i2) m((0 : : : 0) (y1 : : : yn ))) :f~n+1(g(rt:on rt:i2) 0 zn+1) (46), (39) and de nition of f~n imply: L ~ :f(c d m(0 Z)) = :f~n (1&0 0&0 m((0 : : : 0) (z1 : : : z n)) (z n+1 )_ L :f~n+1(g(rt:on rt:i2) 0 zn+1) (47) :f~n (g(rt:i1 rt:i2) m((0 : : : 0) (y1 : : : yn ))) L (47), (40) and (37) and the de nition of imply: ~ ~ (48) :f(c d m(0 Z)) = :f(c d m(0 Z)) which ends the proof
Case 2: \count but transmitted beyond on " { Z has to be (1 : : : 1 zn+1 )

(49) ft:i1 = 1 ^ ft:i2 = 0 (37) and (49) imply: (50) g(i1 i2) = (1&0 0&0)_g(rt:i1 rt:i2) (37) and (50) imply: ~ ~ (51) :f(c d m(0 Z)) = :f((1&0 0&0)_g(rt:i1 rt:i2) m(0 Z)) (51) and de nition of f~ imply: ~ ~ :f(c d m(0 Z)) = :f(1&0 0&0 m(0 Z))_ (52) ~ :f(g(rt:i1 rt:i2) m(0 (0 : : : 0 :zn+1 ))) Induction hypothesis implies: ~ ~ :f(c d m(0 Z)) = :f(1&0 0&0 m(0 Z))_ L (53) :f~n (g(rt:i1 rt:i2) m((0 : : : 0) (0 : : : 0))) :f~n+1 (g(rt:on rt:i2) 0 :zn+1)

19

(53) and de nition of f~ and of imply: L ~ :f(c d m(0 Z)) = (0 : : : 0) (:z n+1 )_ L (54) :f~n (g(rt:i1 rt:i2) m((0 : : : 0) (0 : : : 0))) :f~n+1 (g(rt:on rt:i2) 0 :zn+1) (54) and de nition of m and ntb imply: L ~ :f(c d m(0 Z)) = ntb(m((0 : : : 0) (0 : : : L (:z n+1 )_ 0))) (55) :f~n (g(rt:i1 rt:i2) m((0 : : : 0) (0 : : : 0))) :f~n+1 (g(rt:on rt:i2) 0 :zn+1) (55), (49) and de nition of f~n imply: L ~ :f(c d m(0 Z)) = :f~n (1&0 0&0 m((0 : : L0) (1 : : : 1)) (:z n+1)_ : (56) :f~n (g(rt:i1 rt:i2) m((0 : : : 0) (0 : : : 0))) :f~n+1 (g(rt:on rt:i2) 0 :zn+1) L (56), (50) and (37) and the de nition of imply: ~ ~ (57) :f(c d m(0 Z)) = :f(c d m(0 Z)) which ends the proof
Case 3: \no change"

(58) ft:i1 = 0 ^ ft:i2 = 0 (37) and (58) imply: (59) g(i1 i2) = (0&0 0&0)_g(rt:i1 rt:i2) (37) and (59) imply: ~ ~ (60) :f(c d m(0 Z)) = :f((0&0 0&0)_g(rt:i1 rt:i2) m(0 Z)) (60) and de nition of f~ imply: ~ ~ ~ (61) :f(c d m(0 Z)) = :f(0&0 0&0 m(0 Z))_ :f(g(rt:i1 rt:i2) m(0 Z)) Induction hypothesis implies: ~ ~ :f(c d m(0 Z)) = :f(0&0 0&0 m(0 Z))_ L (62) ~ ~n (g(rt:i1 rt:i2) m((0 : : : 0) (z1 : : : z n))) :f n+1 (g(rt:on rt:i2) 0 zn+1 ) :f L (62) and de nition of f~ and of imply: L ~ :f(c d m(0 Z)) = (z 1 : : : zn ) (z n+1 )_ L (63) ~ :f~n (g(rt:i1 rt:i2) m((0 : : : 0) (z1 : : : z n))) :f n+1 (g(rt:on rt:i2) 0 zn+1 ) (63) and de nition of m and ntb imply: L ~ :f(c d m(0 Z)) = ntb(m((0 : : : 0) (z1 : : : zL))) (z n+1)_ n (64) ~ :f~n (g(rt:i1 rt:i2) m((0 : : : 0) (z1 : : : z n))) :f n+1 (g(rt:on rt:i2) 0 zn+1 ) (64), (58) and de nition of f~n imply: L ~ :f(c d m(0 Z)) = :f~n (0&0 0&0 m((0 : : : 0) (z1 : : : z n))) (z n+1 )_ L :f~n+1(g(rt:on rt:i2) 0 zn+1) (65) :f~n (g(rt:i1 rt:i2) m((0 : : : 0) (z1 : : : z n)))

20

(65), (59) and (37) and the de nition of imply: ~ ~ (66) :f(c d m(0 Z)) = :f(c d m(0 Z)) which ends the proof
Case 4: \clear"

2
;

(67) ft:i1 6=? ^ft:i2 = 1 (ft:i1 = 0 is taken here

ft:i1 = 1 is analagous)

(37) and (67) imply: (68) g(i1 i2) = (0&0 1&0)_g(rt:i1 rt:i2) (37) and (68) imply: ~ ~ (69) :f(c d m(0 Z)) = :f((0&0 1&0)_g(rt:i1 rt:i2) m(0 Z)) (69) and de nition of f~ imply: ~ ~ ~ (70) :f(c d m(0 Z)) = :f(0&0 1&0 m(0 Z))_ :f(g(rt:i1 rt:i2) m(0 0)) Induction hypothesis implies: ~ ~ :f(c d m(0 Z)) = :f(0&0 1&0 m(0 Z))_ (71) ~n (g(rt:i1 rt:i2) m((0 : : : 0) (0 : : : 0))) L :f~n+1 (g(rt:on rt:i2) 0 0) :f L (71) and de nition of f~ and of imply: L ~ :f(c d m(0 Z)) = (0 : : : 0) (0)_ L (72) :f~n (g(rt:i1 rt:i2) m((0 : : : 0) (0 : : : 0))) :f~n+1 (g(rt:on rt:i2) 0 0) (72) and de nition of m and ntb imply: L ~ :f(c d m(0 Z)) = ntb(m((0 : : : 0) (0 : : : L (0)_ 0))) (73) :f~n (g(rt:i1 rt:i2) m((0 : : : 0) (0 : : : 0))) :f~n+1 (g(rt:on rt:i2) 0 0) (73), (67) and de nition of f~n imply: L ~ :f(c d m(0 Z)) = :f~n (0&0 1&0 m((0 : : L0) (z1 : : : z n))) (0)_ : (74) :f~n (g(rt:i1 rt:i2) m((0 : : : 0) (0 : : : 0))) :f~n+1 (g(rt:on rt:i2) 0 0) L (74), (68) and (37) and the de nition of imply: ~ ~ (75) :f(c d m(0 Z)) = :f(c d m(0 Z)) which ends the proof (76) ft:i1 =? ^ft:i2 6=? which is trivial because of monotonicity (77) ft:i1 6=? ^ft:i2 =?
Case 6: \still waiting for i2 " Case 5: \still waiting for i1 "

21

which is trivial because of monotonicity Now we want to show (35) based on the lemma (36). We assume (78) g(i1 i2) = (c d) ~ (79) :f~1 (c d 0 z1 ) = o1 ^ : : : ^ :f n+1 (on d 0 zn+1) = on+1 Now we have to proof ~ (80) :f(c d m(0 Z)) = (o1 : : : on+1) (78), (79) and (80) imply: ~ (81) :f(c d m(0 Z)) = ( :f~1(c d 0 z1 ) : : : :f~n+1 (on d 0 zn+1)) L de nition of implies: L ~ ~ :f(c d m(0 Z)) = ( :f~1 (c d 0 z1 ) : : : :f n (on;1 d 0 zn )) (82) :f~n+1(on d 0 zn+1 ) Induction Hypothesis implies: L ~ :f(c d m(0 Z)) = :f~n (c d m((0 : : : 0) (z1 : : : z n))) (83) :f~n+1(on d 0 zn+1 ) which holds because of (36)

22