Heterogeneous Simulation—Mixing Discrete-Event Models with ...

P1: SSK/SRK

P2: PMR

Journal of VLSI Signal Processing

KL387-09-Chang

January 10, 1997

14:10

Journal of VLSI Signal Processing 15, 127–144 (1997) c 1997 Kluwer Academic Publishers. Manufactured in The Netherlands. °

Heterogeneous Simulation—Mixing Discrete-Event Models with Dataflow WAN-TEH CHANG EECS Dept., U.C. Berkeley, USA SOONHOI HA Department of Computer Engineering, Seoul National University, Korea EDWARD A. LEE EECS Dept., U.C. Berkeley, USA

Abstract. This paper relates to system-level design of signal processing systems, which are often heterogeneous in implementation technologies and design styles. The heterogeneous approach, by combining small, specialized models of computation, achieves generality and also lends itself to automatic synthesis and formal verification. Key to the heterogeneous approach is to define interaction semantics that resolve the ambiguities when different models of computation are brought together. For this purpose, we introduce a tagged signal model as a formal framework within which the models of computation can be precisely described and unambiguously differentiated, and their interactions can be understood. In this paper, we will focus on the interaction between dataflow models, which have partially ordered events, and discrete-event models, with their notion of time that usually defines a total order of events. A variety of interaction semantics, mainly in handling the different notions of time in the two models, are explored to illustrate the subtleties involved. An implementation based on the Ptolemy system from U.C. Berkeley is described and critiqued.

1.

Introduction

This paper relates to system-level design of signal processing systems. Such systems are often embedded, and their implementation mixes hardware and software. This inevitably complicates the design process by forcing a heterogeneous approach. Even within the software or hardware portions themselves there is often heterogeneity. In software, control-oriented processes might be mixed under the supervision of a multitasking real-time kernel running in a microcontroller. In addition, hard-real-time tasks may run cooperatively on one or more programmable DSPs. The design styles used for these two software subsystems are likely to be quite different from one another, and testing the interaction between them is unlikely to be trivial. The hardware side of the design will frequently contain one or more ASICs, perhaps designed using logic

or behavioral synthesis tools. On the other hand, a significant part of the hardware design most likely consists of interconnections of commodity components, such as processors and memories. Again, this time on the hardware side, we find heterogeneity. The design styles used to specify and simulate the ASICs and the interconnected commodity components are likely to be quite different, and may not be supported by the same design and simulation tools. A typical system, therefore, not only mixes hardware design with software design, but also mixes design styles within each of these categories. Two opposing approaches for such system-level design are possible. One is the unified approach, which seeks a consistent semantics for specification of the complete system. The semantics must be rich enough to support heterogeneous design. The other is a heterogeneous approach, which seeks to systematically

P1: SSK/SRK

P2: PMR

Journal of VLSI Signal Processing

128

KL387-09-Chang

January 10, 1997

Chang, Ha and Lee

combine disjoint semantics. Although the intellectual appeal of the unified approach is compelling, we have adopted the heterogeneous approach. We believe that the diversity in design styles commonly used today precludes a unified solution in the foreseeable future. 1.1.

14:10

Models of Computation

Key to the heterogeneous approach is the notion of models of computation. A model of computation (MoC) is the semantics of the interaction between modules or components. MoCs are used in computer programming as well as in the design of electronic systems. They can be viewed as the organizing principles of a design specification or model. They relate strongly to the design style, but may or may not relate strongly to the implementation technology. Classes of MoCs include: Imperative. In an imperative model of computation, modules are executed sequentially to accomplish a task. Finite State Machine (FSM). In an FSM MoC, a specification enumerates the set of states that a system can be in together with the rules for transitioning from one state to another. Dataflow. In a dataflow MoC, modules react to the availability of data at their inputs by performing some computation and producing data on their outputs. Communication between modules is via streams, which are sequences of data tokens. Each token is an arbitrary data structure that is treated monolithically by the MoC. Discrete Event. In the discrete-event MoC, modules react to events that occur at a given time instant and produce other events either at the same time instant or at some future time instant. Execution is chronological. Synchronous Languages. In synchronous languages, modules simultaneously react to a set of input events and instantaneously produce output events. If cyclic dependencies are allowed, then execution involves finding a fixed point, or a consistent value for all events at a given time instant. It is important to recognize the distinction between a MoC and the way that the MoC might be implemented. For example, while the first two of the above MoCs are fundamentally sequential and the last three are fundamentally concurrent, it is possible to use the first two on parallel machines and the last three on sequential machines. It is also important to recognize the distinction between a model of computation and a language. A syntax is an important part of a language and not of a MoC. A language may add little more than a syntax to a MoC,

