Bill:
Dataflow alone is perhaps not ideal for networking applications
since it is awkward to specify control using pure dataflow.
There are several possibilities:
1) Dataflow + FSM. A hierarchical combination of these
might be a good solution. We have an experimental formalism
called heterochronous dataflow that is expressive with
regard to control, but decidable like SDF (and hence,
in principle, amenable to synthesis). See paper by
Girault, Lee, and Lee on the Ptolemy website.
2) Synchronous/Reactive. Dataflow-ish in flavor, but better
at control.
3) SR + PN, with PN at the top. SR provides fairly tightly
coupled concurrency, which may not match your architecture
well. We have done very little experimentation with SR + PN,
but it seems promising. Some people advocate this sort of
"globally asynchronous, locally synchronous (GALS)" approach.
4) Timed Multitasking (TM). Aimed at implementation using
priority-driven RTOSs, but with a more deterministic model
of computation than that offered by threads and semaphores,
the standard RTOS-based development strategy.
Edward
At 10:43 AM 5/14/2002 -0500, Bill Wood wrote:
> . . .
> > I think it is more common in this application area to use
> > discrete-event modeling (as in the DE domain) and finite
> > state machines (as in the FSM domain).
>
>Several people made essentially this point; it's well-taken
>and I basically agree.
>
>I'm wrestling with the problem of finding a good model of
>computation to support design of applications that are to
>be implemented on coarse-grained arrays.
<snip>
>...
>I envision an environment in which a developer can design an
>application in a high-level data-flow or process network
>notation, validate at the high level for correctness, then
>map onto the implementation architecture and validate for
>performance.
<snip>
>An important aspect of this problem is the question of
>appropriateness -- some problems fit the implementation
>platform like a glove, and others should simply be done
>some other way. I'd like the design environment to inform
>the selection decision -- bad fit would manifest as clumsy,
>convoluted design.
>
>So my primary question is, what appear to be good candidates
>for computational models to support this sort of design, if
>not some variety of dataflow?
>
>Many thanks,
>
> -- Bill Wood
>
>----------------------------------------------------------------------------
>Posted to the ptolemy-hackers mailing list. Please send administrative
>mail for this list to: [EMAIL PROTECTED]
------------
Edward A. Lee, Professor
518 Cory Hall, UC Berkeley, Berkeley, CA 94720
phone: 510-642-0455, fax: 510-642-2739
[EMAIL PROTECTED], http://ptolemy.eecs.berkeley.edu/~eal
----------------------------------------------------------------------------
Posted to the ptolemy-hackers mailing list. Please send administrative
mail for this list to: [EMAIL PROTECTED]
