Systematic Design of Synchronous Digital Circuits - Users

Systematic Design of Synchronous Digital Circuits

Tiberiu Seceleanu

Department of Computer Science Åbo Akademi University

Supervised by Professor Kaisa Sere Department of Computer Science Åbo Akademi University Lemminkäisenkatu 14 A 20520 Turku Finland

Reviewed by Professor Mary Sheeran Department of Computer Science Chalmers University of Technology Göteborg University SE-412 96 Göteborg, Sweden

Associate Professor Axel Jantsch Department of Electronics, Royal Institute of Technology S- 164 40 Kista Sweden

ISBN 951-29-1974-5 ISSN 1239-1883 Painosalama Oy, 2001 Turku, Finland

To my family and in the memory of my father

Acknowledgements It is a pleasure for me to start the presentation of this doctoral thesis by expressing my gratitude to some of those who in uenced most, in a more or less visible manner, my achievements of the last years. This thesis is the result of several years of research under the guidance of my supervisor, Professor Kaisa Sere. I am very grateful for the patience and trust she placed on me. By giving me the freedom to chose the \why" and \when", she often showed me \how". Her professional and moral support, as well as the continuous encouragement allowed me to persevere in my search for improvement. Special thanks I have to direct to my friend and colleague, Juha Plosila. Together, we fought most of the problems described in this study. Even after I collected enough strength to solve them by myself, his advice and experience was still at hand and valuable. Professor Mary Sheeran (Chalmers University of Technology, Sweden) and Professor Axel Jantsch (Royal Institute of Technology, Sweden) kindly accepted to review the thesis. I really appreciate the attention and accuracy that they dedicated to the process, helping me to present now a better and more complete version of the study. I would also like to thank Professor Ralph-Johan Back for his useful remarks on my work and very good recommendations for further improvement. Professor Joakim von Wright also provided help in certain technical problems, for which I am thankful. The excellent working conditions and nancial support oered by Turku Centre for Computer Science, one of the top research institutions in Finland are gratefully acknowledged. I am also thankful for the trust showed by Professor Jouni Isoaho, when oering me a position at the Laboratory of Electronics and Information Technology, where I presently work. My thoughts also go to all my professors at The Electronics Department of Polytechnic University of Bucharest, where I rst learned what study was about. Special thanks to Professor Vasile Lazarescu and Professor Stefan Stancescu, who helped me to nd a way after graduation, too. To my good friends in TUCS and elsewhere, I am thankful for both professional help and good moments of life. i

ii At the end, I would like to thank my family. To my mother, Geta, for her love and devotion, for always showing me the right way to follow, for letting me build my own future. To my dear friend and wife, Cristina, I bring my gratitude for her enthusiasm, her incredible support in re ning the thesis, in nding good answers to a lot of dierent questions. I thank her for being close, generous, for always nding the best in me. This thesis is especially dedicated to them.

Turku, May 5, 2001 Tiberiu Seceleanu

Abstract This thesis presents a formal approach to the eld of digital hardware design. More speci cally, we describe synchronous hardware design. The formal framework, in which we elaborate our design process, helps us transform initial abstract descriptions into more concrete representations that, eventually, are possible to be implemented as actual hardware devices. A synchronous circuit is characterized by having data storage units and processing synchronized to a global signal, called clock. The clock signal synchronizes the operations performed by a device, such that the output signals are updated simultaneously. The initial step in modeling synchronous systems is an analysis of the two-phase operation of the common D ip- op. The clock signal is also modeled, oering the possibility to develop gated clock designs. We present our ideas on synchronous hardware design within the framework of the Action Systems formalism. Action Systems has been successfully applied to the area of asynchronous VLSI design. Thus, we take advantage of the asynchronous design experience and consider the top-level of any system as an (initial) asynchronous system. Following a stepwise procedure, we show that, if certain conditions are met, one can obtain a synchronous representation of the described systems. One of the advantages of this approach is the fact that we can then have mixed (synchronous / asynchronous) architecture design. After reaching a synchronous format for the system under analysis, the design process continues with steps addressing timing issues, interconnections and the actual implementation as a hardware device. At this last step, the designer is oered two options:

custom design - the hardware implementation can be obtained by direct

mapping. Such an implementation is composed of synchronous primitives called basic cells.

translation into VHDL code. The process is translated then into the CAD environment of choice.

As asynchronous circuit design has already been included into the formalism earlier, we have obtained a design framework that allows us to formally derive iii

iv hardware systems that contain both synchronous and asynchronous components. This is strongly re ected by gated-clock designs. The mixed architecture design is an issue not often found in the dierent formal approaches to hardware design. In our framework, we are able to use exactly the same rules for asynchronous or synchronous descriptions. Hence, Action Systems proved to be suitable for our purposes, allowing us to build a powerful uni ed basis for hardware design generally. It oers the possibility to work in a stepwise manner with systems that contain both synchronous and asynchronous components, leading to correctly derived descriptions and implementations.

Contents 1 In troduction 2 Action Systems

2.1 Actions . . . . . . . . . . . . . . . . . . . . 2.1.1 Semantics of actions . . . . . . . . . 2.1.2 Properties of actions . . . . . . . . . 2.2 Action Systems . . . . . . . . . . . . . . . . 2.2.1 P arallel action systems . . . . . . . . 2.2.2 Prioritizing composition . . . . . . . 2.3 Re nement . . . . . . . . . . . . . . . . . . 2.3.1 Re nement of actions . . . . . . . . 2.3.2 Re nement of action systems . . . . 2.4 Development of Action Systems . . . . . . . 2.5 Action Systems in Digital Hardware Design

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

3 Synchronous Action Systems - the Basics

3.1 General Characteristics of Synchronous Devices 3.2 Synchronous Action Systems . . . . . . . . . . 3.2.1 Two-phase actions . . . . . . . . . . . . 3.2.2 Simultaneous composition of actions . . 3.2.3 Synchronous composition of actions . . 3.2.4 Synchronous action systems . . . . . . . 3.3 Modeling the External Clock . . . . . . . . . . 3.4 Conclusions and Related Work . . . . . . . . .

4 Designing Synchronous Action Systems

4.1 Asynchronous vs. Synchronous Systems . . . . 4.2 Asynchronous to Synchronous Transformation . 4.2.1 T ransforming system components . . . . 4.2.2 Generic asynchronous system . . . . . . 4.2.3 Synchronization requirements . . . . . . v

1 7

7 8 9 9 10 12 14 14 17 19 20

23 23 27 27 30 32 37 38 40

45 45 47 48 52 54

vi

CONTENTS 4.3 Synchronizing Action Systems . . . . . . . . . . 4.3.1 Initial asynchronous approach . . . . . . 4.3.2 Synchronous approach . . . . . . . . . . 4.4 An Example: The Trac Lights Controller . . 4.5 Implementation Aspects . . . . . . . . . . . . . 4.6 Pipelining . . . . . . . . . . . . . . . . . . . . . 4.6.1 Timing issues . . . . . . . . . . . . . . . 4.6.2 Non pipelined vs. pipelined systems . . 4.6.3 Local variable introduction . . . . . . . 4.6.4 Elimination of a local variable . . . . . . 4.6.5 Pipelining procedure . . . . . . . . . . . 4.7 Design of Synchronous Action Systems in Brief 4.8 Conclusions and Related Work . . . . . . . . .

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

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

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

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

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

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

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

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

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

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

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

56 56 59 60 64 67 67 69 71 73 73 81 85

5 Mixed-Architecture Design

89

6 VHDL for Synchronous Action Systems

97

5.1 Synchronous Action Systems with Cloc Gated k . . . . . . . . . . . 90 5.2 Implementation Aspects . . . . . . . . . . . . . . . . . . . . . . . . 93 5.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

6.1 Premises . . . . . . . . . . . . . . . . 6.2 Code Characteristics . . . . . . . . . 6.2.1 Architecture . . . . . . . . . 6.2.2 Basic constructs . . . . . . . 6.3 Program Execution . . . . . . . . . . 6.4 Example: a 4-Bit Binary Counter . 6.5 F unctions . . . . . . . . . . . . . . . 6.5.1 F unction de nition . . . . . . 6.5.2 VHDL aspects . . . . . . . . 6.6 Example - The FEAL-8 Algorithm . 6.6.1 The action systems approach 6.6.2 The function f . . . . . . . . 6.6.3 T ranslation into VHDL . . . 6.7 Conclusions . . . . . . . . . . . . . .

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

7 Analysis of a Linear Prediction System 7.1 Linear Prediction . . . . . . . . . . 7.2 Speci cation of the Analyzer . . . 7.2.1 F ormal speci cation . . . . 7.3 System Development . . . . . . . . 7.3.1 The input system . . . . . . 7.3.2 The autocorrelation system

. . . . . .

. . . . . .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

. 98 . 100 . 100 . 101 . 104 . 107 . 111 . 113 . 114 . 115 . 117 . 119 . 121 . 123

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. 129 . 132 . 133 . 134 . 137 . 139

129

CONTENTS 7.3.3 Synchronous representation of Durbin's algorithm 7.3.4 Implementation and optimization issues . . . . . . 7.3.5 Timing issues . . . . . . . . . . . . . . . . . . . . . 7.4 The Controller . . . . . . . . . . . . . . . . . . . . . . . . 7.5 System Level Synchronous Description . . . . . . . . . . . 7.6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . .

8 Conclusions 9 Appendix 9.1 9.2 9.3 9.4 9.5 9.6 9.7 9.8 9.9

vii . . . . . .

Two-Phase Action Re nement . . . . . . . . . . . . . . . . Monotonicity of the Clock Operator . . . . . . . . . . . . . Monotonicity of the Simultaneous Composition . . . . . . . Monotonicity of Synchronous Composition . . . . . . . . . Veri cation of the Extended Operator . . . . . . . . . . . . Re nement of the Asynchronous System Async. . . . . . . Transforming a Sequence into a Simultaneous Composition. The Transformation of Choices. . . . . . . . . . . . . . . . . Composed Systems Analysis. . . . . . . . . . . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. 139 . 147 . 154 . 156 . 158 . 158

161 175

. 175 . 178 . 178 . 179 . 179 . 181 . 182 . 183 . 184

viii

CONTENTS

Chapter 1

Introduction Production technology of electronic devices has improved in huge steps in the last decades, followed immediately by a continuous increase in the complexity of digital systems. This, in its turn, led to digital systems having shorter life cycles and the design tasks becoming more dicult. Safety critical applications (aviation, trac control, nuclear plants, etc) making use of these devices introduced the need for reliable products, at a reasonable price. Systematic, rule-based design is no longer a subject of study only, but a strong requirement in the development of such applications, concerning both software and hardware elements. Formal methods became, thus, an increasingly important step in the design

ow of digital systems. Several studies were carried out in order to adapt various formalisms to the characteristics of hardware design, with remarkably good results. We mention here only few of them, as for instance Lava [22], Tangram [19], Ruby [43], Action Systems [62], Synchronized Transitions [80]. When applying formal methods to hardware design we are interested to ensure that the nal stage of the process corresponds to the initial speci cation (or that it re ects a correct implementation of the initial speci cation). This is usually acquired by two main approaches [48]:

post-design veri cation. The advantage of this approach is that the veri-

cation is separated from the design process. However, this is also characterized by a sensible lack of information sharing with the design process [48]. Model-checking approaches have proven successful in many situations. Initially limited to nite-state systems (no longer an absolute restriction), model-checking is still applicable to systems whose states have short and easy to manipulate descriptions [86]. The reduced generality and the often too large or even in nite number of states to be covered represent the main drawbacks of the method [38, 86].

correctness preserving transformations. Each step of the design is based on 1

2

CHAPTER 1. INTRODUCTION a set of rules which ensure that the eventual representation corresponds to the initial speci cation.

However, none of the methods guarantees that physical defects do not appear at the last steps of the design process. At this level, one uses test benches to nd errors. This study addresses issues of formal synchronous digital design, in the framework of Action Systems formalism. Thus, our approach mainly falls into the second of the above categories (although post design veri cation techniques are possible to be used, too) [14]. Through step-by-step derivations, we correctly transform an initial (abstract) speci cation into a more concrete description. Thus, the nal representation (the lowest level of the design we are taking into consideration) actually implements the intended functionality. Even though in several sections we address issues close to the gate level of the hardware implementation of our systems, the focus is concentrated on higher levels of the design. In this respect, some of the aspects we discuss here have to be detailed in further stages of the design ow.

Synchronous circuits. A synchronous circuit is characterized by having processing and data storage units synchronized to a global signal, called clock [52]. The above is not the singular de nition of a synchronous circuit. Several of them can be found in the literature [55, 64], with only minimal dierences between them. The main aspects we retain are the operation on the global signal, clock a periodic rectangular shaped signal, and the presence of edge-sensitive (referring to the raising and falling slopes of the clock signal) storage devices. Synchronous operation can be viewed as a process composed of two separate phases following each other, repeatedly. At the read phase the storage elements receive new input values computed by the combinational logic of the system. At the write phase, the received input values are locked simultaneously to the outputs of the storage elements. This continuous two-phase process is controlled by the clock signal. A synchronous machine is de ned as a combinational network, with feedback from outputs to input via edge-sensitive devices [55]. Action Systems. The Action Systems formalism initially proposed by Back and Kurki-Suonio [10] and extended in other studies [12, 13, 15, 73] is a framework for speci cation and correctness preserving development of reactive systems. Based on an extended version of the guarded command language of Dijkstra [30], Action Systems is developed in a stepwise manner within the Re nement Calculus. Re nement Calculus was originally introduced by Back [6] as a method for correctly deriving sequential programs. The work was continued by other researchers, too [9, 13, 16]. Data [7, 16] and trace re nement [15] techniques for

3 action systems respond perfectly to our intention to build a design methodology that covers several levels of abstraction while providing rules that guide us through the process of system derivation. We give details on the Action Systems formalism in Chapter 2. The Action Systems framework has been applied in the design of asynchronous systems [58, 59, 60, 62]. By providing it with a set of new operators and taking advantage of the precise rule-based development we are able to propose a methodology of synchronous system design. Hence, the Action Systems formalism oers a powerful unifying basis for hardware design generally. It oers the possibility to work in a stepwise manner with systems that contain both synchronous and asynchronous components, leading to correctly derived descriptions and implementations. This is a feature not usually found in the other formal approaches that we mention here. They mainly address either synchronous or asynchronous design aspects, or, in the case when they also cover both design styles, they provide distinct rules for each of them.

Synchronous action systems. Our intention is to build descriptions that will

model the behavior of synchronous devices and that, at some level, will reduce the gap between a formal (more abstract) representation and its hardware implementation as much as possible. For this, we introduce the concept of two-phase execution, corresponding to the read / write phases of the synchronous operating devices. A synchronous action system is thus a collection of synchronous, twophase actions. Further, the mathematical basis of the Action Systems framework allows us to describe a design ow that can easily be automatically performed, as we are able to formulate precise rules that the designer has to follow when executing certain steps of the process. We consider that the asynchronous representation of a system describes the intended behavior at a higher level than a (functionally) similar synchronous system. Consequently, higher levels of the design will be represented by asynchronously described systems. The synchronous design methodologies have reached a very mature stage compared to asynchronous design methodologies. However, there are no pure synchronous devices, as, in some manner, every circuit has to interact with some environment. This interaction occurs, most usually, through an asynchronous interface [58, 64]. Based on the experience in designing asynchronous systems, as well as on the global asynchronicity idea, one of our goals is to build a design

ow that would allow us to develop both synchronous and asynchronous systems, or having mixed architecture representations (locally synchronous, globally asynchronous). Thus, we would have the advantage to use the same rules for correctly deriving either synchronous or asynchronous systems from a higher-level speci cation. Further, this allows us to delay the decision upon the nal device

4

CHAPTER 1. INTRODUCTION

architecture. The majority of modern digital hardware uses synchronous techniques, although the asynchronous model gains again, more and more attention, especially because of the potential for low-power systems. The basic reason for this is that the design experience base and CAD tool support for synchronous hardware are outstanding. Furthermore, a synchronous circuit seems to be equally fast or somewhat faster, and certainly smaller, than an asynchronous equivalent circuit [37]. The automated CAD tools normally oer, beside a schematic editor, compilers for one (or more) hardware description languages. One of our goals concerns the possibility of correctly translating our descriptions into a tool-supported hardware description language. The reason why we chose this direction in order to complete the hardware design of the synchronous action systems is the high quality of existing CAD tools. The use of such tools, though it improves in many respects the process of hardware design, does not provide a fully formal environment for the mentioned process. Thus, instead of constructing a whole new hardware description and implementation tool, we decided to only complement the ones already in use, towards the completion of the design ow with formal aspects.

Related work. As mentioned earlier, dierent approaches have been studied

towards formal representation of hardware designs. We are mostly interested in those that address issues related to synchronous implementations. As a general aspect, we can specify that, although the \two-phase execution" term can be found in some other studies, too, it does not bear the same meaning as ours. In addition, the representation of a synchronous action system and the way we describe simultaneity of execution (synchronicity) is dierent compared to all the other approaches. During the presentation of our approach, we will later underline in more detail the dierences between our model and the ones we brie y mention in the next paragraphs. Staunstrup's Synchronous transitions [80] is one of the rst sources we analyzed when starting our modeling of synchronous action systems. We will identify some of the common things we share as well as the dierences in-between the two formal approaches. Alur and Henzinger present in Reactive modules [2], perhaps, the closest method to ours, judging by the interpretation of synchronous hardware operating mode. The ESTEREL language [20], developed by the group of Berry at INRIA, synchronizes the operations by means of a Write-Things-Once policy, implemented as await statements [21] (dierent from our description of simultaneity). Jones and Sheeran adopt a functional view in their description of FP. FP

5 presents digital circuits as binary relations between data values [42]. Abstracting from the synchronization issues, one can describe asynchronous, synchronous or mixed circuits [41]. The synchronous implementations are identi ed by means of the non-combinational primitive D (a latch). T-Ruby [77] is a formalism quite similar to FP. We will refer to it in connection with aspects concerning the translation of formal descriptions into tool-supported hardware description languages. The above-mentioned approaches to digital hardware design have in common the lack of timing issues in their syntax (and so does ours). However, several programming languages also include timing aspects. For instance, in the LUSTRE approach used by Halbwachs et al. [36], the ow is a construct including a time sequence (even though not necessarily connected to physical time notions). Another timed model is represented within the Concurrent Constraint Programming frame [23]. Even though the idea is also based on a two-phase execution, it refers to the combinational computation and the actual update of the registered outputs.

Overview of the thesis. The thesis is built on previous studies that appeared

in conference proceedings and journals. In this presentation we provide more profound details on the distinct phases of the synchronous design using Action Systems, as well as new information that is not available in previously printed material. Next, we show the list of papers describing the initial steps in studying the synchronous action systems. The papers are listed in the order of publication:

J. Plosila, T. Seceleanu. Synchronous Action Systems. TUCS Technical Report No 192, 1998.

J. Plosila, T. Seceleanu. Synchronous Design Aspects Using Action Systems. Romanian Journal of Information and Technology, Volume 1, No. 4, pages 353-391, 1998, The Publishing House of the Romanian Academy.

J. Plosila, T. Seceleanu. Design of Synchronous Action Systems. Proceed-

ings of The 12th International Conference on VLSI Design, Goa, India, January 1999.

T. Seceleanu. VHDL for Synchronous Action Systems. Proceedings of The International HDL Conference and Exhibition, Santa Clara-CA, pages 119128, April 1999.

T. Seceleanu, J. Plosila. Synchronization of Action Systems. In Proc. of the

International Symposium on Signals, Circuits & Systems - SCS'99, pages 135-138, Iasi, Romania, July 1999.

6

CHAPTER 1. INTRODUCTION

J. Plosila and T. Seceleanu. Modeling Synchronous Action Systems. Pro-

ceedings of the 17th NORCHIP Conference, Oslo, Norway, November 1999, pages 242-248. T. Seceleanu, J. Plosila. Formal Representation of Gated Clock Designs. In Proceedings of The 13th Annual IEEE International ASIC / SOC Conference Systems-On-Chip in the Internet Age, Washington DC, USA, September 2000, pages 352-356. T. Seceleanu, J. Plosila. Formal Pipeline Design. To appear in Proceedings of the 11th Advanced Research Working Conference on Correct Hardware Design and Veri cation Methods, Livingston, Scotland, September 2001. The content of the thesis is organized as follows. In Chapter 2 we present the Action Systems formalism, concentrating on the aspects which we will use in the next chapters. This is followed by the introduction of the basics of the synchronous modeling in Action Systems, in Chapter 3. We present the theoretical aspects of the approach by de ning operators that help us address synchronous design. Chapter 4 describes the initial steps in the design of synchronous action systems, starting from an asynchronous representation. We also provide custom hardware representation of our constructs. Chapter 5 refers to formal aspects as well as to practical ones in connection with the locally synchronous, globally asynchronous idea. The design ow is continued in the next chapter by aspects related to the translation of action systems descriptions into VHDL code. A more complex example is analyzed in Chapter 7. Basically, it is a synchronous analysis of a previous study on an asynchronous linear prediction device [61]. We end with some concluding remarks and general views on future work in Chapter 8. We end the Chapters 3 to 7 with short remarks on the content of the speci c chapter. Throughout the thesis, when considered necessary, we illustrate our statements with appropriate exempli cations. The whole Chapter 7 is actually built on a larger example. For most of the statements regarding re nement steps, we provide the proofs in the Appendix.

Chapter 2

Action Systems Action Systems [10, 12] is a state based formalism. It is derived from the guarded command language of Dijkstra [30] and de ned using weakest precondition predicate transformers. The Action Systems framework is used as a speci cation language and for the correct development of reactive systems. An (atomic) action, or guarded command, is the basic building block in the formalism. An action system is an iterative composition of actions with distinct local and global variables. In this chapter, we revise the basics of the Action Systems formalism. This, however, re ects only aspects that we will need later in describing our approach to the synchronous action systems model. The connection with digital systems is also brie y described at the end of the chapter.

2.1 Actions An action A is de ned by

A ::= abort

j j j j j j j

