.\" @(#)timing	1.10	12/12/92
.H1 "Timing Relationship Between Domains
.pp
\*(PT can support an effectively unlimited number of different
domains since adding a new domain affects neither any existing
implementation of other domains nor the kernel.
The domain interface should take care of timing relations between
the outer and  the inner domains. Timing management is the most 
.IE "timing management"
challenging task in the design of
.c Wormhole s
and their interconnection mechanism.  Our approach is to
classify the domains into two groups: \fItimed\fR, and
\fIuntimed\fR.  In a \fItimed\fR domain, the scheduler
.IE "timed domain"
.IE "untimed domain"
keeps track of the global timing relations among data packets
.c (Particles).
On the other hand, an \fIuntimed\fR domain
requires only the local ordering information of data packets.
The taxonomy of existing domains is:
.sp
.nf
\fItimed\fR : DE, THOR, etc
\fIuntimed\fR : SDF, DDF, CG, etc
.fi
.sp
.pp
The scheduler
of a domain maintains a member called \fIcurrentTime\fR for timing
.IE "currentTime"
management.  For a timed domain, \fIcurrentTime\fR indicates the
global time.  As the scheduler proceeds, \fIcurrentTime\fR also
.IE "global time"
increases.  Hence, the stopping condition for a timed domain is
given by a stopping time.  On the other hand, an untimed domain
does not have the concept of time in its model of computation.
If an untimed domain resides in a
.c Wormhole ,
then the \fIcurrentTime\fR of the domain is simply the copy of the
\fIcurrentTime\fR of the outer domain.
.pp
There are four combinations of timed and untimed domains.  For each
combination, we will show how to do timing management.
.H2 "An Untimed Domain in an Untimed Domain"
.pp
This first combination is the simplest for timing management: 
an untimed domain contains another untimed domain.
For example, a DDF domain may contain an SDF domain.
Since the outer domain does not care about the \fIcurrentTime\fR 
of the inner domain,
we are free to manage the \fIcurrentTime\fR of the inner domain.
In this case, the \fIcurrentTime\fR of the inner domain is just
copied from that of the outer domain.
During the execution of the
wormhole, the \fIcurrentTime\fR remains unchanged.  
The stopping condition of the inner domain is given by the number of
iterations of the schedule.  
The \fIresetStopTime()\fR method of the scheduler sets the
stopping condition to "one iteration", ignoring the argument to
the method.
The meaning of "one iteration" is domain specific.
.IE "iteration, scheduling"
Refer to the individual domain documentation for the
interpretation of "one iteration".
.H2 "An Untimed Domain in a Timed Domain
.pp
The second possibility is that a timed domain contains an untimed domain.
If a DE domain contains an SDF domain, it falls into this category.
In this case, the \fIcurrentTime\fR of the inner untimed domain
is synchronized with the \fIcurrentTime\fR of the outer timed domain
at the beginning of the
execution of the wormhole.
Like the first case, the \fIcurrentTime\fR
of the inner domain is not increased during the execution.
It gives an illusion to the outer domain that the untimed domain takes
zero time for execution.  Since the inner domain has no notion of
time, it seems not only awkward but infeasible to assign any 
execution delay to the inner domain.  Instead, we can simulate
any desired time delay of the inner domain by attaching a
.c Delay
star in the outer domain to the inputs or outputs of the wormhole.
The decoupling of the delay and the functionality of a 
block in a timed domain
is the basic technique we use in a timed domain like DE.
The stopping condition of the inner domain is again "one iteration".
.H2 "A Timed Domain in a Timed Domain
.pp
This third combination is the most complicated: a timed domain contains
another timed domain.  It is complicated because timed domains
have a notion of chronology, but the principle of wormholes
implies that the chronology of one domain cannot be visible from another.
Maintaining consistency between these chronologies is the principal
challenge.
A DE domain containing a THOR domain will be
an example.  First of all, since both domains have global clocks, 
we have to synchronize them.  Therefore, the inner domain's
.c Target
object has a 
.c State 
called \fItimeScale\fR which is the ratio between the time unit of
.IE "timeScale"
inner domain and that of the outer domain.  The
\fItimeScale\fR is $1.0$ by default (no scaling).  
At the beginning of the execution of the 
wormhole,
the \fIcurrentTime\fR of the outer domain is scaled by the \fItimeScale\fR
and copied to the \fIcurrentTime\fR of the
inner domain.  The \fIcurrentTime\fR of the inner domain
proceeds as the wormhole
is executed until the stopping condition is met.  After the execution 
finishes, the \fIcurrentTime\fR of the inner domain is scaled again
by the inverse of the \fItimeScale\fR and informed to the outer domain.
A user can change the value of the
scale factor by changing the value of the target parameter
(\fItimeScale\fR) in the outermost galaxy of the inner timed domain.
In the interpreter, the following line does it:
.(c
targetparam timeScale 10.0
.)c
In the graphical interface, this state can be modified by executing
the
.i edit-target
command on the inner galaxy.  Doing so causes two menus to appear
in succession; the first permits the user to change the target object
used; simply click ``OK''.  The second menu permits galaxy parameters
to be altered; now the \fItimeScale\fR parameter can be altered.
.pp
The decision about the stopping condition of the inner domain is the most
complex part of the domain interface.  Suppose that the
wormhole
has two inputs ($input sub 1$, $input sub 2$) and two outputs
($output sub 1$, $output sub 2$).  If $input sub 1$ receives an
event
.c (Particle),
the wormhole
starts execution.  The complication arises from the observation
that this wormhole cannot safely process internal events
with later time stamps than the event on $input sub 1$.
It may later receive an event on $input sub 2$ that invalidates
these computations.
For example, if 
$input sub 2$ is a reset input of a system, the reset event will
affect the previous execution if it is not completed.
Therefore, we can process the inner system at a given event
only until the time stamp of the next event to arrive at any input.  
Unfortunately it is generally
not possible to predict when the next event will arrive.
One possible solution is to process the
wormhole
for one time unit at each invocation.  In case of THOR domain, one
time unit is well defined so that this approach is acceptable.
However, there is no notion of a basic time unit in the DE domain.
Also, the approach is too conservative and will result in a lot of overhead.
Even though there will be no event during the next $100$ time units,
the 
wormhole
would be invoked $100$ times to march one time unit
at each invocation.  
.pp
Another approach is to process the 
wormhole
until the next earliest event in the outer domain. 
When the
wormhole
is to be executed, we check the \fIexpected\fR next global time by examining
the next earliest event in the event queue of the outer domain.  
The stopping condition
of the inner timed domain is set with the stop time equal to the
expected next global time.  As long as the
wormhole
does not generate any event during execution, the expected next global
time becomes the \fIactual\fR next global time.  If the inner domain generates
any output events, however, 
they may be the next earliest events
in the outer domain.
Hence, this approach may not work.
Suppose that the inner domain generates output events through
$output sub 1$ earlier than through $output sub 2$.  Moreover, the
output event through $output sub 1$ is routed back to $input sub 2$ of the
.c Wormhole .
Then, we meet the original problem if this feedback event should have
affected the
output event through $output sub 2$ of the previous execution.
Since the output event through $output sub 2$ is already produced in the
previous execution, there is no way to correct the event.
.pp
We can improve the previous approach as follows. 
Suppose that we have exactly one timed 
.c Wormhole .
At the beginning of the execution,
we set the stop time of the
.c Wormhole
with the expected next global time.  We proceed the inner
scheduling
until the \fIcurrentTime\fR reaches the stop time, or until
the inner domain generates any output.
If the wormhole
generates an output, the output becomes the next earliest event
in the outer domain.  Therefore, our scheme is simply to
process the wormhole
until the actual (not expected) next global time in the outer domain.
This proves the correctness of our solution.
But, if there are more than one, say two, timed
wormholes,
this approach also fails.  We have to compare the
time stamps of the output events from both
wormholes to detect the actual next global time. 
While we are executing a 
wormhole,
it is not possible to determine the actual next global
time since it is unknown before executing the other
wormhole.
.pp
Finally, we have developed the following solution.  
When a wormhole is fired, its stopping time is set equal to the
external global time. Generally that external global time must be equal to
the time stamp of the event that triggered the firing of the
wormhole. Thus, the stopping time is equal to the time stamp of the
event that triggered the firing of the wormhole.
Thus, generally speaking the wormhole cannot advance in time at
all. The wormhole looks like a functional star without delay.
The wormhole processes this single input event and any simultaneous
internal events, sets its global time to
the oldest (stalest) event on its event queue, and returns control.
The external domain must invoke this wormhole again at this internal
global time, or earlier if another event on its own event queue triggers
the wormhole earlier. Thus, in effect the external domain must
store an event on its event queue at the internal global time for the wormhole;
in effect, the outer event queue is storing the stalest event on the
inner domain event queue. This event triggers the firing of the
wormhole at that proper time.
Therefore, at the end of the execution of the
wormhole,
we determine the next event time of the inner domain and copy it to
\fIcurrentTime\fR of the inner scheduler.
We also set a flag, \fIstopBeforeDeadlocked\fR, if the inner domain
is not deadlocked.
If the flag is set, 
Then, the outer scheduler
stores a triggering event of the inner domain
in the event queue
at the scaled \fIcurrentTime\fR of the inner scheduler.
.pp
In this approach, the total system event queue consists of the outer
domain event queue and the wormhole event queues. These event queues
are coordinated by storing the stalest event of the inner domains
on the outer domain event queue in order to invoke the wormholes
at the proper time.
Each time a wormhole is fired, it processes one event, either
an external triggering event or an internal event queue event.
If there are multiple events with the same time stamp, they can
all be processed.
.pp
An important exception occurs when the outer domain knows that
future events are constrained in the earliest time they can occur.
For this case, the outer domain can set a stopping time equal to
that "earliest next event". This will be more efficient because
generally the wormhole can process more than just the external
triggering event, it can also process some internally generated and
consumed events. This exception would occur for an SDF outer domain,
which when it invokes the wormhole can set the stopping time equal
to the next sample time for the wormhole.
.pp
In summary, the inner domain can never overtake the the
outer domain in time, which proves the correctness of the approach
regardless of the number of timed
wormholes involved.  The timed
wormhole forms a special class of
stars in a timed domain, called "process-star".  The first invocation
.IE "process-star"
of a process-star is triggered by external events to the star.
But the further invocations are triggered
without external events until the
star has no more internal events to process.
.H2 "A Timed Domain in an Untimed Domain
.pp
The last possible combination is that of a timed domain in an
untimed domain.  Even though the untimed domain has no notion of
time, it needs to control the inner timed domain by setting the
stopping condition.  For that purpose, an untimed domain
keeps a property called its \fIschedulePeriod\fR.  
.IE "schedulePeriod"
The \fIcurrentTime\fR of the untimed domain is increased by the
\fIschedulePeriod\fR after each iteration.
A user can control the value of the \fIschedulePeriod\fR by altering
the
(\fIschedulePeriod\fR) target parameter
in the outermost galaxy of the untimed domain.
In the interpreter, the following line does the job:
.(c
targetparam schedulePeriod "10.0"
.)c
The default value of \fIschedulePeriod\fR of the untimed
domain is set to a large number ($10000$).
Presumably, the \fIschedulePeriod\fR has no physical significance
since in the untimed domain, time has no meaning.  The sole
purpose of the state is to define the stopping condition of the
timed domain.  A user should make sure that the 
wormhole does all necessary tasks before it reaches the stopping condition.
The common approach is to set the stop time large enough so that
the timed domain is deadlocked (meaning that there are no
active events in the timed system) before the stop time.  Then, the
timed domain acts as a functional block like a conventional 
star in the untimed domain.  Note that in this case, the inner timed
domain need not stop after it generates its first output event, unlike the
third case above.
.pp
There is a special case where the above discussion is not
applicable.  Suppose that the untimed 
universe is an SDF domain.
We can interpret the SDF domain as a time driven domain where
.IE "time driven"
the time interval between data packets is fixed, and hidden safely
in the system representation.  A synchronous digital
signal processing system falls into this category.
In this case, the SDF domain looks like a timed domain!.  The
\fIschedulePeriod\fR then has physical significance.
Hence, the user has to supply a meaningful value.
The \fIschedulePeriod\fR of the SDF system represents the repetition
period of the SDF schedule, and during one iteration, there may
arrive more than one data packet at the
wormhole.
The time-interval of the data packets becomes the ratio of the
\fIschedulePeriod\fR and the number of arrived data packets during one
iteration.  It is this time-interval and not the \fIschedulePeriod\fR
that determines the stop time of the inner timed domain.
This combination of a SDF domain and a timed domain has 
abundant applications.
.H2 "Summary
.pp
We have discussed four combinations of the domains.
If a wormhole contains another wormhole,
we can apply the basic rule developed in this section
to each domain interface.  For example, a timed domain
contains a wormhole of an untimed domain which itself contains a timed
wormhole.
Since the timed domain inside an untimed domain loses the physical
meaning of times, the innermost timed domain has nothing to do with
the outer timed domain in timing management.  Still the untimed
domain takes zero time in the sense of the outer global clock.
An exceptional case is when
the untimed domain is the SDF domain for time-driven application
(e.g. DSP application).  By controlling the \fIschedulePeriod\fR
of the SDF domain, we can synchronize the innermost timed
domain and the outer timed domain.