but more commonly it will implement more than one MoC. For example, VHDL can be used in an imperative or discrete-event style. Hierarchical FSMs, like Statecharts [1] and at least 22 variants [2], combine FSMs with a concurrent MoC, typically that of synchronous languages. Languages that are fundamentally based on one MoC may also be used to implement another. For example, C, which is fundamentally imperative, may be used to implement a dataflow MoC [3]. A MoC is often most easily defined in terms of a language. The language may be very incomplete and/or very abstract. For example, it may specify only the interaction between computational modules, and not the computation performed by the modules. Instead, it provides an interface to a host language that specifies the computation, and is called a coordination language. Or the language may specify only the causality constraints of the interactions without detailing the interactions themselves nor providing an interface to a host language. In this case, the language is used as a tool to prove properties of systems, as done, for example, in process calculi. 1.2.

Time

Some concurrent MoCs have a built-in notion of time. Time provides such a natural conceptual model of concurrency that we might define concurrency in terms of time (using the phrase “at the same time”). A broader definition, however, would be more consistent with the etymology of the word “concurrent,” which comes from the Latin concurrere, con- (together) plus currere (to run). Dataflow MoCs are concurrent with no notion of time. In the discrete-event (DE) MoC, time is an integral part of the model. Events in this MoC will typically carry a time stamp, which is an indicator of the time at which the event occurs within the model. A DE simulator will typically maintain a global event queue that sorts events by time stamp. Note that a DE simulator has an internal notion of simulated time that need not correspond to real time. A key to designing successful simulators is to not rely on real time to maintain a correct model of simulated time. In synchronous languages, the notion of time is more abstract. The word “instantaneously” used above is not to be taken literally. Time progresses in discrete jumps, called ticks, rather than continuously as in nature. “Instantaneously” means “at the same tick.” Simulation of hardware designs is typically accomplished using a discrete-event simulator, such as that embodied in VHDL or Verilog simulators. A signal is

P1: SSK/SRK

P2: PMR

Journal of VLSI Signal Processing

KL387-09-Chang

January 10, 1997

14:10

Heterogeneous Simulation

a sequence of events. A time stamp tags each event, giving the set of events an order. The tag may be an integer, a floating-point number, or a data structure representing both the advance of time and possibly the sequencing of microsteps within a time instant. In all cases, the job of the simulator is to sort events so that those with the earliest time stamps are processed first, and so that the events seen by any particular component have monotonically increasing time stamps. Time stamps, therefore, define an ordering of events. Discrete-event modeling can be expensive. The sorting of time stamps can be computationally costly. Moreover, ironically, although discrete-event is ideally suited to modeling distributed systems, it is very challenging to build a parallel discrete-event simulator. The global ordering of events requires much tighter coordination between parts of the simulation than would be ideal for parallel execution. In an alternative model, events occur synchronously, according to a clock. Events that occur at different clock ticks are globally ordered (one unambiguously precedes the other). Simultaneous events (those at the same clock tick) may be totally ordered, partially ordered, or unordered, depending on the MoC. Unlike the discrete-event model, however, all signals have events at all clock ticks. This results in considerably simpler simulators, because sorting is not required. Simulators that exploit this simplification are called cycle-based or cycle-driven simulators. Processing all events at a given clock tick constitutes a cycle. Within a cycle, the order in which events are processed may be determined by data precedences, which therefore define microsteps. These precedences are not allowed to be cyclic, and typically impose a partial order. Cyclebased models are excellent for clocked synchronous circuits. They have also been applied successfully at the system level in certain signal processing applications. A cycle-based model is inefficient for modeling systems where events do not occur at the same rate in all signals. While conceptually such systems can be modeled (using for example special tokens to indicate the absence of an event), the cost of processing such tokens is considerable. Fortunately, the cycle-based model is easily generalized to multirate systems. In this case, every n-th event in one signal aligns with the events in another. A multirate cycle-based model is somewhat limited. It is an excellent model for synchronous signal processing systems where sample rates are related by known rational multiples, but in situations where the alignment of events in different signals is irregular, it can be inefficient.

