Router Interface Modeling

A router interface model defines a platform-dependent context for the Inter-Process Commu- nication (IPC). The IPC context we consider is a virtualization of bus and global memory components for one or more processes mapped onto a single processor.

Recall that the application model limits inter-process communication to FIFO-based IPC only. The read andwrite symbolic instructions directly abstract the FIFO read/write IPC. However, such symbolicread/writeinstructions are executed inside the processor model. The question is: Why do we need to model yet another application-process related context (router interfaces) when we already have the processors for that purpose? The answer is rather intuitive: the refinement of the IPC symbolic instructions also depends on other non- processor components - mainly those in the interconnecting network. When data needs to be moved between the network and a processor (or multiple processors), processors are only partially involved. Data needs to be loaded and stored into the global FIFO memory. Also, on the way to/from the global memory, arbitration for data-transfer lines takes place. These is- sues were described when interface protocols were discussed (See Section 3.3.5). Hence, the status of these network components and their dynamics act in a way which is complementary to the processor components in the case of IPC. Network dynamics and global memory capac- ity influence the schedules of the SP executions:readSI’s stall processor components until sufficient data is available in the global memory andwriteSI’s will stall processor compo- nents until sufficient space is available in the global memory. These stallings are the result of the finite network throughput and the finite global memory capacity. Thus, these constraints affect the way processor components push and pull data via the network and memory. By considering both processor and network components, the IPC modeling picture is complete. In this subsection we provide an insight into the behavioral elements implementing the above IPC refinements in router components. We mention them following the order in which the IPC refinement is carried out: connection, synchronization and transfer. In addition, we show how network-generated interrupts are modeled.

Opening and Closing FIFO Connections

The opening and closing of read and write IPC connections is implemented inside the FIFO- Input Controller (FICTRL) and the FIFO-Output Controller (FOCTRL) threads. The two are essentially the same: the only differences consist of (i) the unit to which they are connected (the RU or the WU processor thread) and (ii) their purposes (to establish either a read or a write connection). Thus, we exploit their similarities to provide a general explanation of the dynamic features of these threads.

Initially, a thread waits for a request to come from the processor unit. In the case of the FICTRL thread, the request comes from the RU processor thread; in the case of the FOC- TRL thread, the request comes from the WU processor thread (see Section 3.4.2). As soon as the request arrives, the thread configures the appropriate connection based on the infor- mation available within the interface component context36_{. The connection configuration}

is performed according to the received ‘logical’ (application) FIFO identification number. Eventually, the requester is given the acknowledgement that the connection is ready-to-use. The opening of the FIFO connection can be modeled by means of a user-configurable delay parameter. A FIFO connection is considered to close instantaneously. The closing is done after read/write IPC have been completed (see Figure 3.2). The implementation details of the FICTRL and FOCTRL threads are given in Appendix A, Figures A.16 and A.17.

Synchronizing FIFO Connections

The synchronization over FIFO connections is implemented inside the FIFO-Input Unit (FIU) and the FIFO-Output Unit (FOU) threads. The two are essentially the same: the only differ- ences are (i) the unit they are connected to (either to the reader or to the writer side of the FIFO component) and (ii) their purpose (to load the data from or to store the data in the FIFO component).

The FIU thread is connected to (1) the read FIFO component side and to (2) the pull event- synchronization channel. The FOU thread is connected to (1) to the write FIFO component side and to (2) the push event-synchronization channel. In addition to these, the threads can be connected to the bus arbiter component. That is, each time the FIFO is accessed by either of these threads, bus arbitration takes place.

The FIFO connection synchronization can be modeled by means of a user-configurable delay parameter. The implementation details of the FIU and FOU threads are given in Appendix A, Figures A.18, A.19 and A.20.

Network Interrupt Modeling

We considered interrupt modeling in Section 3.4.2. The Read and Write interrupts are gen- erated by some bookkeeping activities in the router components: the data and room status information are acquired using the FIU and FOU threads. These status acquisitions (1) must be done in a non-blocking way (i.e., status check must not interfere with the main IPC tasks of the router component threads) and (2) should appear only when the relevant room and data changes in the FIFO appear (i.e., ideally they should be performed only once, when the status has already meaningfully changed - sufficient room or data spotted.).

These two ”rules” appear to be imprecise because we may not know explicitly when to gen- erate an interrupt. Furthermore, the processor DOS channel is fundamentally dependent on the presence of the status information (see Section 3.4.2). Thorough examination of the in- teraction between processor components and the router components provides the following guidance. Both writing-to and reading-from the FIFOs are operations generated at the pro- cessor side; recall that, ‘push’ and ‘pull’ channels are blocked until processor WU and RU threads generate requests. It is worth noting that when storing data to a FIFO component, the processor component first writes to the router component and then it may possibly apply a block. Conversely, when loading data from a FIFO component, the processor component

may first apply a block if there is no data and then continue with the loading sequence. This is visualized in Figure 3.2, in the push and pull protocol sequence parts. Consequently, (1) room status can be obtained from the FOU thread of the write router component by acquiring room status of a FIFO at the beginning of the push sequence and (2) data status requires an independent polling mechanism which can be activated whenever there is a change in the FIFO status from ‘empty’ to ‘data-has-just-arrived’.

Router-Interface Synchronous-Event Channels

The synchronous-event channels of the router-interface component model interconnection data paths between internal router modules. This models the opening/closing/synchronising connections and network-interrupts according to definitions for synchronous channels estab- lished in Section 3.4.1 .They are thus named synchronous-event channels. There are two internal synchronous event channels available: (1) A Pull Channel (PULL) and (2) a Push Channel (PUSH). They model the pull and push protocols, respectively. The PUSH and PULL channels are important parts of the router-interface components.

The channels have the same structures but complementary roles. The PULL channel provides the means for the processor RU threads to pull data from the FIFO’s. The FIU thread connects to the other side of the PULL channel and provides the interface to the designated FIFO component. Similarly, the PUSH channel provides the means for the processor WU threads to push data to the FIFO’s. The FOU thread connects to the other side of the PUSH channel and provides the interface to the designated FIFO component.