skip x := x0 :R x := e A1 [] : : : [] Am A1 ; : : : ; Am j[ var x := x0; A ]j

(abortion, non-termination) (empty statement) (non-deterministic assignment) ((multiple) assignment) (non-deterministic choice) (sequential composition) (block with local variables) (guarded action)

p!A where A and Aj ; j = 1; : : : ; m are actions, p and R predicates (boolean conditions), x a variable or a list of variables, x0 some value(s) of the variable(s) x, and e an expression or a list of expressions. The scope of operators is indicated 7

8

CHAPTER 2. ACTION SYSTEMS

with parenthesis. F or example (A; : : : ; D are actions as de ned above): A; ((B ; C ) [] D)

Notations. If a multiple assignment assigns the same value, say X , to several

variables x1 ; : : : ; xn , we often use the shorthand notation: x1 ; : : : ; xn := X The variables which are assigned within the action A are called the write-variables (write set) of A, denoted wA [12]. The other variables present in the action A are called the read-variables (read set) of A, denoted rA. The write- and readvariables form together the access set vA of A: vA =b wA [ rA A substitution operation within an action A is denoted by A[enew =eold ] where eold refers to an element (variable, predicate, component action etc.) of the original action A, and enew denotes the new element which replaces eold in A. The same notation is applied to an action system A (section 2.2) as well.

2.1.1 Semantics of actions

An action A is considered atomic, that is, only its input-output behavior is of interest. This indicates that only the initial and nal state of an action can be observed. The total correctness of an action A with respect to a precondition P and a postcondition Q is denoted P A Q and de ned by P A Q =b P ) wp(A; Q) where wp(A; Q) stands for the weakest precondition [30] of action A to establish the postcondition Q. We de ne: wp(abort ; Q) =b false wp(skip ; Q) =b Q wp(x := x0 :R; Q) =b 8x0 :R ) Q[x0 =x] wp(x := e; Q) =b Q[e=x] wp(A1 [] : : : [] Am ; Q) =b wp(A1 ; Q) ^ : : : ^ wp(Am ; Q) wp(A1 ; : : : ; Am ; Q) =b wp(A1 ; wp((A2 ; : : : ; Am ); Q)) wp(j[ var x; A ]j; Q) =b 8x:wp(A; Q) wp(p ! A; Q) =b p ) wp(B; Q)

2.2. ACTION SYSTEMS

9

In the case of a guarded action A =b p ! B we have that

gA = p ^ gB An action A is said to be enabled in some state, if its guard is true in that state. Otherwise A is disabled. Observe that any action A can be written in the form true ! A

and thus, each action can be considered a guarded action, even though a nontrivial guard does not exist. If gA is invariantly true, the action is always enabled. Furthermore, if wp(A; true) = true holds, the action A is said to be always terminating. The body sA of the action

A is de ned by

sA =b A [] :gA ! abort

2.1.2 Properties of actions

The way in which two actions A and B interact is captured by the following de nitions: A cannot enable B =b :gB ) wp(A; :gB ) A enables B =b :gB ) wp(A; gB ) A cannot disable B =b gB ) wp(A; gB ) A disables B =b gB ) wp(A; :gB ) An action A is called a stuttering action in some state, if it is enabled in that state, but does not change the state. Otherwise, if A is enabled in some state and causes a state transition, it is called a change action in that state.

2.2 Action Systems

An action system A is a collection of actions sharing a common set of local and global variables. For representing an action system we use the syntax sys A (g) :: j[ var l; init g; l := g0; l0;

do A od

]j where g, and l are lists of identi ers (state variables) initialized to g0 and l0, respectively. The identi ers l are the local variables visible only within A. The identi ers g, in turn, are the global variables of A visible to other action systems

10


as well. The list g is also known as the interface list, and the items of the list as the ports of the action system A. The local and global variables are assumed to be distinct. The identi er A within the loop denotes any of the atomic actions de ned in the section 2.1. The action of A is allowed to refer to all of the state variables consisting of the local and global variables. Each variable is associated with a data type such as bool, int, natural, or real. In case g is an empty list, that is, if there are no global variables, A is a closed action system. If global variables exist, it is an open action system. Notice that in the above description of A, the action A is not necessarily an atomic construct. Actually, action A is a composition of any of the actions described in the previous section. In general, we denote the sets of the local and global variables of an action system A by lvA and gvA, respectively. The set of the state variables of A, denoted vA, is then de ned by

vA =b lvA [ gvA Also, we extend the de nition of the read and write sets of variables from actions to action systems. Thus, the set of variables that are modi ed by an action system A, the write set, is denoted as wA, and the set of variables accessed, but not modi ed by A, is denoted as rA. The action system A above operates as follows. After the initialization g; l := g0; l0 the action A is repeatedly selected for execution as long as it remains enabled. When A becomes disabled, the computation terminates. In the following chapters, we use action systems as formal representations of digital circuits. Thus, we take advantage of the mathematical background supporting the development of Action Systems in order to obtain correctly derived nal versions of our circuits.

2.2.1 Parallel action systems

We model parallel behavior with the Action Systems formalism by a non-deterministic choice in which some component actions can be interleaved or selected for execution in any order. This is the case, if these component actions can be enabled simultaneously, and if they do not have any read-write con icts, that is, an action does not read variables onto which another action writes. At the system level, we proceed as follows. Consider two action systems A and B sys A (gA ) :: j[ var lA; init gA; lA := g0A ; l0A ; ]j

do A od

2.2. ACTION SYSTEMS

11

sys B (gB ) :: j[ var lB ; init gB ; lB := g0B ; l0B ; do B od ]j where lA \ lB = ;. Furthermore, we require that the initializations of the global variables gA \ gB in the systems A and B are consistent with each other, so that 8v 2 gA \ gB : (v0A = v0B ) holds. Here v0A 2 g0A and v0B 2 g0B . The parallel composition of A and B, denoted A k B, is the following action system: sys C (gA [ gB ) :: j[ var lA [ lB ; init gA [ gB ; lA [ lB := g0A [ g0B ; l0A [ l0B ; do A [] B od ]j Thus, parallel composition combines the state spaces of the constituent action systems keeping the local variables lA and lB distinct. The reactive components A and B interact with each other via the global variables that are referenced in both components. Reactivity means that A and B do not terminate independently of each other, but termination is a global property of the composed action system C. Obtaining sub-circuit descriptions (modules) is an important aspect of circuit design. This can be achieved by inversely using the parallel composition operator to decompose a large action system, C ; into a parallel composition of several smaller and more dedicated systems, A and B:

C=AkB

Hiding and revealing variables. Consider the above parallel composition A k B. If some of the variables gA [ gB are exclusively accessed by the two component systems, we can hide them from the outside world. In the notation

j[ var v; A k B ]j : g we have g gA [ gB , v = (vA[ vB) n g, and the meaning is that the variables v are made local to the composition A k B, while the other variables g are considered

visible. The opposite operation, revealing, is also useful in certain cases. Then we have that g = gA [ gB [ g0 , where g0 lA [ lB , and v = (lA [ lB ) n g0 , with the same notation j[ var v; A k B ]j : g

12

CHAPTER 2. ACTION SYSTEMS The nested construct is de ned as follows:

j[ j[ A k B ]j : g1 ]j : g2 =b j[ A k B ]j : g2 In other words, the outmost speci cation overrides the inner ones. Note that the hiding or revealing operation can be applied to a single action system as well: j[ var v; A ]j : g

Closure. Consider still the above parallel composition A k B. Assume that the interface lists gA and gB are identical, or

g = gA = gB Furthermore, assume that the global variables g are exclusively used by the two component systems. Then we say that the system

j[ A k B ]j =b j[ var g; A k B ]j is the closure of A, denoted C ls[A], and that B is the environment of A, or vice versa. If A is a closed action system, it is the closure of itself: C ls[A] = A In general, the environment of A is an arbitrarily complex system composed of several parallel action systems:

B = j[ B1 k : : : k Bn ]j : g Thus, the behavior of a circuit and its environment is modeled, at an abstract or concrete level, by a closed non-terminating action system (there is always an enabled action of the system) sys A () :: j[ var l; init l := l0; do A1 [] : : : [] Am od ]j

2.2.2 Prioritizing composition

An extension of the parallel composition described above is the prioritizing composition introduced by Sekerinski and Sere [73]. It speci es a higher priority in execution of a particular system(s) over other system(s). We will take advantage of some of the properties of the composition when discussing issues related to the design and implementation of synchronous action systems (Chapter 4).

2.2. ACTION SYSTEMS

13

The prioritizing composition is initially de ned for actions, as:

A == B =b A [] :gA ! B This means that if both actions A and B are enabled, A is executed, B being executed only when gA = false (and, of course, id B is still enabled). We mention here only some of the properties of the above-de ned operator (for proofs we refer to [73]). Thus, The prioritizing composition of two actions is enabled if either operand is:

g(A == B ) = gA _ gB

The prioritizing composition is associative: (A == B ) == C = A == (B == C )

The prioritizing composition distributes over choice to the right: A == (B [] C ) = (A == B ) [] (A == C ) The prioritizing composition of action systems is de ned in similar terms to the parallel composition. Thus, considering the systems A and B (section 2.2.1), their prioritizing composition is given as

A == B =b C ; sys C (gA [ gB ) :: j[ var lA [ lB ; init gA [ gB ; lA [ lB := g0A [ g0B ; l0A [ l0B ; do A == B od ]j Obviously, based on the properties of the composition with respect to actions, we also have that the prioritizing composition of action systems is associative. Moreover, let G be an action system without local variables,

sys G = j[ do G od ]j Then we have that prioritizing composition with an action system without local variables distributes over parallel composition to the right:

G == (A k B) = (G == A) k (G == B) (Notice that, if the system G would have local variables, they would be duplicated in the right side of the above relation, and thus, the above relation would not hold.)

14


2.3 Re nement Action systems are intended to be developed in a stepwise manner within the re nement calculus framework [6]. Basically, we start our descriptions at a high abstract level and, following speci c rules, more concrete aspects are introduced until we nally reach the desired level of representation. Thus, the system transformations performed at each step are guaranteed to be correct. In this chapter, we revise brie y the basic concepts of the re nement calculus and derivation of action systems. We only present issues that will help us build, in the following chapters, our formal model of synchronous design. Comprehensive studies on the re nement calculus can be found elsewhere [7, 16].

2.3.1 Re nement of actions

An action A is said to be (correctly) re ned by an action C , denoted A C , if

8Q:(wp(A; Q) ) wp(C; Q)) holds. This is equivalent to the condition

8P; Q:((P A Q) ) (P C Q)) which means that the concrete action C preserves every total correctness property of the abstract action A.

Data re nement. Assume that A is an action on the program variables a and

u, and C on the variables c and u, respectively. Let R(a; c) be a boolean relation between the variables a and c. Then the abstract action A is data re ned by the concrete action C using the abstraction relation R(a; c), denoted A R C , if

8Q:(R ^ wp(A; Q) ) wp(C; 9a:R ^ Q)) holds. Note that Q is a predicate on the variables a, u, and (9a:R ^ Q) is a predicate on the program variables c and u. The above de nition of data re nement can be written in terms of the guards gA, gC and bodies sA, sC of the actions A and C as follows: (i) Guard : R ^ gC ) gA (ii) Body : 8Q:(R ^ gC ^ wp(sA; Q) ) wp(sC; 9a:R ^ Q)) The data re nement A R C replaces the variable a with the variable c preserving the variables u. Naturally, if we do not replace any variables but maybe just add some new ones, we have that R true, and hence the relation R can be omitted from the re nement proof. We then prove re nement by showing that

2.3. REFINEMENT

15

(i) Guard : gC ) gA (ii) Body : 8Q:(gC ^ wp(sA; Q) ) wp(sC; Q)) Further, assume that the concrete action C also preserves some invariant I (c; u) on the variables c and u (as it will be the case when we prove the transformation into two-phase format in section 3.2.1, for example). A predicate I is an invariant over an action C , if

I ) wp(C; I ) holds. Then, in the above relations one should also consider I , besides R: (i) Guard : R ^ I ^ gC ) gA (ii) Body : 8Q:(R ^ I ^ gC ^ wp(sA; Q) ) wp(sC; 9a:R ^ I ^ Q)) Example 1 Consider an action that describes a cyclic two-bit counter. If a is the variable that represents the value of the counter, this means that our device starts counting when a = 0 up to a = 3, and then a = 0 again. Initially we represent a as an integer variable ranging from 0 to 3, and the action updating the counter as A =b a := (a + 1) mod 4 Going at a lower level of description, we would represent a as a two-bit variable. In order to reach this level, we perform a data re nement on the action A, replacing the variable a with the pair of variables b0 and b1 . We take into consideration the following abstraction relation:

R(a; b0 ; b1 ) =b (a =

1 X j =0

bj 2j )

The resulting action is:

A0 =b b0 ; b1 := :b0 ; b1 b0 ; where we consider b0 ; b1 2 f0; 1g: Also,

:b0 =b

(

0; b0 = 1; and b b =b 0 1 1; b0 = 0

(

0; b0 = b1 ; 1; b0 6= b1

In order to prove the data re nement A R A0 we proceed as follows: 1: Guards. The guards of both actions evaluate to true.

16


2: Bodies. We have to prove, for any predicate Q that does not contain free occurrences of b0 ; b1 , the relation

R ^ wp(A; Q) ) wp(A0 ; 9a:R ^ Q)

(2.1)

We consider known (easy to prove) that:

a=

1 X j =0

bj 2j ) (a + 1) mod 4 = :b0 + (b0 b1 ) 2

(2.2)

Then we prove the relation 2.1:

R ^ wp(A; Q)

, f de nition of wpg (a = b0 + b1 2) ^ Q[(a + 1) mod 4=a] ) f relation 2:2g ((a + 1) mod 4 = :b0 + (b0 b1 ) 2) ^ Q[(a + 1) mod 4=a] , f substitutions g ((a = :b0 + (b0 b1 ) 2) ^ Q)[(a + 1) mod 4=a] ) f introduction of the existential quanti erg 9a:((a = :b0 + (b0 b1) 2) ^ Q) , f substitution, b0 ; b1 do not appear free in Qg 9a:(a = :b0 + (b0 b1 ) 2) ^ Q)[:b0=b0 ; (b0 b1) 2=b1 ] , f de nition of wpg wp(A0 ; 9a:R ^ Q) An extension of this example (without the re nement proof) is presented in section 6.4.

Commutativity. Commutativity is another important property of actions. Assume that some action A is selected for execution prior to another action B . If the order of execution can be reversed without aecting the result, we say that A commutes (right) with B , denoted A * ) B . This is the case, if (1) A cannot disable B , (2) B cannot enable A, and (3) the computation (sA; sB ) can be changed to (sB ; sA), without aecting the result, in any state where A and B are both enabled. By using the re nement concept, we de ne: A* ) B =b (A; B ) (B ; A)

2.3. REFINEMENT

17

In other words, A * ) B means that the sequential composition A; B can be re ned (`') into the sequential composition B ; A. We will see later (Chapter 4) that in this situation we can actually simultaneously execute the actions A and B.

2.3.2 Re nement of action systems

A trace is de ned as being a sequence of global states (observable behavior). Similar consequent states are called stuttering states and are considered as a single one. The idea behind re ning an open action system within some environment is to preserve the traces of the system in question. Therefore, such a transformation is often referred to as a trace re nement of the system. A fundamental study on trace re nement can be found elsewhere [15]. Rather than going into the details of the trace re nement theory, we revise here a commonly used method to prove a trace re nement between two systems by means of data re nement. Consider action systems sys A (u) :: j[ var a; init a; u := a0 ; u0 ; do A od ]j

sys C (u) :: j[ var c; init c; u := c0 ; u0; do C [] X od ]j where A, C , and X are any of the actions de ned in section 2.1. Lemma 1 Let R(a; c) be a relation between the local variables a and c, and I (c; u)

an invariant of the system C . The abstract system A is (trace) re ned by the concrete system C , denoted A v C , if there exists an abstraction relation R(a; c) such that: (i) Initialization: R(a0 ; c0 ) = true (ii) Main action: A R C (iii) Auxiliary action: skip R X (iv) Continuation condition: R ^ gA ) gC _ gX (v) Internal convergence: R ) wp(do X od; true)

( End of Lemma ). The rst condition of Lemma 1 says that the initializations of the systems A and C establish the abstraction relation R. The second condition requires the abstract action A to be data re ned by the concrete action C using R. The third condition, in turn, indicates that the auxiliary action X is obtained by data re ning a skip action. This means that X behaves like a skip action with respect to the global variables u which are not allowed to be changed in the re nement.

18


The fourth condition requires that whenever the action A of the abstract system A is enabled, assuming the abstraction relation R holds, there must be an enabled action in the concrete system C as well. Finally, the fth condition states that if R holds, the execution of the auxiliary action X , taken separately, must terminate at some point. Observe that, in the situation when we do not add any auxiliary actions, as the re nement is only a result of a rewriting the existing actions, targeting an optimization of the execution, we do not have to check the requirements (iii) to (v).

Invariants. A predicate I is an invariant of some action system A, if it is 1. established by the initialization: wp(g; l := g0; l0; I ); 2. preserved by the action A:

I ) wp(A; I ) Either providing a non-trivial abstraction relation R, or not, in the following chapters we make very much use of the above lemma when proving re nement steps related to transformations of the action systems. The important thing is the preservation of the sequence of the observable states. This helps us in deriving synchronous action systems from asynchronous ones, or synchronizing several mutually asynchronous sub-systems. In addition, sometimes we will take advantage of certain invariants that ease the task of proving a correct transformation. Example 2 Consider the action system

sys A (u) :: j[ var a : f0; : : : ; 3g; init a; u := 0; u0 ; do A1 [] : : : [] An od ]j Assume that the action A1 , for instance, is the same as the action A in EXAMPLE 1. It updates the counter variable a. As presented in EXAMPLE 1, we can re ne A R A0 , where we use the same abstraction relation:

R(a; b0 ; b1 ) =b (a =

1 X j =0

bj 2j )

2.4. DEVELOPMENT OF ACTION SYSTEMS

19

Consequently, in this example we have:

A1 =b a := (a + 1) mod 4; A01 =b b0 ; b1 := :b0; b1 b0 ; A1 R A01 We want to prove the re nement A v A0 , where sys A0 (u) :: j[ var b0; b1 ; init b0; b1 ; u := 0; 0; u0 ; do A01 [] : : : [] An od ]j For this, we check the requirements of the Lemma 1. It is clear that the abstraction relation R is established by the initializations in the system A0 . The re nement A1 R A01 was proven in EXAMPLE 1. As we add no auxiliary actions, the next three requirements trivially hold. Thus, we have A v A0. (In the situation where the variable a also appears in other actions of the system A0 , these actions must be analyzed in the re nement process, too.)

2.4 Development of Action Systems Stepwise derivation of action systems is based on the following properties of the (trace) re nement operator ` v':

Re exivity: A system is re ned by itself: AvA Equivalence: If then we write A = B:

A v B ^ B v A;

Monotonicity: A re nement of a component system implies a re nement of the whole composition [16]:

(A1 v C1 ) ) ((A1 : : : An) v (C1 A2 : : : An )) (the `' stays for either the parallel `k' or the prioritizing ` == ' operator). Monotonicity holds if the component systems Ai , where i = 2::n, do not violate the abstraction relation used in the re nement of A1 .

20


Transitivity: A system obtained by successive re nement steps is a re nement of the initial system: (A v C1 v : : : v Cn ) ) (A v Cn )

The monotonicity and the transitivity properties of the re nement operator `v' are, generally, very important in system design (and speci cally in digital circuit design, as it is in our case). Thus, as the parallel or prioritized composition operators help us decompose systems into sub-systems, the above properties oer the designer the possibility to concentrate on sub-systems, sub-processes, etc. The dierent transformations (re nement steps) will thus be correctly re ected in the whole composition as well.

2.5 Action Systems in Digital Hardware Design We brie y present here some simple associations that help us map the elements of formal descriptions to physical or conceptual elements of digital circuits. We illustrate the basic mapping of elements in Figure 2.1, from a general point of view. Synchronous design speci c issues are addressed in Chapter 3. Sys A ( global variablesA )::

action AA

|[ VAR: local variables; INIT...........; Do AA [] BA ; CA * DA Od ]| global variables (A and B)

A

BA the system A

in / out

Sys B ( global variablesB ):: |[ VAR: local variables; INIT...........; Do AB ; BB ; CB Od ]|

AA

in / out

AB

in / out

B

BB

C = A || B a local variable of B

Action systems description

Hardware implementation

Figure 2.1: Action Systems in digital hardware design. Thus, the action system situated at the highest level in the hierarchy of the formal representation, C (C = A k B), has as a counterpart, in the physical realization, the whole digital device, such as a microprocessor, a controller, an application speci c integrated circuit, or a combination of such devices. Descending in the hierarchy, the top-level system can be split into several subsystems (in

2.5. ACTION SYSTEMS IN DIGITAL HARDWARE DESIGN

21

our case, only the subsystems A and B). In the end, these may exist either on the same VLSI chip, as in Figure 2.1, or as physically distinctive entities. Actions map to smaller sub-circuits. All of them perform operations on dierent sets of data, in parallel; hence, the subsystems are part of a parallel composition in the formal description. In general, the systems may be compared with the entities of VHDL, or the modules of VERILOG or ESTEREL (a more detailed comparison with the VHDL language is presented in Chapter 6). The parameters of an action system represent the input / output connections of its hardware implementation. In a natural manner, the variables represent physical lines one nds on the electronic circuit. Quite often, we will also refer to the variables of an action system as signals. Their classi cation as local or global variables is relative, depending on the partitioning in subsystems. While all the variables have a corresponding set of electrical signals at the hardware implementation level, it is not necessary that all the wires be assigned to a variable in the formal description of the system. The actions of a speci c action system represent operations on data, describing the behavior of the circuit. The actions map at the hardware level on the combinational blocks that compose a device. The higher or lower level of representation may also be decided based on the complexity of the actions in a particular action system. This is usually re ected by the dimensions of the resulting circuitry or by the time required to perform, that is, by the period necessary for updating the output signals, in the synchronous approach.

22


Chapter 3

Synchronous Action Systems the Basics We introduce in this chapter the theoretical aspects of synchronous action systems. The reader can nd in the literature similar approaches towards the formal description of synchronous hardware, some of which we have already mentioned earlier. However, there are characteristics that distinguish our representation of synchronous devices. They will be identi ed and brie y analyzed when necessary. We illustrate some characteristics of synchronous actions and action systems through several examples. Even though these do not re ect complex situations, we think that they help creating a more precise image of the new issues. One of our goals is to develop the synchronous approach inside the Action Systems framework. This means that we intend to use the same rules that apply to the previously developed asynchronous design to synchronous representations, as well. This is not an easy task, as the synchronous systems, by their nature, have features and behavior that may never appear in asynchronous descriptions. More on the dierences between synchronous and asynchronous implementations are analyzed in Chapter 4.

3.1 General Characteristics of Synchronous Devices We start our modeling of synchronous devices by studying two basic aspects of synchronous design: the presence of the clock signal and the storage devices. In the following, we brie y present some general issues concerning these subjects.

Introductory aspects. The primary building block of a digital circuit (wheth-

er synchronous or not) is the logical gate. A gate is a device that implements in hardware a certain logical function (starting with the simple ones such as NOT, AND, OR functions and continuing with more complex relations - Figure 3.1). 23

24

CHAPTER 3. SYNCHRONOUS ACTION SYSTEMS - THE BASICS

At the next higher level in the hierarchy, we think of a synchronous digital circuit as a network of storage devices connected via combinational blocks (clusters of gates implementing a diversity of functions) - CB - and activated by the same clock signal (Figure 3.2).

f = (a AND b) OR (c AND d)

a b

f

f = a AND b

a b

f

f = a OR b

a

f

f = NOT a

a b f c d

Figure 3.1: Gate implementations of logical functions. As a counterpart, we build our basic notions of formally representing (synchronous) circuits around a speci c kind of action, the non-deterministic assignment. At the beginning, we present the non-deterministic assignment in a more general manner as a guarded action, while later we will consider always-enabled actions.

D

Q

CB

Clock generator

Output

Input

D

Q

CB

CB

D

Q

Figure 3.2: A generic digital synchronous circuit. In Figure 3.2, the combinational blocks de ne the value that will be stored

3.1. GENERAL CHARACTERISTICS OF SYNCHRONOUS DEVICES

25

by the corresponding storage element. It comes then, intuitively, to represent the pairs CB - storage element of Figure 3.2 as non-deterministic assignment actions like A =b v := v0 :Q, where v is the output variable of the storage element and the predicate Q is implemented by the combinational block at the input of the corresponding storage element. The variable v is not necessarily a one-bit variable - which would be implemented as a single electronic wire. Instead, v may be a collection of (one-bit) variables, re ected, consequently, in the structure of the storage element. In this situation, A is a multiple non-deterministic assignment. Further, we say that the predicate Q describes the update performed on the variable v. Observe that Q has to provide enough information so that the update of v is covered in all the possible input states. An illustration of such a predicate is for instance,

A =b out := out0 :Q; Q =b (sel ) out0 = a) ^ (:sel ) out0 = b) The above action represents a two input multiplexer: the output variable out is updated based on the value of the input variable sel to either a or b (their values are not important in this case). Thus, the predicate Q covers the update in either state dependent on the values of a; b; sel: Definition 1 We call a non-deterministic assignment v := v0 :Q a hardware

implementable assignment (an HI - assignment), if it is an always enabled action and the predicate Q provides enough information so that the update of v is covered in all the possible input states. The predicate of an HI - assignment is correspondingly called an HI - relation.

A collection of HI - assignments composes an action system representing a digital circuit. Observe that, while the updates of an HI - assignment are always described by an HI - relation, the latter is not necessary to be part of an HI - assignment: the action A = b ! v := v0 :Q is not an HI - assignment, as it is not always enabled. However, the predicate Q might be an HI - relation. Definition 2 We denote a guarded non-deterministic assignment of the form

A = b ! v := v0 :Q, where Q is an HI - relation, a guarded HI - assignment (a GHI - assignment).

The clock signal. The operation of a synchronous device is based on storage

elements sensitive to the rising or falling edge of a common timing signal called the clock. If the clock stops switching, the system preserves its current state as long as it is powered. Synchronous operation can be viewed as a process composed of two separate phases following each other, repeatedly. At the read phase the storage

26


elements receive new input values computed by the combinational logic of the system. At the write phase the received input values are locked simultaneously to the outputs of the storage elements. This continuous two-phase process is controlled by the clock signal. Assuming that the system uses a rising transition of the clock as an active edge, the read phase is executed whenever the clock has the value false, and the write phase whenever the clock has the value true. Observe, however, that the combinational logic starts to compute the next input values for the storage devices immediately after an active clock edge has changed and has locked the outputs. As Action Systems formalism is a state-based approach, we will model the clock signal by an auxiliary variable. The status of this variable determines the execution of the read or write-parts of one or more synchronous actions.

The D ip- op. The edge-sensitive device that we consider in the rest of the study is the D ip- op. We show in Figure 3.3 an implementation of a ip- op (one of the many that can be found in dierent sources). It is also the starting point for our modeling of synchronous actions and, further, of synchronous action systems. The main characteristic that we consider is the master / slave construction. The intermediate signal M is owned by one ip- op only and it is invisible from other points in the design. The value of M is computed at the read phase and passed at the output of the device as soon as the write phase is established. The output Q does not change its value until the next write phase is reached. The two-phase actions that we introduce later in this chapter model the exact behavior of the D ip- op. D

M

clk

Master

Figure 3.3: The D ip- op.

Q

Slave

3.2. SYNCHRONOUS ACTION SYSTEMS

27

3.2 Synchronous Action Systems In this section, we introduce the basic theoretical concepts for modeling synchronous circuits within the action systems framework. We introduce a set of new operators into the formalism. They are based on pre-existent ones and help us build the synchronous representations. The fundamental idea is to divide the execution of an atomic action into two separate parts corresponding to the read and write phases of the two-phase behavior. This will also be re ected at the syntactic level. Re nement related proofs implied by statements in this section are given in the Appendix.

3.2.1 Two-phase actions

Let A be the action b ! v := v0 :Q, where the value assigned to the variable v is consistent with the predicate Q, an HI - relation. Thus, we have then that gA = b. The guard b is not necessarily a single boolean variable, but can as well be the boolean result of a more complex relation. In order to explicitly model two-phase behavior, we proceed as follows (with the proofs detailed in Appendix 9.1). Consider the non-terminating (but not necessarily closed) action system sys A (g) :: j[ do A [] AC od ]j; AC =b :b ! skip where v 2 g. The main idea concerning the introduction of the complementary action AC is that it allows us to completely specify the updates performed on v in some given state. Later we will see that this helps in obtaining an HI assignment from the composition A [] AC . However, it is not necessary for the complementary action to have the above particular description, which represents a stuttering action. AC may also be a change action, such as: AC =b :b ! v := v0:R In the following derivations, we assume that the complementary action is given as AC = :b ! skip (we consider that this speci cation is most commonly met in the design process). Thus, AC preserves the old value of v, and we re ne A v A0 , where A0 =b A[A0=(A [] AC )]; A0 =b v := v0:Q0 ; (3.1) 0 0 Q =b (b ) Q) ^ (:b ) v = v) The above trace re nement is based on the relation (A [] AC ) A0

28


Next we introduce an intermediate variable u, which is of the same type as v, and re ne A0 v A00 , where

sys A00 (g) :: j[ var u; init u := v; do A00 od ]j; A00 =b u := u0 :Q0[u0 =v0 ]; v := u for which the re nement A0 A00 holds.

We continue the derivation by splitting the action A00 into two separate atomic entities by introducing an auxiliary boolean variable p and re ning A00 v A000 , with sys A000 (g) :: j[ var u; p : bool; init u := v; p := false=true; do :p ! RA; p := true [] p ! WA; p := false od ]j where we denoted:

RA =b u := u0:Q00 ; Q00 =b (b ) Q[u0 =v0 ]) ^ (:b ) u0 = u); WA =b v := u The actions RA and WA are called the read and write parts of the action A. The boolean variable p, in turn, models the behavior of the clock: when it is false, the read phase of an action is executed, and when it is true, the write phase is executed. We hide p into a shorthand notation `}' (`diamond'), which we call the clock operator de ned by

RA } WA =b var p : bool; p := false=true; :p ! RA; p := true [] p ! WA; p := false In the above notation, the leading declaration and initialization of var p stays only as a reminder that the variable has to be declared in the list of local variables of the system containing the construct (in our case A000 ) when the composition RA } WA is \opened down" to the choice representation. Otherwise p is hidden by the clock operator. In the following, however, we consider this as known, and we only write