129

A more general model is embodied in the so-called synchronous languages [4]. Examples of such languages include Esterel [5], Signal [6], and Lustre [7]. In synchronous languages, every signal is conceptually (or explicitly) accompanied by a clock signal. The clock signal has meaning relative to other clock signals. It defines the global ordering of events. Thus, when comparing two signals, the associated clock signals indicate which events are simultaneous and which precede or follow others. A clock calculus allows a compiler to reason about these ordering relationships and to detect inconsistencies in the definition. Various looser models of computation specify only a partial ordering between events. This means that while events within any given signal are ordered, events in different signals may or may not have an ordering relationship. This type of specification has the advantage that it avoids overspecifying a design. If an ordering relationship is not important in a design, why specify it? Specifying it may severely constrain the implementation options. Thus, for example, while discrete-event simulators are difficult to parallelize, dataflow models, which are usually partially ordered [8], are comparatively easy to parallelize.

1.3.

Expressive Power

Theoreticians strive for simple but expressive models of computation. “Simple” in this case means that the MoC can be defined by a language with only a few primitives. For example, Turing machines, which define an imperative MoC, are defined by the Turing-Post language, which has only seven instructions [9, 10]. Church’s lambda calculus is based on only a few formal rules for transforming strings [11]. “Expressive” in this case means that the MoC can specify many different systems. Both Turing machines and the lambda calculus can describe a set of functions that are called the “effectively computable functions.” This set is so large that many people regard any computation that is not in the set to be not computable. Practitioners view such efforts much the way they view Turing machines: they make interesting abstractions, but they do not tell us much about how to build systems. To a practitioner, the utility of a MoC stems from a more pragmatic view of expressiveness: how easy is it to construct a given system description? How expensive is the compiled implementation? How sure can we be that the design is correct? It is largely irrelevant that it is theoretically possible to construct such a description. Moreover, since the practitioner works

P1: SSK/SRK

P2: PMR

Journal of VLSI Signal Processing

130

KL387-09-Chang

January 10, 1997

Chang, Ha and Lee

more directly with a language than with a MoC, the syntax and practical expressiveness of the language become central. This tension between theorists and practitioners is healthy, and the best solutions emerge from compromise. But a major risk in this compromise is “creeping featurism.” In an effort to win the broadest support, features and options are added to a language until all semblance of simplicity has been lost. This is frequently how languages come to contain more than one MoC. The down side of such large languages with multiple MoCs is that formal analysis may become very difficult. This compromises our ability to generate efficient implementations or simulations. It also makes it more difficult to be sure that a design is correct; it precludes such formal verification techniques as reachability analysis, safety analysis, and liveness analysis. Usually, features are added to a language for good reason. Their advocates can cite numerous applications, and win their acceptance through compelling arguments about the utility of the features. The key is that both excessive simplicity and excessive complexity can interfere with utility. 1.4.

14:10

Heterogeneity

A reasonable way to balance the pressures of breadth and simplicity is to support heterogeneity. Failure to do so has doomed some otherwise laudable efforts. For example, Common Lisp did not at first define a “foreign function interface,” presumably because everything could be done in Lisp. Practitioners, who built Common Lisp systems, realized that this was not a practical approach, and built their own, mutually incompatible foreign function interfaces. As a result, Lisp systems were only interchangeable if applications used no foreign functions. And few significant applications qualified. Standardization failed. Small, specialized languages and tools are useful. For example, viewed as languages, spreadsheets are extremely useful. But they are certainly not general, in that there are many applications for which they are inappropriate. Such tools are therefore most useful if they can be combined with other specialized tools. Each tool is developed independently, making the development effort manageably small. But by embedding the tool in an environment with appropriate interfaces between tools (a file system, cutting and pasting, and a multitasking operating system, to name some examples), the utility of the tool is greatly magnified.

