
DTDirector |
ptolemy.domains.dt.kernel.DTDirector |
The Discrete Time (DT) domain director.
<h1>DT overview</h1>
The Discrete Time (DT) domain is a timed extension of the Synchronous
Dataflow (SDF) domain. Like SDF, it has static scheduling of the
dataflow graph model. Similarly, DT requires that the data rates on
the ports of all actors be known beforehand and fixed. DT handles
feedback systems in the same way that SDF does, but with additional
constraints on initial tokens. <p>
<h1>Local and Global Time</h1>
Because of the inherent concurrency occurring within SDF models, there
are two notions of time in DT -- global time and local time. Global
time increases steadily as execution progresses. Moreover, global
time increases by fixed discrete amounts given by the <i>period</i>
parameter. On the other hand, each receiver is associated with an
independent local time. All the receivers have distinct local times as
an iteration proceeds. The local time of a receiver during an
iteration depends on the global time, period, firing count, port
rates, and the schedule. These local times obey the following
constraint:
<center>Global Time <= Local Time <= (Global Time + period)</center>
The exact way that local time increments during an iteration is described in
detail in the DTReceiver documentation.
<p>
<h1> Period Parameter </h1><p>
The DT director has a <i>period</i> parameter which specifies the
amount of time per iteration. For hierarchical DT, this period
parameter only makes sense on the top-level. The user cannot
explicitly set the period parameter for a DT subsystem inside another
DT system. For heterogeneous hierarchies (e.g. DT inside DE or DT
inside CT), the period parameter specifies the time interval between
firings of the DT subsystem. The DT subsystem will not fire on times
that are not integer multiples of the period parameter.
<p>.
<h1>DT Features</h1>
The design of the DT domain is motivated by the following criteria:
<OL>
<LI>) Uniform Token Flow: The time interval between tokens should be
regular and unchanging. This conforms to the idea of having sampled
systems with fixed rates. Although the tokens flowing in DT do not
keep internal time stamps, each actor can query the DT director for
its own local time. This local time is uniformly increasing by a
constant fraction of the director's <i>period</I>. Local time is
incremented every time the get() method is called to obtain a token.
<LI>) Causality: Tokens produced by an actor should only depend on
tokens produced or consumed in the past. This makes sense because we
don't expect an actor to produce a token before it can calculate the
token's value. For example, if an actor needs three tokens A, B, and
C to compute token D, then the time when tokens A, B, and C are
consumed should be earlier than or equal to the time when token D is
produced. Note that in DT, time does not get incremented due to
computation. <LI>) SDF-style semantics: Ideally, we want DT to be a
timed-superset of SDF with compatible token flow and scheduling.
However, we can only approximate this behavior. It is not possible to
have uniform token flow, causality, and SDF-style semantics at the
same time. Causality breaks for non-homogeneous actors in a feedback
system when fully-compatible SDF-style semantics is adopted. To
remedy this situation, every actor in DT that has non-homogeneous
input ports should produce initial tokens at each of its output ports.
</OL>
</p>
<p>
<h1> Design Notes</h1>
DT (Discrete Time) is a timed model of computation. In order
to benefit from the internal time-keeping mechanism of DT, one should
use actors aware of time. For example, one should use TimedPlotter or
TimedScope instead of SequencePlotter or SequenceScope.
<p>
Top-level DT Directors have a <i>period</i> parameter that can be set by the
user. Setting the period parameter of a non-top-level DT Director
under hierarchical DT has no meaning; and hence will be ignored.
<p>
<p> Domain-polymorphic actors that want to take advantage of the
multi-rate timing capabilities of DT should call
getCurrentTime(channel_number) for every
get(channel_number). Moreover, the call sequence should be ordered as
follows: getCurrentTime(channel_number) before get(channel_number).
Known bugs:
<pre>
1.) Put more tests on this case: when events come in faster than the period
of a DT composite actor (e.g clock feeding DT)
2.) Put more tests on this case: when DT composite actor doesn't fire because
there aren't enough tokens.
3.) Domain-polymorphic actors that use getCurrentTime() should be modified
to use DT's multirate timing capabilities.
CurrentTime - modified
TimedPlotter - modified
TimedScope - modified
SequentialClock - no input ports, gets global time only
PoissonClock - under investigation
Clock - under investigation
Expression - under investigation
</pre>
Author(s): C. Fong
Version:$Id: DTDirector.doc.html,v 1.1 2006/02/22 18:40:26 mangal Exp $
Pt.Proposed Rating:Yellow (chf)
Pt.Accepted Rating:Yellow (vogel)