Design and analysis of efficient MPSoC simulation techniques

CPU Model Application Code class AS { public: SC_HAS_PROCESS(AS); AS(sc_module_name nm) { SC_THREAD(); } private: . Abstract realization of a PE Figure 7.3: Example configuration, 2D-mesh with 6× 6 routers use case of the simulation system different types of PE simulations can be used. For instance, for a detailed analysis of the system timing behavior, the PEs are modeled as a complete subsystem including a CA processor model, a bus and memories. For the CA processor models, LISA [58, 59] generated processors are used which are the only components that are not available in source code. In case that the NoC and the routers are the main focus of the analysis, abstract processor simulators can be used as PEs. In favor of high simulation speed the abstract processor simulator executes the application directly on the host neglecting all HW details. In order to roughly model the timing of the application it is possible to annotate the timing by means of SystemC wait() statements to the application code. This kind of abstract processor simulators is well suited for stimulating the NoC with realistic traffic scenarios while at the same time its impact on the simulation speed is low. Hence, this configuration is well suited for evaluating the characteristic and scalability of the NoC subsystem using a high number of nodes. It is even possible to combine different types of PE simulators inside one simulation system, i.e. a few nodes are simulated in detail whereas the remainder of the nodes use the abstract processor simulator to generate the NoC stimulus. In Figure 7.4 the realization of the network processor is shown. It is composed out of two main components: the bridge module and the router module. The bridge module is responsible of communicating with the local tile by moving data from the local tile to the router and back. Furthermore, all control commands (e.g. send request, data receive) sent by the local tile to the network processor are interpreted inside the bridge 108 Chapter 7. Timing Approximate NoC Simulation Figure 7.4: Realization of the network processor module and the appropriate control signals are then forwarded to the router. The router module is responsible of forwarding the incoming packets to their destination according to the selected routing algorithm. Data packets for the local tile are forwarded to the bridge module which copies the data to the appropriate memory location of the tile. Due to the modular design, different components of the network processor can easily be extended or replaced, e.g. the routing algorithm, without affecting other components. During the analytical simulation of the NoC the router module is deactivated, instead the source bridgemodule will transfer the data directly to the destinationmodule using the bypass engine. The destination bridge module will annotate the delay of the transaction according the data estimated by the analytical NoCmodel. Only bypassing the the NoC results in very a limited simulation speedup since the data transfer from and to the local tile is becoming the bottle neck. In order to circumvent this problem a direct memory interface (DMI) has been integrated into the bridge module. This enables the bridge to directly copy the data to the desired memory location bypassing the complete communication hierarchy of the PE. 7.4. 2 Software Stack In order to exploit the parallelism offered by such a scalable HW platform an appropriate programming model and the corresponding SW stack are required. The well established MPI based programming model [104, 115] has been selected to keep the porting efforts of the application developers low. This programming model assumes a separate address space for each process. The inter-process communication is explicit and needs to be added by the application developer. Using the MPI programming model has the advantage that the application developer can run the application directly on the host during the first development steps. 7.4. Simulation Environment 109 Figure 7.5: SW Stack running on top of the HW 1 int MPI_Init(int *argc, char ***argv); 2 int MPI_Finalize(); 3 int MPI_Abort(MPI_Comm comm, int errorcode); 4 int MPI_Get_processor_name(char *name, int *resultlen); 5 int MPI_Comm_rank(MPI_Comm comm, int *rank); 6 int MPI_Comm_size(MPI_Comm comm, int *size); 7 8 // Blocking communication 9 int MPI_Ssend(void *buf, int count, MPI_Datatype datatype, 10 int dest, int tag, MPI_Comm comm); 11 int MPI_Recv(void *buf, int count, MPI_Datatype, int source, 12 int tag, MPI_Comm comm, MPI_Status *status); 13 14 // Non-blocking communication 15 int MPI_Isend(void *buf, int count, MPI_Datatype datatype, 16 int dest, int tag, MPI_Comm comm, 17 MPI_Request *request); 18 int MPI_Irecv(void *buf, int count, MPI_Datatype datatype, 19 int source,int tag, MPI_Comm comm, 20 MPI_Request *request); Listing 7.1: Functions supported by the μ-MPI layer Later, the application can be easily ported to the simulated platform. The translation of the MPI primitives into control and data primitives for the network processor is performed by the μ-MPI layer as shown in Figure 7.5. Currently, the μ-MPI layer supports blocking and non-blockingMPI data transfers. The non-blocking communication is restricted to at maximum four parallel transactions from four different senders per receiver node. Each sender node supports only one transaction at a time. These limitations have been introduced for the sake of simplicity of the μ-MPI layer and the reduced memory consumption of the system. Listing 7.1 shows the interfaces of all functions supported by the μ-MPI layer. 110 Chapter 7. Timing Approximate NoC Simulation Figure 7.6: Screenshot of an 8× 8 FDM heat simulation