Looser integration of diverse capabilities has numerous advantages: 1. Existing, familiar tools do not need to be discarded in favor of a new, all-encompassing tool. This is particularly valuable when expertise with complex tools has built up over time. 2. Capabilities can come in “bite sized” modules, making them easier to learn, and rendering them more acceptable to a cautious clientele. 3. Tools from different vendors can be mixed, drawing from the strengths of each. 4. Competition among vendors is enhanced because fewer customers are “locked in.” This results in better tools at lower prices. 5. Innovative tools with specialized capabilities have a market. They do not need to be all- encompassing to be salable. So innovation is encouraged. There are also significant disadvantages: 1. User interfaces are likely to be different with different tools, making them more difficult to learn. 2. Integration may not be complete. For example, once a design is migrated from one tool to another, without tight integration, it may be difficult to back annotate the original design. We believe that with system-level design problems, the advantages outweigh the disadvantages, and that the disadvantages will at least partially disappear later as the technology solidifies. Our experience suggests that several models of computation are required for the design of complete systems. In particular, in order to successfully apply formal methods, and in order to obtain good results from highlevel synthesis, the smallest (most restrictive) models of computation are best. Thus, to achieve generality, one has to embrace heterogeneity. 1.5.

Modeling and Specification

There is a subtle relationship between the specification of a system and the modeling of a system. An executable specification, for example, is also a model of an implementation. The difference is in emphasis. A specification describes the functionality of a system, and may also describe one or more implementations. A model of a system describes an implementation, and may also describe the functionality. In a specification,

P1: SSK/SRK

P2: PMR

Journal of VLSI Signal Processing

KL387-09-Chang

January 10, 1997

14:10

Heterogeneous Simulation

131

a discrete- event language to model its detailed implementation. Often, it makes sense to combine modeling and specification. Design elaboration, for example, is the process of replacing portions of an executable specification with ever more detailed models of the implementation. Often, for efficient simulation, it makes sense to maintain multiple levels of abstraction in a system simulation. This requires a simulation environment where diverse models of computation can interact. 1.6. Figure 1.

Models of computation and cosimulation.

it is important to avoid overspecifying the design, to leave implementation options open. In a model, often the key criteria are precision, simplicity, and efficient simulation. A model should be the most abstract model that represents the details being tested. Fig. 1 shows the role that specification and modeling might take in system design. Specification is closer to the problem level, at a higher level of abstraction, and uses one or more models of computation. A specification undergoes a synthesis process (which may be partly manual) that generates a model of an implementation. That model itself may harbor multiple models of computation, mainly to model components at varying levels of abstraction, or to separately model hardware and software components. Visual dataflow programming languages, for example, are commonly used in the signal processing community for specification. Hierarchical finite-state machine languages are used for specifying controloriented systems. Symbolic processing languages are used to specify functionality in scientific computing. Imperative languages are used for everything (whether or not they are appropriate). Discrete-event MoCs are used to specify concurrent communicating systems. Discrete-event MoCs, such as those used in VHDL, Verilog, and other simulation environments, are also used for modeling implementations. They describe physical components with states that evolve over time and with interactions that occur at discrete points in time. Imperative MoCs provide a natural way to model software implementations. They are also used for modeling hardware components at higher levels of abstraction. For example, an instruction set architecture model for a hardware processor might be implemented in the imperative language C rather than using

From Specification to Modeling

In Fig. 1, the synthesis paths are somewhat constrained by the choice of MoC used for specification. It is well known, for example, that a discrete-event MoC is difficult to implement efficiently on a sequential machine. This is the main reason that VHDL simulations surprise the designer by taking so long. A model that heavily uses entities communicating through signals will burden the discrete-event scheduler and bog down the simulation. Thus, a specification built on discreteevent semantics is a poor match for implementation in software. By contrast, VHDL that is written as strictly sequential code, using imperative semantics, runs relatively quickly, but may not translate well into hardware. Imperative C, of course, runs very quickly, and is well suited to specifying components that will be implemented in software. However, it is poorly suited to specifying hardware. Dataflow and finite-state machine MoCs have been shown to be reasonably retargettable. Hierarchical FMS such as Statecharts [1, 2, 12], for example, can be used effectively to design hardware or software. Similarly, a number of commercial and research tools use dataflow to specify signal processing systems that can be implemented either way [13–15]. It has also been shown that a single dataflow specification can be partitioned for combined hardware and software implementation [16, 17]. 2.

Multi-Paradigm Design

In this paper, we will focus on the interaction between dataflow models, with their partially ordered events, and discrete-event models, with their notion of time defining a (mostly) total order of events. A variety of interaction semantics are explored, and an implementation based on the Ptolemy system from U.C. Berkeley

P1: SSK/SRK

P2: PMR

Journal of VLSI Signal Processing

132

KL387-09-Chang

January 10, 1997

14:10

Chang, Ha and Lee

