Maintaining synchronization between all NoC components during simulation is a difficult task. A large number of synchronization FSMs are needed to be implemented explicitly for this purpose. Therefore, our FSM based model presented in the previous chapter may not be suitable for developing formal simulator. In contrast, in Communicating Finite State Machines (CFSMs), synchronization between functional units are maintained automatically with help of message passing. No dedicated CFSMs for synchronization are required. There- fore, we use CFSMs for developing formal simulator of NoCs. A formal modeling of NoC using CFSM is presented first. We have automated the CFSM model generation for NoC with Mesh and Torus topologies. We have then presented the CFSM based formal simulator.
The same approach can be applied to NoC, where router components are the processes and communication between them takes place using the packets. Therefore, in this work, we use CFSM for modeling the NoC components. To the best of our knowledge, detailed formal modeling of NoCs is not explored enough in the literature (discussed in the Chapter 2).
There are some abstract level models of NoCs in the literature [80], [31], [50] that do not capture the detailed behaviour of the NoC architecture. Specifically, the contributions of this work on modeling NoCs are as follows:
• This work demonstrates an approach for formal modeling of Mesh and Torus topologies using CFSMs. A similar approach can be followed for designing other NoC topologies as well.
• We formulate the naming convention of each component of the CFSM model so that each component is uniquely identifiable.
• It is error-prone to create formal models of NoC manually, which requires a large num- ber of CFSMs for its representation. Therefore, a programming interface is developed to automatically generate the formal CFSM models of Mesh and Torus based NoCs of any size.
• The condition required for deadlock in CFSM based model of NoCs is formally cap- tured in Theorem 4.5.2. Moreover, we formally show the bounded communication of our CFSM models using Lemma4.6.1 and Lemma 4.6.2.
• The proposed CFSM based model of NoCs is generic in terms of routing algorithms, i.e., any routing algorithm can be symbolically simulated on it.
4.2.2 Development of CFSM based Simulation Framework
We further develop a formal simulator based on our CFSM model. As an application of our CFSM based simulator, we focus on detecting deadlock of a routing algorithm for a given application in the next phase of the work. Several techniques on deadlock avoidance
like restriction on packets from taking certain turns [9], increasing the buffer size and the number of virtual channels [103] etc. have been proposed. Most of these schemes require additional overhead in terms of system resources, area, and power consumption. Further, such avoidance techniques are designed to prevent deadlocks for a given routing algorithm.
A routing algorithm may have deadlock for an NoC topology. However, the same routing algorithm may not reach in deadlock state for a given set of applications in the same NoC topology. If deadlock avoidance techniques can be designed to work only for a given set of applications the NoC currently executes, system resource overhead can be minimized. To elaborate, if application specific deadlock detector is designed, it can be used to enable or disable deadlock avoidance scheme based on the requirement. In this work, we aim at the development of an application specific deadlock detector for NoC using our CFSM based models.
Detection of deadlock in an NoC is a challenging task, due to the prohibitive state space required to model the NoC and the routing algorithms therein. Booksim2.0 [24] is a cycle accurate NoC simulator that simulates the NoC components including routers in parallel. This simulator uses a threshold number of cycles to determine deadlock. If the number of cycles exceeds the threshold and yet packets remain to be delivered, simulation is aborted giving warning message for possible deadlock. Gem5 [25] is another widely used full system simulator that uses a similar philosophy for deadlock detection. It internally uses Garnet [26], an interconnection network model, for NoC simulation. It may be noted that since cyclic dependency for the resource is not checked in Booksim or in Gem5, it does not give a guarantee that the scenario, in fact, is a deadlock. The threshold value may overshoot due to other circumstances like failure, livelock or starvation.
The second contribution of this work is an application specific simulation framework using our CFSM based NoC models. Our framework accurately detects the occurrence of a deadlock situation for a given routing algorithm and an input traffic sequence. Specifically, the contributions of the second part of the work are as follows:
• A CFSM based simulation framework is developed to detect confirmed deadlock sce-
Formal Simulator / Deadlock Detector CFSM Based NoC Model
Traffic Pattern Routing Algorithm
Deadlock present / not present
Figure 4.1: Deadlock Detection using CFSM based NoC Model
nario in an NoC on a given traffic pattern for a given routing algorithm. The overview of the simulator is given in Fig.4.1.
• We have tested our framework for three routing algorithms namely, XY routing (static) and Dynamic-XY routing [8] (adaptive) and a modified version of West-First routing (adaptive) [9] on Mesh and Torus NoCs. The experimental results are presented for various network sizes and for various traffic patterns. Our CFSM based framework identifies false-positive deadlock warnings of the Booksim simulator.
The rest of the chapter is organized as follows. Section 4.3 covers the background the- ory of CFSMs. Section4.4 demonstrates the modeling of NoC using CFSM. Our proposed approach to NoC deadlock detection and representation of cyclic dependencies using CFSM are described in Section4.5. Automated NoC model generation and computational feasibil- ity of our models are described in Section 4.6. Experimental results and their analysis are presented in Section4.7. Finally, we conclude the chapter in Section 5.7.