Results 1  10
of
10
Design of Embedded Systems: Formal Models, Validation, and Synthesis
 PROCEEDINGS OF THE IEEE
, 1999
"... This paper addresses the design of reactive realtime embedded systems. Such systems are often heterogeneous in implementation technologies and design styles, for example by combining hardware ASICs with embedded software. The concurrent design process for such embedded systems involves solving the ..."
Abstract

Cited by 128 (9 self)
 Add to MetaCart
(Show Context)
This paper addresses the design of reactive realtime embedded systems. Such systems are often heterogeneous in implementation technologies and design styles, for example by combining hardware ASICs with embedded software. The concurrent design process for such embedded systems involves solving the specification, validation, and synthesis problems. We review the variety of approaches to these problems that have been taken.
Comparing Models of Computation
 IN PROC. ICCAD
, 1996
"... We give a denotational framework (a "meta model") within which certain properties of models of computation can be understood and compared. It describes concurrent processes as sets of possible behaviors. Compositions of processes are given as intersections of their behaviors. The interacti ..."
Abstract

Cited by 30 (1 self)
 Add to MetaCart
We give a denotational framework (a "meta model") within which certain properties of models of computation can be understood and compared. It describes concurrent processes as sets of possible behaviors. Compositions of processes are given as intersections of their behaviors. The interaction between processes is through signals, which are collections of events. Each event is a valuetag pair, where the tags can come from a partially ordered or totally ordered set. Timed models are where the set of tags is totally ordered. Synchronous events share the same tag, and synchronous signals contain events with the same set of tags. Synchronous systems contain synchronous signals. Strict causality (in timed systems) and continuity (in untimed systems) ensure determinacy under certain technical conditions. The framework is used to compare certain essential features of various models of computation, including Kahn process networks, dataflow, sequential processes, concurrent sequential processes with rendezvous, Petri nets, and discreteevent systems.
Heterogenous Simulation  mixing discreteevent model with dataflow
, 1996
"... This paper relates to systemlevel 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 ..."
Abstract

Cited by 19 (4 self)
 Add to MetaCart
This paper relates to systemlevel 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 discreteevent 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.
Effective heterogeneous design and cosimulation
 In NATO Advanced Study Institute Workshop on Hardware/Software Codesign
, 1995
"... ..."
(Show Context)
The token flow model
 In
, 1993
"... This paper reviews and extends an analytical model for the behavior of dataflow graphs with datadependent control flow. The number of tokens produced or consumed by each actor is given as a symbolic function of the Booleans in the system. Longterm averages can be analyzed to determine consistency ..."
Abstract

Cited by 14 (0 self)
 Add to MetaCart
This paper reviews and extends an analytical model for the behavior of dataflow graphs with datadependent control flow. The number of tokens produced or consumed by each actor is given as a symbolic function of the Booleans in the system. Longterm averages can be analyzed to determine consistency of token flow rates. Shortterm behavior can be analyzed to construct an annotated schedule, or a static schedule that annotates each firing of an actor with the Boolean conditions under which that firing occurs. Necessary and sufficient conditions for boundedlength schedules, as well as sufficient conditions for determining that a dataflow graph can be scheduled in bounded memory are given. Annotated schedules can be used to generate efficient implementations of the algorithms described by the dataflow graphs. 1.
A Calculus of Stochastic Systems for the Specification, Simulation, and Hidden State Estimation of Mixed Stochastic/Nonstochastic Systems
 Theoretical Computer Science
, 1995
"... In this paper, we consider mixed systems containing both stochastic and nonstochastic 1 components. To compose such systems, we introduce a general combinator which allows the specification of an arbitrary mixed system in terms of elementary components of only two types. Thus, systems are obtai ..."
Abstract

Cited by 9 (2 self)
 Add to MetaCart