is described. We begin with some background on each. This will be followed by a formal framework that unambiguously defines the essential features of each MoC and their interaction. 2.1.

Dataflow Process Networks

In dataflow, a program is specified by a directed graph where the nodes represent computations (actors) and the arcs represent streams of data tokens. The graphs are often represented visually and are typically hierarchical, in that an actor in a graph may represent another directed graph. The nodes in the graph can be either language primitives or subprograms specified in another language, such as C or FORTRAN. In the latter case, we are already mixing two of the models of computation from Fig. 1, where dataflow serves as the coordination language for subprograms written in an imperative host language. Some examples of graphical dataflow programming environments intended for signal processing (including image processing) are Khoros, from the University of New Mexico [18] (now distributed by Khoral Research, Inc.), Ptolemy, from the University of California at Berkeley [3], the Signal Processing Worksystem (SPW), from the Alta Group at Cadence (formerly Comdisco Systems), COSSAP, from Synopsys (formerly Cadis), and the DSP Station from Mentor Graphics (formerly EDC). These software environments all claim variants of dataflow semantics, but a word of caution is in order. The term “dataflow” is often used loosely for semantics that deviate significantly from those outlined by Dennis in 1975 [19]. Most, however, can be described formally as special cases of dataflow process networks [8], which are in turn are a special case of Kahn process networks [20]. In Kahn process networks, a number of concurrent processes communicate through unidirectional FIFO channels, where writes to the channel are non-blocking, and reads are blocking (see Fig. 2). This means that

Figure 2. In a process network, where processes communicate through unidirectional FIFO channels, writes are non-blocking, and reads are blocking.

Figure 3.

A dataflow process consists of repeated firings of an actor.

Figure 4.

Static scheduling of a dataflow process network.

writes to the channel always succeed immediately, while reads block until there is sufficient data in the channel to satisfy them. In particular, a process cannot test an input channel for the availability of data and then branch conditionally. Testing for available data constitutes a read, and will block the entire process until data is available. This restriction helps to assure that the program is determinate, meaning that its outputs are entirely determined by its inputs and the behavior specified by the programmer. In dataflow process networks, each process consists of repeated firings of a dataflow actor (see Fig. 3). An actor defines a (often functional) quantum of computation. By dividing processes into actor firings, the multitasking overhead of context switching incurred in direct implementations of Kahn process networks is avoided. In fact, in many of the signal processing environments, a major objective is to statically (at compile time) schedule the actor firings (see Fig. 4). The firings are organized into a list (for one processor) or set of lists (for multiple processors). In Fig. 4, a dataflow graph is shown mapped into a single processor schedule. Thus, the lower part of the figure represents a list of firings that can be repeated indefinitely. A basic requirement of such a schedule is that one cycle through the schedule should return the graph to its original state (defined as the number of tokens on each arc). This is not always possible, but when it is, considerable simplification results. Many possibilities have been explored for precise semantics of dataflow coordination languages, including for example the computation graphs of Karp and Miller [21], the synchronous dataflow graphs of Lee and

P1: SSK/SRK

P2: PMR

Journal of VLSI Signal Processing

KL387-09-Chang

January 10, 1997

14:10

Heterogeneous Simulation

Messerschmitt [22], the cyclo-static dataflow model of Lauwereins et al. [23, 24], the Processing Graph Method (PGM) of Kaplan et al. [25], Granular Lucid [26], and others [27–30]. Many of these limit expressiveness in exchange for considerable advantages such as compile-time predictability. Synchronous dataflow (SDF) and cyclo-static dataflow both have the particularly useful property that a finite static schedule can always be found that will return the graph to its original state. This allows for extremely efficient implementations. For more general dataflow models, it is undecidable whether such a schedule exists [31]. A key property of dataflow processes is that the computation consists of atomic firings. Within a firing, anything can happen. In many existing environments, what happens can only be specified in a host language with imperative semantics, such as C and C++. In the Ptolemy system [3], it can consist of a quantum of computation specified with any of several models of computation. We will return to this notion of a “quantum of computation.” 2.2.

Discrete Event

