. . .
> 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.  It seems perverse
to simply compile some flavor of a sequential programming
language such as MATAB or C to the platform, since this
requires the application designer (who is presumably
familiar with that language) to simultaneously (1) think
sequentially, as experience and habits would encourage, and
(2) think parallel, in order to use the right patterns for
the compiler to translate into good parallel code.  I'm also
discovering that engineers are very comfortable with graphical
models like signal flow graphs and block diagrams.  Thus I'm
leaning towards a graphical, parallel language, likely visual.
The computational model that defines its semantics, then, would
have to be parallel and network-oriented as well.  I'm not
convinced that data-parallel models fit the application space
very well, so sequential application of vector operations ala
MATLAB doesn't seem appropriate.

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.  A multi-model simulation environment like
Ptolemy seems perfect for some of these validation tasks.
In addition some tool like the French AAA/SynDEx for
automagically mapping the application design onto the
architecture would be nice.

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]

Reply via email to