Hardware Integration

A typical hardware integration of OSIP-based systems is depicted in Figure 3.3. The system consists of several PEs, a shared memory, peripherals and OSIP, which are connected with each other through some interconnect, e.g., a bus. OSIP further com- prises three components, a register interface (REG_IF), an interrupt interface (IRQ_IF) and the OSIP core. While the OSIP core is the actual ASIP that performs task schedul- ing and mapping, the two generic interfaces of OSIP enable easy integration of OSIP into the system as a hardware IP. The main features of the two interfaces are described in the following.

• Register Interface: The register interface makes OSIP able to be addressed as a standard memory-mapped I/O. In this interface, the essential information required for the system-wide task scheduling and mapping is exchanged and maintained.

As illustrated in the figure, the registers can be divided into two groups. The first group contains several OSIP-core-related registers, which interact with the OSIP core. The most important registers in this group are a command (Cmd) register and several argument (Arg) registers. Through the command register, the PEs send instructions to the OSIP core, informing what the core should perform with the information contained in the argument registers. The commands can be used for configuring the system, handling tasks or accessing/setting specific system information.

Some exemplary commands are given in Listing 3.4. In the first example, the command is called SYNC_TASK, which is used to synchronize pending tasks that have dependency of other tasks. In this command, the information in Arg0

Listing 3.4: Exemplary OSIP commands 1 Command example 1 2 Cmd : SYNC_TASK 3 Arg0: pendingTaskList 4 Arg1: syncTaskRef 5 . . . : . . . 6 7 Command example 2 8 Cmd : CREATE_SCHEDULE_NODE 9 Arg0: parentNode 10 Arg1: schedulePolicy 11 . . . : . . . 12 13 Command example 3 14 Cmd : GET_NUM_OF_PENDING_TASK_LISTS

is interpreted as the list of the pending tasks that are considered for possible synchronizations. Arg1 is the task, to which the tasks in Arg0 are synchronized. More arguments are needed for this command, but they are omitted in this example. In the second example, the command CREATE_SCHEDULE_NODE is a system configuration command. It creates a scheduling node with a spe- cific scheduling policy (Arg1) in a scheduling hierarchy under a given parent scheduling node (Arg0). The third command does not have any arguments. It simply gets the number of total pending task lists in the system.

OSIP also returns information to the PEs through the argument registers after it finishes command execution. To ensure that the PEs fetch the return information at the proper time, a status register is introduced in the interface, indicating the OSIP status whether OSIP is still handling the command (busy state) or the command is already done (idle state).

In order to prevent accidental mixing up of the command and arguments sent by different PEs, e.g., the Cmd register containing the SYNC_TASK command sent by PE_A while the Arg registers containing the arguments sent by PE_B for the command CREATE_SCHEDULE_NODE, a spinlock register (OSIP-lock) is used in the interface to guarantee that only one PE can access these registers, consequently the OSIP core at a time. Only after a successful acquisition of the OSIP-lock, a PE is allowed to send a command and the corresponding arguments to OSIP. The other PEs have to poll OSIP-lock until it is freed by the owning PE, and the owning PE frees OSIP-lock only after the command is finished by OSIP. A pseudo code of implementing this on the PEs is given in Listing 3.5.

The second group of registers are a set of spinlock registers, which are used to protect shared resources, such as shared variables in the memory or peripherals. These registers can only be accessed by the PEs and have no interaction with the OSIP-core. Therefore, they are OSIP-core-unrelated. So, they can in principle also

Listing 3.5: An exemplary code to get unique access to the OSIP core

1 /*Poll the OSIP-lock until a successful acquisition*/

2 while(AcquireOSIPLock() != SUCCESSFUL) {}

3 /*Send command and arguments to OSIP, triggering OSIP*/

4 SendToOSIP(Command, Arguments);

5 /*Wait until OSIP finishes the command*/

6 while(OSIPStatus() != IDLE) {}

7 /*Read results from OSIP*/

8 GetReturnValuesFromOSIP();

9 /*Free the OSIP-lock*/

10 ReleaseOSIPLock();

be separated from the OSIP register interface as an individual hardware block. In Chapter 5, more details and investigation on these spinlock registers will be given.

• Interrupt Interface: Through this interface, interrupts are generated from OSIP to PEs using interrupt lines. Each PE is connected to one dedicated interrupt line, and the current OSIP architecture supports up to 32 PEs. The interrupts are typically for triggering task execution on the PEs or preempting task execution. They are only generated when OSIP executes a command. Whether to interrupt and which PE to interrupt depends on the system status, e.g., whether there are tasks ready for execution or whether there are PEs currently available for executing the tasks, etc.

In general, the register interface is a slave interface and the interrupt interface is a master interface. The behavior in both interfaces is simple and very generic, which enables easy integration of OSIP. As the operations in the interrupt interface are only activated when a command is being executed, i.e., after the OSIP core reacts to the command from the slave register interface, the whole OSIP behaves more like a slave component in the system from this perspective.

In both interfaces, little flexibility is required due to simple and regular opera- tions such as standard register accesses and address decoding. In fact, the simplicity of the interface operations is also important for ensuring fast information exchange between the PEs and OSIP, e.g., for accessing the spinlock registers. Therefore, an ASIC implementation is naturally used for the interfaces. For different systems, the two interfaces might need to be slightly adapted, e.g., to the number of PEs or the number of spinlocks required by the target applications. However, the adaption is simple and straightforward, requiring only very low design overhead.