As described above, the discrete-event model of computation has events with time stamps. The role of the simulator is to keep a list of events sorted by time stamp and to process the events in chronological order. There are, however, some subtleties that are dealt with differently in different systems. The main difficulties concern how simultaneous events (those with the same time stamp) are dealt with, and how zero-delay feedback loops are managed. Consider the graph shown in Fig. 5. Suppose it specifies a program in a discrete-event coordination language. Suppose further that B is a zero-delay component. This means that its output has the same time stamp as the most recent input. Thus, if A produces one event on each of its two outputs with the same time stamp T , then there is an ambiguity about whether B or C should be invoked next. This situation is illustrated in Fig. 6(a). B and C have events at their inputs

Figure 5.

A discrete-event example.

Figure 6.

133

Simultaneous events in discrete-event systems.

with identical time stamps, so either could be invoked next. But the behavior of C could be different in the two circumstances. Suppose B is invoked first, resulting in the configuration shown in Fig. 6(b). Now, depending on the simulator, C might be invoked once, observing both input events in one invocation. Or it might be invoked twice, processing the events one at a time. In the latter case, there is no clear way to determine which event should be processed first. Some discrete-event simulators leave this situation ambiguous. Such simulators are nondeterminate. In most applications, this is not desirable. A partial solution provided in some simulators is the infinitesimal delay. If B has an infinitesimal delay, then its output events will have time stamps that are ordered after those of the inputs even if they represent the same simulated time. Then, firing A followed by B will result in the situation shown in Fig. 6(c), where the effect of the infinitesimal delay is indicated by the “T +”. The next firing of C will observe only the first event, the one with time stamp T . This is the next one in the event queue. After this firing of C, the event with time stamp T + remains to be processed, as shown in Fig. 6(d). Infinitesimal delays are not an entirely satisfactory solution. Suppose the designer wishes for C to see both events at once, as in Fig. 6(b). There is no way to ensure that B will be invoked before C. For this reason, the discrete event domain in Ptolemy uses a different solution [3]. Graphs specifying discrete event programs are topologically sorted, and a priority is assigned to each arc. The topological sort is based on an annotation of the nodes in the graph indicating whether the node can have zero delay from any particular input to any particular output. When such zero delay is possible, the topological sort views this as a precedence constraint. Ignoring the feedback arc in Fig. 5, this would resolve all ambiguities. The topological sort would indicate that B should always be invoked before C when they have events at their inputs with identical time stamps.

P1: SSK/SRK

P2: PMR

Journal of VLSI Signal Processing

134

KL387-09-Chang

January 10, 1997

Chang, Ha and Lee

Figure 7. Sources of events in DE with and without explicit feedback loops.

This sort of precedence analysis is identical to that done in synchronous languages (Esterel, Lustre, and Signal) to ensure that simultaneous events are processed in a deterministic way. Of course, the feedback loop in Fig. 5 creates a problem. The same problem occurs in synchronous languages, where such loops are called causality loops. No precedence analysis can resolve the ambiguity. In synchronous languages, the compiler may simply fail to compile such a program. In the discrete-event domain in Ptolemy, we permit the user to annotate the arcs the graph to break the precedences. Thus, the programmer could annotate the leftward pointing arc in Fig. 5, again resolving the ambiguities. If the user fails to provide such annotation, a warning is issued, and the precise behavior is arbitrary (nondeterminate). A slight subtlety arises in discrete-event simulators with sources of events. Consider the example shown in Fig. 7(a). An initial event on the self loop with time stamp T causes A to fire at simulated time T . At that time, it can produce an event to B and another event on the self loop with a larger time stamp. By continuing to produce events on the self loop, it continually acts as a source of events for B. In the Ptolemy DE domain, we support the syntactic sugar shown in Fig. 7(b), where the self loop is hidden from view. Conceptually, any source of events is allowed to put its own future firings on the event queue. 3.

14:10

Time and Partial Orders

A major impediment to further progress in heterogeneous modeling and specification is the confusion that arises from different usage of common terms. Terms like “synchronous,” “discrete event,” and “dataflow” are used in different communities to mean significantly different things. No doubt, many readers have interpreted the descriptions above in ways quite different from what we intended.

