Code File Location: VisualSim/Simulators/de/kernel/DEDirector
Simulator is a form of Model of Computation that controls the activity and time in a model.
The Digital Simulator is used for Performance and Architecture modeling.
This Simulator is used to model protocols, hardware and mapping of behavior to architecture. This simulator is used when the model is being triggered as an event or based on time. The Digital Simulator implements the discrete-event Model of Computation (MoC). This Simulator maintain a notion of current time, and processes events chronologically in this time. An event is a token with a time stamp. Much of the sophistication in this Simulator is aimed at handling simultaneous events intelligently, so that deterministic behavior can be achieved.
Note: This block defaults to Digital Simulator Only mode. If the usre needs to construct a model containing analog, control, DSP or image processing blocks, then the Digital ONly must be unselected.
The DigitalDebugger pull-down menu in the Simulator provides graphical debugging support. In the Digital simulation mode, users can get model summary, the firing order of the blocks and perform step-by-step evaluation of the model. To enable this feature, select Configure>>DigitalDebugger>>Pause, Summary_Only or Run in the Digital Simulator icon. If the top-level simulator is enabled, all lower-level simulators are set to this default.
The debug mode can be triggered from the start of the simulation or when the "DigitalDebuggingExpr" parameter evaluates to true.
To view the debugging information, select Listen to Simulator from the Debug Menu in the BDE.
The debugger parameters are:
|
Parameter |
Explanation |
|
Off |
This disables the debugging mode and is recommended when the model is running in batch mode or is in analysis mode. |
|
Pause |
This will turn on the debugger to stop at every block in the model flow. The GO button must be selected to continue the simulation after the model stops at each block. Use Listen To Simulator (Debug >> Listen to Simulator) to determine which block is currently being fired. This provides a model summary at the end of the simulation (Refer Summary_Only). |
|
Summary_Only |
At the end of the simulation, this generates a list of all the blocks at the current level of the simulator and all levels below. For each block:
It also lists all blocks that are not used in the model. |
|
Run |
This mode records the order in which each block is fired in the model. This provides a model summary at the end of the simulation (Refer Summary_Only). |
The bottleneck in a typical Digital Simulator is in the maintenance of the global event queue. By default, a Digital Simulator uses the calendar queue as the global event queue. This is an efficient algorithm with O(1) time complexity in both enqueue and dequeue operations.
A Discrete Event(DE) has a time stamp, a microstep, and a depth.
Time stamp: It indicates the time when the event occurs.
Microstep: It represents the phase of execution when processing simultaneous events in directed loops, or when an actor schedules itself for firing later at the current time (using fireAt()).
Depth: It is the index of the destination block in a topological sort. A larger value of depth represents a lower priority when processing events. The depth is determined by topologically sorting the actors according to data dependencies over which there is no time delay.
ÞNote: The zero-delay data dependencies are determined on a per port basis.
Ports in the DE domain may be instances of DEIOPort. The DEIOPort class should be used whenever an actor introduces time delays between the inputs and the outputs. When an ordinary IOPort is used, the Simulator assumes, for the purpose of calculating priorities, that the delay across the actor is zero. On the other hand, when DEIOPort is used, the delay across the actor can be declared to be non-zero by calling the delayTo() method on output ports.
Directed loops with no delay actors are not permitted; they would make it impossible to assign priorities. Such a loop can be broken by inserting an instance of the Delay actor. If zero delay around the loop is truly required, then simply set the delay parameter of that actor to zero.
Input ports in a DE model contain instances of DEReceiver. When a token is put into a DEReceiver, that receiver enqueues the event to the Simulator by calling the _enqueueEvent() method of this Simulator. This Simulator sorts all such events in a global event queue (a priority queue).
An iteration, in the DE domain, is defined as processing all the events whose time stamp equals to the current time of the Simulator. At the beginning of the fire() method, this Simulator dequeues a subset of the oldest events (the ones with smallest time stamp, microstep, and depth) from the global event queue, and puts those events into their destination receivers. The actor(s) to which these events are destined are the ones to be fired. The depth of an event is the depth of the actor to which it is destined. The depth of an actor is its position in a topological sort of the graph. The microstep is usually zero, but is incremented when a pure event is queued with Time stamp = Current time.
The actor that is fired must consume tokens from its input port(s), and will usually produce new events on its output port(s). These new events will be enqueued in the global event queue until their time stamps equal the current time. It is important that the actor actually consume tokens from its inputs, even if the tokens are solely used to trigger reactions. This is how polymorphic actors are used in the DE domain. The actor will be fired repeatedly until there are no more tokens in its input ports with the current time stamp. Alternatively, if the actor returns false in prefire(), then it will not be invoked again in the same iteration even if there are events in its receivers.
A model starts from the time specified by startTime, which has default value 0.0.
The stop time of the execution can be set using the stopTime parameter. The parameter has default value Infinity, which means the execution stops only when the model time reaches that (rather large) number.
Execution of a DE model ends when the
time stamp of the oldest events exceeds a preset stop time. This stopping
condition is checked inside the prefire() method of this Simulator. By default,
execution also ends when the global event queue becomes empty. Sometimes, the
desired behaviour is for the Simulator to wait on an empty queue until another
thread makes new events available. For example, a DE actor may produce events
when a user hits a button on the screen. To prevent ending the execution when
there are no more events, set the stopWhenQueueIsEmpty parameter to false.
If the parameter synchronizeToRealTime
is set to true,
then the Simulator will not process events until the real time elapsed since
the model started matches the time stamp of the event. This ensures that the
Simulator does not get ahead of real time, but, of course, it does not ensure
that the Simulator keeps up with real time.
This Simulator tolerates changes to the model during execution. The change should be queued with a component in the hierarchy using requestChange(). While invoking those changes, the method invalidateSchedule() is expected to be called, notifying the Simulator that the topology it used to calculate the priorities of the actors is no longer valid. This will result in the priorities being recalculated the next time prefire() is invoked.
However, there is one subtlety. If an actor produces events in the future via DEIOPort, then the destination block will be fired even if it has been removed from the topology by the time the execution reaches that future time. This may not always be the expected behavior. The Delay actor in the DE library behaves this way.
Refer Digital Demo Model.
Parameter |
Explanation |
Can be modified |
Type |
Example |
|
digitalDomainOnly |
The digitalDomainOnly is a high performance simulation option available when other types of non-digital simulators such as Continuous Time are not used in the model. This eliminates a number of checks and synchronization functions to accelerate the simulation. |
- |
- |
- |
|
DigitalDebuggingExpr |
This condition can have any RegEx function. This can contain TNow, global and local memories (requires the Window name.memory_name), block name and Regex functions such as GetBlockStatus. |
Yes |
- |
(getBlockStatus(memory_Queue,”length”,1)>25) |
|
startTime |
The start time of model. |
Yes |
Double |
0.0 |
|
stopTime |
The stop time of the model. |
Yes |
Double |
Infinity |
|
stopWhenQueueIsEmpty |
Specify whether the execution stops when the queue is empty. This parameter must contain a BooleanToken. If this parameter is true, the execution of the model will be stopped when the queue is empty. |
No |
- |
- |
|
synchronizeToRealTime |
Specify whether the execution should synchronize to the real time. This parameter must contain a BooleanToken. If this parameter is true, then do not process events until the elapsed real time matches the time stamp of the events. |
No |
- |
- |
|
timeResolution |
It has an impact on the length of the simulation. For example, a 'stopTime' Parameter (2000000.0) is too large to be converted precisely to an instance of time within the specified 'timeResolution' (1.0E-10). The maximum value that can be precisely converted is 1699999.9999000002. If you use a larger 'timeResolution' of 1.2352941177197234E-10, or greater, then the Simulation should run. |
Not always. To modify the parameter, follow the procedure listed example column of this row. |
Double |
1.0e-12. Open the Parameters->Preferences->Pull-down Time Resolution to Line->Click OK->Change Value |