Post-mortem scheduler models

The ETG post-mortem scheduler is based on a discrete event system specification (DEVS) formalism [180, 181]. This is a modular, hierarchical and timed-event system which makes possible, among other things, the modeling and the analysis of discrete-event systems. The two basic elements that describe a DEVS model are the following:

• AtomicModel: the basic building blocks of a DEVS model. The behavior of an atomic

model is described by its state transition functions (internal, external, and confluent), its output function, and its time advance function.

• PortValue: makes the communication possible between a pair of atomic models.

Moreover it defines the template argument for the types of objects that can be accepted as input and produced as output.

The state of an atomic model is realized by the attributes contained in the object that im- plements the model. The evolution of the state is modeled through the combination of the following functions and events:

• Internal transition functionδext: describes the model autonomous behavior (i.e. how

its state evolves in the absence of input). These types of events are called internal events because they are self-induced (i.e. internal to the model).

• Time advance functionδa: schedules these autonomous changes of state.

• Output functionδout: describes the output of the model when an internal event occurs.

• External transition functionδext: describes how the model changes state in response

to the input.

• Confluent transition functionδcon f: handles the simultaneous occurrence of both an

internal and an external event.

In this section how the dataflow program and the target architecture are modeled using the DEVS formalism is described. See Appendix A.2 for a complete overview about DEVS.

8.1. Performance estimation IN_DATA REQUEST_SPACE READY_TO_CONSUME IN_DATA_DONE OUT_DATA REQUEST_TOKENS Buffer

Actor Output Port OUT_DATA ASK_SPACE OUT_DATA_RECEIVED HAS_SPACE IN_DATA ASK_TOKENS Actor Input Port

(a) DEVS model of a buffer, actor input port and actor output port.

Partition B

Producer b1 Filter b2 Consumer

Partition A

Scheduler

STATUS ENABLE STATUS ENABLE STATUS ENABLE ENABLE ENABLE

Scheduler

(b) DEVS model of the dataflow application, discussed in Section 2.5.4, mapped on two separate operator partitions. Figure 8.1: Execution trace graph post-mortem scheduler: simulation models.

Actor model

Each actor a ∈ A is modeled as anAtomicActorelement which describes a DEVS atomic model. Each actor atomic model contains the subset of the actor firings Sa⊆ S. Each actor

output port pout_i ∈ Pouta is modeled, as illustrated in Figure 8.1a, with the following four PortValueelements:

• OUT_DATA: used to send the produced tokens to the output buffer.

• ASK_SPACE: used to send the number of tokens that should be produced.

• HAS_SPACE: used for receiving an acknowledgment signal when the requested token

space is available.

• OUT_DATA_RECEIVED: used for receiving an acknowledgment signal when all the

produced tokens have been successfully received.

Similarly, each actor input port p_ii n∈ Pai n is modeled with the following twoPortValue

elements:

• IN_DATA: used to receive the input tokens from the input buffer.

It must be noted that an input event is associated with each inputPortValue. Similarly, an output event is associated with each outputPortValue. Furthermore, as illustrated in Figure 8.1b, the additionalENABLEinputPortValueelement and theSTATUSoutput

PortValueelement are defined for each actor. Both ports are used by the partition scheduler (i.e. see the following part of this section) to enable and disable the actor and to retrieve its status.

Buffer model

Each buffer b ∈ B is modeled as anAtomicBufferwhich describes a DEVS atomic model. Each buffer atomic model is modeled as an asynchronous receiver/transmitter (Rx/Tx). The following fourPortValueelements, as illustrated in Figure 8.1a, are used to model the Rx interface with the source actor:

• IN_DATA: used to receive the tokens produced by the actor.

• IN_REQUEST_SPACE: used to receive the number of tokens that the actor wants to

produce.

• READY_TO_CONSUME: used to send the acknowledgment signal when the requested

token space is available.

• IN_DATA_DONE: used to send the acknowledgment signal when all the tokens pro-

duced by the actor have been received.

Similarly, the following twoPortValueelements are used to model the Tx interface with the target actor:

• OUT_DATA: used to send the tokens requested by the actor.

• REQUEST_TOKENS: used to receive the number of tokens required by the actor.

It must be noted that an input event is associated with each inputPortValue. Similarly, an output event is associated with each outputPortValue. Furthermore, as illustrated in Figure 8.1b, the additionalENABLE_RXandENABLE_TXinputPortValueelements are defined for each buffer. These are used by the partition scheduler (i.e. see below) to asynchronously enable and disable the Rx and Tx interfaces, respectively, of the buffer.

Mapping model

Each partition is modeled as anAtomicPartitionwhich describes a DEVS atomic model. As illustrated in Figure 8.1b, the scheduler of each actor and buffer partition is modeled as a controller that enables or disables the corresponding atomic objects. Each actor is enabled by

8.1. Performance estimation

sending a signal to theENABLEport according to its status provided thought theSTATUSport. Similarly, each buffer is enabled by sending a signal to theENABLE_RXandENABLE_TX

ports. These ports can be used asynchronously in order to model buffers that are on the boundary of two actor partitions or buffers that are used in a multi-clock domain architecture. As an example, Figure 8.1b illustrates the post-scheduler model for the dataflow program discussed in Section 2.5.4. In this case theProducerandFilteractors are partitioned in the same partition PartitionA, and theConsumeractor is partitioned in partition PartitionB. Each of these partitions have an actors scheduler and a buffers scheduler. It must be noted that the buffer b1is modeled as a synchronous buffer (i.e. input and output interfaces are

activated at the same time), and contrary to the buffer b2, which is modeled as a asynchronous

buffer (i.e. the activation of the input and the output interfaces is decoupled).