Task Modules

The tasks are modules that represent the execution of instruction on the CPU. They are managed by the Operating System (OS). The task modules of the sensor network model are based on the concept introduced by the SoC/NoC model. In addition to the periodic task (perTask module), modeling sensor network applications require additional classes of tasks. These tasks differ in their execution patterns, but they share some common characteristics. These characteristics are defined in the absTask module class.

As can be seen in figure 5.2, the task module type is further divided by defining the abstract class ioTask inheriting from absTask for the IO tasks. In this section, the abstract task modules, absTask and ioTask, and the implementation module sporTask are documented. TheperTask module is identical to the one of the SoC/NoC framework.

The other implementation modules are examples of ioTask sub-modules of ioTask and are presented in section 5.2.1.

Abstract General Task Module Class

TheabsTask module class describes the fundamental characteristics of all the tasks and provides some functions to generate messages to the operating system model.

• Parameters.

The tasks have many parameters. Each task is uniquely defined within the node by its id. The number of the scheduler to which the task is mapped, schid, is also defined. Additionally, the node has real-time parameters (period, priority, deadline, etc.). They are defined in the abstract class because these parameter may be used by the scheduling algorithm (for example EDF schedules tasks depending on their deadline, RM depending on their period) and are therefore required to be able to define the functions for generating the messages for requesting the RTOS.

5.1 Organisation of the Model Implementation 35

ioTask

absTask

abstract modules

sporSendTask ioEvtTask

rcvTask

sendTask sporTask perTask

implementation Modules

Figure 5.2: Class Diagram for task modules

to enable to define the communication function at this level. A tasks also has a schid parameter that indicates which scheduler the task is mapped to. Finally, Each node is given the number of the node it is attached to: nodenum; this is mainly used for debugging purposes.

• Task Interface.

The fundamental interface of the task models is composed of a clock port and a pair of master-slave port for connection to the operating system model. The out_indicationmaster port is used to request services from the operating system (requests for execution and requests for resources). The in_command slave port receives the commands from the operating system. Additionally, all tasks are equipped with theout_activate master port that is used for activating sporadic tasks. Also note that the clock port is not a traditional boolean port, but rather a integer port. This is needed for supporting Dynamic Voltage Scaling techniques.

This is further explained in section 5.1.8. All tasks also have a output signal, sig_state, indicating their state. It makes it possible to trace the state on the simulation waveforms.

• SystemC Methods.

There are two main SystemC methods in the absTask module class: The first is a clock-sensitive method that has the responsibility of counting time and of notifying the operating system when execution finishes, resources are required, etc. However, the behavior is not represented in the absTask class because it is very dependent on the type of tasks. The other is the slave method attached to the in_command port. This method handles the commands of the operating system,

5.1 Organisation of the Model Implementation 36

such as the RUN or thePREEMPT commands. Together, these two methods controls the transitions of the task based on the state machine presented in the previous chapter (figure 4.4). However, the functionality of the methods is not implemented in the absTask class. Only, the transition to the s_off state representing the fact that the node’s battery is empty is controlled in this class. The rest of the walk-through of the state-machine is deferred to the member functionsstate_machine and get_comm_from_rtos called respectively on clock events and on reception of RTOS commands. These functions are abstract functions. As all the task inherit from theabsTask module class, they all have to provide an implementation of these two functions for describing their behavior.

• Communication functions.

The absTask module also defines some standard functions. forwardMessage gen-erates a copy of the message passed as argument, sendIndication generates a request to the scheduler. The argument of the function defines the type of request.

The generated request further contains the task parameters (task number, priority, etc.). sendResourceInfogenerates a request to the allocator. The type of request (resource request or resource release) and the number of the concerned resource are passed as arguments of this function. activateTask generates an activation message carrying the data passed as an argument. As the type of data carried by the activation message vary with the application, this function is defined as a template so that the argument of the function can be of any data type.

Abstract Input/Output Task Module Class

The difference between ioTask and other tasks is the fact that IO tasks not only com-municate with the RTOS, but also with hardware components (despite of the name, input/output tasks can be used not only for IO device managing but also for power management of processor units).

• Parameters.

In addition to the absTask parameters, each ioTask has a parameter, hwcid, to specify the hardware component it is handling. This parameter is inserted in all requests to the hardware components modules and is also used to filter responses and event from them.

• Interface.

TheioTask also have an additional pair of master-slave ports to communicate with devices. The hw_request master port is used to request the hardware component and the hw_replyslave port to get responses or events from it.

• SystemC Methods.

The slave port’s SystemC method is attached theget_comm_from_hwabstract func-tion which is responsible of handling the messages received from the IO devices.

Sporadic Task Model

The sporadic Tasks are tasks that are not activated periodically but that are activated by an external module through the activation link. Similarly toioTask, thesporTaskmodule inherits from theabsTask class. However,sporTask is not an abstract class: it provides

5.1 Organisation of the Model Implementation 37

an implementation of the state_machine and the get_comm_from_rtos functions. It represents a computation activity with no Input/Output activity.

• Parameters.

The sporadic tasks must specify which task they expect an activation from. The activatingTask parameters fulfils this purpose. When receiving an activation message, the sporadic task module compares number of the task sending the ac-tivation message with this parameter to determine whether it should activate or not.

• Interface.

An additional slave port,in_activate, is added to connect to the activation port.

• SystemC Method.

In addition to providing an implementation of the abstract functions of theabsTask module, the sporTask module has an additional SystemC slave method for the in_activateport. The functionget_activationis attached to this slave method and handles the activation messages. The three SystemC methods implemented in thesporTask module maintain the state of the task according to the state machine presented in the previous section (figure 4.4).

• Functionality of Sporadic Tasks.

The functionality of sporadic tasks are described by a Function_c object given to the task through its constructor. Function_c is a class is composed of the start_enableandexecutemethods. Both of these methods operate on the input data, i.e. the data carried by the activating message. start_enableis called when an activation message is received. It returns a boolean value specifying whether the task should become ready or ignore the activation message. executeis called when the task finishes execution and generates output data. This data is inserted in the activation message generated by the sporadic task when it completes. Function_c is an abstract class declaring these two methods.

To define the functionality of a sporadic task, the user of the framework must define a sub-class of Function_c. The functionality of the sporadic tasks was defined as a class rather than functions in order to allow the user to store information about the previous activation received. Thereby, the methods of the functionality class may not only depend on data carried by the current activation, but also on the previous history of the sporadic task.

It is to be noted, that a sporadic node need not be attached a functionality. If a null pointer is passed instead of a Function_c object, the sporadic task gets activated independently of value carried by the activation message, and the value will be passed on in the activation messages generated at the end of the execution of the sporadic task.

A problem of the representation of the sporadic tasks is that a sporadic task can only follow the execution of one instance of the task. For example, if a sporadic task receives an activation before the execution corresponding to the former activation is completed, the second activation is ignored. A solution to this problem would be to have a module dynamically creating sporadic tasks at simulation time. However, this is not supported by the current version of SystemC (version 2.0.1). It is expected that version 3 will support this feature.

5.1 Organisation of the Model Implementation 38