A High-Level Language for Programming Complex Temporal Behaviors and Its Translation into Synchronous Circuits Ching-Tsun Chouz
Jiun-Lang Huangy
Masahiro Fujita
(Last revised: 11 March 1997)
Abstract
We present YASL, a synchronous programming language that supports high-level programming of nite-state machines by providing a rich set of control constructs for specifying complex temporal behaviors and an automatic procedure for translating such high-level timing speci cations into nite-state machines in the form of synchronous circuits. In addition to operators for expressing watchdog, conditional, sequencing, and concurrency, YASL o ers a powerful temporal projection operator that supports hierarchical description of temporal behaviors at di erent granularities of time. We motivate the design of YASL, discuss its potential applications, describe its syntax and semantics, explain its translation into synchronous circuits, and compare it with related languages Tempura, Esterel, and Handel. Topics: System-level speci cation and design, high-level synthesis.
1 Introduction The complex temporal behaviors of hardware are implemented by nite-state machines (FSMs). As is well-known, unstructured FSMs are dicult to understand and construct, since even minor changes in the state-transition structure of a FSM can lead to profound and often unexpected changes in its behavior. While an unstructured FSM with 10 states is probably within the grasp of the human mind, an unstructured FSM with 100 states is almost certainly beyond it. In order to make the programming of FSMs easier, it is desirable to have a high-level programming language for FSMs with the following characteristics: Fujitsu Laboratories of America, 3350 Scott Blvd., Bldg. 34, Santa Clara, CA 95054, U.S.A. y Dept. of Electrical and Computer Engineering, Univ. of California at Santa Barbara, Santa Barbara, CA 93106, U.S.A. z From 17 March 1997, the rst author will start working for Intel at Santa Clara, CA. As his new address is not yet known, please use
[email protected] for future correspondence.
1
It allows programs to be combined in arbitrary ways using such natural
operations as concurrency, sequencing, iteration, conditional, preemption, and suspension. It supports temporal abstraction |the hierarchical description of temporal behaviors at di erent granularities of time [10]. It has a simple and precise semantics. Its programs are directly synthesizable into hardware. In this paper we present such a language, which we call YASL (Yet Another Synchronous Language) because its semantics is based on the same synchrony hypothesis as adopted by other synchronous languages [6], which assumes that every program is so fast in response to stimuli from its environment (i.e., other programs) that such response can be considered instantaneous. The reason for our adopting the synchrony hypothesis is simple: most hardware systems are clocked and, in a clocked system, one does not care what happens during a clock cycle other than the end results (i.e., the values that are latched into registers at the end of the clock cycle). Of course, this presupposes that there is no combinational loops that can cause oscillation, and that the clock period is long enough for the combinational logic between latches to stabilize. But this is the usual assumption of synchronous circuit design anyway and has the desirable e ect of separating functional considerations from delay considerations. The control constructs of YASL are inspired by Tempura [12], an executable subset of interval temporal logic [11]. They allow programs to be combined in arbitrary ways using watchdog (await e), conditional (if e then p else q), sequencing (p ; q), concurrency (p k q), and temporal projection (p C q). The temporal projection operator C is the most distinctive feature of YASL. The program p C q behaves like p at the beginning. If p terminates then, p C q also terminates without executing q; otherwise q is executed and p is suspended until q terminates, whereupon p is resumed. If p terminates then, p C q terminates; otherwise q is re-executed, p is suspended until q terminates, and the same process is repeated again. This is illustrated in Figure 1, where the dashed p
q
q
Figure 1: How to execute p C q 2
q
arrows depict ow of control, the bullets represent execution steps of p and q, and two adjacent bullets indicate that the two steps of q (and the intervening step of p) should be executed in the same clock cycle. There are two ways of looking at a temporal projection p C q. First, it can be viewed as a generalized iteration where p is used to control the iteration of q. Indeed, the usual looping constructs can be easily derived from C: while e do q = await(:e) C q (1) repeat q until e = (pause ; await(e)) C q (2) where await(e) terminates once e is true and pause pauses for one step and then terminates. Second, it can be viewed as a form of temporal abstraction [10] where p is executed using the slower clock de ned by the endpoints of q's executions. (Note, however, that this does not mean that the computation of a step of p can take multiple cycles of q's clock to nish; see Figure 1.) For example, the suspension operator of Esterel [1] can be easily de ned using C: suspend p when e = p C (pause ; await(:e)) (3) where p in e ect uses the negation of e as its clock. Furthermore, it can be shown that C is associative, so the temporal projections can be stacked one on top of another to form a hierarchical description of temporal behaviors at di erent granularities of time. For example, in the Pentium Pro processor bus protocol [15], a memory or I/O operation may consist of multiple transactions, each of which consists of multiple phases, each of which takes multiple clock cycles. A controller for a bus agent might use the following code fragment: operation
C transaction C phase
where operation (resp., transaction and phase) is executed once per operation (per transaction and per phase). A possible scenario of their termination signals is depicted in the \timing diagram" in Figure 2. We developed the precursor of YASL and its circuit translation without knowledge of the body of works on synchronous languages [6]. Since we became aware of it, we have been in uenced by the synchronous language Esterel [1, 2]. In particular, we have borrowed the notion of signals and the style of de ning formal semantics from Esterel (see Section 2). Interestingly, though they were Termination signal of phase Termination signal of transaction Termination signal of operation Figure 2: Operations, transactions, and phases 3
developed independently, the control constructs of YASL and Esterel are equally expressive in the sense that they can easily simulate each other (see Section 4). The circuit translations for YASL and Esterel are based on the same principles, but di er in many details. So far YASL is designed only for programming the control parts of hardware. In our view, the fundamental problem of datapath design in a language like YASL is how to ensure that no two (sub)programs drive the same datapath at the same time. We do not expect this problem to be easy to solve: for instance, the absence of bus contention in a complicated bus protocol is inherently hard to establish. In the literature there seem to be two approaches to this problem. In Esterel, con icts in driving a signal are allowed, but the programmer is required to specify a resolution function. In Handel [13, 17], such con icts are avoided by syntactic restrictions (e.g., no two branches of a parallel composition may contain assignments to the same register). But we are skeptical about whether either approach is exible enough for \real-world" hardware designs. Since we do not have sucient experience in this problem, we will restrict ourselves to the control aspects of hardware in the formal part of this paper. Some ideas on how to introduce datapaths into YASL are given in the comparison of YASL and Handel (Section 4). A language like YASL can have signi cant applications in the validation, veri cation, and synthesis of hardware and even software components: Capture of designer's intention: The expressiveness of YASL makes writing YASL programs far easier and less error-prone than trying to come up with the state-transition diagrams of FSMs directly. Simulation-based veri cation: The expressiveness of YASL also makes it a good medium in which to write test harnesses that embody the desired behaviors of a system. Note that the system under consideration need not itself be written in YASL. Model checking-based veri cation: Circuits synthesized from YASL are FSMs and hence amenable to model checking by systems like VIS [19]. YASL can also be used to program FSMs representing the properties to be checked (or their negations).1 1 It is interesting to compare YASL with CTL [5], a popular formalism for specifying temporal properties of hardware. Consider the following property: Sustain O1 until I1 is high, then sustain O2 until I2 is high, then sustain O3 until I3 is high. which can be easily speci ed in YASL as: (sustain O1 until I1 ) ; (sustain O2 until I2 ) ; (sustain O3 until I3 ) where: sustain X until e = await(e) C (emit(X ); pause) The reader is invited to specify the same property in CTL. On the other hand, it is impossible to specify liveness properties in YASL, which can be done in CTL.
4
Synthesis: Hardware and even software components can be generated from
the circuits synthesized from YASL programs. But extensive optimization is needed in order to achieve good performance. Encouraging results in this direction using Esterel can be found in [4, 18]. The rest of this paper is organized as follows. Section 2 describes the syntax and semantics of YASL. Section 3 explains how to translate YASL into synchronous circuits without \schizophrenia" [1]. Section 4 compares YASL with Tempura, Esterel, and Handel. Section 5 concludes this paper by outlining future research directions. There are also three appendixes supplying details that are omitted from the main text due to space limitations.
Acknowledgments
We are grateful to Ben Moszkowski for his work on interval temporal logic, to Robert Brayton and Alberto Sangiovanni-Vincentelli for pointing out the existence of Esterel and its relevance to this work, to Gerard Berry and Ellen Sentovich for helping us clarify the relationship between YASL and Esterel, to Michael Gordon for pointers to Handel, and to Dominique Borrione, Randy Bryant, Stephen Edwards, Ganesh Gopalakrishnan, Stott Parker, and our colleagues at FLA for enlightening discussions.
2 Syntax and Semantics of YASL 2.1 Signals
YASL programs communicate with each other via signals (denoted by X , Y , etc.). In each clock cycle, a signal is either present or absent. It is present i at least one (sub)program emits it; otherwise, it is absent. Formally, let B = f+; ?g be the set of signal statuses : + denotes presence and ? absence. An event E is a mapping from a set S of signals to B , where S is called the sort of E , denoted S (E ). Let ; denote the event in which all signals are absent, fX + g denote the event in which X is present and all other signals are absent, and E [ F denote the event in which a signal is present i it is present in E or in F . The sorts of these events will be clear from context. Given an event E and X 2 S (E ), let E n X denote the event of sort S (E ) n X that coincides with E on all signals except X . Lastly, for an event E , a signal X possibly not in S (E ), and b 2 B , let E s denote the event E 0 of sort S (E ) [ fX g de ned by E 0(X ) = b and E 0 (Y ) = E (Y ) for all Y 2 S (E ) n X . b
2.2 Expressions
YASL expressions (denoted by e, e0 , etc.) have the following abstract syntax: e ::= present X j true j :e j e ^ e0 5
where present X tests for the presence of a signal X . Other boolean connectives are derived from true, :, and ^ in the usual manner. Formally, an expression e is evaluated on an event E whose sort contains at least the signals mentioned in e. The evaluation function is de ned recursively as follows: [ present X ] (E ) = E (X ) [ true ] (E ) = + + if [ e ] (E ) = ? [ :e ] (E ) = ? if [ e ] (E ) = + + if [ e ] (E ) = + and [ e0 ] (E ) = + [ e ^ e0 ] (E ) = ? if [ e ] (E ) = ? or [ e0 ] (E ) = ?
2.3 Statements
YASL statements (denoted by p, q, etc.) have the following abstract syntax: p ::= emit X j pause j await e j if e then p else q j p ; q j p k q j p C q j signal X in p The statement emit X emits on the signal X and terminates immediately (i.e., in the same cycle in which it is started). The statement pause does nothing, pauses for one cycle, and terminates in the next cycle. The statement await e monitors the expression e and terminates once e becomes true. We also de ne: skip = await (true) loop = await (false) to be the statement that terminates immediately and the statement that never terminates, respectively. The statement if e then p else q rst evaluates e (which takes no time), then behaves like p if e is true and like q if e is false. The statement p ; q rst behaves like p and, once p terminates, immediately behaves like q. The statement p k q starts p and q simultaneously and terminates once p or q terminates. The intuitive meaning of p C q has been described in Section 1. Here we further stipulate that q is not allowed to be a statement that may terminate immediately, because that would lead to combinational loops in the circuit translation. In signal X in p, the signal X is made local and emissions on X are made available to presence tests on X . This can give rise to causality loops, some of which allow no behavior: signal X in ( if present X then skip else emit X ) and some others of which allow more than one behavior: signal X in ( if present X then emit X else skip ) Using the ideas in [1], it is possible to de ne a constructive semantics for YASL that rules out such pathological programs; see Appendix A for details. But, in order to understand this paper, such knowledge is not really needed. 6
Formally, the semantics of statements is given, in the style of structural operational semantics (SOS) [14], by a transition relation of the form: 0
p ???! p0 E ;k E
where p and p0 are statements, E and E 0 are events whose sort is the set of free signals of p, and k 2 f0; 1g. Intuitively, the above transition says that in one cycle, if the environment of p provides the input event E , then p can produce the output event E 0 and the completion code k and behave like p0 from the next cycle on, where k = 0 (resp., k = 1) signi es (non-)termination. The SOS rules are as follows: (skip)
skip ?;?!0 skip
(emit)
f g0 emit X ????? ! skip
(pause)
pause ??;!1 skip
(await-+)
;
E
X
+
;
E
;
E
[ e ] (E ) = +
await e ?;?!0 skip [ e ] (E ) = ? await e ?;?!1 await e ;
E
(await-?)
;
E
(cond-+)
0 p ???! p0 if e then p else q ???0 ! p0
[ e ] (E ) = +
E ;k E
E ;k E
(cond-?)
0
q ??! q0 0 if e then p else q ??! q0
[ e ] (E ) = ?
F ;l E
F ;l E
0 p ???! p0 E ;k
(par-0)
E
0
q ??! q0 k = 0 or l = 0 0[ 0 0 p k q ?????! skip F ;l E
E
F ;
E
01 01 p ??! p0 q ??! q0 0[ 0 1 p k q ?????! p0 k q0 E ;
(par-1)
F ;
E
E
E
F ;
E
(seq-1)
0 E ;1
p ??! p0 01 p ; q ??! p0 ; q E
E ; E
7
00 p ??! p0
0
q ??! q0 0[ 0 p ; q ????? ! q0
E ;
(seq-0)
F ;l
E
E
E
F ;l
E
0
0 p0 p ??! E ;
(proj-0)
E
0
0 skip p C q ??! E ; E
01 01 p ??! p0 q ??! q0 0[ 0 1 p C q ?????! q0 ; (p0 C q) E ;
(proj-1)
F ;
E
E
E
F ;
E
0 + p ?????? ! p0 S (E 0 ) = S (E ) n X + 0 signal X in p ???! signal X in p0 E
(sig-+)
X
;k
E X
E ;k E
0 ? p ?????? ! p0 S (E 0 ) = S (E ) n X ? 0 signal X in p ???! signal X in p0 E
(sig-?)
X
;k
E X
E ;k E
In the complete version of YASL, there is another level of constructs that transforms statements into models with unidirectional interface signals. For simplicity, we ignore them here.
3 Translating YASL into synchronous circuits The translation from YASL into synchronous circuits is syntax-directed : to translate a compound expression or statement, we recursively translate its components and then combine the resulting circuits together by adding some extra circuitry. Each expression e is translated into a combinationalcircuit T (e) whose single boolean output is high i e evaluates to +. How to do so is obvious and hence the details are omitted. Each statement p is translated into a sequential circuit T (p) whose combinational part C (p) is shown in Figure 3. The latches of T (p) stores the control state (i.e., \program counters") of p. The number of latches is the total number of pause and await statements in p. P (revious) (resp., N (ext)) is the wire bundle from the latches to C (p) (from C (p) to the latches); note that they are internal wires of T (p). T (p) is started when the B(egin) wire becomes high and terminates when the E(nd) wire becomes high. (So, if p terminates immediately, then E becomes high in the same cycle as B .) Whenever the S(uspend) wire is high, T (p) is suspended (i.e., keeps the contents of its latches) and does not drive any of its output wires high in that cycle. The B and S wires should never be high in the same cycle; the circuit translation scheme guarantees that this is the case if the global environment also follows the 8
X Y i
B S P
i
E R N
C (p)
X Y o
o
Figure 3: The combinational part of T (p) rule. If the R(eset) wire becomes high, then T (p) is reset (i.e., all its latches are set to low) in the next cycle. (This can happen even when B or S is currently high.) Each signal X occurring free in p is implemented by an input wire X , on which presence tests on X are performed, and an output wire X , on which emissions on X are performed. The implementations of the control constructs of YASL, except temporal projection, are depicted in Figures 4{10, which should be self-explanatory. For reasons that will become clear shortly, the implementations are stated in terms of the combination parts C () instead of the complete sequential circuits T (); the latter can be easily recovered from the former by adding the suitable number of latches and connecting them to P and N . For illustrative purposes, we assume in the gures that the expression e tests signal W and the statement p (resp., q) has free signals X and Y (X and Z ). At rst sight, the circuit shown in Figure 11 seems to be a satisfactory implementation of temporal projection, where the gate marked by an asterisk () represents the OR of all its input wires. Unfortunately, this is not the case due to the so-called schizophrenia problem [1]. In a temporal projection p C q, two successive iterations of q have a one-cycle overlap. So it is possible for two (or more, if there are nested temporal projections) \incarnations" of q to be active simultaneously in the circuit C (q), which can become \schizophrenic" and produce incorrect behaviors. For example, loop C ( pause k (pause ; emit X ) ) should make X present from the second cycle on. But if Figure 11 is used, X is present only in the second cycle and absent from the third cycle on, because the control tokens for the second iteration are mistakenly killed by the parallel composition (see Figure 9) of the rst iteration. For another example, loop C (signal Y in ( (if (present Y ) then emit X else skip) ; pause ; emit Y )) i
o
9
X
i
E R
B S X
o
Figure 4: C (emit X )
B S P
E R N
0 1
Figure 5: C (pause)
W
i
e B S P
1 0 0 1
0
W
o
Figure 6: C (await e)
10
E R N
W e B
i
0 1
S P
X Y i
Z
i
Xi Yi B E S C (p) R P N Xo Yo
i
E R N Xi Zi B E S C (q) R P N Xo Zo
0
W
o
X Y o
Z
o
o
Figure 7: C (if e then p else q) X Y i
B S P
Z
i
Xi Yi B E S C (p) R P N Xo Yo
X Y o
i
E R N Xi Zi B E S C (q) R P N Xo Zo
Z
o
o
Figure 8: C (p ; q) 11
X Y i
B S P
Z
i
i
Xi Yi B E S C (p) R P N Xo Yo
X Y o
E R N Xi Zi B E S C (q) R P N Xo Zo
Z
o
o
Figure 9: C (p k q)
Y
B S P
i
Xi Yi B E S C (p) R P N Xo Yo Y
E R N
o
Figure 10: C (signal X in p)
12
X Y i
Z
i
i
Xi Yi B E S C (p) R P N Xo Yo
B S P
E R N
Xi Zi B E S C (q) R P N Xo Zo
X Y o
Z
o
o
Figure 11: The in correct version of C (p C q) should never make X present. But if Figure 11 is used, X is present from the second cycle on, because the emission of Y at the end of the n-th iteration mistakenly causes the then branch to be taken in the n + 1st iteration (see Figure 10). Clearly, to \cure" schizophrenia, the part of C (q) that can be active in the initial cycle of an iteration of q, which will be denoted by I (q), must be duplicated so that the computations of temporally overlapping iterations of q always proceed in spatially disjoint circuits. The correct implementation of temporal projection is shown in Figure 12, where the OR of the N outputs of C (q) and I (q) is component-wise. Note that the E output of I (q) is ignored, because q is not allowed to terminate immediately and hence E must be low. Due to space limitations, the initial-cycle circuits I () are given in Appendix B; they are straightforward simpli cations of the corresponding C () circuits. Note that the I () circuits do not need the S and P wires, because they are always low in the initial cycles. Circuits generated by the above translation scheme contain a lot of redundancy, which must be optimized away before acceptable results can be obtained. Roughly speaking, there are four categories of optimizations, which are listed below in increasing order of cost: 13
X Y i
i
Z
i
Xi Yi B E S C (p) R P N Xo Yo
B S P
E R N Xi Zi B E S C (q) R P N Xo Zo
X Y o
B
Xi Zi
E I (q) R N Xo Zo
Z
o
o
Figure 12: The correct version of C (p C q) 1. The circuit translation scheme itself can be optimized. For example, if a signal X is never used as an input (resp., output) in a statement, then the wire X (X ) and all associated circuitry need not be generated. 2. Optimization can be applied to the attened netlists of generated circuits. Examples include constant propagation and the removal of circuitry whose results are not used. 3. Combinational logic optimization techniques can be applied to the combinational parts C (). Here structural invariants of the translation scheme can be pro tably exploited, e.g., the fact that the B and S wires are never high at the same time. 4. Sequential logic optimization techniques can be applied to the complete circuits T (). This kind of optimization can be expensive and can change the state encoding. For example, using techniques from categories 1{3 above, it is possible (though very tedious!) to show that the combinational part of the circuit for: sustain X until e = await(e) C (emit(X ) ; pause) i
o
14
W
i
e B S P
E
1 0
R
0 1
N
0 1
X
o
Figure 13: C (sustain X until e) after simpli cation can be simpli ed into the circuit shown in Figure 13. Exactly what optimization techniques are in general most useful and how their applications should be coordinated are a major topic for future research.
4 Comparing YASL with Tempura, Esterel, and Handel 4.1 Comparison with Tempura
Tempura [12] is an executable subset of interval temporal logic (ITL) [11]. Executing an ITL formula means generating a model (i.e., a sequence of states) that satis es . The control constructs of YASL are inspired by those of Tempura, including temporal projection. However, since Tempura was intended to be executed by a software interpreter, it allows recursion, which does not seem to be easily implementable by circuits and hence has been barred in YASL. Tempura also supports data types such as integers and lists, which are not available in YASL (though we are considering introducing bit vectors into YASL). The major di erence between the design philosophies of Tempura and YASL is in the handling of con icts. In Tempura, it is possible that one process insists on termination while another insists on continuation, or that one process sets a variable to 0 while another sets it to 1. In such cases, an error ag is raised and the execution aborted. In YASL, a process can insist on termination but not on continuation, and can force a signal present but cannot force it absent. Thus such con icts never arise. (Actually, an early version of YASL uses extra 15
circuitry to detect and ag con icts. But later we felt that this is not a very elegant solution in the context of hardware.)
4.2 Comparison with Esterel
Esterel [1, 2] is a synchronous language for programming reactive systems. Both software and hardware implementations of Esterel are available. The control constructs of Esterel di er from YASL in three major ways explained below. (Esterel keywords will be printed in this font.) First, in Esterel, a parallel composition p || q terminates when both p and q have terminated. In YASL, p k q terminates when one of p and q terminates; the other process is reset. So the || operator of Esterel includes synchronization, while the k operator of YASL includes preemption. It turns out that || and k can simulate each other (with the help of other operators in Esterel and YASL), the details of which can be found in Appendix C. Second, Esterel supports a trap-exit mechanism that allows a process to exit at any point to the end of an enclosing trap: trap T in p end (4) where p is an Esterel statement that may contain exit T . The intuitive semantics is that, upon reaching exit T in p, the control immediately jumps to after end. It is easy to see that (4) can be simulated by the following YASL fragment: signal T in ( await(present T ) k p [exit T 7! emit T ] ) (5) where p [ 7! ] is obtained from p by replacing every occurrence of by . It is less easy to see that (5) is not a correct construction when there are nested traps (we are grateful to Gerard Berry and Ellen Sentovich for pointing out this error). Nevertheless, nested traps can be simulated in YASL; see Appendix C for details. Third, Esterel does not have the temporal projection operator C. But it is possible to simulate p C q in Esterel, as follows: trap T in signal X; Y in suspend || loop
(p ; emit X ) when (:present Y ) ; exit T
( if (:present X ) then (q ; emit Y ) else (pause) )
end
end end
where the signal X (resp., Y ) is used to signify the termination of p (q). This construction is due to Gerard Berry. To summarize, Esterel and YASL di er in the grouping of basic notions of control. On the one hand, YASL has a single temporal projection operator that encompasses both iteration and suspension operators of Esterel. On the other hand, Esterel has a powerful trap-exit mechanism that often allows terser programs than YASL does. But this power is not without a price: an Esterel 16
statement has a separate completion code for each exit label it contains, which complicates its semantics and circuit translation [1]. Still, the control constructs of Esterel and YASL can simulate each other (see Appendix C for the remaining details). Since they were developed independently, this shows that they are \natural" and \non-arbitrary" in some (admittedly hard to de ne!) sense.
4.3 Comparison with Handel
Handel [13, 17] is essentially a small subset of Occam [8] and CSP [7], but with a synchronous semantics. Currently it is compiled into netlists for implementation on DPGAs (dynamically programmable gate arrays). The main di erence between Handel and YASL is that Handel has many data operations for manipulating bit vectors, while YASL is a skeleton language for programming control patterns. The basic data-manipulating statement in Handel is the assignment: R := e, where R is a register name and e an expression of the same bit width. The assignment statement takes exactly one clock cycle to execute and its semantics is obvious: the expression e (which may refer to the values of any registers, including R itself) is evaluated during the clock cycle and the result is latched into the register R only at the end of the clock cycle (so, unlike Esterel/YASL signals, assignments cannot produce causality loops); registers that are not assigned to retain their old values. We think it will be useful to incorporate assignments into YASL. If we do so, then Handel, including its channel communication constructs, can be simulated in YASL, as follows. Consider a Handel program p that contains the channel input command C ? R and the channel output command C ! e, where C is a channel name, R a register name, and e an expression. Then p can be simulated in YASL by:
signal I; O in loop C (await(present I ^ present O) ; R := e) k p [C ? R 7! (sustain(I ) k await(present O)) ; pause; C ! R 7! (sustain(O) k await(present I )) ; pause] where sustain is de ned by: sustain(X ) = loop C (emit X ; pause)
We should point out that the Handel compiler actually gives access to (the equivalents of) the I and O signals above, so the same trick can be used in Handel as well. It is easy to see how to simulate the other constructs of Handel in YASL. The real problem, of course, is that it is very easy to write a program that attempts to make two di erent assignments to the same register in the same clock cycle. It is not clear what the semantics of such con icts should be. Handel, like Occam, relies on syntactic restrictions on program formation to avoid this problem. But the Handel compiler does not actually enforce the 17
restrictions, but only gives warnings. We wonder whether this is because the Occam rules are too restrictive for \real-world" applications.
5 Future Research 5.1 Implementations
We are currently implementing a translator from YASL to BLIF-MV [3]. The reason for using BLIF-MV as the target format is that it provides entry into both veri cation [9, 19] and synthesis and optimization [16] tools. Indeed, we expect that the optimization of circuits obtained from syntax-directed translation be one of our main research topics in the future. We are also considering the feasibility of implementing YASL as a \macro package" for Verilog or VHDL.
5.2 Examples
We are currently investigating the feasibility of formal modeling in YASL of the Pentium Pro processor bus protocol [15]. One problem that has to be solved is the introduction of data (at least bit vectors) into YASL. As we have mentioned earlier, it is not clear how con icts in data assignments should be handled. Our intuition is that we probably have to live with this diculty, since it is inherently hard to prove that no such con icts occur in complex protocols while syntactic restrictions for avoiding con icts such as those adopted by Occam may be too restrictive for \real-world" applications.
5.3 Equational theories
It seems worthwhile to investigate equational theories of YASL. For instance, the following are some equational laws related to C:
skip C p skip pause C p p p C pause (p ; q) C r (p C r) ; (q C r) (p C q) C r p C (q C r) where denotes strong bisimilarity. Useful reasoning and optimization may be achieved using this kind of equational laws. Note that introducing data into YASL can reduce the number of valid equations; for example, parallel composition k may no longer be idempotent due to data assignment con icts.
5.4 Asynchrony
In this paper we have restricted ourselves to synchronous circuits because of their simplicity and ubiquity. But many interesting and important timing issues in digital systems arise from the interaction between di erent clock domains, where the clocks are not synchronized with respect to each other. We believe that the 18
design of high-level synthesizable languages for specifying temporal behaviors in this kind of applications will be a fruitful research topic for the future.
Appendixes A Constructive semantics of YASL
The SOS rules for signal hiding, (sig-+) and (sig-?), are non-constructive in the sense that they do not specify how to compute the status of the hidden signal X constructively, but only what \guesses" are logically consistent. This can lead to the kind of causality loops mentioned in Section 2.3. To rule out such pathological cases, we replace them by the following constructive rules: (c-sig-+) 0 + X 2 Must (p; E X ? ) p ?????? ! p0 S (E 0 ) = S (E ) n X + E
s
X
;k
E X
signal X in p ???0 ! signal X in p0 E ;k E
(c-sig-?)
0 ? p ?????? ! p0 S (E 0 ) = S (E ) n X ? 0 signal X in p ???! signal X in p0
X 62 Can (p; E X ? ) s
E
X
;k
E X
E ;k E
where Must and Can compute what p \must" and \can" do in one step assuming that the status of X is unknown (?). More precisely, we extend the set of signal statuses from B to B? = f+; ?; ?g and de ne a partial event to be a mapping from a signal sort to B? . Given a statement p and a partial event E , the Must (resp., Can) function returns a pair: Must(p; E ) = hS; K i Can(p; E ) = hS 0 ; K 0 i where S (S 0 ) is the set of signals that p must (can) emit and K (K 0 ) is the set of completion codes that p must (can) return, if the environment of p provides E . We will denote S by Must (p; E ) and K by Must (p; E ); similar notations apply to Can(p; E ). The operations [ and n are generalized component-wise to (S; K ) pairs. We evaluate expressions on partial events as follows: [ present X ] (E ) = E (X ) [ true ] (E ) = + 8 < + if [ e ] (E ) = ? [ :e ] (E ) = : ? if [ e ] (E ) = + 8 ? otherwise < + if [ e ] (E ) = + and [ e0 ] (E ) = + 0 [ e ^ e ] (E ) = : ? if [ e ] (E ) = ? or [ e0 ] (E ) = ? ? otherwise s
k
19
The Must and Can functions are de ned (mutually) recursively as follows: Must(emit X; E ) = Can(emit X; E ) = h fX g; f0g i Must(pause; E ) = Can(pause; E ) = h ;; f1g i
8 > < Must(await e; E ) = > : 8 > < Can(await e; E ) = > :
h ;; f0g i if [ e ] (E ) = + h ;; f1g i if [ e ] (E ) = ? h ;; ; i if [ e ] (E ) = ? h ;; f0g i if [ e ] (E ) = + h ;; f1g i if [ e ] (E ) = ? h ;; f0; 1g i if [ e ] (E ) = ? 8 > < Must(p; E ) if [ e ] (E ) = + Must(if e then p else q; E ) = > Must(q; E ) if [ e ] (E ) = ? : h ;; ; i if [ e ] (E ) = ? 8 if [ e ] (E ) = + > < Can(p; E ) Can(if e then p else q; E ) = > Can(q; E ) if [ e ] (E ) = ? : Can(p; E ) [ Can(q; E ) if [ e ] (E ) = ? Must(p k q; E ) = h8Must (p; E ) [ Must (q; E ); K i > < f0g if Must (p; E ) = f0g or Must (q; E ) = f0g where K = > f1g if Must (p; E ) = f1g and Must (q; E ) = f1g s
s
k
k
: ; otherwise k
k
Can(p k q; E ) = h Can (p; E ) [ Can(q; E ); K i where K = f min(k; l) j k 2 Can (p; E ); l 2 Can (q; E ) g s
k
k
8 Must(p; E ) > < if 0 62 Must (p; E ) Must(p ; q; E ) = > h Must (p; E ) [ Must (q; E ); Must (q; E ) i > : if 0 2 Must (p; E ) 8 Can(p; E ) > > if 0 62 Can (p; E ) < Can(p ; q; E ) = > h Can (p; E ) [ Can (q; E ); > (p; E ) n 0) [ Can (q; E ) i > : (Can if 0 2 Can (p; E ) k
s
s
k
k
k
s
s
k
k
k
20
8 Must(p; E ) > < if 1 62 Must (p; E ) Must(p C q; E ) = > ) [ Must (q; E ); 1 i > : h Mustif 1(p;2EMust (p; E ) 8 Can(p; E ) > < if 1 62 Can (p; E ) Can(p C q; E ) = > ) [ Can (q; E ); Can (p; E ) i > : h Canif (1p;2ECan (p; E ) k
s
s
k
k
s
s
k
k
8 Must(p; E X + ) n X > > > if X 2 Must (p; E X ? ) > < X ?) n X Must(signal X in p; E ) = > Mustif(p;XE 62 Can (p; E X ? ) > > (p; E X ? ) n X > : Mustotherwise s
s
Can(signal X in p; E ) = Can(p; E X ? ) n X
B Initial-cycle circuits for YASL operators
I (emit X )
X
i
E R
B X
I (pause)
o
B
0
21
E R N
I (await e)
W
i
e E R N
1 0
B
0
W
o
I (if e then p else q) W e
B
X Y
i
0 1
i
B
Z
i
i
Xi Yi
E I (p) R N Xo Yo
E R N B
Xi Zi
E I (q) R N Xo Zo
0
W
o
X Y o
Z
o
o
22
I (p ; q)
X Y i
B
B
Z
i
i
Xi Yi
E I (p) R N Xo Yo
E R N B
X Y o
I (p k q)
X Y i
B
B
Xi Zi
E I (q) R N Xo Zo
Z
o
Z
i
o
i
Xi Yi
E I (p) R N Xo Yo
E R N B
X Y o
Xi Zi
E I (q) R N Xo Zo
Z
o
o
23
I (p C q)
X Y i
B
B
Z
i
i
Xi Yi
E I (p) R N Xo Yo
E R N B
X Y o
E I (q) R N Xo Zo
Z
o
I (signal X in p)
Y
B
Xi Zi
B
i
Xi Yi
E I (p) R N Xo Yo Y
o
E R N
o
C Simulating Esterel in YASL and vice versa C.1 Simulating Esterel in YASL
It has been shown in Section 1 how to express both iteration (Eqs. (1) and (2)) and suspension (Eq. (3)) in YASL. To simulate the parallel composition p || q of Esterel in YASL, we use an 24
explicit synchronizer: signal X; Y in ( await(present X ^ present Y ) k (p ; sustain(X )) k (q ; sustain(Y )) ) where X and Y are fresh signal names. To simulate nested trap-exits in YASL, we re ne the construction for nonnested trap-exit given in Section 4.2. Assume without loss of generality that no trap name is declared twice or used as a signal name. We will adopt the convention that if a program executes exit T at a place not in the scope of any trap T declaration, then it loops. An Esterel statement trap T in p end is simulated by the following YASL statement: signal T in ( (await(present T ) k p0 ) ; (if (present T1 _ _ present T ) then loop else skip) ) where fT1 ; : : : ; T g is the set of trap names that appear in an exit statement in p but are not declared anywhere by a trap in p, and p0 is obtained from p by recursively applying this very construction to every trap declaration in p and then replacing every exit T by (emit T ; loop). Note that n could be 0, in which case we get the same construction as (5) in Section 4.2 for non-nested trap-exit. n
n
C.2 Simulating YASL in Esterel
It only remains to show that the await and k operators of YASL can be simulated in Esterel. Clearly, await e can be simulated by: trap T in (loop (if e then exit T else pause) end) end and p k q by: trap T in ( (p ; exit T ) || (q ; exit T ) ) end where T is a fresh trap name.
References [1] G. Berry, The Constructive Semantics of Pure Esterel (draft version 2.0), 22 May 1996. (Available over the Internet.) [2] G. Berry and G. Gonthier, \The Esterel synchronous programming language: Design, semantics, implementation", Science of Computer Programming, 19(2):87{152, 1992. 25
[3] BLIF-MV, VIS Development Group, Dec. 1995. [4] M. Chiodo, P. Giusto, H. Hsieh, A. Jurecska, L. Lavagno, and A. Sangiovanni-Vincentelli, \Hardware-Software Codesign of Embedded Systems", IEEE Micro, 14(4):26{36, Aug. 1994. [5] E.M. Clarke, E.A. Emerson, and A.P. Sistla, \Automatic veri cation of nite-state concurrent systems using temporal logic speci cations", ACM Trans. on Prog. Lang. and Sys., 8(2):244{263, Apr. 1986. [6] N. Halbwachs, Synchronous Programming of Reactive Systems, Kluwer Academic Publishers, 1993. [7] C.A.R. Hoare, Communicating Sequential Processes, Prentice-Hall, 1985. [8] Inmos, The Occam2 Programming Manual, Prentice-Hall, 1988. [9] H. Iwashita, T. Nakata, and F. Hirose, \CTL model checking based on forward state traversal", International Conference on Computer-Aided Design, 1996. [10] T. F. Melham, \Abstraction Mechanisms for Hardware Veri cation", pp. 267{291 of G. Birtwistle and P.A. Subrahmanyam(ed.), Current Trends in Hardware Veri cation and Automated Theorem Proving, SpringerVerlag, 1989. [11] B. Moszkowski, Reasoning about Digital Circuits, Ph.D. Thesis, Dept. of Computer Science, Stanford University, 1983. [12] B. Moszkowski, Executing Temporal Logic Programs, Cambridge University Press, 1986. [13] I. Page, \Constructing hardware-software systems from a single description", Jul. 1995. (Available over the Internet.) [14] G. Plotkin, \A structural approach to operational semantics", Technical Report DAIMI FN-19, University of Aarhus, 1981. [15] Pentium Pro Family Developer's Manual, Vol. 1: Speci cations, Intel Corporation, 1996. [16] E.M. Sentovich, et al., SIS: A system for sequential circuit synthesis, Technical Report M92/41, University of California at Berkeley, May 1992. [17] M. Spivey, I. Page, and W. Luk, How to program in Handel, Aug. 1995. (Available over the Internet.) [18] H. Touati and G. Berry, \Optimized controller synthesis using Esterel", International Workshop on Logic Synthesis, Lake Tahoe, 1993. [19] T. Villa, G.Swamy, T. Shiple, et al., VIS User's Manual, Dec. 1995. 26
