"Time" in the DE domain means simulated time. The DE domain may be used in combination with other domains in MLDesigner, even if the other domains do not have a notion of simulated time.
A given simulation, therefore, may involve several schedulers, some of which use a notion of simulated time, and some of which do not. There may also be more than one DE scheduler active in one simulation. The notion of time in the separate schedulers needs to be coordinated. This coordination is specific to the inner and outer domains of the wormhole. Important cases are described below.
A common combination of domains pairs the SDF domain with the DE domain. There are two possible scenarios. If the SDF domain is inside the DE domain, then the SDF subsystem appears to the DE system as a zero-delay block. Suppose, for example, that an event with timestamp T is available at the input to the SDF subsystem. Then when the DE scheduler reaches this time, it fires the SDF subsystem. The SDF subsystem runs the SDF scheduler through one iteration, consuming the input event. In response, it will typically produce one output event, and this output event will be given the timestamp T.
If the SDF subsystem is a multi-rate system, the effects are somewhat more subtle. First, a single event at the input may not be sufficient to cycle through one iteration of the SDF schedule. In this case, the SDF subsystem will simply return, having produced no output events. Only when enough input events have accumulated at the input will any output events be produced. Second, when output events are produced, more than one event may be produced. In the current implementation, all of the output events that are produced have the same timestamp. This may change in future implementations.
When an SDF domain appears within a DE domain, events at the input to the SDF subsystem result in zero-delay events at the output of the SDF subsystem. Thus, the timestamps at the output are identically to the timestamps at the input.
More care has to be taken when one wants an SDF subsystem to serve as a source primitive in a discrete-event domain. Recall that source primitives in the DE domain have to schedule themselves. One solution is to create an SDF "source" subsystem that takes an input, and then connect a DE source to the input of the SDF wormhole.
The reverse scenario is where a DE subsystem is included within an SDF system. The key requirement, in this case, is that when the DE subsystem is fired, it must produce output events, since these will be expected by the SDF subsystem. A very simple example is shown below. It's a typical DE subsystem intended for inclusion within an SDF subsystem. When a DE subsystem appears within an SDF system, the DE subsystem must ensure that the appropriate number of output events are produced in response to input events. This is typically accomplished with a "Sampler" primitive.
The DE subsystem in the figure routes input events through a time delay. The events at the output of the time delay, however, will be events in the future. The Sampler primitive, therefore, is introduced to produce an output event at the current simulation time. This output event, therefore, is produced before the DE scheduler returns control to the output SDF scheduler.
This may not be the desired behavior. The Sampler primitive, given an event on its clock input, copies the most recent event from its input to the output. If there has been no input data event, then a zero-valued event is produced. There are many alternative ways to ensure that an output event is produced. For this reason, the mechanism for ensuring that this output event is produced is not built-in. The user must understand the semantics of the interacting domains, and act accordingly.
The DE domain is a timed domain. Suppose it contains another timed domain in a DE wormhole. In this case, the inner domain may need to be activated at a given point in simulated time even if there are no new events on its input portholes. Suppose, for instance, that the inner domain contains a clock that internally generates events at regular intervals. Then these events need to be processed at the appropriate time regardless of whether the inner system has any new external stimulus.
The mechanism for handling this situation is simple. When the internal domain is initialized or fired, it can, before returning, place itself on the event queue of the outer domain, much the same way that an event generator primitive would. This ensures that the inner event will be processed at the appropriate time in the overall chronology. Thus, when a timed domain sits within a timed domain wormhole, before returning control to the scheduler of the outer domain, it requests rescheduling at the time corresponding to the oldest timestamp on its event queue, if there is such an event.
When an internal timed domain is invoked by another time domain, it is told to run until a given "stop time", usually the time of the events at the inputs to the internal domain that triggered the invocation. This "stop time" is the current time of the outer scheduler. Since the inner scheduler is requested to not exceed that time, it can only produce events with timestamp equal to that time. Thus, a timed domain wormhole, when fired, will always either produce no output events, or produce output events with timestamp equal to the simulated time at which it was fired.
To get a time delay through such a wormhole, two firings are required. Suppose the first firing is triggered by an input event at time , then the inside system generates an internal event at a future time . Before returning control to the outer scheduler, the inner scheduler requests that it be reinvoked at time . When the "current time" of the outer scheduler reaches , it reinvokes the inner scheduler, which then produces an output event at time .