Recognition of this problem has led to efforts to “unify” the work of different communities by defining a “grand unifying language” that embraces the semantic models of a set of competitors. A common language, it is suggested, provides a means by which people and tools can communicate more effectively. While we agree that such languages provide these benefits, we argue that they do so at great expense. In order to be sufficiently rich to encompass the varied semantic models of the competing approaches, they become unwieldy, too complex for formal analysis and high quality synthesis. We argue that small, simple, specialized models of computation are valuable. Efforts to subsume them into large, unwieldy, “general” models are misguided. The objectives of human communication can be achieved more simply by developing a human language that is sufficiently precise and formal to unambiguously differentiate approaches. Moreover, if the objectives of the resulting formalism are sufficiently constrained, it can provide a framework within which the semantics of the interaction between models of computation can be understood. Generality can be achieved through heterogeneity, where more than one model of computation is used. The objective of communication between tools is harder to achieve. Fundamentally, a translation from a language used by one tool to that used by another is primarily a translation of syntax. Translation of semantics is much harder. Thus, to get interoperability between tools by translation, we force each tool to implement each semantic model of interest. This, needless to say, severely complicates tool development, and serves as a barrier to innovation. To address these issues, we develop a human language that will enable description and differentiation of models of computation. To be sufficiently precise, this language is a mathematical one. We will define precisely a set of terms like “process,” “discrete-event systems,” and “synchronous” that are unambiguous, but will often conflict with common usage in some communities. We have made every attempt to maintain the spirit of that usage with which we are familiar, but have discovered that terms are used in contradictory ways in different communities (sometimes even within a community). Maintaining consistency with all prior usage is impossible without going to the unacceptable extreme of abandoning the use of these terms altogether. Our definitions in this paper conflict even with our own prior usage in certain cases. We apologize to anyone who is offended by our abuse of some term

P1: SSK/SRK

P2: PMR

Journal of VLSI Signal Processing

KL387-09-Chang

January 10, 1997

14:10

Heterogeneous Simulation

for which they have a different meaning that they are comfortable with. But there is no way to accomplish our objectives without this abuse. 3.1.

The Tagged Signal Model

Given a set of values V and a set of tags T , we define an event e to be a member of V × T , i.e., an event has a tag and a value. We define a signal s to be a partial function from T to V . By “partial function” we mean that the signal may be defined only for a subset of T . A signal s can be viewed therefore as a collection s of events, i.e., a subset of V × T , where if e1 = (v1 , t) ∈ s and e2 = (v2 , t) ∈ s, then v1 = v2 . We call the set of all signals S. It is often useful to form a collection s of n signals. The set of all such signals will be denoted S n . A process P with n inputs and m outputs is a subset of S n × S m . In other words, a process defines a relation between input signals and output signals. Signals provide communication between processes. Note that with this definition, non-determinacy is supported. A particular set of input signals may have several possible sets of output signals that satisfy the relation. A functional process F, or simply a function, is a single valued mapping from some subset of S n to S m . That is, if (s1 , s2 ) ∈ F and (s1 , s3 ) ∈ F, then s2 = s3 . A tagged system is a set of signals and processes defining relations between these signals. A tagged system is said to be fixed if each process and each signal exists throughout the existence of the system. Otherwise, it is said to be mutable. Thus, in a mutable tagged system, processes or signals may come and go. Our term “tagged system” here does not refer to an implementation. It refers to a model or a specification. This usage of “system” is common in system theory, but uncommon in other disciplines. Frequently, a natural interpretation for the tags is that they mark time in a physical system. Neglecting relativistic effects, time is the same everywhere, so tagging events with the time at which they occur puts them in a certain order (if two events are genuinely simultaneous, then their order is arbitrary). For specifying systems, however, the global ordering of events in a timed system may be overly restrictive. A specification should not be constrained by one particular physical implementation, and therefore need not be based on the semantics of the physical world. Thus, for specification, often the tags should not mark time. In a model of a physical system, by contrast, tagging the events with the time at which they occur may seem

135

natural. They must occur at a particular time, and if we accept that time is uniform, then our model should reflect the ensuing ordering of events. However, when modeling a large concurrent system, the model should probably reflect the inherent difficulty in maintaining a consistent view of time in a distributed system [32–34]. If an implementation cannot maintain a consistent view of time, then it may be inappropriate for its model to do so (it depends on what questions the model is expected to answer). Fortunately, there are a rich set of untimed models of computation. In these models, the tags are more abstract objects, often bearing only a partial ordering relationship among themselves. We now give one way to classify these models of computation. 3.1.1. Types of Systems. A partially ordered tagged system (POTS) is a tagged system where T is a countable, partially ordered set. Partially ordered means that there exists an irreflexive, antisymmetric, transitive relation between members of the set [35]. We denote this relation using the symbol “