Dynamic Dataflow Modeling in Ptolemy II - Ptolemy Project ...
Dynamic Dataflow Modeling in Ptolemy II - Ptolemy Project ...
Dynamic Dataflow Modeling in Ptolemy II - Ptolemy Project ...
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
<strong>Dataflow</strong> programm<strong>in</strong>g has come a long way s<strong>in</strong>ce its use <strong>in</strong> the signal process<strong>in</strong>g<br />
community. Various programm<strong>in</strong>g environments based on this model of computation<br />
have been developed over the years. Various specialized dataflow models of computation<br />
have been <strong>in</strong>vented and studied. (We will give a brief overview <strong>in</strong> section 2). Various<br />
schedul<strong>in</strong>g algorithms based on different criteria pert<strong>in</strong>ent for specific applications have<br />
been proposed. It is still a fruitful area of active research due to its expressive way to<br />
represent concurrency for embedded system design.<br />
1.3 A Software Environment for Experiment<strong>in</strong>g with MoC ---- <strong>Ptolemy</strong> <strong>II</strong><br />
The <strong>Ptolemy</strong> project at University of California at Berkeley studies model<strong>in</strong>g, simulation,<br />
and design of concurrent, real-time, embedded systems. The focus is on assembly of<br />
concurrent components. The key underly<strong>in</strong>g pr<strong>in</strong>ciple <strong>in</strong> the project is the use of well-<br />
def<strong>in</strong>ed models of computation that govern the <strong>in</strong>teraction between components [4].<br />
Unlike most system design environments which have one or two built-<strong>in</strong> models of<br />
computation, the <strong>Ptolemy</strong> kernel has no built-<strong>in</strong> semantics. Instead the kernel package<br />
def<strong>in</strong>es a small set of Java classes that implement a data structure support<strong>in</strong>g a general<br />
form of un<strong>in</strong>terpreted clustered graphs (see Figure 1.1 taken from [6]), which provide an<br />
abstract syntax that is not concerned with the mean<strong>in</strong>g of the <strong>in</strong>terconnections of<br />
components, nor even what a component is.<br />
The semantics is <strong>in</strong>troduced <strong>in</strong> the actor package which provides basic support for<br />
executable entities. However it makes a m<strong>in</strong>imal commitment to the semantics of these<br />
entities by avoid<strong>in</strong>g specify<strong>in</strong>g the order <strong>in</strong> which actors execute and the communication<br />
mechanism between actors. These properties are def<strong>in</strong>ed <strong>in</strong> each doma<strong>in</strong> where the<br />
12