RA } WA = :p ! RA ; p := true [] p ! WA ; p := false Hence, the above system A000 can be written as

sys A000 (g) :: j[ var u; init u := v; do RA } WA od ]j


29

Observe that p is not considered a local variable of the choice construct, but of the whole system A000 . Hence, it is initialized only once. The initialization init p := true=false is meant to stress the fact that the initial value that we assign to p is not important (as actually we cannot predict the rst edge of the clock signal, when we power up some digital equipment). The initialization init u := v ensures that, if p is initialized to true, the variable v preserves its old value, until p = false again. From now on, in order to improve readability, we will only specify the initialization init p := false: The composition RA } WA is called a two-phase action, or the two-phase representation of A, denoted TA :

TA =b RA } WA The two-phase representation of TA is de ned to be TA itself:

TTA =b TA which means that the read and write parts of the two-phase action TA are the read and write parts of the original action A. Note that the clock operator sequences the read and write parts, making them mutually exclusive, but it does not specify which is executed rst. This comes from the fact that the hidden sequencing variable p can be initially either true or false. It is also important to observe that RA and WA are always enabled, but in case the guard b is false, the read part RA behaves as skip, and thus the value of the variable v is not changed (RA performs a fake update of the variable v). The clock operator is monotonic with respect to re nement due to the monotonicity of the choice and sequential composition (Appendix 9.2):

RA RA0 ) RA } WA RA0 } WA; WA WA0 ) RA } WA RA } WA0 As a concrete exempli cation of a two-phase action construct, we consider the following example. Example 3 The action we want to represent in a two-phase format is:

A =b b ! v := v + 1 When targeting a two-phase representation we should specify the new value assigned to v under all circumstances. Unless dierently mentioned, the complementary action is of the type AC = :b ! skip . Thus, we have the system:

sys A (g) :: j[ do b ! v := v + 1 [] :b ! skip od ]j

30


The non-deterministic assignment format for action A is

b ! v := v0 :(v0 = v + 1); and the system is re ned to:

sys A0 (g) :: j[ do v := v0 :((b ) v0 = v + 1) ^ (:b ) v0 = v)) od ]j; or (with an obvious notation):

sys A0 (g) :: j[ do v := v0 :Q0 od ]j With the introduction of the intermediate variable u, of the same type as v, the action inside the loop becomes:

A00 =b u := u0:Q00 ; v := u; Q00 =b Q0 [u0 =v0 ] and we have:

sys A00 (g) :: j[ var u; init u := v; do u := u0:Q00 ; v := u od ]j Further we identify the read/write parts:

RA = u := u0 :Q00 ; WA = v := u; and the two-phase representation TA is: TA =b RA } WA ; = :p ! RA ; p := true [] p ! WA ; p := false

3.2.2 Simultaneous composition of actions

In order to synchronize a collection of two-phase actions (which means that latter, at the implementation level they will act on the same clock), we need an operator that combines several actions in such a way that they are executed simultaneously, as a single atomic action. Consider actions

Ai =b bi ! Bi; i = 1::n; Bi =b vi := vi0 :Qi where bi are boolean conditions, vi distinct variables, and Qi predicates determining the values assigned to the variables vi . In the general case, it is not


31

necessary that gBi = true; 8i = 1::n. However, in our approach we consider that the assignments Bi are HI - assignments, according to DEFINITION 1 (and thus, gBi = true; 8i = 1::n). The simultaneous composition of the actions Ai , denoted A1 ? : : : ? An , is de ned as

A1 ? : : : ? An =b

^n

^ bi ! v1 ; : : : ; vn := v10 ; : : : ; vn0 : Qi i=1 i=1 n

Hence, the simultaneous composition of actions is equivalent to a single atomic action containing a multiple non-deterministic assignment, and thus, synchronicity can be re ected by this kind of construct.

Properties. The skip action is de ned to be the unit operand of the simultaneous composition operator: A ? skip =b A (This property might have been as well proven.) Furthermore, simultaneous composition of actions has the following basic properties which can be easily derived from the de nition of `?', considering the idempotency, commutativity and associativity of the conjunction in the de nition of the simultaneous composition: 1. Idempotency. 2. Commutativity.

A?A=A A?B =B?A

3. Associativity.

A ? (B ? C ) = (A ? B ) ? C = A ? B ? C 4. Re nement related properties. The simultaneous assignment is monotonic with respect to re nement (Appendix 9.3):

A A0 ) A ? B A0 ? B; B B0 ) A ? B A ? B0

32


Comments. The idea of simultaneous assignment is not new. It can be also

found in other formal frameworks [1]. Even Action Systems provides other ways to implement simultaneous execution of actions. The product operator `' [9, 17] has the same eect as the simultaneous assignment de ned above (it produces a simultaneous update of the write variables of the actions connected by the `' operator). However, the properties of this operator prevent us to use it conveniently in our approach. For example, unlike `?', it is not commutative. Furthermore, as the actions in our synchronous systems will be restricted to nondeterministic assignments, we prefer a simpler operator, tailored for our purposes.

3.2.3 Synchronous composition of actions

Consider the actions A1 , . . . , An that write onto distinct state variables v1 , . . . , vn , respectively, and which are HI - assignment actions of the form

vj := vj0 :Qj ; j = 1 : : : n or two-phase representations of such actions. The synchronous composition of the actions Ai , denoted A1 r : : : r An (`nabla'), is then de ned in terms of the read and write parts of the component actions as

A1 r : : : r An =b var u1 ; : : : ; un ; init u1; : : : ; un := v1 ; : : : ; vn ; (RA1 ? : : : ? RAn ) } (WA1 ? : : : ? WAn ) (with a similar remark on the leading declaration and initialization of the list u1 ; : : : ; un as in the case of the clock operator and the variable p.) Thus, the synchronous composition of actions is a two-phase action, where the simultaneous execution of the read parts is sequenced with the simultaneous execution of the corresponding write parts of the component actions. The read and write parts of the composed two-phase action are atomic, because the simultaneous composition operator `?' creates atomic entities. The sequencing variable p, hidden into the clock operator `}', and the intermediate variables ui , assigned by the read parts RAi and hidden into the `r' operator, are considered local to the action system which contains the composition in question. Observe that we can follow the process described in section 3.2.1 in reverse order. Thus, an action represented in a two-phase format can be transformed back into a non-deterministic assignment similar to the one in relation 3.1. (We rst replace the variable u with the output variable v. Then the variable p becomes a local variable with no in uence on the update of the variable v, thus it can be removed from the system.) The further implication is that the synchronous composition allows the involved actions to be represented as HI - assignments and not necessarily as two-phase constructs. Thus, we can write:


33

TA r TB = TA r B = A r TB = A r B

Hence, we will often not explicitly describe the actions in a synchronous composition in the two-phase format. Instead, their representation as always-enabled non-deterministic assignments will be sucient. However, all the properties of the synchronous composition (presented later), as well as other issues concerning the synchronously composed actions, rely on the fact that an HI - assignment is always possible to be represented in a two-phase format.

Simultaneity aspects. As mentioned previously (Chapter 2), in the original

action systems framework, actions that do not have any con icts [12], or, in other words, actions that do not interfere [3], can be executed in any order (they commute - section 2.3.1), which models parallel execution. If con icts exist, the execution is considered sequential. The synchronous two-phase approach, in turn, allows the write parts WAi of the component actions Ai to be executed simultaneously, even though the actions Ai themselves have read-write con icts. The reason for this is that the read parts RAi write simultaneously (and atomically) onto distinct intermediate variables each of which is then read by the corresponding write part only. In fact, the simple (\one-phase") simultaneous composition A1 ? : : : ? An has the same property, that is, interference between component actions Ai is not a problem as long as the actions write onto distinct variables. However, the fundamental dierence between the simultaneous and synchronous compositions is that the former is enabled only when all actions Ai are enabled, while the latter is always enabled, even though they may perform fake updates of their corresponding variables (assigning them the same value). Due to the requirement to specify the output under all situations, an otherwise disabled action is eectively a skip action in the synchronous composition. This property makes the detailed modeling of synchronous hardware with the synchronous two-phase approach possible. We can present the above issues more explicitly by using the notations introduced in section 2.1. We have the obvious (by de nition of the read / write actions) relations: rRA = rA; rRB = rB; wWA = wA; wWB = wB; wRA = rWA; wRB = rWB and, following the de nition of the intermediate variables: rRA \ wRB = rRB \ wRA = ;; rWA \ wWB = rWB \ wWA = ;; meaning that the execution of two-phase actions eliminates the possibility of action interference.

34


Example 4 Consider the actions:

A =b gA ! u := v + 1 B =b gB ! v := u + 1 We require a simultaneous update of u and v in the situation when both actions are enabled, or a partial update (either of u or v) in the situation when only one action (A or B ) is enabled. We assign the initial values u = 5 and v = 10: As we do not detail the guards gA, gB , we consider that gA 2= wB and gB 2= wA (one action cannot enable or disable the other). As actions A; B interfere, their execution in any order produces dierent results (supposing gA = true ^ gB = true): executing A; B leads to the nal result: u = 11; v = 12; executing B ; A leads to the nal result: v = 6; u = 7 A synchronous approach for the combination of the two actions would produce, however, the required behavior. If we rede ne the actions as

A =b gA ! u := v + 1 [] :gA ! skip B =b gB ! v := u + 1 [] :gB ! skip; executing A r B means: 1. Simultaneously executing the read parts of the actions: RA ? RB , with the result: vm = 6; um = 11 (vm ; um are the intermediate variables). 2. Simultaneously executing the write parts of the actions: WA ?WB , with the nal result: v := vm ; u := um : In the end, v = 6; u = 11; when the guards are true, and the execution of one action does not depend on the enabledness of the other. When either of the actions A or B is not enabled, the composition A r B updates only the variable corresponding to the enabled action. When neither action is enabled, then there are no real updates performed.

Comments. The situation described in the above example can be also ana-

lyzed in correlation with determinacy and con uence issues as presented in [53]. Generally, we categorize a system as being deterministic if, whenever the same input state is provided, the output is correspondingly the same. Therefore, we can consider that the synchronous composition of actions leads to determinate systems, as actions are executed at once. We will also see in the next chapter, that, if one follows certain re nement rules during a system transformation, the determinacy is preserved at a lower level of description.


35

Other ways to describe the speci cations of EXAMPLE 4, for instance sequence or choice, lead to non-deterministic descriptions, if there are variables updated by some actions and read by some other actions (as is the case in the mentioned example). This is also valid if we analyze con uence properties. As de ned in [53], con uence re ects the fact that of any two possible actions, the execution of one will never preclude the other. In other words, given an action system, if the order in which its actions are executed does not aect the nal result, then we could call this a con uent system. As synchronous actions are executed simultaneously, this characteristic is not of great importance to synchronous action systems.

Properties. The synchronous composition of actions has the following basic properties. They can be straightforwardly proved by opening the r-notation

using the de nition. Let A, B , C be always-enabled non-deterministic assignments, and TA , TB the two-phase representations of A and B .

1. Unit operand. As skip was de ned as the unit operand for the simultaneous composition operator (`?') and considering:

skip = skip } skip; we have that

A r skip = (RA ? skip ) } (WA ? skip ) = RA } WA = TA 2. Idempotency. Due to the similar property of the `?'-operator, we have:

A r A = TA rTA = (RA ? RA ) } (WA ? WA ) = RA } WA = TA 3. Commutativity. Based on the commutativity of the simultaneous composition operator, we have that:

A r B = (RA ? RB ) } (WA ? WB ) = (RB ? RA ) } (WB ? WA ) = BrA

36

CHAPTER 3. SYNCHRONOUS ACTION SYSTEMS - THE BASICS 4. Associativity. Based on the associativity of the simultaneous composition operator, we have that: (A r B ) r C = ((RA ? RB ) } (WA ? WB ))rC = ((RA ? RB ) ? RC ) } ((WA ? WB ) ? WC ) = (RA ? RB ? RC ) } (WA ? WB ? WC ) = ArBrC Similarly, A r (B r C ) = A r B r C: 5. Composability of two-phase actions. TA r TB = (RTA ? RTB ) } (WTA ? WTB ) = (RA ? RB ) } (WA ? WB ) = ArB = TAB In other words, any composition of several two-phase actions can be seen as a single two-phase action. Notice also that the individual variables pA and pB are replaced by a common variable p by the de nition of the synchronous composition. Using the de nition of the r-operator inversely, a complex two-phase action of the form T = (R1 ? : : : ? Rn) } (W1 ? : : : ? Wn ) can be decomposed into a synchronous composition of simpler two-phase actions Ti , i = 1::n. In other words, we can write T = T1 r : : : r Tn where, for i = 1; : : : ; n: Ti =b Ri } Wi =b :pi ! Ri ; pi := true [] pi ! Wi ; pi := false Hence, the decomposition operation creates a set of distinct two-phase actions Ti , with distinct variables pi . 6. Re nement-related properties. The synchronous composition operator is monotonic with respect to re nement (Appendix 9.4), following from the monotonicity of the simultaneous composition operator `?' and of the clock operator `}':

A A0 ) A r B A0 r B B B0 ) A r B A r B0


37

3.2.4 Synchronous action systems

An action system whose actions Ai are synchronously composed is called a synchronous action system. Such a system never terminates, since the two-phase representation of a component action is always enabled. However, if the guard of each component action remains false, the system stutters or preserves its current state until the read part of some action stops performing a fake update of its output variable. Consider two synchronous action systems A and B: sys A (gA ) :: j[ var lA; init gA; lA := gA0 ; lA0; ]j

