- Reset_After_Firing - To reset a node's input-arc amounts every N firings,
set the node's Reset_After_Firing attribute equal to N.
This is intended for use when a node's input-arc thresholds are greater than
the consume amounts.
Normally a threshold amount of data must be received to fire a node the first time.
After the first time, only a (threshold - consume) amount of data must be
received to fire the node every time, in steady-state.
However, in some systems, the steady-state cycle must be re-started
periodically, as with a periodic data-refresh. To model such processes,
set the Reset_After_Firing attribute to a positive non-zero
number of firings.
When the firing count is reached, instead of removing just the consume amount
of data from each arc, the threshold amount will be removed.
(In other words, an extra (threshold-consume) amount will be removed.)
- Multicast DFG Node -
A new DFG node type, MultiCast, was added to support multicast message
transfers. It is defined by setting the DFG node Type-Name in the Properies
menu to MultiCast (case insensitive). This node should have one input arc
coming from the source node and multiple output arcs, one for each destination
node. This node does not need to be mapped to a hardware device. It will then
use the mapping of the node preceding it. All the output arcs are transmitted
simultaneously by the hardware device that supports multicasting. All the
output arcs must have equal Produce, Threshold and Consume amounts to be valid.
If the multicast message is passed along several devices that may implement the
message distribution or replication, the device to replicate the message is
defined in the MultiCast node by an attribute such as Replicate_Device = NIU or
Replicate_Device = Fibre. The selected attributes must be recognized by the NIU and
Fibre-Switch devices. Do not use an attribute named Replicate as it is
already used for a different purpose.
The scheduler implements MultiCast node output transfers by first generating a
'pendmessg' instruction for each output arc and then generating a 'multimessg'
instruction. They are all mapped to the source device. The multimessg is used
a wrapper for all the previous pendmessg instructions.
The source device creates a message to be sent to a destination for each
pendmessg instruction. The messages are held at the source until it encounters
a multimessg instruction. At that time, a multicast message is generated which
wraps all previous pendmessg messages. It is sent out by the sourcing device.
It is assumed that only one device in the path is responsible for unwrapping
the multicast message and distributing the separate messages to their
destinations. The device that is responsible for the distribution may act on it
as it sees the multicast message or it may verify its role by checking the
device type attribute set in the MultiCast node by the user. If it isn't
responsible for unwrapping the messages, it just passes the multicast message
on to the next device at its output port.
The 'pendmessg' instruction generates a message of message_type DATA whereas
the 'multimessg' instruction generates a message of message_type REQ_MULTI.
This is in contrast to previous 'multicast' and 'broadcast' instruction
implementations which generate a DATA_MULTI and DATA_BROAD message,
respectively.
- Multiple Timer Device -
The generic_pe has been implemented to allow multiple DFG GEN nodes to be
mapped onto it with different timing intervals or monotones. The interval time
for each GEN node is defined by its Compute Time node Properties entry. The
number of cycles to run is defined by its Iterations entry. The input arc to
the GEN node should not be used to control the number of iterations. The
Produce, Threshold and Consume entries of the input arc should all have the
same value. The destination nodes of the output arcs of each GEN node define
which tasks get triggered by which GEN node timer. The arcs may be set with the
attribute SilentXfer = True to avoid any transfer delays in the timer triggers.
A new attribute called NoDisplay = True (case insensitive) may be used on any
arc to suppress the display of arc transfers in the timeline post-processors.
- Hard EXIT DFG Node -
The current EXIT node implementation does not guarantee that additional tasks
will not be executed after encountering the EXIT node in the simulation. It is
only a DFG name used by the user for the node s/he thinks will be executed
last, although it is required by the scheduler that it exist.
To force the simulation to stop processing any additional tasks after
encountering the EXIT node, an attribute called Exit_type = STOP (case
insensitive) has been implemented. This should be added as an EXIT node
attribute to force a hard exit. The EXIT node should be mapped onto a device
that supports this EXIT atttribute, such as the generic_pe or the
multi_priority_pe. The statistics and post-processing files get closed before
the simulation comes to a complete stop.
- Replicate Node (addendum) -
The input arc to a Replicate node must have equal Produce, Threshold and
Consume amounts. If it desired to vary these amounts, it is suggested that
an intermediate node with zero compute delay be used in front of the Replicate
node.