In this paper, we consider mixed systems containing both stochastic and nonstochastic 1 components. To compose such systems, we introduce a general combinator which allows the specification of an arbitrary mixed system in terms of elementary components of only two types. Thus, systems are obtained hierarchically, by composing subsystems, where each subsystem can be viewed as an "increment" in the decomposition of the full system. The resulting mixed stochastic system specifications are generally not "executable", since they do not necessarily permit the incremental simulation of the system variables. Such a simulation requires compiling the dependency relations existing between the system variables. Another issue involves finding the most likely internal states of a stochastic system from a set of observations. We provide a small set of primitives for transforming mixed systems, which allows the solution of the two problems of incremental simulation and estimation of stocha...
Interoperation of heterogeneous CAD tools in Ptolemy II
 In Proc. SPIE Vol. 3680, Design, Test, and Microfabrication of MEMS and MOEMS
, 1999
"... Typical complex systems that involve microsensors and microactuators exhibit heterogeneity both at the implementation level and the problem level. This naturally leads to a heterogeneous approach to system design that uses domainspecific models of computation (MoC) at various levels of abstractions ..."
Abstract

Cited by 2 (1 self)
 Add to MetaCart
(Show Context)
Typical complex systems that involve microsensors and microactuators exhibit heterogeneity both at the implementation level and the problem level. This naturally leads to a heterogeneous approach to system design that uses domainspecific models of computation (MoC) at various levels of abstractions to define a system, and leverages multiple CAD tools to do simulation, verification, and synthesis. As the size and scope of the system increases, the integration becomes too difficult and unmanageable if different tools are coordinated using simple scripts. In addition, for MEMS devices and mixedsignal circuits, it is essential to integrate tools with different MoCs to simulate the whole system. Ptolemy II, a heterogeneous systemlevel design tool, supports the interaction among different MoCs. This paper discusses heterogeneous CAD tool interoperability in the Ptolemy II framework. The key is to understand the semantic interface and classify the tools by their MoC and their level of abstraction. Interfaces are designed for each domain so that the external tools can be easily wrapped. Then the interoperability of the tools becomes the interoperability of the domains. Ptolemy II can serve as the standard interface among different tools to achieve overall design modeling. A microaccelerometer with digital feedback is studied as an example.
SystemLevel Specification and Cosimulation for Multimedia Embedded Systems
"... As a systematic design approach, hardware/software codesign has been focused as a new design methodology to bridge the increasing gap between design complexity and productivity. There have been proposed various codesign procedures depending on system level specification method. In this thesis, we us ..."
Abstract
 Add to MetaCart
(Show Context)
As a systematic design approach, hardware/software codesign has been focused as a new design methodology to bridge the increasing gap between design complexity and productivity. There have been proposed various codesign procedures depending on system level specification method. In this thesis, we use formal models of computation for system specification to ease design validation by using &quot;correct by construction &quot; principle. It is challenging to specify the complex multimedia embedded systems by existent formal models of computation. Complex multimedia systems do not perform a single dedicated function but support multiple operational modes with different system constraints. Diverse activation conditions and realtime properties of the system should be considered from initial specification.
Abstract Statecharts in the Making: A Personal Account
"... This paper is a highly personal and subjective account of how the language of statecharts came into being. The main novelty of the language is in being a fully executable visual formalism intended for capturing the behavior of complex realworld systems, and an interesting aspect of its history is t ..."
Abstract
 Add to MetaCart
(Show Context)
This paper is a highly personal and subjective account of how the language of statecharts came into being. The main novelty of the language is in being a fully executable visual formalism intended for capturing the behavior of complex realworld systems, and an interesting aspect of its history is that it illustrates the advantages of theoreticians venturing out into the trenches of the real world, &quot;dirtying their hands &quot; and working closely with the system's engineers. The story is told in a way that puts statecharts into perspective and discusses the role of the language in the emergence of broader concepts, such as visual formalisms in general, reactive systems, modeldriven development, model executability and code generation. 1.