do A1 r : : : r Am od

sys B (gB ) :: j[ var lB ; init gB ; lB := gB0 ; lB0 ; do B1 r : : : r Bn od ]j where lA \ lB = ;, and the initializations of the global variables gA \ gB in the systems A and B are consistent with each other. The synchronous composition of A and B, denoted A r B, is the action system C : sys C (gA [ gB ) :: j[ var lA [ lB ; init gA [ gB ; lA [ lB := gA0 [ gB0 ; lA0 [ lB0 ; do A1 r : : : r Am r B1 r : : : r Bn od ]j

Thus, the synchronous composition merges the component systems by synchronizing their actions and keeping the local variables distinct. Observe that the above de nition of synchronous composition can be used inversely to decompose a synchronous system into a r-connected set of smaller mutually synchronous action systems, providing premises for a modular design. On the other hand, the simplest synchronous action system is the one having a two-phase action as the single component (a direct consequence of the composability of the two-phase actions property).

Properties. The properties of the synchronous composition of action systems

are easily derived from the properties of the synchronous composition of actions given in the previous section and the de nition of a synchronous action system. Let A, B, and C be synchronous action systems. 1. Commutativity. ArB=B rA

38

CHAPTER 3. SYNCHRONOUS ACTION SYSTEMS - THE BASICS 2. Associativity.

(A r B) r C = A r (B r C ) = A r B r C

Example 5 Consider the synchronous action system:

sys S ync (g) :: j[ var l; init : : : do A r B od ]j

Using the (de)composability property of two-phase actions and the de nition of the synchronous action system, S ync may be split into two smaller ones: S ync = S yncA r S yncB ; where sys S yncA (gA ) :: sys S yncB (gB ) :: j[ var lA; init : : : ; do A od ]j j[ var lB ; init : : : ; do B od ]j Observe that it is not necessary that g = gA [ gB or that l = lA [ lB . For example, if actions A and B share some local variables of the initial system S ync, these become global variables of the systems S yncA and S yncB . Consequently, we have the relations g gA [ gB and lA [ lB l:

3.3 Modeling the External Clock As mentioned in the beginning of the chapter, synchronous circuits operate on a global signal, the clock. Certain issues (connected to application speci c implementations, area / power constraints, routing and placement, etc.) may be analyzed in a more ecient manner if the designer can operate directly on certain characteristics of the clock signal (such as distribution, availability, status - operating or not, etc). In the following we take into consideration the modeling of the clock signal so that it provides support for later discussed issues (synchronization and gated clock design). Consider the simple synchronous action system sys A (g) :: j[ var u; init u := v; do A r skip od ]j = j[ var u; init u := v; do TA od ]j; A = v := v0:Q where v 2 g. The two-phase representation TA of A is (section 3.2.1): TA =b RA } WA; RA =b u := u0 :Q00 ; WA =b v := u

3.3. MODELING THE EXTERNAL CLOCK

39

Let us model the clock signal of the system explicitly by providing RA and WA with auxiliary guards yielding

RA0 =b :clk ! RA WA0 =b clk ! WA and

TA0 =b RA0 } WA0

where the boolean variable clk represents the external clock which is repeatedly switched by the clock action

C =b :clk ! clk := true [] clk ! clk := false Assume that the actions RA0 and WA0 have always higher priority than C . This can be expressed with the prioritizing composition as

TA0 == C which means that TA0 is selected for execution, if it is enabled, and the action C can be selected only if TA0 is disabled. The role of the sequencing variable p hidden into the clock operator of TA0 is to disable TA0 after each execution in order to make switching between TA0 and C possible. For example, when p turns to true after the execution of the read part, the control is passed to the action C , which turns clk to true, enabling the write part. We hide the new sequencing variable clk by de ning the extended clock operator `}e ' as RA }e WA =b var clk : bool; TA0 == C Observe that clk is considered a local variable of the whole system A. Hence, like the variable p, also clk is intended to be initialized only once. The extended two-phase action is then de ned as

TAe =b RA }e WA Hence, the extended clock operator, and thereby the extended synchronous composition operator `re', includes two auxiliary sequencing variables: p of the original clock operator, and clk of the new de nition. It can be proven (Appendix 9.5) that the transformation of the original operator into the extended one preserves correctness of the system, or:

A v A0 ; A0 =b A[TAe =TA ]

40


In case of the synchronous composition of actions, we have that: A1 r e : : : r e An =b ((:clk ! RA1 ? : : : ? RAn ) } (clk ! WA1 ? : : : ? WAn )) == C = ((:clk ! p ! RA1 ? : : : ? RAn ; p := false) [] (clk ! :p ! WA1 ? : : : ? WAn ; p := true)) == C = ((:clk ^ p ! RA1 ? : : : ? RAn ; p := false) [] (clk ^ :p ! WA1 ? : : : ? WAn ; p := true)) == C = (RA1 ? : : : ? RAn ) } e (WA1 ? : : : ? WAn ) The extended synchronous composition of two synchronous action systems is represented by the extended synchronous composition of their actions.

Comments. The variable clk and hence the clock action C and the extended synchronous operators make the separation of the clock signal from the \functional" two-phase action (the read and write parts) possible. This is not achieved by only using the sequencing variable p. Providing this facility allows us further to address issues that concern the characteristics of the clock signal itself.

3.4 Conclusions and Related Work In this chapter, we introduced the basic elements that we need in order to formally represent, in our framework, systems intended to be implemented as synchronous circuits. The new operators may actually be considered, from some dierent perspectives, as macros that help us describe in a more concise manner the synchronous two-phase behavior. They are built on top of basic constructs, the choice and the sequential operators. We introduced a \basic" level of the representation and an \extended" one as well. The extended level takes into account the presence of a clock generator that supplies the clock signal to the synchronous action systems. Thus, it re ects, in a more concrete description, the behavior of a synchronous device. An extended level description can substitute a basic level one (section 3.3). The basic or extended synchronous descriptions are represented on three levels of abstraction. Each level is characterized by the operator that we use and therefore, by the variables that the speci c operator shows or hides. The highest level corresponds to a r-based (or re-based) description, where the synchronously connected actions can be presented as always-enabled nondeterministic assignments. The intermediate variables and the boolean variables p and clk are not \visible" (which means that they are not mentioned in the variable list of the system, as they are \hidden" by the de nition of the synchronous operators. We go one level lower and we have a description based on the clock

3.4. CONCLUSIONS AND RELATED WORK

41

operator, `}' or `}e '. Here the intermediate variables that pass the updated values from the read part to the write part appear in the variable list, as the clock operator(s) only hide the variables p and clk. We mainly view the clock operator level as an intermediate level that makes a logical connection from the r-based descriptions to the next (lowest) level. We reach the last level of the description when we open down all the newly introduced synchronous operators (`r' and `}') and we have a description based on choice constructs. Here, all the local variables that have helped us model the synchronous behavior are made \visible" by appearing in the local variable list of the system. These aspects are brie y illustrated in Figure 3.4.

Figure 3.4: Synchronous description levels. The dierent levels that we have described above are useful in distinct phases of the design ow. We brie y anticipate here some of the aspects that we address in the next chapters. Thus, at the r-level (or re -level) we can directly specify systems that we know we want to implement as synchronous circuits. The `}' (or `}e ') levels of representation provide us with a correct translation into the choice construct level, where we can reason about synchronization and gated clock issues.

Related work. A quite similar approach to formal synchronous design is rep-

resented in Reactive Modules [2]: the synchronous action systems correspond to modules, and the synchronous actions are atoms. The two-phase representation is modeled by latched / updated variables. The main dierence resides in the interpretation of the execution of modules / synchronous systems: while the atoms of some module are executed in an arbitrary consistent order, the

42


read / write parts of a synchronous action system are executed simultaneously. As a consequence, several rounds are necessary for initializing and executing one reactive module, whereas a synchronous action system is executed in two steps. While a module may as well represent a combinational element only (such as an AND gate, for instance), our descriptions do not allow this, considering it a lower level of abstractization. Another similarity consists in the one variable per action organization. Thus, only a single atom performs the updates on one output variable within a module. A skip action is available in describing reactive modules, as the guarded command `true !'. It allows the atom that contains it to behave as lazy, that is, as a stuttering action. It also preserves the non-deterministic characteristic of the atom / module as it may be picked for updating the output variable, even though some eager atom / change action is enabled, too. In describing two-phase actions / synchronous action system, a stuttering situation appears only when no change option is enabled. Reactive Modules also allows building (describing) a clock generator module for synchronization purposes, which executes in parallel with the synchronous modules. By hiding the \clock" module in a parallel composition, the system becomes asynchronous (with respect to the other components of the design). This is also possible in our descriptions, at a higher representation level, where the internal details of the systems are not visible. We present more comparisons with the Reactive Modules in section 4.8. With regard to the introduction of the clock variable p, a similar modality was chosen by O'Leary et al [57]: components sharing the same clock event (synchronous actions) decide upon the transition to the next phase. Although ordering is required in connection with clocked variables, the authors present an untimed approach, too. Synchronized Transitions [80] is a UNITY-based formalism which has a synchronous composition operator. This operator resembles our simultaneous composition operator `?', but it allows composed actions to update in turns the same variables, which is not possible in our formalization of `?'. However, Synchronized Transitions does not contain an operator for explicit two-phase modeling, but a composition of transitions is directly transformed into a circuit diagram. In our approach, synchronous two-phase behavior is modeled in more detail making the gap between the formal correctness proofs and the hardware realization narrower. FP [41], a functional programming based approach to synchronous circuit design, presents untimed descriptions for synchronous circuit design. However, this only means that there are no explicit referrals to time units. In this language, the base objects are in nite sequences of signal values. Concurrent Constraint Programming has been adapted to model synchronous two-phase behavior (although not in the same sense as our timeless view) [23, 69]. The timed analysis uses special kinds of temporal operators (tell and ask)


43

satisfying strong synchronization assumptions. The clock signal is also modeled by a distinct process [23], the synchronization being, however, the job for the synchronous process itself, which, by means of the mentioned temporal operators, enquires and receives information about the clock signal. The programming language LUSTRE also reaches synchronicity by means of timed events [36]. Even though not necessarily related to the real time ow, the succession of updates in LUSTRE is coordinated by a time sequence, which de nes the clock signal. Multiple clocks can be de ned. This may seem dicult to obtain in our approach, but we show in Chapter 5 that actually it can be done, quite easily. The synchronization of data ow in ESTEREL [20, 21] is mainly reached by the usage of await statements. Explicit time speci cations are also allowed in the language. Our approach builds an untimed model of the synchronous world. Synchronicity is achieved by the introduction of the simultaneous execution of actions. We considered this as not being enough for the description of synchronous actions and thus, we also required the presence of a complementary action, so that the outputs are explicitly resolved under all circumstances. Further, the synchronous operator `r', by the properties of composition / decomposition, sets the premises for a modular representation of synchronous action systems. The extended clock-operator level is speci c to our descriptions. Its usefulness will be stressed in section 4.3, when synchronizing two initially asynchronous subsystems. We take advantage of the presence of the extended clock-operator when it comes to issues concerning gated clock designs, in Chapter 5.

44


Chapter 4

Designing Synchronous Action Systems We agree to the opinion expressed in [57], that the asynchronous approach can be considered a natural way to describe system behavior. Moreover, the Action Systems formalism has suitable features for asynchronous modeling. Thus, we consider the initial speci cation of the target system to be asynchronous. We present in the following, steps to be followed in order to reach a synchronous system level representation, from an initial asynchronous description. They do not represent the only way one has to follow in the design process, but they re ect the basic notions around which the design process is built. For a large category of descriptions, we are able to provide a method for obtaining synchronous representations. We also provide a generic format for those action systems that can be re ned into synchronous representations. The extended level of the synchronous operators introduced in section 3.3 help us to extend the design ow with aspects related to the synchronization of mutually asynchronous action systems. Synchronization is required when the circuit is composed of simpler (smaller) synchronous design units (systems). However, if the synchronous implementation has been decided at the earliest stage, then an overall synchronous representation can be used from the start. The nal stage of any digital design ow is the actual hardware implementation. Towards the end of the chapter, we give hardware interpretations of the previously analyzed descriptions.

4.1 Asynchronous vs. Synchronous Systems From the point of view of the Action Systems formalism, the fundamental dierence between a synchronous action system, de ned in section 3.2.4, and an asynchronous action system is that the former never terminates, since a two-phase 45

46

CHAPTER 4. DESIGNING SYNCHRONOUS ACTION SYSTEMS

action is always enabled, while the latter terminates when none of the actions is enabled. However, an (asynchronous) action system is composed in parallel with an environment-modeling system (section 2.2.1), such that the composition never terminates. Synchronous action systems, in turn, are individually nonterminating. Let us consider the dierences between the two system types from a more general and practical point of view. An asynchronous system interacts with its environment via an asynchronous communication (or handshake) channel, which is composed of two boolean handshake variables [32], denoted req and ack (request, acknowledge), and data variables whose values are transferred from the system to its environment, or vice versa. The handshake variable req is updated by the master system which is the active party of communication requesting tasks from the server system which is the passive party of communication. Respectively, the variable ack is updated by the server, whenever it has completed a task requested by the master. Furthermore, the master only reads ack, and the server only reads req. There are also dierent communication protocols one has to choose when designing an asynchronous application. We based our design approach on the four-phase signaling protocol [28] (Figure 4.1). Thus, the master system sets the request line and it holds it until the server system replies by setting up the acknowledge variable. Then the request is released and, in response, the server resets the acknowledgment line. Afterwards, the process may be reinitialized by the master system, by setting again the request signal. Notice that a single data sample is processed in one transaction, and not a block of data (a sequence of incoming samples).

request

acknowledge

data in

data out

one transaction

Figure 4.1: The four phase handshake.

4.2. ASYNCHRONOUS TO SYNCHRONOUS TRANSFORMATION

47

A synchronous system does not usually need a communication channel with handshake variables. Especially, the variable ack is often unnecessary, since the operation of a synchronous device is paced by a regular clock signal, and the completion of a task does not have to be acknowledged explicitly. At this point, we have to mention that, in the following sections, we do not present the details of constructing an asynchronous / synchronous interface. The protocol described above helps us to provide a high level modeling of our systems. In a more concrete (lower level) representation, several other issues have to be addressed, such as the interception and identi cation of the req signal, time aspects, etc, also depending on the speci c application / implementation.

4.2 Asynchronous to Synchronous Transformation

We start the description by establishing an action system Async that will implement our system speci cation, together with another system, E nv, that models the environment in which the system Async works. Our approach resembles the synchronous execution mode of the reactive systems [24], where the environment and the synchronous system (program) exchange control and data, while only one of them is running at a time. Further, as E nv provides the req signal to our system, we consider it as the master in our design. It is then important that E nv prevails over system Async, which means that, whenever an action in E nv is enabled, it is executed, even though there might be enabled actions in Async, too. This can be modeled in the Action Systems formalism by the prioritized composition operator (section 2.2.2). Thus, the initial speci cation in our case will be E nv == Async: Let us rst consider an asynchronous system that updates a list of output variables in the following way: sys Async (req; ack : boolean; global variables) :: j[ var local variables; init initialization of variables; do req ! (g1 ! A1 [] : : : [] gn ! An ); ack := true [] :req ! ack := false

od

]j Actions Ai ; i = 1 : : : n are HI - assignments of the following form:

Ai =b v := v0 :Qi = w1 : : : wm := w10 : : : wm0 :(Qi1 ^ : : : ^ Qim ) where v is the list of (local and global) variables, w1 ; : : : ; wm , updated by actions Ai . Each variable wj ; j = 1 : : : m is updated by the action Ai consistent with the predicate Qji . For reasons that will become clear in the next sections, we also

48


require that one and only one of the guards gk ; k = 1 : : : n evaluates to true, at a given moment:

_n

9k = 1 : : : n:(gk = true) ^ ((

j =1;j 6=k

gj ) = false)

(4.1)

Thus, the choice composition

g1 ! A1 [] : : : [] gn ! An

(4.2)

is formed by a set of GHI - assignments (DEFINITION 2), of which only one is enabled in a given state. We also oer a very simpli ed exempli cation of an E nv system, as: sys E nv (req; ack : bool; global variables) :: j[ do :req ^ :ack ! actions; req := true [] req ^ ack ! req := false

od

]j Considering the above, Async can be re ned in order to produce a separation between actions that update variables v and ack, leading us to the following system: sys Async1 (req; ack : boolean; global variables) :: j[ var local variables; init initialization of variables; do :req ! ack := false [] req ! ack := true; (req ! (g1 ! A1 [] : : : [] gn ! An )) [] :req ! skip

od ]j

We have that Async v Async1 (Appendix 9.6). Notice that the sequence of actions in the above action systems is an atomic composition. Even though for the above re nement step this is not really an important issue, for the following steps we only consider atomic interpretation for the sequence composition.

4.2.1 Transforming system components

Below, we detail further steps taken in order to obtain a synchronous representation of the above system Async1.

Choice composition. Considering the requirement described by relation 4.1,

we have that

g1 ! A1 [] : : : [] gn ! An A;

(4.3)

4.2. ASYNCHRONOUS TO SYNCHRONOUS TRANSFORMATION where

49

Ai =b v := v0 :Qi ; i = 1 : : : n A =b v := v0 :Q; Q =b (g1 ) Q1 ) ^ : : : ^ (gn ) Qn )

The above relation 4.3 comes as a consequence of an extension of Proof 1. presented in Appendix 9.1. In the context of the system Async1 , we have that Async1 v Async2 ; with: sys Async2 (req; ack : boolean; global variables) :: j[ var local variables; init initialization of variables; do Sack ; Sv od ]j The action Sack is obtained by applying the rule 4.3: :req ! ack := false [] req ! ack := true Sack ;

Sack =b ack := ack0 :Qack ; Qack =b (req ) ack0 = true) ^ (:req ) ack0 = false) The same rule, applied twice, leads us to the action Sv : First g1 ! A1 [] : : : [] gn ! An A; A =b v := v0 :Q; Q =b (g1 ) Q1 ) ^ : : : ^ (gn ) Qn ) and then

req ! A [] :req ! skip Sv ;

Sv =b v := v0 :Q0; Q0 =b (req ! Q) ^ (:req ) V ); V =b (v0 = v) In case v is a list of m variables: v =b fw1 ; : : : ; wm g we interpret Sv taking

into account that: V =b Vj =b Q =b = Qj =b

V1 ^ : : : ^ Vm ; j = 1 : : : m; (wj0 = wj ); (g1 ) Q11 ^ : : : ^ Qm1 ) ^ : : : ^ (gn ) Q1n ^ : : : ^ Qmn ) Q1 ^ : : : ^ Qm; (g1 ) Qj1 ) ^ : : : ^ (gn ) Qjn )

50


We further decompose the action Sv into m actions Sv1 ; : : : ; Svm . Each of them updates a single variable wj ; j = 1 : : : m, as follows: Sv =b w1 ; : : : ; wm := w10 ; : : : ; wm0 :(Q ^ V ) = Sv1 ? : : : ? Svm ; Svj =b wj := wj0 :Q0j ; j = 1 : : : m Q0j =b (req ) Qj ) ^ (:req ) Vj ) Observe in the above relations the \distribution" of the predicate V over the updates on individual variables. This is how we can obtain the distinct actions Sv1 ; : : : ; Svm grouped in the simultaneous assignment composition Sv .

Sequential composition. The precedent paragraph showed that a choice (of

the mentioned particular type) can be re ned into a non-deterministic assignment format, leading to the representation of system Async2 : Next, let us introduce the intermediate, local variables u and uack , of the same type as v and ack, respectively. We also split the execution of actions Sack and Sv , accordingly: Sack ; Sv Rack ; Wack ; Rv ; Wv ; Rack =b u := u0:Q0 [u0 =v0 ]; Wack =b v := u; Rv =b uack := u0ack :Qack [u0ack =ack0 ]; Wv =b ack := uack At the system level we have Async2 v Async3; sys Async3 (req; ack : boolean; global variables) :: j[ var local variables; u; uack ; init initialization of variables; do Rack ; Wack ; Rv ; Wv od ]j The order of actions Wack and Rv in the above system is not important (they are independent actions, or they can commute - section 2.1.2). Therefore it can be reversed, to Rv ; Wack with the obvious relation: Rack ; Wack ; Rv ; Wv Rack ; Rv ; Wack ; Wv Moreover, actions Rack and Rv have no read / write con icts and this is valid for Wack and Wv , too. They can then be executed in a simultaneous manner (Appendix 9.7). Thus, we have Rack ; Rv ; Wack ; Wv (Rack ? Rv ); (Wack ? Wv ); which further means that Async3 v Async4 , where:


51

sys Async4 (req; ack : boolean; global variables) :: j[ var local variables; u; uack ; init initialization of variables; do (Rack ? Rv ); (Wack ? Wv ) od ]j Following the steps used in obtaining the two-phase representation of actions (section 3.2.1), we further transform Async4 v S ync, by introducing p and interpreting Rack ? Rv as the read part of a non-deterministic assignment and Wack ? Wv as its write part. (Note that the construct (Rack ? Rv ); (Wack ? Wv ) is always enabled.) We obtain the description:

sys S ync (req; ack : boolean; global variables) :: j[ var local variables; u; uack ; init initialization of variables; do (Rack ? Rv )}(Wack ? Wv ) od ]j Due to the decomposability property of the synchronous composition, we can further write the system S ync as sys S ync (req; ack : boolean; global variables) :: j[ var local variables; init initialization of variables; ]j

do Sack rSv od

Observe that, in case v = fw1 ; : : : ; wm g; Sv is a simultaneous assignment composition. Following the descriptions presented in the previous paragraphs, we have the system: sys Async4 (req; ack : boolean; global variables) :: j[ var local variables; u; uack ; init initialization of variables; do (Rack ? Rv1 ? : : : ? Rvm); (Wack ? Wv1 ? : : : ? Wvm) od ]j; which leads to the synchronous format: sys S ync (req; ack : boolean; global variables) :: j[ var local variables; init initialization of variables;

do Sack r Sv1 r : : : r Svm od

]j;

or, in the two-phase representation (S ync = S yncT , and Tvj is the two-phase representation of Svj ; j = 1 : : : m):

52


sys S yncT (req; ack : boolean; global variables) :: j[ var local variables; init initialization of variables; do Tack r Tv1 r : : : r Tvm od ]j

We eventually have:

E nv == Async v E nv == S ync; E nv == Async v E nv == S yncT Moreover, as S ync v S ynce (or S yncT v S ynce, section 3.3) and by the

transitivity of the re nement relation (section 2.4), we also have

E nv == Async v E nv == S ynce; where

sys S ynce (req; ack : boolean; global variables) :: j[ var local variables; init initialization of variables; do Tack re Tv1 re : : : re Tvm od ]j

4.2.2 Generic asynchronous system

In section 4.2.1, we introduced the basic issues of translating an asynchronous description into a synchronous format. We also presented the appropriate techniques to follow in the process. Based on this, we can imagine a more general format for the Async system. First, we consider the following system: sys Async1G (req; ack : boolean; global variables) :: j[ var local variables; init initialization of variables; do req ! choice1 ; : : : ; choicen ; ack := true [] :req ! ack := false

od

]j where, for k = 1 : : : mj ; j = 1 : : : n :

choicej =b g1j ! Aj1 [] : : : [] gmj j ! Ajmj ; (4.4) Ajk =b vj := vj0 :Qjk ; (4.5) Observe that the choice 4.2 of the previous system Async is extended into a sequence of choices in system Async1G. We present design examples based on the generic system Async1G in sections 4.4, 6.4 and 6.6.


53

Another initial asynchronous representations also allows a correct translation into a synchronous description. The most important constraint is that the updates of the variables must be speci ed under all circumstances. For instance, let us analyze the system sys Async2G (req; ack : boolean; global variables) :: j[ var local variables; init initialization of variables; do req ! (gA ! A [] :gA ! ack := true) [] :req ! ack := false

od

]j where A is the choice sequence A =b choice1 ; : : : ; choicen ; (4.6) and we use the above notations 4.4, 4.5. In the description of the system Async2G we consider that: gA and req are initially set by the master system. gA 2 wA: It is also necessary that action A, by repeatedly updating gA, disables itself (eventually, gA = false). In turn, this enables the action that updates the variable ack (ack := true). Thus, the system Async2G executes the action A as long as gA = true: This proves useful as it allows us to represent iterative constructs (while or for loops). The variable gA is a global variable, too, shared by the master system and Async2G. The latter can be transformed into sys Async2G0 (req; ack : boolean; global variables) :: j[ var local variables; init initialization of variables; do req ^ :gA ! ack := true [] :req ! ack := false [] req ^ :gA ! skip; req ^ gA ! A [] :(req ^ gA ) ! skip

od

]j From here, following a similar procedure as described in the previous section, we reach a synchronous system description. We call Async2G the second generic system, and we present a design example based on Async2G in Chapter 7. Example 6 In section 7.3.2 we describe the transformation into a synchronous representation of the system that implements the autocorrelation part of the encoding device. We also present it here, as an example of a derivation based on the system Async2G: Thus, in the description

54


sys Aco (req; ack : bool; baseR ; i; s[0::511]; R[0::10] : integer; ) :: j[ var j; base : integer; init j; base; baseR = 0; 256; 3; do req ! ((i p) ! A [] (i > p) ! ack := true) [] :req ! ack := false od ]j; we can identify gA =b (i p); A =b (j < N ; 1 ; i ! R[j ] := R[j ] + s[basejj ] s[basejj + i]; j + +; i := i; base := base) [] (j = N ; 1 ; i ! (i = p ! base := base + N mod 2N [] i < p ! base := base); R[j ] := R[j ]; i + +; j := 0) We eventually reach the synchronous representation sys AcoS (req; ack : bool; i; baseR ; s[0::511]; R[0::10] : integer; ) :: j[ var j; base : integer; intermediate variables init j; base; baseR = 0; 256; 3; initialization of intermediate variables; ]j

do T1 r T2 r T3 r T4 od

4.2.3 Synchronization requirements

As a step in de ning precise rules for the translation process described in previous sections we present next a set of requirements necessary for an asynchronous system to be eligible for a translation into the synchronous format. The following represent the synchronization requirements. S.R. 1 The designer has to re ne the initial system into one of the generic formats presented in the previous subsection. S.R. 2 The actions involved in each choice must be represented in the nondeterministic assignment format: Ajk =b vj := vj0 :Qjk ; k = 1 : : : mj ; j = 1 : : : n S.R. 3 One and only one of the GHI - assignments in each choice choicej (relation 4.4) is enabled:

8j = 1 : : : n:(9 k = 1 : : : mj :(gkj

= true) ^ ((

m _j

i=1;i6=k

gij ) = false))

(4.7)


55

This ensures the fact that every choice choicej can be correctly transformed into a HI - assignment of the format:

vj := vj0 :(Q01j ^ : : : ^ Q0mj j );

(4.8)

Q0kj =b (gkj ) Qjk ); k = 1 : : : mj

(4.9)

where Hence, only one of the predicates Q0kj is involved in updating the variable vj at a given moment. S.R. 4 The execution of a speci c choice, choicej , must not depend on the new values of the variables updated by some previous choicek in the composition (k = 1 : : : j ). However, it may consider the old value of a variable updated by choicek . The requirements S.R. 2 and S.R. 3 ensure that a choice of the presented type can be correctly transformed into a (multiple) non-deterministic assignment. The latter requirement, S:R:4; is needed when re ning the sequence of choices (Appendix 9.8). The resulting synchronous system is then modeled by

sys S yncG (req; ack : boolean; global variables) :: j[ var local variables; init initialization of variables; do Tack r Tchoice1 r : : : rTchoicen od ]j where Tchoice1 : : : Tchoicen are the two-phase representations of the choices and action Tack the two-phase representation of the action updating the communication variable ack. Example 7 The above-de ned fourth requirement might seem to be a restrictive one. It is in the habit of the designer (programmer) to present events (actions) in a sequential manner. Then, actions in the sequence would naturally read what previous actions updated, thus, contravening the mentioned requirement. In this example, as well as in Chapters 6 and 7 we show how this situation can be circumvented. At a rst look, it seems that we will not be able to describe a register implementation of a simple queue, where the data is just translated from input to the output through a chain of ip- ops (Figure 4.2). Let us consider that we want to implement the sequence

a := in; b := a; c := b

56


We model the above assignments as actions:

A =b a := a0 :(a0 = in); B =b b := b0 :(b0 = a); C =b c := c0 :(c0 = b) and we identify them with the choices of the generic asynchronous system. Notice then that a sequence like A; B ; C does not comply with the requirement S:R:4 : B and C read the values just updated by actions A and B , respectively. Notice that we can also describe the sequence as C ; B ; A which, except for changing the order in the formal description ensures the compliance with the fourth requirement, with no change in the actual hardware implementation.

in

a A

c

b B

C

Clock generator

Figure 4.2: D Flip- op queue.

4.3 Synchronizing Action Systems As digital circuits tend to contain increased functionality, the systems get larger. In order to eciently handle the design of these systems one solution is to split them into smaller subsystems. The method described in the previous section covers the synchronous design of a single action system. We enlarge the view on the design of synchronous action systems by describing one way in which a system composed of several subsystems can be synchronously represented within the Action Systems framework. The subsystems could be asynchronous with respect to each other, while some of them may operate on the clock, or all the systems may be mutually synchronous, depending on the targeted architecture.

4.3.1 Initial asynchronous approach

The initial subsystems are grouped into a parallel composition. The environment is modeled by system E nv, with a higher priority. The target is to have a synchronous representation of all the subsystems, or of a part of them only. It is

4.3. SYNCHRONIZING ACTION SYSTEMS

57

enough to study a composition of only two subsystems, larger designs being a generalization of this particular situation. In addition to the conditions S.R. 1 to S:R:4; another requirement has to be satis ed in order to reach the declared target. Thus, as the subsystems are initially asynchronously represented, it is necessary that the communication channel (req / ack signals) to be routed through the system that models the environment. Explicitly, this means that the environment (E nv) provides request signals for all the subsystems and E nv becomes enabled when all the subsystems have acknowledged back. The subsystems themselves have to comply with the synchronization requirements S.R. 1 to S.R. 4 (section 4.2.2). The re nement steps take into consideration one property of the prioritized composition (section 2.2.2), namely that prioritized composition with an action system distributes over parallel composition to the right: E nv == (AsyncA k AsyncB ) = (E nv == AsyncA) k (E nv == AsyncB ) This relation, however, is valid only in the case that E nv has no local variables. We can consider separately the compositions E nv == AsyncA and E nv == AsyncB : Applying the method described in the section 4.2 we obtain: (E nv == AsyncA) v (E nv == S yncA ); (E nv == AsyncB ) v (E nv == S yncB ) and thus, (E nv == AsyncA) k (E nv == AsyncB ) v (E nv == S yncA) k (E nv == S yncB ) = E nv == (S yncA k S yncB ) Both S yncA and S yncB operate in a synchronous manner internally. Depending on the requirements, this description could be enough: two subsystems with distinct clock generators, mutually asynchronous. Then the designer's job is done with respect to these subsystems. On the other hand, the speci cation may require a mutually synchronous implementation of the two subsystems, situation which imposes a further processing of the system composition. A synchronous system may be represented by a two-phase action only (section 3.2.4). Let us consider (j 2 fA; B g): sys S yncj (reqj ; ackj : bool; global variablesj ) :: j[ var local variablesj ; init initialization of variables; do :pj ! Rj ; pj := true [] pj ! Wj ; pj := false ]j

od

58

CHAPTER 4. DESIGNING SYNCHRONOUS ACTION SYSTEMS The parallel composition of the two systems is (section 2.2.1): Async =b S yncA k S yncB ; sys Async (reqA; ackA ; reqB ; ackB : bool; global variablesA[B ) :: j[ var local variables; init initialization of variables; do :pA ! RA; pA := true [] pA ! WA ; pA := false [] :pB ! RB ; pB := true [] pB ! WB ; pB := false

od ]j

The synchronization of the (initial) two subsystems means that there is a single clock action shared by the actions of the system Async: We add this action, with the evident relation Async v Asynce : sys Asynce (reqA; ackA ; reqB ; ackB : bool; global variablesA[B ) :: j[ var local variables; init initialization of variables; do (:clk ^ :pA ! RA; pA := true [] clk ^ pA ! WA ; pA := false [] :clk ^ :pB ! RB ; pB := true [] clk ^ pB ! WB ; pB := false) == :clk ! clk := true [] clk ! clk := false

od ]j

From here, through successive steps, by forcing pA and pB to be initialized with the same value, then merging them into a single variable, we reach the relation Asynce v S ynce (Appendix 9.9), with sys S ynce (reqA; ackA ; reqB ; ackB : bool; global variablesA[B ) :: j[ var uA; uB ; init uA; uB := vA; vB ; do (RA ? RB ) } e(WA ? WB ) od ]j In the view presented in [74] we can consider the system S ync as a coarsening of S ynce: S ynce w S ync; where sys S ync (reqA; ackA ; reqB ; ackB : bool; global variablesA[B ) :: j[ var local variables; init initialization of variables; do (RA ? RB )}(WA ? WB ) od ]j Thus, we realized the synchronization of the two initial subsystems, S yncA and S yncB :

4.3. SYNCHRONIZING ACTION SYSTEMS

59

Comments. In the above, we synchronized two distinct synchronous action

systems. Further, let us consider a single action system that is described by a choice between a synchronous composition (or at least one two-phase action) and an always-enabled non-deterministic assignment (or a construct possible to be transformed into an always enabled non-deterministic assignment). This may follow a parallel composition of two synchronous action systems, as above, or be the result of another operation (an added auxiliary action). For instance, consider

sys A (global variables) :: j[ var local variables; init initialization of variables; do A [] B od ]j; where A is a two-phase action and B is an always enabled non-deterministic assignment. By using the parallel composition of action systems we can split the system A into S yncA k B :

sys S yncA (global variables) :: j[ var local variables; init initialization of variables; do A od ]j; sys B (global variables) :: j[ var local variables; init initialization of variables; do B od ]j After obtaining the synchronous representation of B; S yncB ; we follow the previously presented techniques for synchronizing the composition S yncA k S yncB : We obtain the system

sys S ync (global variables) :: j[ var local variables; init initialization of variables; do A r B od ]j

4.3.2 Synchronous approach

The analysis on translating asynchronous action systems into their synchronous correspondents is intended to provide two important aspects: the initial asynchronous speci cation (which we consider being more \natural") and the delaying of the decision upon the nal architecture of the targeted design (synchronous/asynchronous). A separate design method can be taken into account if the

60


synchronous architecture solution has been already decided at early stages. This consists of considering the environment system as being a synchronous system, too. Hence, there is no need for control lines between the involved systems. As a starting point, instead of the prioritized composition of an environment system (E nv) with the system under analysis (A, for instance), E nv == A, we will use the synchronous composition of the two systems: E nv r A: As a consequence, a variant of the generic systems (section 4.2.2) can be used as a template-system for both E nv and A:

sys S yncG (global variables) :: j[ var local variables; init initialization of variables; do choice1 ; : : : ; choicen od ]j Here, the synchronization requirements S.R. 2 to S.R. 4 (section 4.2.3) can be used to insure the capability of re ning the systems into synchronous representations.

4.4 An Example: The Trac Lights Controller This section will present an Action Systems analysis on the initial speci cation of a trac lights controller, showing in detail the step-by-step process that transforms the asynchronous version of the description into a synchronous one. The trac light controller is a popular example in dierent studies [80, 46].

Initial speci cation The controller is based on a timer variable that decides

which light is to be on or o. The units of the timer are abstract, their values depending on the speci c requirements. However, in the example we include actual gures, the speci cation being also simpli ed, as we take into account a single light controller only. When certain values of the timer are met, the controller decides to light another lamp, while putting the previous one o. One cycle is completed when the timer gets to the highest value in the speci ed range, after which it goes back to zero. The initial action system description, as mentioned in section 4.2, contains the prioritized composition of the environment and the system under analysis, in this case E nv == T LC :

4.4. AN EXAMPLE: THE TRAFFIC LIGHTS CONTROLLER

61

sys T LC (req; ack : boolean; lights : TL; timer : integer; ) :: j[ init lights = red; timer = 0; req; ack = false; do req ! (timer = 0 ! lights := red [] timer = 1000 ! lights := yellow [] timer = 2000 ! lights := green [] timer 62 f0; 1000; 2000g ! lights := lights0 :(lights0 = lights)); timer := (timer + 1) mod 3000; ack := true [] :req ! ack := false

]j

od

where lights : TL is a variable that represents the stop lights, of the type TL (Trac Lights), TL =b fred; yellow; greeng and timer : integer is the timer which value is tested. At each execution of the system timer is incremented, and, in special cases (timer 2 f0; 1000; 2000g) actions on the vector lights are executed, too. As we don't analyze it here, the E nv system is considered to be a very simple one, for example just providing the req signal: sys E nv (req; ack : boolean; ) :: j[ init req; ack = false; do :req ^ :ack ! req := true [] ack ^ req ! req := false

od

]j One can notice that sys T LC maps directly on the generic asynchronous system presented in section 4.2.2, Async1G. Considering the notations:

g1 g2 g3 g4

=b =b =b =b

(timer = 0); (timer = 1000); (timer = 2000); (timer 62 f0; 1000; 2000g);

we further identify (section 4.2.2):

choice1 =b g1 ! lights := red [] g2 ! lights := yellow [] g3 ! lights := green [] g4 ! lights := lights0 :(lights0 = lights); choice2 =b timer := (timer + 1) mod 3000 The original system is re ned to:

62


sys T LC 0 (req; ack : boolean; lights : TL; timer : integer; ) :: j[ init lights = red; timer = 0; req; ack = false; do S1; S2 od ]j; where

S1 =b :req ! ack := false [] req ! ack := true; S2 =b (req ! choice1 ; choice2 ) [] :req ! skip Further, perform the changes:

choice1 S21 ; S21 =b lights := lights0 :QL QL =b (g1 ) lights0 = red) ^ (g2 ) lights0 = yellow) ^(g3 ) lights0 = green) ^ (g4 ) lights0 = lights); choice2 S22 ; S22 =b timer := timer0 :QT ; QT =b (timer0 = (timer + 1) mod 3000); S2 S20 ; S20 =b (req ! S21 ; S22 ) [] :req ! skip We continue with:

S200 S20 1; S20 2; S20 1 =b lights := lights0 :((req ) QL ) ^ (:req ) lights0 = lights)) = lights := lights0 :Q00L S20 2 =b timer := timer0:((req ) QT ) ^ (:req ) timer0 = timer)) = timer := timer0 :Q00T ; S1 Sack ; Sack =b ack := ack0 :Qack ; Qack =b (req ) ack0 = true) ^ (:req ) ack0 = false) As the synchronization requirement S.R. 4 is respected, we can write

S20 1 ; S20 2 Sv ; Sv =b S20 1 ? S20 2 Due to the transitivity of the re nement relation, we also have

4.4. AN EXAMPLE: THE TRAFFIC LIGHTS CONTROLLER

63

T LC0 v T LC00 ; sys T LC 000 (req; ack : boolean; lights : TL; timer : integer; ) :: j[ init lights = red; timer = 0; req; ack = false; do Sack ; Sv od ]j Next we introduce the intermediate variables lightsm ; timerm and ackm :

Rv1 Wv1 Rv2 Wv2 Rack Wack and

=b =b =b =b =b =b

lightsm := lights0m :Q00L ; lights := lightsm ; timerm := timerm0 :Q00T ; timer := timerm ; ackm := ackm0 :Qack ; ack := ackm ;

T LC00 v T LC 000; sys T LC 000 (req; ack : boolean; lights : TL; timer : integer; ) :: j[ var lightsm : TL; ackm : boolean; timerm : integer; init lights; lightsm = red; timer; timerm = 0; req; ack = false;

do Rack ? Rv1 ? Rv2 ; Wack ? Wv1 ? Wv2 od

]j The synchronous format is nally reached:

T LC000 v ST LC ; sys ST LC (req; ack : boolean; lights : TL; timer : integer; ) :: j[ init lights = red; timer = 0; req; ack = false; do S20 1 r S20 2 r Sack od ]j

Comments. In the above exempli cation we showed in detail all the steps performed in order to correctly transform an initially asynchronous description into a synchronous one. We consider that the translation into ST LC is quite a direct one and it could be done automatically, once the requirements S.R. 1 to S.R. 4 have been checked on system T LC . A subsystem-based design of the trac lights controller is presented in [71]. The approach is based on a pair of subsystems: one describes the timer operations and the other describes the updates on the variable lights. The communication between subsystems is done with the help of a third system (E nv), which sends the request and receives the acknowledge signals.

64


4.5 Implementation Aspects Circuit design is the transformation of a speci cation describing the required behavior into an equivalent one that is suitable for direct implementation in hardware. A synchronous machine is de ned as consisting of a combinational network, with feedback from outputs to input via edge-sensitive devices [55]. In this section, we present the immediate hardware re ection of some basic constructs.

Elementary cell. As a particular implementation issue we will consider the

assignment for a one-bit variable. In this case, the design would describe a common digital circuit: a storage element, the D-type ip- op (Figure 4.3). We

Figure 4.3: D Flip- op will refer to this circuit as the elementary cell. The elementary cell represents the lowest level of a synchronous system description. A collection of elementary cells creates a register, or a basic cell. For a bottom-up design, the elementary cell should be the starting point when describing a synchronous system.

Implementation of a two-phase action. The trivial two-phase action (sec-

tion 3.2.1)

TAe =b var clk : bool; (:clk ! RA } clk ! WA) == C = var clk : bool; (:clk ! u := u0 :Q00 } clk ! v := u) == :clk ! clk := true [] clk ! clk := false

is transformed into a circuit block diagram as follows. First, the two-phase action TA0 =b :clk ! RA } clk ! WA is interpreted as a data register sensitive to the rising edge of the clock signal clk. Input data u is prepared when clk is false, and output data v is updated when clk is switched to true.

4.5. IMPLEMENTATION ASPECTS

65

The read part (section 3.2.1)

RA =b u := u0 :Q00 ; Q00 =b (b ) Q[u0 =v0 ]) ^ (:b ) u0 = u); taken separately, can be interpreted in two dierent ways (Figure 4.4): The condition u0 = u is viewed as a skip operation, and the combinational logic implementing the boolean condition b is used to gate the clock clk. This means that the eective clock clk0 observed at the register is stopped whenever the guard b becomes false, and the assignment to the output variable v is skipped altogether. A more detailed description of the gated clock issues is presented in Chapter 5. The condition u0 = u is implemented as the assignment u := v, which will preserve the current value of the output v at the write phase. In this case, the choice controlled by the boolean condition b can be interpreted as a multiplexer whose selection input is driven by the combinational logic implementing b. In both interpretations, the predicate Q is implemented as a combinational circuit which computes input data u for the register. In the latter case, however, the output of this combinational logic is multiplexed with the output v of the register. Observe that the output v can be one of the inputs of Q or b as well. Finally, the clock action

C =b :clk ! clk := true [] clk ! clk := false is interpreted as an independent clock generator which delivers the clock signal

clk to the register.

The block diagrams shown in Figure 4.4, excluding the clock generator C , are called basic cells.

Implementation of a synchronous system. Consider a non-trivial synchronous action system with several actions Ai , which can be represented in any of the following formats:

sys A (g) :: j[ do A1 re : : : re An od ]j; or sys A (g) :: j[ do TA1 re : : : re TAn od ]j; or sys A (g) :: j[ var u1 ; : : : ; un ; init u1 ; : : : ; un := v1 ; : : : ; vn ; do (RA1 ? : : : ? RAn ) }e (WA1 ? : : : ? WAn ) od ]j The synchronous composition operator `re ' synchronizes the read and write parts of the separate two-phase actions TAi . The phases are sequenced by the common


u

Q inputs

Q v

Reg b

Mux

66

u

inputs

Reg

v

b

clk’

clk clk

C

C

Figure 4.4: Basic cells with gated clock or multiplexer. boolean variables p and clk hidden into the clock operator `}e '. Hence, we implement each component action separately and connect the resulting cells to a common clock generator. The block diagram of a construct with two cells is shown in Figure 4.5. Note that the cells can naturally share input variables and read outputs of each other.

inputs 1

inputs 2 clk

Cell A1

v1

Cell A2

v2

C

Figure 4.5: Composition of two basic cells

Choice. On the hardware level, choice can be represented with the help of a multiplexer placed in the combinational circuit of a register (Figure 4.6). Sequence of choices. The hardware representation of the sequence is a repetition of the schematic in Figure 4.6, for as many times as choices in the sequence.

4.6. PIPELINING

67

The relative placement of choice blocks is dictated by the input/output variables of each construct.

Figure 4.6: Choice as a multiplexer

4.6 Pipelining Pipelining is a very common technique used in digital systems design in order to increase parallelism. It has an important impact on the rate at which data is produced and consumed, a pipelined version allowing a higher speed than the non-pipelined version of the same circuit [52]. Furthermore, if a computation task is split into suciently simple subtasks, the supply voltage of the circuit can be reduced still maintaining the required clock frequency. Hence, pipelining can be utilized in low-power design as well [27, 64]. In our descriptions, pipelining will be re ected in transforming a synchronous system into another synchronous system, with a larger number of (simpler) actions and an equivalent behavior with respect to input or output variables.

4.6.1 Timing issues

An important aspect of synchronous operating devices is the computation of the period of the clock signal. All the combinational logic computations have to oer a stable value just as the clocking signal comes close to the active edge. At higher levels of design, the actual gure of the period can only be estimated. However, based on the experience of the designer and on technical information, estimation can often be considered accurate. As shown in section 3.1, a digital design implementation, eventually, comes down to a gate level description (of course, the design process continues even further, to silicon level, but this is not part of the present study). The gates implemented in a given technology have associated certain propagation delay gures. The propagation delay represents the time needed for the output of the

68


gate to stabilize after the occurrence of a change in the input signal (as long as this one triggers a change of the output). Based on lower level data, one has quite accurate information about dierent gate delays. Thus, the designer is able to approximate, within a certain error interval, the delay of the implementation of some synchronous action. For this, it is necessary that the descriptions be brought to the level at which one can fairly approximate the propagation delay of the updates performed by the systems under study. Through a repeated process of data re nement, the actions of every synchronous action system can be detailed at the desired level. The critical or longest path issue is tightly connected with the process of determining the necessary clock period, so that a synchronous device operates as intended. It refers to the longest period required so that an input signal propagates its in uence to the output. Usually this is computed based on the number of gates the speci c input signal has to propagate through: the designer adds the propagation delay gures for every gate that the signal nds in its way to the output. In the present-day digital design, due to the technical advances, such as sub-micron VLSI technologies, the delay of gates comes closer and closer in value to the delays produced on wires. Thus, targeting an accurate estimation this aspect should also be taken into consideration. However, in the following we only take into account the gate delays of a digital circuit. By identifying the critical path within a gate-level implementation, the designer is able to predict the period of time after which all the actions complete their updates. This leads further to the decision on the clock frequency (period). Example 8 Consider the update on the variable v, performed by the action A =b v := v0 :QA, where QA =b v0 = ((a b) ^ (b _ a _ c)) ^ d. The implementation of action A is represented in Figure 4.7. As mentioned earlier, the implementation of Q is represented by the combinational logic at the input of the storage element A.

By analyzing the appropriate technology information, the designer knows the propagation delays corresponding to the used gates. (They are shown in Figure 4.7. The values are purely for exempli cation purposes). Thus, one can estimate that, for a correct update, the implementation of action A needs at least 20n s (the dotted line in Figure 4.7). If this is the largest delay of the whole synchronous system, then the clock period can be set to 20n s. f End of Example g

In the next sections and chapters, we will often compare two or more synchronous actions in terms of their complexity (or the complexity of the predicates describing the updates on the actions' output variables). We estimate this by comparing the propagation delay associated with the implementation of each involved actions. The term delay of A will correspond to the period of time ne-

4.6. PIPELINING

69

S t o r a g e d e v i c e s

a b c

5n s

5n s

10n s d

5n s A

Clock generator

Figure 4.7: Critical path computation. cessary for the hardware implementation of the action A to update the speci ed output. We obtain faster circuits, in terms of throughput, by increasing the parallelism of the design and the clock frequency. Thus, the combinational logic placed at the input of a storage element should be as \simple" as to allow a high clock speed. The two-phase action de nition does not specify any representation level for the update performed on the action's output variable(s). This means that the updates can be described by very complex relations. If we try to implement them directly, we would probably end up with a not convenient (in terms of speed) gure corresponding to the clock period, because of a large propagation delay associated with the implementation. In order to obtain larger operating speed, we have to split the complex actions into several parts so that the predicates become simpler, and then the direct implementation provides lower values for the propagation delays. We analyze in more detail these aspects in the next section.

4.6.2 Non pipelined vs. pipelined systems Actions in a synchronous composition are not necessarily of the same complexity. Very probably, some of them might even require several clock steps to execute, motivated by hardware related issues (in the case of complex updates). However, the synchronous composition of these actions speci es that their updates are simultaneous. To satisfy this requirement, as well as to adapt to the speci c hardware aspects, the execution of complex actions can be split (having as a result several new simpler actions), while the execution of the actions that do

70


not need splitting is delayed so that the updates on the write variables of the synchronous composition are simultaneous. Example 9 Let us analyze the synchronous implementation of the action system

sys A (g) :: j[ var l; init l; g := l0; g0 ; do A r B od ]j Suppose further that the operations described by the actions A and B are very complex, and thus, the delays of A and B have larger values than the period of the clock signal that we would like to operate the device. One solution for reaching the clock frequency requirement can be a pipelined representation and implementation of the system.

a

QA

d1 QA1

d n-1

D1

Q A n-1

D n-1

a QAn

A'

QBn

B'

A

b QB

Combinational logic

clk 1

Combinational logic

clk 2

B

clock gen.

a) Non-pipelined implementation of actions A and B

clock gen.

c1 QB1

C1

c n-1 Q B n-1

C n-1

b

b) Pipelined implementation of actions A and B

Figure 4.8: Non-pipelined vs. pipelined implementation of synchronous actions. A non-pipelined vs. a pipelined hardware implementation of the system A is presented in Figure 4.8, where the clock frequency of the pipelined version can be n times higher than for the non-pipelined version. The updates initially performed by action A and B in a single clock step are split over n shorter clock periods. f End of Example g On the other hand, suppose that, in the above example, the delay of B is suciently small, so that the corresponding implementation would also t the new (higher) frequency. But this is not valid for action A. Thus, we would still need to split A over n stages. However, B can be left as it is, but it must update the output variable simultaneously with the last stage of (the original) A. At the

4.6. PIPELINING

71

implementation level, this is realized by buering the input variables of B . This means that the combinational logic at the input of each storage element in the chain C1 ; : : : ; Cn;1 (Figure 4.8 b)) only passes the input variables to the next element (practically, there are only wires). Thus, the combinational logic at the input of the last storage element B 0 performs the update of the original action B , but taking as input the buered versions of the input variables of the original action B . If this is the case, the actions C1 ; : : : ; Cn;1 are called buering actions and are described as Cj =b cj := cj ;1 ; j = 1 : : : n ; 1: In the following, we rst introduce notions and procedures that will help us develop a method of transforming a synchronous action system from a nonpipelined into a pipelined format.

4.6.3 Local variable introduction

In this section, we adapt the local variable introduction rule presented in [16] to our speci c purposes. Consider the action system: sys A (g) :: j[ var l; init g; l := g0; l0 ;

do A od

]j where A =b a := a0 :Qa ; a 2 g. We introduce a new local variable b, updated as speci ed by the predicate Qb of action B : B =b b := b0:Qb At the system level we have

A v A1 ; l0 =b l [ fbg; sys A1 (g) :: j[ var l0; init g; l0 := g0 ; l00 ; do A; B od ]j

If the variable a does not appear free in Qb , that is, if action B does not read the updated variable a, then we can transform the sequence A; B of the above system A1 into A ? B : A; B A ? B;

A1 v A2; sys A2 (g) :: j[ var l0; init g; l0 := g0 ; l00 ; do A ? B od ]j

72


Hence, we can directly introduce new variables by either extending a simultaneous assignment (in case this already existed), or by creating it, as in the situation of system A2 . Notice also that A is not supposed to be the only action of the initial system A: Thus, A can be part of a more complex construct within the main loop of the system. Next, we extend the local variable introduction technique, now in the context of a synchronous system. Consider sys S ync (g) :: j[ var l; init g; l := g0 ; l0 ; ]j;

do A r B od

A =b a := a0:Qa ; B =b b := b0 :Qb

At the choice level, we have sys S ync (g) :: j[ var l; p; uA ; uB ; init g; l; p; uA ; uB := g0 ; l0 ; false; a; b; do :p ! RA ? RB ; p := true [] p ! WA ? WB ; p := false ]j

od

RA =b ua := u0a :Qa [u0a =a0 ]; RB =b ub := u0b :Qb [u0b =b0 ]; WA =b a := ua ; WB =b b := ub

We intend to introduce a new local variable c. The action C is updating the new variable and is executed synchronously with the other actions, A and B . Thus, we also need an intermediate variable (uC ) for the two-phase modelling of C . We apply twice the previously discussed results, for the introduction of the intermediate variable uc and the variable c, respectively. We then have the following system description:

S ync v S ync1; sys S ync1 (g) :: j[ var l; p; c; uA ; uB ; uC ; init g; l; p; c; uA ; uB ; uC := g0 ; l0 ; false; c0 ; a; b; c0 ; do :p ! RA ? RB ? RC ; p := true [] p ! WA ? WB ? WC ; p := false od ]j; RC =b uc := u0c:Qc [u0c=c0 ]; WC =b c := uc

4.6. PIPELINING

73

Using appropriate de nitions, we further represent the system as sys S ync1 (g) :: j[ var l; c; init g; l := g0; l0 ; c0 ; ]j

do A r B r C od

4.6.4 Elimination of a local variable

Elimination of a local variable can often help simplifying the description of a system. Related to hardware implementation issues, this can be viewed also as a reduction in signal lines and area of the device. We intend to apply the rules of eliminating local variables [16] to a synchronous composition of actions. Thus, we need to check only one of the requirements: the variable to be eliminated appears solely in assignments to itself, or, in other words, it is a ghost variable. If this happens, then we can eliminate the variable from the synchronous system, together with the action that updates it.

4.6.5 Pipelining procedure

Let us consider now a synchronous action system resulted from the design process presented in previous sections. We have the composition E nv == A, where the system A is a synchronous action system. Thus, sys A contains the action ACK that updates the acknowledge signal ack : sys A (req; ack : bool; x; y; a; b : data) :: j[ var l; init l; x; : : : ; b := l0 ; x0 ; : : : ; b0 ; req; ack := false do A r B r ACK od (1) ]j; where A =b a := a0 :QA; QA =b (req ) Qa) ^ (:req ) a0 = a); 0 B =b b := b :QB ; QB =b (req ) Qb ) ^ (:req ) b0 = b); ACK =b ack := ack0 :QK ; QK =b (req ) ack0 = true) ^(:req ) ack0 = false) Let us now assume that the direct circuit implementation of the actions A and B of the system A is estimated to be so complex that it cannot be operated with the speci ed clock frequency. Then the computations of A and B have to be divided into n (n1) phases each of which is simple enough to be executed in one clock cycle. A set of n ; 1 new local variables is introduced for every action we split, in order to store the results of each phase. The combinational logic that updates the variable ack is a very simple construct. Consequently, the update is possible to be completed in a single clock step.

74


For simplicity, in the description of system A, we consider that rA = x; wA = a; rB = y; wB = b. Naturally, rack = req and wACK = ack. Thus, the predicate QA is a relation on a0 and x, etc.

Pre-analysis step. Intuitively, the rst step in dividing the action A into n

pipelined actions is to transform it locally into the atomic n-element sequence:

A A0 ; A0 =b A0 ; : : : ; An;1 ; Aj =b aj := a0j :Qja ; j = 0; : : : ; n ; 1; an;1 = a The above re nement requires that (Q0a ^ Q1a [a00 =a0 ] ^ : : : ^ Qna ;1 [a0n;2 =an;2 ]) QA Each action of the sequence A0 reads the values of the variables updated by the previous action in the sequence. Thus, it is not possible to obtain a synchronous representation of the action A0 (for instance A0 r : : : r An;1 ), as the composing actions breach the mentioned synchronization requirement (section 4.2.3). However, this study is necessary as it indicates what the relations Qja ; j = 0 : : : n ; 1 are (in other words, it shows how to split the execution of action A). They will be used in the following steps, when we describe the transformation of the system A into an equivalent pipelined system. Observe that a similar procedure is to be applied to action B , too. Step 1. Buering. We start the transformation of the action system (1) by introducing 3 (n ; 1) variables, (n ; 1) of which will help us obtain the pipelined version of each action in the system. Consequently, we also have 3 (n ; 1) new actions. Initially we only modify the original actions so that they have as input the new local variables, instead of the initial global variables. We have: sys A1 (req; ack : bool; x; y; a; b : data) :: j[ var l; a0 ; : : : ; an;2; b0 ; : : : ; bn;2; req0; : : : ; reqn;2; init l; x; : : : ; b := l0 ; x0 ; : : : ; b0 ; req; ack; req0 ; : : : ; reqn;2 := false; a0 ; b0 ; : : : ; an;2; bn;2 := a00 ; b00 ; : : : ; an;20 ; bn;20 ;

where

]j;

do A0 r A0 : : : r An;2 rB 0 r B0 : : : r Bn;2 rACK 0 r ACK0 : : : r ACKn;2 od

A0 =b A[an;2; reqn;2 =x; req];

4.6. PIPELINING

75

B 0 =b B [bn;2; reqn;2 =y; req]; ACK 0 =b ACK [reqn;2=req] and the new (buering) actions are A0 =b a0 := x; B0 =b b0 := y; ACK0 =b req0 := req; Sj =b sj := sj ;1;

s 2 fa; b; reqg; S 2 fA; B; ACK g; j = 1 : : : n ; 2

The hardware implementation of the system A1 is shown in Figure 4.9.

x

a0

an-2

A0

An-2

clk y

req

QB[bn-2,reqn-2/ y,req]

B'

bn-2 Bn-2

req0 ACK0

A'

clock gen.

b0 B0

a QA[an-2,reqn-2/ x,req]

b

ack

reqn-2 ACKn-2

QK[,reqn-2/ req]

ACK'

Figure 4.9: Intermediate stage in the pipelining process. The result of Step 1 is the re nement A v A1 : This is obtained due to the replacement of the input variable req with the new local variable reqn;2 in the actions A0 ; B 0 and ACK 0 . Thus, until reqn;2 = true; the system A1 does not modify its observable state (it stutters). Also, after req becomes false, until reqn;2 = false, the system stutters again. Step 2. Auxiliary actions. Next, we introduce 2 n additional actions D0 ; : : : ; Dn;1 and C0 ; : : : ; Cn;1 , that synchronously update the new local variables d0 ; : : : ; dn;1 and c0 ; : : : ; cn;1 , respectively. We have D0 =b d0 := d00 :Q0D ; Q0D =b Q0a [d00 =a00 ]; C0 =b c0 := c00 :Q0C ; Q0C =b Q0b [c00 =b00 ] and

76


For j = 0 : : : n ; 1; the actions Dj and Cj update the corresponding output variables as speci ed by the predicates selected in the pre-processing step:

Dj QjD Cj QjC

=b =b =b =b

dj := d0j :QjD ; (reqj ;1 ) Qja [d0j =a0j ]) ^ (:reqj ;1 ) d0j = dj ); cj := c0j :QjC ; (reqj ;1 ) Qjb [c0j =b0j ]) ^ (:reqj ;1 ) c0j = cj )

At the system level we have, based on the results of section 4.6.3, sys A1 v sys A2; where A2 is described as

sys A2 (req; ack : bool; x; y; a; b : data) :: j[ var l; a0 ; b0 ; req0; d0 ; c0 : : : ; an;2; bn;2 ; reqn;2; dn;1 ; cn;1 ; init l; x; : : : ; b := l0 ; x0 ; : : : ; b0 ; req; ack; req0 ; : : : ; reqn;2 := false; a0 ; b0 : : : ; an;2 ; bn;2 := a00 ; b00 : : : ; an;20 ; bn;20 ; d0 ; c0 : : : ; dn;2 ; cn;2 := d00 ; c00 : : : ; dn;20 ; cn;20 ; do A0 r A0 : : : r An;2 rB 0 r B0 : : : r Bn;2 rACK 0 r ACK0 : : : r ACKn;2 r C0 : : : r Cn;1 r D0 : : : r Dn;1

]j

od

Step 3. Removal of auxiliary variables. The nal description. Next,

notice that

req ^ reqn;2 ) (QnD;1 [a=dn;1 ] QA[an;2 ; reqn;2 =x; req]) ^ (QnC;1[b=bn;1 ] QB [bn;2; reqn;2=y; req]) The interpretation of the above relation is as follows. The update on variable a; either according to QA , or to QnD;1, leads to the same result. Therefore, we can write A0 A00 ; A00 =b Dn;1 [a=dn;1 ]; B 0 B 00 ; B 00 =b Cn;1 [b=cn;1 ] From the above relations, it follows further that the variables an;2 ; bn;2 become ghost variables. Thus, we can safely eliminate them from the system description, together with the actions that update them. We repeat this procedure for the variables aj ; bj (j = n ; 3 : : : 0) and for the corresponding actions. Eventually we come to the system:

4.6. PIPELINING

77

A2 v A3; sys A3 (req; ack : bool; x; y; a; b : data) :: j[ var l; req0; d0 ; c0 : : : ; reqn;2; dn;1 ; cn;1 ; init l; x; : : : ; b := l0 ; x0 ; : : : ; b0 ;

req; ack; req0 ; : : : ; reqn;2 := false; d0 ; c0 : : : ; dn;2 ; cn;2 := d00 ; c00 : : : ; dn;20 ; cn;20 ; do A00 r B 00 r D0 : : : r Dn;2 r C0 : : : r Cn;2 rACK 0 r ACK0 : : : r ACKn;2

]j

od

The implementation of the system A3 is shown in Figure 4.10. d0 req x

Q D n-2

Combinational logic

req y

d n-2

D0

Q D0

clk 2

D n-2

req

c n-2 Q C n-2

C0

C n-2

req 0 ACK 0

A''

clock gen.

c0 Q C0

a

Q A [d n-2 ,req n-2 /x, req]

b

Q B [c n-2 ,req n-2 /y, req]

B''

req n-2 ACK n-2

ack QK

ACK'

Figure 4.10: The system A3 in hardware.

Comments. The above procedure helps only towards obtaining a pipelined

description of a certain synchronous action system. This mainly means that the implementation of the speci c system can operate at higher frequencies. In order to get improved results with respect to the throughput of the whole design, the systems that interact with the just pipelined system have to be modi ed accordingly. This further step is dependent on the particular device that we want to describe and implement, and thus, we do not continue in this direction. When analyzing pipelining issues, the main drawback of our approach comes from the selection of the communication protocol. While it proved to be a very good selection when describing the concepts of asynchronous to synchronous transformation, the four-phase, single-data protocol cannot help us in provid-

78


ing faster throughput for a pipelined synchronous system. This is due to the fact that the system has to acknowledge after processing every data sample. The generic system Async2G shows an improvement with respect to this situation. However, it is required that it performs a known number of operations. The solution would be to change the communication protocol to a block-data four-phase protocol, presented in Figure 4.11.

request

acknowledge data in

data out

one transaction

Figure 4.11: Block four-phase protocol. The buering of the action ACK is important not only because the outputs of the system have to be simultaneously updated. The intermediate variables reqj ; j = 0 : : : n ; 2, delayed copies of req, help us in controlling the phase of the operation and provide a way to obtain o correct transition into the pipelined version. This is visible in the description of Step 1 and Step 2. There we have, for instance that: A0 =b a := a0 :QA[an;2 ; reqn;2 =x; req]; Dj =b dj := d0j :QjD ; QjD =b (reqj ;1 ) Qja [d0j =a0j ]) ^ (:reqj ;1 ) d0j = dj ) It is interesting to think of what happens when the request line is set (req = true) by the master system, for the rst time. If the above actions were: A0 =b a := a0 :QA [an;2=x]; Dj =b dj := d0j :QjD ; QjD =b (req ) Qja [d0j =a0j ]) ^ (:req ) d0j = dj ); then they would have started updating their output variables as soon as req = true. Thus, the traces of the pipelined and non-pipelined versions of the system

4.6. PIPELINING

79

under analysis would not match for the rst n ; 1 states following req = true. Using the replacement reqj =req means that the pipelined system stutters for the rst n ; 1 clock steps, thus allowing us to perform a correct transformation. On the other hand, it is equally interesting to observe how the output evolves after the request line is released: the variables reqj ; = 0 : : : n ; 2 turn false, one after the other, with every clock step. This means that the output of a pipeline stage, the kth , for instance, remains unchanged after reqk = false. Thus, the following stages in the pipeline also do not perform changes in their output, even though their request lines are still true, but this is due to the fact that their corresponding inputs are the same. Therefore, the whole pipelined system stutters also after the master system released the request line, until the last stage of the initial action ACK changes the value of the signal ack (to ack = false) and after this, the master system takes control. The existence of the request/acknowledge signals helps us obtain the pipelined version of a synchronous action system. However, if we start from a synchronous system composition, things are dierent with respect to the control of the pipeline. One solution would be to introduce a local variable that keeps track of the current phase of the operations. We take this idea into consideration in Chapter 7. In the previous paragraphs we presented in detail the proposed pipelining procedure for synchronous action systems. Nevertheless, it is easy to observe that after the pre-process step, when we have enough information on how the initial actions are to be divided over several stages, the pipelined version of the analyzed system can be obtained directly, as in the following example. More details regarding pipelining control issues are subject of current studies [72]. Example 10 Consider the synchronous system

sys S ync (req; ack : bool; a; b : integer) :: j[ init a; b := 1; 0; req; ack := false; do A r B r ACK od ]j

where:

QA =b (req ) a0 = (a + 2) 4 + 4) ^ (:req ) a0 = a); 0 B =b b := b :QB ; QB =b (req ) b0 = b + 1) ^ (:req ) b0 = b); 0 ACK =b ack := ack :QK ; QK =b (req ) ack0 = true) ^ (:req ) ack0 = false) A

=b a := a0 :QA ;

For the purpose of exempli cation, let us consider that the execution of A takes a longer time than the execution of B (depending on the width of the

80


bit representation of a and b, this might even be true, but not in a dramatic manner). For instance, suppose we want a four times higher operating frequency, than the one that would allow the operations described by action A to complete. Consequently, we have to split the execution of action A into four stages (n = 4). We consider that the implementation of action B is not that complex, hence, it is possible to perform with the new, faster frequency. The pre-process analysis gives us the following sequence: A0 =b A0 ; A1 ; A2 ; A3 ; A0 =b a0 := a00 :Q0a; Q0a =b (a00 = a + 2); A1 =b a1 := a01 :Q1a; Q1a =b (a01 = a0 2); A2 =b a2 := a00 :Q2a; Q2a =b (a02 = a1 2); A3 =b a3 := a03 :Q3a; Q3a =b (a03 = a2 + 4) From here we can directly obtain the pipelined version of the system S ync as: sys S yncP (req; ack : bool; a; b : integer) :: j[ var d0 ; d1 ; d2 ; b0 ; : : : ; req2; init a; b := 1; 0; req; ack; req0 ; req1 ; req2 := false; d0 ; : : : ; b3 := d00 ; : : : ; b30 ;

]j;

do A00 r D0 r D1 r D2 r B 0 r B0 r B1 r B2 r ACK 0 r ACK0 r ACK1 r ACK2 od

where

A00 =b a = a0 :((req2 ) a0 = d2 + 4) ^ (:req2 ) a0 = d2 )); B 0 =b b := b0 :((req2 ! b0 = b2 + 1) ^ (:req2 ) b0 = b)); ACK 0 =b ack := ack0 :((req2 ) ack := true) ^ (:req2 ) ack := false)) and

D0 =b d0 := d00 :Q0D ; Q0D = (req ) d00 = a + 2) ^ (:req ) d00 = d0 ); D1 =b d1 := d01 :Q1D ; Q1D = (req0 ) d01 = d0 2) ^ (:req0 ) d01 = d1 ); D2 =b d2 := d02 :Q2D ; Q2D = (req1 ) d02 = d1 2) ^ (:req1 ) d02 = d2 ) The actions Bj ; ACKj j = 0 : : : 2 are buering actions as described in previous paragraphs. The hardware implementation of the system S yncP is shown in Figure 4.12.

4.7. DESIGN OF SYNCHRONOUS ACTION SYSTEMS IN BRIEF

d0

d2

D0

d 0 := a + 2

req

d 2 := d 1 * 2

Combinational logic

clk 2

D2

b 0 := b

B0

req

A''

b2 b 2 := b 1

b

B2

req 0 ACK 0

a a := d 2 + 4

clock gen.

b0 req

81

b := b 2+ 1

B''

req 2 ACK 2

ack ack :=req

2

ACK'

Figure 4.12: Pipeline example.

4.7 Design of Synchronous Action Systems in Brief The design methodology of synchronous action systems is based on the correct derivation of synchronous-implementable systems from an initial (asynchronous) speci cation. While the theory behind this might be considered complex, it can be made transparent to the user, as the process can easily be mechanized. We consider this because, after checking the conditions S.R. 1 to S:R:4; it should not be a dicult task to build a program that translates the choices into HI - assignments and replace the sequence with a synchronous operator. However, building this program was not one of the priorities of this thesis. Therefore, this is a subject to be analyzed in further studies. The requirement S.R. 3 (section 4.2.2) ensures an increase in the determinism of the system, unlike in the reactive modules of Alur and Henzinger [2], where the non-determinism is preserved through dierent stages of design. The requirement also provides the possibility of a correct translation into VHDL code (Chapter 6). Two of the main aspects that we can consider as rules to follow in the translation of the asynchronous system into a synchronous one: Rule (i) Provided the conditions S.R. 2 and S.R. 3 are respected, it becomes possible to have a correct translation of each choice into a non-deterministic assignment. Rule (ii) If also S.R. 4 is complied with, then a sequence of non-deterministic assignments can be correctly translated into a simultaneous assignment. In the following, we present a sequence of steps that one has to follow in order to reach a synchronous description from an initial asynchronous one. The design

82


steps rely on the fact that it is possible to reach a description that maps to either of the generic systems presented in section 4.2.2. Step 1: The (possibly necessary) re nement of the initial asynchronous description in order to match one of the presented generic formats, satisfying the synchronization requirements. Most probably, this is a repeated operation of transforming choices or sequences at certain (low) levels into non-deterministic assignments. In their turn, these are part of (upper level) choice compositions. Step 2: Re nement into one of the generic asynchronous formats (Async1G or Async2G). Step 3: Preparing for the re nement into the synchronous format (S yncG): Step 3:1 The separation of the actions that update the req=ack signals from the choice(s). (It can be also delayed for some later stage.) Step 3:2: Every choice-compositions in the sequence choice1 ; : : : ; choicen is transformed into an HI - assignment. Step 3:3: The above obtained sequence of non-deterministic assignments is changed into a single HI - assignment:

A =b v := v0 :Q; v =b fv1 ; : : : ; vn g

Step 3:4: After this, also the resulting construct: req ! A [] :req ! skip; is transformed into

A0 =b v := v0 :((req ) Q) ^ (:req ) V )); V =b v0 = v

Step 3:5: The choice-composition that updates the communication variables

(req and ack) is also transformed into the non-deterministic assignment format, similar (depending on the chosen generic asynchronous system) to:

B =b ack := ack0:((req ) ack0 = true) ^ (:req ) ack0 = false))

Step 3:6: The sequence of non-deterministic assignments B ; A0 is translated into a simultaneous composition, C =b A0 ? B (Rule (ii)). Step 4: The action C is translated into a two-phase action, as shown in section

3.2.1. Notice that the above steps can be performed on a single large system, or, if the designer has already split the top level into several smaller sub-systems, the steps are applied to these ones, instead. Next, the synchronization of the systems is done as presented in section 4.3. Pipelining operations can be performed even

4.7. DESIGN OF SYNCHRONOUS ACTION SYSTEMS IN BRIEF

83

at a later stage of the design (if this has not been observed as necessary earlier), by means of local variable introduction. The synchronous system(s) obtained using the above-described formal design

ow preserves the presence of communication variables req=ack. The signals will also be present in the nal hardware implementation, and this will produce some area-overhead. The corresponding actions (that update these variables) could be further removed from the nal description. This can be looked at as a re nement of the composition j[ E nv == S ync ]j, where we reveal all the (global) variables but the ones composing the communication channels. (Intuitively it is obvious that this would not aect the correct functionality of the devices, with respect to the other variables of the composition.) As mentioned earlier, not all the asynchronously described action systems are possible to be transformed into their synchronous counterparts. On the opposite side, it may also be possible that a system that does not map to the generic formats (section 4.2.2) could still be correctly translated into a synchronous representation. In this chapter, we described one possibility of reaching a synchronous two-phase representation from an initially asynchronous one. Some other methodologies might be possible to apply.

Fairness issues. The notion of fairness is a very general concept and can be

used to coin terms in many dierent application areas. This wide variety of possibilities leads to a confusing situation: selection of a particular de nition of fairness for any particular model or language relies almost exclusively on subjective, implicit criteria [4]. We discuss here two of the most common fairness issues that appear in dierent languages [4, 78, 46] targeting hardware / software implementations. Fairness problems are usually avoided by specifying certain fairness constraints that are included in dierent manners in the speci c language the designer uses. We will see that, in our approach, we do not need such mechanisms, as both of the issues we discuss here are resolved in the same manner. First, we address the liveness property, as de ned in [4]: an action will eventually be executed in some process, if the system is not deadlock. This may be identi ed also as the feasibility assumption: all actions that are in nitely enabled are eventually chosen for execution. The most usual solution to enforce these properties is to employ a scheduler, which raises a set of problems of its own [4, 78]. Secondly, we can address robustness [4]: two linear execution sequences which are identical up to the order of two independent actions, should be equivalent. An important contribution to hardware design within the framework of Action Systems is described in [58]. Even though the conventional Action Systems formalism does not contain any fairness assumptions, the author speci es that the

84


actions of an (asynchronous) action system be supposed to behave in a weakly fair manner. This means that every continuously enabled action is eventually selected for execution (similar with the above de nition of feasibility). In other words, in nite successive selection of an action Ai is not possible, if there is some other action Aj which remains enabled simultaneously with Ai . The synchronous action systems are always enabled systems, as their actions are always enabled. Using a parallel composition between an environment modeling system and a synchronous action system would force us to also provide some weak fairness assumptions. This aspect has to be extended from actions to action systems (a quite smooth step, considering the de nition of the parallel composition - section 2.2.1). In our case, the mentioned fairness aspects are not to be raised within a synchronous action system. This is due to the fact that all the composing actions are executed simultaneously, once the request line is set. Being disabled, in this situation, means performing only a false update of the output. The use of the prioritized composition, which de nes the synchronous system as the slave component, together with the communication protocols that we employed, lead to the same conclusion at the system level: no need for fairness-enforcing constraints. A synchronous system and its environment execute in turns: after request, eventually, the slave raises the signal ack, the environment-system becomes enabled and precludes the synchronous system from execution. We may relate robustness aspects with the situation described in section 4.3. The possibly necessary scheduling may come by assigning values in a certain mode to the req signals, thus imposing a relative order in the execution of the synchronous systems, if necessary. Concluding, the design ow we proposed for the development of synchronous action systems does not raise the problem of specifying fairness constraints. Still, a certain ordering of the updates can be realized by means of communication signals controlled by the master system. On the other hand, in the design of synchronous action systems we have to check the compliance with the four synchronization requirements.

Traces. As with fairness, the observable behavior of systems describing hard-

ware devices is also a common technique in dierent approaches. It is mainly used in order to allow changes / replacements in the description of systems, by analyzing how the environment observes the new entities, compared to the old ones. Trace re nement played a central role in the derivations described in this chapter. The de nition of a trace diers slightly from one approach to other. Therefore, we might consider our own de nition oered in section 2.3.2 as a general one: a trace is de ned as the sequence of global states (stuttering states considered as one).


85

Dierences in de nitions mostly appear as some languages allow dierent levels / strengths of trace equivalence. For instance, Milner [53] de nes a weak trace equivalence in terms of sequences of observable actions (eliminating the internal, stuttering actions). It is appreciated as weak because it allows a deadlocking system to be trace equivalent to a non-deadlocking one. In our study, a stuttering system is trace re ned into a terminating system, as described in Chapter 5. Hiding techniques are often employed in the context of trace-based transformations. They are used to subtract from a complete trace (that is, one that contains states determined with the help of local variables, too) some states that do not present changes in global variables, but, due to the changes of local variables, may aect the result of the transformation / equivalence [53]. In other approaches [2], hiding is also useful for constructing asynchronous modules from synchronous ones, by making invisible the synchronization signals. In section 4.3.1 we described the synchronization of two synchronous, initially mutually asynchronous subsystems. The proof of this transformation involves a certain \observation point", from where the traces of the initial and resulting system appear the same. This is similar with the generalization of the trace inclusion in [51]: the externally visible state of the system is subject to an interface protocol. The equivalence of the systems is tested at a speci c point, where the variables become visible.

4.8 Conclusions and Related Work The purpose of detailed modeling of synchronous two-phase behavior is to bring the formal description closer to its hardware implementation. This gives a possibility to provably preserve the logical correctness of the design from the initial speci cation to a much lower level description. As asynchronous circuit design has already been included into the formalism earlier, we obtain a design framework that allows us to formally derive hardware systems that contain both synchronous and asynchronous components. Thus, the synchronous action systems design is based on translating asynchronous action systems, a natural way of describing system behavior, into synchronous action systems, while preserving the correctness of the design. The subset of asynchronous descriptions that can be transformed into their synchronous representation, within the Action Systems framework, resemble the class of VHDL-implementable T-Ruby relations [76]. Thus, we might call this subset a synchronous-implementable class of descriptions. As mentioned in section 3.2.3, we consider that the synchronous action systems are deterministic systems. Presented with the same set of input variables, the output is correspondingly the same. The synchronization requirement S.R.

86


3 ensures exactly this characteristic. Determinacy is further preserved by the

transformations presented in this chapter. Because the fourth synchronization requirement, S:R:4; imposes a certain order in the sequence of choices, the initial, generic asynchronous systems may not be characterized as con uent. However, the order only helps us in the process of transforming the description into a synchronous format, the con uent property being of no relevance from here on, with regard to a single synchronous system. As in the case of robustness, con uence related aspects might be discussed when synchronizing two (or more) synchronous sub-systems, mutually asynchronous. Most of the asynchronous data processing action systems [60, 62] can be re ned to the generic formats we take into account. Some other systems, which perhaps do not map on one or the other generic systems, could still be translated into a synchronous representation. However, this would be possible only if the basic idea backing the two-phase action representation is respected, that is, the updates on every variable of the system are speci ed under all the possible situations. We also provided immediate schematic representation for the constructs we analyzed (section 4.5). The example studied in section 4.4 is an illustration of the presented design methodology. The pipelining issues addressed in section 4.6 are based on time related aspects of design. Even though ours is a timeless approach, we considered that one could not avoid discussing this important technique of digital hardware design. Clearly then, our pipelining procedure depends on the designer's experience, as there are no other indications that may come from the language itself. Another question that may be raised with respect to our pipelining procedure concerns the block processing issue. We will see in Chapter 7 that this is possible to solve (partly) by employing the second generic system described in section 4.2.2.

Related work. We mentioned that Reactive Modules [2] is a similar approach

to synchronous formal design. Besides the similarities, we also stressed the dierences. Thus, fairness issues are distinctive features. As described in the previous section, we do not employ the notion of \fair systems", as is the case with reactive modules. The trace re nement requirements and the subsequent use of the technique resemble the implementation operation in Reactive Modules, even though it is stricter. Thus, up to a data re nement procedure, the interface of the new system has to be strictly similar to the one of the original system. Hiding mechanisms described in [2] are also part of the common aspects shared by Reactive Modules and Action Systems, in a general manner. A more particular comparison is interesting, and this is related to the synchronization requirement S:R:4: The consistent order necessary when executing


87

the atoms of some reactive module is imposed due to the same considerations taken when de ning the requirement S:R:4: The dierence resides in the fact that the order of choices in the sequence 4.6 is not necessarily arbitrary, as it may be the situation in Reactive Modules. A two-level approach to the synchronous circuit design is presented by O'Leary et al. [57]. First, there is a higher (asynchronous) level of abstraction, where formal related aspects are easier to be modeled and checked; the second, lower level is intended to capture the circuit behavior. The communication between synchronous components is also realized by means of asynchronous protocols. A dierent aspect is the fact that while in the mentioned study the components may \refuse" the synchronous cooperation, in our view the acceptance of an event is mandatory within a synchronous representation. Circuit design in FP [41, 42] or in Ruby [43] are relational approaches to hardware design. Asynchronous or synchronous circuits can be analyzed within these frameworks. In the cited studies, the emphasis is on combining functions in networks, viewed as hardware circuits. Due to a quite rich set of transformations that allow easy manipulation (placement) of hardware blocks, backed by theorems, it seems a very suitable approach when the hardware implementation presents a regular systolic structure. For this reason, we have it in mind for further studies regarding FPGA targeted designs. A step further goes, within the coordinates of functional programming, the hardware design in LAVA [22]. Adding higher-order logic functions to the process, but still preserving the above mentioned features of relational languages, LAVA seem to oer, together with some additional tools for veri cation and circuit derivation purposes, a quite complete environment for hardware design. On the other hand, for dierent tasks, such as simulation, veri cation or code generation for hardware implementation, one has to design / derive dierent representations (interpretations) of the same circuit. So far, in our proposed design ow, we did not require other classes of representation. Nevertheless, it is true that Chapter 6 analyzes the problem of language translation in order to address the same issues as simulation and circuit implementation. A similar globally asynchronous, locally synchronous view on the subsystem based design can be found in the basics of the ESTEREL language [21], too. In distinction with ESTEREL or with LUSTRE [25], where the program compiler or dierent tools perform veri cation activities, our systems are correct-byconstruction entities. Also, in our framework we are able to use exactly the same rules for asynchronous or synchronous circuit derivations. Hence, Action Systems formalism proved to be suitable for our purposes, allowing us to build a powerful uni ed basis for hardware design generally. It oers the possibility to work in a stepwise manner with systems that contain both synchronous and asynchronous components, leading to correctly derived descriptions and implementations. Asynchronous communication channels are intended for the HDL proposed

88


by Russino [67], but the asynchronous aspects of the design stop at this point. The transformation from the initial asynchronous speci cation to the nal synchronous representation can easily be automated. It is composed of mechanical steps that we consider easy to be controlled by a software program. However, for the moment, we do not describe such an evolution, as the present study is mainly concerned with the basic ideas behind a synchronous action systems design

ow. The automation of related processes is of course, extremely important for further developing an easy-to-use environment and tools and will certainly be one of the central issues of future-work studies. Still, we address aspects of implementing synchronous action systems as an automated process when discussing the translation of the formal descriptions into tool-supported HDLs, in Chapter 6.

Chapter 5

Mixed-Architecture Design The increasing complexity of digital ICs makes the fully synchronous approach to digital design increasingly cumbersome. In the mean time, increasingly higher attention is given to power consumption issues. This is mainly due to the growth of the portable electronics market and to the increasing cost of packaging and cooling systems. Thus, the power dissipation has become one of the major design parameters [34]. Several approaches have been studied in order to lower the power consumption of digital circuits. We can mention here the down-scaling of the power supply, transistor sizing, path balancing, encoding, gated clock designs, pre-computation, asynchronous design, etc. Good overviews of some of the solutions can be found in recent literature [27, 29, 65, 83]. In general, power consumption of digital integrated circuits gets higher with increasing circuit complexity and clock frequencies. The most ecient way to decrease dissipation is to reduce the supply voltage of a chip. This has a negative eect on performance, but often the performance loss can be compensated by architectural optimizations, which, on the other hand, can be quite costly in terms of chip area. Another approach to achieving lower power consumption is to reduce the activity of a synchronous circuit by gating the clock signal at the inputs of selected circuit blocks. The idea is that the clock signal within such a circuit block, and thereby the related clock buer, is enabled only when the services of the block in question are actually needed. When the clock is disabled, the dynamic power consumption of the block is zero, assuming that there are no spurious transitions in the combinational logic of the block, caused by another circuit unit driving the data inputs of the block. However, as the clock distribution becomes more dicult as circuits grow in size, the premise that synchronous circuits are simpler to design, compared to asynchronous counterparts, is invalidated [52]. Therefore, alternative approaches, such as self-timed design, are becoming attractive [64]. On the other hand, the tools and experience of fully asynchronous design do not yet compete with the 89

90

CHAPTER 5. MIXED-ARCHITECTURE DESIGN

existent tools and experience of the synchronous design process. This keeps the synchronous approach as the mainstream circuit design method also in the coming years. The idea of using gated or stoppable clocks is especially well suited for the mixed architecture design approach, where a large circuit is built from locally synchronous modules which interact asynchronously via communication channels. In such a system, the local clock generators, which supply the clock signals to the modules, are controlled by asynchronous handshake signals. When a request arrives to a generator, the clock in question is activated. After completing its task, the clocked module sends an acknowledgement to the generator, which then stops the clock. The interface between the modules being asynchronous, there are no global clock distribution or skew problems. This sort of problems will make completely synchronous system-on-chip design increasingly cumbersome, if not impossible, in the future. Hence, the globally self-timed, locally synchronous architecture with gated clocks is one possible structure of future low-power ULSI systems [49]. In this chapter, we present a formal approach towards the gated clock implementation and the manner in which we include this into our design of synchronous action systems. We show how a synchronous action system description is transformed by a correctness preserving re nement step into a form where the gated clock is visible. We will also emphasize synchronization aspects from the hardware point of view.

5.1 Synchronous Action Systems with Gated Clock The characteristic of gated clock design is the fact that the clock signal delivered to a subsystem may be stopped from its switching activity on decisions represented by boolean conditions (guards in our approach). At the physical level, this means that the clock signal is not directly supplied to the storage devices (D

ip- ops) of the subsystem, instead, it is rst routed through an analysis device that produces the signal further when the speci c conditions are met. In order to formally represent this in our framework, we start at the lower level description, where the clock action reveals the clock signal that keeps the synchronous system in operating mode. We consider the synchronous action system (section 3.3):

sys Ae (gA) :: j[ var u; init u := v; do TA0 == C od ]j; C =b :clk ! clk := true [] clk ! clk := false Further, we can explicitly write the composition TA0 == C as the choice:

TA0 == C = TA0 [] (:gTA0 ! C )

5.1. SYNCHRONOUS ACTION SYSTEMS WITH GATED CLOCK

RA QA WA C0

91

= TA0 [] :clk ^ p ! clk := true [] clk ^ :p ! clk := false = TA0 [] C 0 ; = :p ^ :clk ! RA ; p := true [] p ^ clk ! WA ; p := false [] C 0 ; =b u := u0 :QA ; =b (b ) Q) ^ (:b ) V ); =b v := u; =b :clk ^ p ! clk := true [] clk ^ :p ! clk := false

The execution of the above action allows a real update of the output variable v only when the boolean condition b evaluates to true. Otherwise the previous value of v is preserved and an outside observer would not notice that the system Ae is active. Informally, this means that the clock signal in the correspondent circuit might as well be stopped. In its turn, this can be interpreted in our description as a disabled action C 0 . Our intention is to have the condition b \gating" the clock of the system by enabling / disabling the action C 0. Observe that this requires that b is not updated by system Ae and b 2 gA (in the next section it will become clear what the variable b stands for in the hardware implementation of Ae and what system updates it). Thus, we want to obtain a system where: the updates on the variable(s) v will be performed only when b evaluates to true (preserving the present situation, where real updates are performed as described by the predicate QA ) and whenever b is false, the whole system will not be enabled. All actions of the system eventually become disabled. This is achieved by the representation of system A0 e :

sys A0e (g) :: j[ var u; init g; l := g0 ; l0 ; do :p ^ :clk ! RA0 ; p := true [] p ^ clk ! WA; p := false ]j;

od

[] C 00

where

RA0 =b u := u0:Q; C 00 =b b ^ :clk ^ p ! clk := true [] b ^ clk ^ :p ! clk := false (Notice that the dierence between RA and RA0 is the fact that the former updates the variable u according to the predicate QA , while the latter updates u as speci ed by the Q only.)

92


We have to prove that Ae v A0 e: We rst concentrate on the active period of the system, i.e. when b = true (and thus, when the clock signal of the system A0e, action C 00, is enabled). We requested that the variable b is not updated by the synchronous system. This can only read it, while other system may update b (we will see in section 5.2 that this supposition is con rmed by hardware related aspects). As a consequence, we consider that the system sys A0 e preserves the invariant I =b b: The proof is done by checking the requirements of lemma 1. 1: Initialization. The initialization should be consequent with the observations mentioned above: init b := true: 2: Main actions. Our intent is to prove

:p ^ :clk ! R; p := true I :p ^ :clk ! R0; p := true; which reduces to proving that R I R0 . We do this by considering: Guards. The guards of both actions evaluate to true: (Thus, gR0 ) gR.) Bodies. We have:

I ^ wp(R; P ) ) wp(R0 ; b ^ P )

, f de nition of weakest precondition g b ^ (8u0:((b ) Q) ^ (:b ) V ) ) P )) ) 8u0:(Q ) b ^ P ) , f b does not depend on u0 g (b ^ ((b ) Q) ^ (:b ) V ) ) P )) ) (Q ) b ^ P ) , f laws of implication g true

3: Continuation condition. It is obvious that, under the invariant I , we have W W j = n j the relation (I ^ j =1 gAj ) ) j ==1n gCj ; where actions Aj and Cj identify with the actions of systems Ae and A0 e ; respectively. When b = false, the system that stutters in nitely, Ae; is re ned by a system that terminates, A0 e ; as long as the behavior prior to the stuttering state / termination (in our case, when b = true) are the same. (A terminating system is a system that can reach a state in which none of its actions is enabled.) From an outside observer, when the clock stopped switching, the result is obviously the same as in the mentioned stuttering: no change in the output variables. The intuitive situation is presented in Figure 5.1, where we denoted by S0 ; : : : ; Sn the visible states of a non-terminating action system and by S00 ; : : : ; Sm0 the visible states of the corresponding terminating action system. Thus, we have shown that Ae v A0 e , or, in other words, that we can correctly derive a gated clock synchronous action system from an always operating system.


S0

S1

93

S n-1

Sn

Non-terminating (stuttering) system

S' 0

S' 1

S' m - 1

S' m

Terminating system

Figure 5.1: Stuttering / terminating system behaviors.

5.2 Implementation Aspects The design of synchronous action systems (Chapter 4) is based on correctly deriving synchronous representations from asynchronous action systems. We built our design ow on the four-phase signaling protocol (Figure 4.1). The master system sets the request line and it holds it until the server system replies by setting up the \acknowledge" variable. Then the request is released and, in response, the server resets the acknowledgment line. In a globally asynchronous, locally synchronous design approach, the variable b of the system A0e would be assimilated to the request signal. Upon completion and setting of the acknowledge line, followed by the release of the request, the slave (server) system will reenter the idle period, due to the suspension of the local clock signal. A synchronous device is de ned as a combinational network, with feedback from outputs to input via edge-sensitive devices [55]. Certain time constraints are to be met so that the data stored in the latches or ip- ops of the circuit is a valid data. By synchronization, we determine an order of events on signals. In a clocked system, it is important that we know if some event occurred before or after the active transition of the clock signal. Either analyzing a composition of one asynchronous and one synchronous devices, or of two synchronous devices, but acting on dierent clock frequencies (thus being mutually asynchronous) implementing reliable, high-speed communication in between these blocks raises non-trivial problems. They come from the fact that it may not be possible to unambiguously state the relative timing of the communication signals, on one hand, and the clock that activates one part of the mentioned composition, on the other hand. Even though one designs a fully synchronous circuit, the interaction with the

94


environment always contains some asynchronous elements. Hence, as synchronous devices work on clear assumptions on the relative timing of the incoming signals with respect to the clock signal, an asynchronous signal must be resolved to be in either the high or the low state before it is fed into the synchronous environment. A circuit that implements such a decision making function is called a synchronizer [64]. The errors that may appear when such modules are designed to communicate are called synchronization [64] or value [44] failures. Several solutions to this issue have been developed during the years. They mainly fall into two categories [87]: 1. brute-force synchronization of communication signals to each module's clock, with an acceptable rate of synchronization failures. 2. adjustment of locally generated clock signal in order to avoid synchronization failures. The approaches that we can include in the rst category [85, 31] implement methods that reduce the probability of failures, in a certain range of frequencies. Based on pipeline synchronization, they are simple and cost-ecient to implement. However, depending on the domain where the devices will be employed, the resulting failure probability might still not satisfy some safety requirements (or, in other words, failure situations might still appear too often). They also cause a slower communication [87]. The methods used by the approaches in the second category above [88, 34] rely on stopping or stretching the (high or low) levels of a locally generated clock. This provides good means to ensure that the time constraints with respect to the appearance of the events relative to the clock signal are valid. They require that the designer also implements a special kind of circuit in order to produce the local clock signal. These circuits are mainly based on ring oscillators. Thus, we obtain faster communication interface and eliminate the failure probability [27, 87]. However, due to the manner in which the clock signal is produced, some other aspects have to be taken into account, such as maximum frequency, temperature dependency, etc. Our formal approach to gated clock synchronous systems allows us to implement in hardware a solution that may belong to either of the two categories mentioned above. Thus, the CDU (Clock-Delivery Unit) block takes as input the request signal provided by the master system. It further delivers the signal clk0 which is interpreted as the clock of the synchronous system. This can be realized in two versions. 1: The clock generator within the CDU is a common crystal-based device (Figure 5.2 a). In this case, the block has to synchronize the incoming req (asynchronous) with the clk signal, in order to deliver a well-shaped and stable output, clk0 . (This implementation corresponds to the brute synchronization class.)


95

2: We synthesize from logical gates a local clock signal (a ring oscillator) Figure 5.2 b. The construct starts oscillating as soon as the request signal is high, thus providing the clk0 output. (This implementation corresponds to the adjustment class.) In both approaches, as soon as the req signal goes down, the actual clock of our system, clk0 is no longer active and thus the system stops its activity. Timing issues such as the moment when the request signal goes low are not taken into account at this level (the formal representation), as our model is a timeless representation. However, these have to be considered when actually implementing the description in hardware.

data Synchronous device (slave)

ack

Master system

clock gen.

clk'

clk req

synchronizer

data Master system

Synchronous device (slave)

ack

clk' clock gen. guard req

synchronizer

Figure 5.2: Implementation of gated clock systems.

Comments. Observe that the same technique (section 5.1) can be used if we

want to derive a lower frequency clock signal from a higher frequency clock generator. Consider again the action C 00 =b b ^ :clk ^ p ! clk := true [] b ^ clk ^ :p ! clk := false as describing the clock generator of some synchronous action system A. If we interpret clk0 = b ^ clk, we obtain a clock (clk0 ) that is dependent on the values

96


of both b and clk. Suppose that the boolean expression b is (synchronously, on the clock clk) switched (true = false) in a regular manner by some (synchronous) action system. Then the frequency of signal clk0 is a divider of the frequency of clk.

5.3 Conclusions Due to the advantages oered by the gated clock designs (strongly related to the power consumption) we introduced the principles of gated clock realizations in the framework of action systems. While in the literature this has been presented mostly as a practical implementation aspect, we are able to express the issue in a formal manner, based on the transformation of a stuttering synchronous action system into a system that terminates. This brings us even closer to the aim of having a uni ed environment, in which we can describe with the same rules asynchronous or synchronous systems design processes. Thus, mixed architecture design systems can be obtained in a formal framework, leading to correctly derived hardware.

Chapter 6

VHDL for Synchronous Action Systems The digital design process is nowadays heavily based on CAD (Computer Aided Design) tools. The designer is able to describe circuits at dierent levels of representation. At the same time, there is a powerful trend in the direction of raising the top level of the representation, re ected in the continuous development of hardware description languages (HDL), such as Verilog or VHDL. Hence, most of the modern tools provide compilers for several HDLs. We consider that the current computer-aided hardware design tools are reliable in the activities concerning the low levels of design (even though there are certain situations when manual intervention might also be needed at these levels). Thus, instead of thinking of building new CAD tools which will go all the way from our formal descriptions to the gate or transistor level of the design, we chose to take advantage of the existing ones and only provide more formal related characteristics, which are not among the most developed aspects of the automated tools. Therefore, our attention is concentrated on nding the means by which our formal descriptions can be translated into a hardware description language with support from CAD tools, following certain rules that will ensure the correctness of the process. Once the translation is completed, one could continue the usual design ow within the speci c hardware design environment. VHDL is one of the most widespread standards for hardware description. From its initial applications in simulation and ASIC description, VHDL is now being used in a large range of applications at all levels, from system down to gate [18]. Because of its large utilization, several high-level speci cation languages provide tools for transferring their own descriptions into VHDL representations, as for example, Lava [22], SPECIAL [84] and T-Ruby [76], to mention only some of them. Due to the diculty of formally verifying VHDL designs [22], the reverse 97

98

CHAPTER 6. VHDL FOR SYNCHRONOUS ACTION SYSTEMS

process, the transcription from VHDL code into a certain formalism, has also been the subject of several studies, for example LARCH VHDL [79]. The two-phase behavior of synchronous action systems seemed to be a suitable subject for translation into VHDL format. We realize this by means of a C++ application, named SASVHDL. In the following, we describe the ideas behind the application, the internal program ow, as well as the characteristics of the resulting VHDL code.

6.1 Premises We intend to translate our synchronous systems into a behavioral VHDL description. This means, from the VHDL perspective, a functional modeling, compared to the structural approach, which describes the system as a speci cation of the composition of the sub-systems (instances) [5]. The reason why we chose the behavioral representation is the higher generality of the code (not related to any low-level issues) and thus, the increased portability. It also provides an easy-tochange structure, for further updates. Figure 6.1 shows in a concise manner the basic idea on which we build the process of translating a synchronous action system description (SAS) into the corresponding VHDL code.

Figure 6.1: The correspondence between SAS and VHDL descriptions. If we take into consideration the results obtained by following the design ow described in chapter 4, the input to the application is a textual description of the synchronous system, at the r-level:

6.1. PREMISES

99

sys S yncG (req; ack : boolean; global variables) :: j[ var local variables; init initialization of variables; do T1 r : : : rTn od ]j; or at the }-level: sys S yncG (req; ack : boolean; global variables) :: j[ var local variables; init initialization of variables; do R1 ? : : : ? Rn } W1 ? : : : ? Wn od ]j Further, let us analyze a single two-phase action synchronous system (which is always possible to obtain). We will transfer the read part of the two-phase construct into a VHDL process and the write part of the same action into another VHDL process, as shown in Figure 6.2. At the same time, the variable p is mapped to the clock signal that activates the write process. We give more details on the processes in the coming sections.

T =
R; p:= true > [] W; p:= false >

read process(signals)

p

write process(clk)

clk

Figure 6.2: VHDL interpretation of a two-phase action. The program parses the text le containing the system representation, in several steps, gathers information and processes it into a resulting VHDL description. The code contains an entity declaration together with its behavioral architecture. It is based on a prede ned structure that has to be present in one le in the working directory. The structure is an illustration of a sequential template and it is shown in Figure 6.3.

100

CHAPTER 6. VHDL FOR SYNCHRONOUS ACTION SYSTEMS entity

name is

port(

clk: in std logic ); end name; architecture behavior of name is begin

read:

{

process()

begin

signals process's body, read actions end process read; write: process() begin if(

CLK = '1' and CLK'event ) then { outputs computation of the outputs, write actions end if; end process write; end behavior;

Figure 6.3: The initial VHDL structure

6.2 Code Characteristics The VHDL entity name is the same as the name of the synchronous system. It contains port declarations based on the variables in the system's interface list. The application will identify the type for every port, plus extra details when necessary (a \range" for integer or natural types, for example). The other information to complete the type settings is also automatically detected (input, output or buer variables). An extra signal, the clock, is automatically added as an input port (it is already present in the initial structure, as clk). The intermediate variables, requested by the two-phase representation of the involved actions, are also detected (if the representation is at the }-level of description) and declared as signals in the architecture body.

6.2.1 Architecture The behavior is modeled by two processes, by default called read and write. The clock signal triggers the write process, while the sensitivity list for the read

6.2. CODE CHARACTERISTICS

101

process is represented by the detected input variables. The read process operates the combinational result, which, on the falling / rising (default) edge of the clk signal is transferred to the output, via signals generated from the intermediate variables. This behavior is closely related to the philosophy of two-phase actions, and this is the main reason for chosing it. The two-phase action concept is in this way re ected in the VHDL code as well. Although there are two processes in the architecture, they are not concurrent ones, in the sense presented, for example, in [33]: only one process updates the signals used in the VHDL description. As an advantage of using two processes in our architecture, we may also mention that this leads to smaller generic net list and therefore to better synthesis results.

6.2.2 Basic constructs

Considering a one-action synchronous action system, the read part of this action is similar to

R = u := u0 :Q; Q =b (g1 ) Q1 ) ^ : : : ^ (gn ) Qn) In addition, the synchronization requirements are satis ed, so we have that (

S.R. 3 - relation 4.7):

8j = 1 : : : n:(9 k = 1 : : : mj :(gkj

= true) ^ ((

m _j i=1;i6=k

gij ) = false)))

(6.1)

As a natural decision, we intend to translate the predicate Q into a conditional construction, where the guards gj ; = 1 : : : n are to be identi ed with the selectors usually met in a conditional construct of any programming language. We may choose one of the two available mechanisms that describe conditional behavior in VHDL: the if-statement or the case-statement. The dierences between the two options that are important to us, are the hardware implementation (Figure 6.6) and the semantics of each construct. A common characteristic of both statements is the fact that the outputs have to be speci ed under all input situations [89], due to priority related issues (for the case-statement) or the generation of undesired latches (for the if-statement). This requirement is, in fact, already included in the formal description (the synchronization requirements, section 4.2.3).

The case construct. The syntax of a generic case statement is presented in

gure 6.4. The branches of the case-statement are equal in priority. This means that one and only one of them can be executed at a given moment. Thus, all possible

102


case expression is when choice => f sequential statement; g

......... when others => f sequential statement; g end case; Figure 6.4: The VHDL case construct. values of the case expression must be covered. For covering all remaining, i.e. not yet covered, cases, the keyword \others" may be used. This speci cation t very well in our synchronous descriptions, as the synchronization requirements ensure (section 4.2.3) the very same situation. Further, the case expression has to have a (unique) type, and this has to match the one of the query variables (choice). This feature is not that welcome for our purposes, as it introduces a limitation: the updates are conditioned by the value of a single guard. This we cannot nd in our descriptions of a two-phase action. Consequently, we do not consider the case statement to be suitable as the target for the translation of the read part of a synchronous action into VHDL code. At the hardware level, the case-statement is synthesized as a single large multiplexer (Figure 6.6 b)).

The if construct. The syntax of a generic if-statement is presented in gure

6.5.

if (condition1 ) then signal

assignment;

elsif (condition2 ) then :::::::::

else

signal

endif

assignment;

Figure 6.5: The VHDL if-construct The branches of an if-statement are not equal in priority. Several conditions might evaluate to true at the same moment (they may overlap). However, this is not a requirement, and still, only one of the branches is executed: the one placed earlier in the construct. Thus, there is no problem if the conditions are mutually

6.2. CODE CHARACTERISTICS

103

exclusive, or if they respect the third synchronization requirement (relation 4.7). In addition, the conditions are not supposed to be of the same type, and they can be evaluations of dierent, arbitrarily complex boolean expressions [5]. Therefore, we consider the if-construct a perfect choice for the conversion of the synchronous actions into VHDL, as it provides a more general mechanism for the selection. At the hardware level, the if-statement is synthesized into a chain of multiplexers (Figure 6.6 a)).

··· if X = 0 then OUT NOP )) v := u

Once the text le is loaded, the description is displayed in the application's main window, as in Figure 6.7. On the Transfer command, the program parses the input le, the rst steps consisting of extracting the name of the VHDL entity. This is speci ed as being the same as the name of the synchronous action system. It is followed by the detection of the level of the system description (`r' or `}'-level). If it is the case of a `r' representation, then the intermediate variables are automatically included in the code, with a trailing m added (for example, if the output variable is v, then the intermediate variable is denoted vm). The intermediate variables are declared as signals in the VHDL architecture. They implement the communication between the read and write processes. The next step is to detect the individual variables, their types and the input/output characteristics. The type is decided upon the declaration in the system's parameter line. If the type is, for example, integer, a dialog box requests for the range of the analyzed variable. The decision upon the other characteristic is done by analyzing the textual description for occurrences of the variable. The input/output attribute is set to in, out or buer, in conformity with the parsing result. Every variable is, at its turn, declared in the entity's body, as a new entry. If the variable is of output type, the associated signal (intermediate variable) is

106


Figure 6.7: The application's main window then detected and written in the architecture part of the code (the type being the same as the variable's one). After the set of variables has been detected and their respective types established, the next step of the analysis is represented by the insertion of the actual code for each action. The write process statements are quite simple to separate and insert, as they are mere copies of the synchronous system's write-actions (Figure 6.8).

Figure 6.8: Translating the write actions into VHDL statements. The statements of the read process, however, require a deeper analysis. The process starts by isolating one read action at a time. The guards/conditions for the execution of the action are then depicted. The rst guard is placed in the condition eld of a new if-construction. If the predicate of the action is composed of multiple terms, the rst one is translated, then an elsif is inserted.

6.4. EXAMPLE: A 4-BIT BINARY COUNTER

107

The operation is repeated until the whole predicate has been analyzed. In Figure 6.9 we depicted the translation of a read action into the corresponding VHDL code. If there are still unparsed actions, the procedure is restarted until the whole read part of the system has been transferred to its VHDL format.

Figure 6.9: Translating the read actions into VHDL statements. After the translation process has nished, what is left is the decision upon the active clock edge and the libraries and packages to be used. If not all the desired libraries and packages are available, one could insert them in the editing window, or add them in the library le for further use.

6.4 Example: a 4-Bit Binary Counter In this section, we show how a four-bit counter description is processed in order to obtain an automatically generated schematic. Although a four-bit counter is not a complex circuit, it illustrates well the design methodology and the translation process. The VHDL code of the trac lights controller presented at the end of Chapter 4 is analyzed in [70]. The starting point for the description is the pair of asynchronously coupled action systems: sys C ount (req; ack; mode : boolean; dload; dout : int) :: j[ init req; ack := false; do req ! (mode ! dout := dout :(dout = (dout + 1) mod 16 ) [] :mode ! dout := dout :(dout = dload)); ack := true) [] :req ! ack := false 0

0

0

]

j

od

0

108


sys E nv req; ack; mode boolean dload; dout int j init req; ack false do :ack ^ :req ! mode mode : mode 2 boolean dload dload : dload 2 f ; : : : ; g req true ack ^ req ! req false od j (

[

:

:=

;

:

) ::

;

0

:=

:=

0

0

(

(

0

);

0

15 );

:=

[]

:=

]

Here the composition E nv == C ount represents the overall description. The variable dload stores the starting value that can be loaded into the counter, while the variable dout stores the output of the counter. The variable mode speci es the way the counter works, i.e., loads an input value or starts counting. Notice that the C ount system maps directly to the format of the generic asynchronous system Async1G (section 4.2.2): the choice sequence is composed by only one choice construct and the requirements upon the actions and their guards are also satis ed. Systematic re nement leads us to the following system: sys C ount0 (req; ack; mode : boolean; dload; dout : int) :: j[ var doutm : int; ackm = boolean; init req; ack := false; do doutm := dout0m:((req ^ mode ) dout0m = (dout + 1) mod 16) ^(req ^ :mode ) dout0m = dload) ^(:req ) NOP )) ?ackm := ackm0 :((req ) ackm0 = true) ^(:req ) ackm0 = false)) } dout := doutm ? ack := ackm

od

]j The action system's int type is converted into the integer type of VHDL. The resulting code is presented in Figure 6.4 and can be further input to the user's preferred CAD tool (the present work is based on Cadence environment, Leapfrog notebook as VHDL compiler and Synergy for the synthesis [89]). We further continue the formal derivation process into bit-level description. This means that the integer-type data variables din and dout are replaced by the vectors din[3::0] and dout[3::0]: The index `0' corresponds to the least signi cant bit and the index `3' to the most signi cant bit, respectively. Naturally, the intermediate data variable hidden into `r' has to be transformed as well. We hide those variables that we change, and re ne

j[ E nv == C ount0 ]j : req; ack; mode v j[ E nv0 == C ount00 ]j : req; ack; mode where the notation of the form j[ A ]j : v means that the variables v of the system A are observable, while the others are hidden (section 2.2.1). The actions of the

6.4. EXAMPLE: A 4-BIT BINARY COUNTER

LIBRARY IEEE; USE ieee.std_logic_1164.ALL; entity Count is port( dout: buffer integer range 0 to 3; dload: in integer range 0 to 3; mode: in boolean; ack: out boolean; req: in boolean; clk: in std_logic ); end Count; architecture behaviour of Count is sig nal ackm:boolean; signal doutm:integer range 0 to 3; begin read:process(req,mode,dload,dout) begin -signals if(req AND mode) then doutm