Top Up Prev Next Bottom Contents Index Search

12.3 Phase-Based Firing Mode

The ordering of simultaneous events is the most challenging task of the DE scheduler. In general, simultaneous events are caused by insufficient time resolution, particularly when the time unit is integral. In our case, simultaneous events are primarily caused by functional stars that produce output events with the same time stamp as the input events. Since the time stamp is a double-precision floating-point number, we have very high time resolution.

As explained earlier, the DE scheduler fetches at most one event for each input porthole for each firing of a DE star. In the body of the star code, the programmer can consume the simultaneous events onto a certain input porthole by calling the getSimulEvent method for the porthole. This mode of operation is called simple mode, which is the default mode of operation.

Suppose we program a new DE star, called Counter. The Counter star has one clock input and one demand input. A clock event will increase the counter value by one, and the demand input will send the counter value to the output. If there are multiple simultaneous clock inputs and a simultaneous demand input, we should count all the clock inputs before consuming the demand input and producing an output. Thus, the programmer should call the getSimulEvent method for the clock input. However, the getSimulEvent method is expensive when there are many simultaneous events, since it gets only one simultaneous event at a time. This runtime overhead is reduced in the phase-based firing mode.

In the phase-based firing mode, or simply the phase mode, before executing a star, the scheduler fetches all simultaneous events for the star. The fetched events are stored in the internal queue of each input porthole. The internal queue of inputs is created only if the star operates in phase mode. In phase mode, when a DE star fires, it consumes all simultaneous events currently available. It constructs a phase. Afterwards, other simultaneous events for the same star may be generated by a network of functional stars. Then, the star may be fired again with another set of simultaneous events, which forms another phase. We can set the operation mode of a star phase by calling method setMode(PHASE) in the constructor, as summarized in table 12-1 on page 12-5. The following example is written in the simple mode.


go {
...
while (input.dataNew) {
temp += int(input.get());
input.getSimulEvent();
}
...
}
If the star is re-written using the phase mode, it will look like:


constructor {
setMode(PHASE);
}
go {
...
while (input.dataNew) {
temp += int(input.get());
}
...
}
or,

go {
...
for (int i = input.numSimulEvents(); i > 0; i--) {
temp += int(input.get());
}
...
}
The get method in phase mode fetches events from the internal queue one at a time. After consuming all events from the queue (now the queue is empty), it resets the dataNew flag. If a star in phase mode does not access all simultaneous input events in a particular firing, the unaccessed events are discarded.

The method, numSimulEvent, returns the current queue size in phase mode. Recall that in simple mode, the method returns the number of simultaneous events in the global event queue, which is one less than the actual number of simultaneous events. This difference of one between two modes is necessary for coding efficiency.

There is still inherent non-determinism in the handling of simultaneous events in the DE domain. For example, suppose that the Switch star has more than one simultaneous control event. Which one is really the last one? Since the input is routed to either the true or false output depending on the last value of the control event, the decision is quite critical. We leave the responsibility of resolving such inherent non-determinism to the user.



Top Up Prev Next Bottom Contents Index Search

Copyright © 1990-1997, University of California. All rights reserved.