Integration of ISS Simulation and NoC Simulation

Transcription

1 Master Thesis ICT/ECS Integration of ISS Simulation and NoC Simulation Master of Science Thesis in System-on-Chip Design by Liang Zhou Stockholm, December/2006 Supervisor: Mladen Nikitovic & Mikael Millberg Examiner: Prof. Axel Jantsch

2 Abstract Simulation methodologies provide efficient ways in the function and performance analysis of a complete computer system. The major benefit is that the hardware/software interactions can be studied in a deterministic manner without the need of the hardware existence. This thesis seeks a way to integrate Instruction Set Simulator (ISS) simulation using SimICS and Network-on-Chip (NoC) Simulation based on SystemC for a full-system simulation of a Network-on-Chip architecture. To deploy the investigation, a SimICS module is built to capture memory access requests and gather memory operation information in the simulation of shared-memory multi-processor (SMP) system. A SystemC module is created to accept and respond to the memory transaction request. The major part of this work is to find a way to enable the cosimulation, which is realized by using blocking sockets. The data transferred during the simulation has been analyzed and the results show that SimICS and SystemC can cosimulate to form a full system simulation with SimICS implementing a shared-memory multi-processor simulation and SystemC mimicking the packet passing behavior of a network. i

3 Acknowledgements I would like to thank my respectable examiner Professor Axel Jantsch for offering me an opportunity to do this challenging thesis work. I am deeply grateful to my supervisors Mladen Nikitovic and Mikael Millberg, whose patient help, valuable technical suggestions and stimulating encouragement helped me in all the time of the work on the thesis. My friends in Sweden, especially from the SoC 2004, supported me a lot in various ways. I want to thank them for all their help and give my best wishes to them. Especially, I would like to give my special thanks to my parents whose love supports me to never surrender and complete this work. ii

4 Table of Contents Abstract...i Acknowledgements...ii Table of Contents... iii List of Figures...v Abbreviations...vi 1 Introduction Background -- Network-on-Chip Motivation Related Work Work Process Thesis Layout Full System Simulation with SimICS Generic System Modeling Introduction to SimICS Inside SimICS Module Use of SimICS Memory Transactions in SimICS Multiprocessor Simulation in SimICS Inter-process Communication (IPC) IPC Overview Single-host (non-networked) IPC Message Passing Shared Memory Sockets The Client Server Model Use of Sockets Communication Protocol NoC simulation based on SystemC Introduction of SystemC SystemC Design Methodology SystemC Language Architecture...31 iii

5 4.4 Insight into Structure of SystemC Model Summary of SystemC Implementation General Practice with Sockets SimICS Module Timing Model Configuration Add Sockets into SimICS Module Implementation of SystemC Module Simulation Result Analysis cpu-switch-time cpu-switch-time Conclusion...53 References...54 Appendix A: Problems in Work Process...57 Appendix B: Relevant Code...58 iv

6 List of Figures Figure 1.1 A typical 2-D mesh topology...2 Figure 2.1 Transaction Path through SimICS Memory System...13 Figure 3.1 Message passing communication...18 Figure 3.2 Shared memory communication implemented on a bus[3]...20 Figure 4.1 SystemC design methodology for hardware...31 Figure 4.2 SystemC 2.0 Language Architecture...32 Figure 5.1 Socket functions for elementary TCP client/server...36 Figure 5.2 Simple data communication via sockets...38 Figure 5.3 Memory transactions with/without delay...40 Figure 5.4 Multi-processor stall schedule...41 Figure 5.5 Communication between SimICS module and general client...42 Figure 5.6 Communication between SimICS module and SystemC module...43 Figure 5.7 Communication regarding one processor...44 v

7 Abbreviations NoC Network-on-Chip 1 SoC System-on-Chip 1 IP Intellectual Property 1 ISS Instruction Set Simulator 3 SMP Symmetric Multiprocessing 3 BFM Bus Functional Model 4 API Application Program Interface 10 MMU Memory Management Unit 12 STC Simulator Translation Cache 13 IPC Interprocess Communication 15 RPC Remote Procedure Call 15 FIFO First-In First-Out 16 BSD Berkeley Software Distribution 21 TCP Transmission Control Protocol 26 UDP User (Unreliable) Datagram Protocol 27 OSCI Open SystemC Initiative 29 RTL Register Transfer Level 29 HDL Hardware Description Language 30 vi

8 1 Introduction This chapter serves as an introduction to the thesis, introducing the background of the work, describing the task definitions and some related works and later giving a short description of the thesis s organization. 1.1 Background -- Network-on-Chip Nowadays, System-on-Chip (SoC) design methodologies have been widely used in many areas, especially in the multimedia, telecommunications and consumer electronics. SoC Technology uses buses as the primary communication structure. While as the improvement of silicon technology and the scaling of integrated circuits, hundreds of IP (Intellectual property) blocks may be integrated in a single chip with a working frequency of up to 10 GHz. This will prevent buses from being a good solution for designs at the view of communication efficiency, performance, power consumption and reusability. So a demand for seeking a better way to implement the communication rises up. Network-on-Chip (NoC) is an emerging approach to System-on-Chip design, providing efficient on-chip communication. In a NoC system, various kinds of resources embedded on a single chip, such as processor cores, DSP, memories and FPGAs exchange data utilizing a network-based communication architecture other than common buses used in other System-on-Chip paradigms. The NoC system can choose different topologies for the network, in which the most popular one is a two-dimensional mesh network topology. It has a mesh structure 1

9 composed of resources and switches that are connected to each other. Each switch is connected to four other adjacent switches through channels. Each resource, which performs its own computational functionalities, is connected to a switch or a router and communicates with other resources via the switches or routers. A 4x4 mesh is shown in Figure 1.1, where S is switch/router, R is resource and Arrow is the channel. Figure 1.1 A typical 2-D mesh topology The utilization of NoC architecture brings a lot of benefits. From a system design viewpoint, it provides separation between communication and computation allowing the designers to focus on each part independently before the establishment of the whole architecture. It has wide bandwidth for large amount of computation at higher speed than other SoC models using buses. It also supports modularity and IP reuse via proper interfaces. From a physical design viewpoint, the adoption of NoC can avoid complex design of long interconnection wires which requires special attention in predictability, power consumption and noise, etc. Notwithstanding the above benefits, the adoption and deployment of NoCs face important issues relating to design and test methodologies and automation tools and NoC is still mainly at the stage of research and experiment. 2

10 1.2 Motivation Simulation methodologies provide efficient ways in the function and performance analysis of a complete computer system. The major benefit is that we can study the hardware/software interactions in a deterministic manner without the need of the hardware existence. The original object of this project is to investigate whether a full-system simulation of a Network-on-Chip (NoC) architecture can be performed by integrating an Instruction Set Simulator (ISS)---SimICS and a Network-on-Chip simulator---semla. As is specified above, a NoC architecture is composed of resources and a network formed by a number of connected switches. SimICS is a full system simulator that can give a detailed simulation of an architecture of resources but the SimICS communication structure is only functionally simulated, whereas Semla is based on SystemC and good at simulating the network communication structure but not the resources. The hypothesis of this work is that a full-system simulation of a NoC architecture can be achieved by integrating these two simulators. The actual work is implemented by first simulating the resources with a shared-memory multi-processor (SMP) configuration in SimICS, then building a SimICS module and a SystemC module as well as establishing some form of communication between the two modules. There is a challenge to make it possible to dynamically halt the simulation of a processor in SimICS whenever a processor is waiting for response from the SystemC module which is used to mimic the state of waiting for a packet from the network. 3

11 1.3 Related Work As a promising simulation platform, a lot of investigation effort has been put into the cosimulation using SystemC. As in [13-16], Most approaches use interprocess communication and a bus wrapper, in which the ISS and the SystemC communicate via IPC primitives and use a bus wrapper to ensure synchronization and cycle-accurate transactions. In [13], Luc Semeria and Abhijit Ghosh present BFM (Bus Functional Model) as basic element for the mixed-level cosimulation and integrate an ISS and BFM. In [15], P.Gerin, et al. use SystemC simulation environment as cosimulation backplane and focus on SoC designs with heterogeneous multi-processor target architectures and present cosimulation interfaces to satisfy scalability and flexibility requirements. L.Benini, et al. raise in [16] a method to implement the IPC interfaces between the wrapper and the ISS based on the GNU s open-source-debugger, GDB to address the problems caused by limitations of IPCs. Although SimICS is an ISS, little literature has referred specially to Cosimulation of SimICS and other external simulators. There are only some words in Virtutech s articles telling that SimICS could communicate with external simulators. 1.4 Work Process This thesis work is implemented in several phases: Learn about related knowledge of SimICS; Investigate in paper and documents to define a communication form between the simulators; Practice the communication form with SimICS and make SimICS module able to communicate with external programs; Learn about related knowledge of SystemC; 4

12 Establish the basic communication and make halting of processor simulation possible without halting entire simulation. 1.5 Thesis Layout The remains of this thesis are structured as follows: Chapter 2 introduces generic system modeling and then the simulator SimICS especially in the part of the memory transactions and the multiprocessor communication. Chapter 3 includes the concept of interprocess communication (IPC) and the comparison of several forms of IPC in common use, and gives a detailed description of Sockets which are used in this work. Chapter 4 gives a brief introduction to SystemC. Chapter 5 focuses on the implementation of the SimICS module and the SystemC module as well as communication between the two simulators. And later the simulation is analyzed. Chapter 6 is the summary of the work and contributions. It also points out directions for future work. Supplementary work information can be found in the Appendix. 5

13 2 Full System Simulation with SimICS This chapter introduces generic system modeling and then the simulator SimICS especially in the part of the memory transactions and the multiprocessor communication. 2.1 Generic System Modeling Simulation is a widely used technique for function analysis and performance evaluation of computer systems. The major benefit is that the hardware/software interactions can be studied in a deterministic manner without the real hardware prototype. Simulation provides an efficient way to verify the function of a design, compare competing design solutions and find the performance drawbacks by comparatively low cost. There are many kinds of computer system simulation techniques, such as trace-driven simulation and execution-driven simulation. Trace-driven simulation technique involves two separate steps. First, an address generator is used to produce a stream of execution events, mostly addresses, to characterize the workload. Second, a memory/network timing simulator estimates the time taken to perform each event on the target architecture [25]. Trace-driven simulation has been widely used to evaluate cache performance on single processor systems. However, it introduces distortion when simulating multiprocessor systems because the address traces to be simulated vary depending on the simulated architecture. 6

14 Execution-driven simulation corrects the drawback of trace-driven simulation for parallel applications by interleaving the execution and tracing of the application with the simulation of the architecture. The address trace generation is controlled by the simulation, which ensures that the address trace simulated is exactly the one that would be obtained if the application was actually executed on the simulated machine [25]. Besides the absence of distortion in simulating multiprocessor systems, execution-driven simulation has another advantage over trace-driven simulation that it avoids the need to store large address trace files and thus reduces the space overhead. However, execution-driven simulation requires a more efficient trace generator and is much more complex to implement due to the necessary synchronization mechanisms between the application, trace generation and the simulation. Execution-driven simulation is implemented by most of the full system simulators. Some basic full system simulators are shown as follows: g88 [20], models a uni-processor Motorola based system and can boot the Unix operating system. gsim [21] extended g88 and supports simulation of multi-processors with shared physical memory. Talisman [22] is another simulator which similar to gsim. Both of gsim and Talisman are instruction-set simulators. SimICS [23], It is another system-level instruction set simulator. It can simulate target systems with good fidelity and high speed of booting and running OS and realistic workloads. This simulator is so powerful that it can simulate PowerPC, x86, x86-64, Alpha, MIPS and Arm architectures. Furthermore, it supports both uni-processor and multi-processor systems as well as a cluster of independent systems and even network systems. 7

15 SimOS [24], It is developed at Standford. And it is an expert to simulate microprocessor. In addition to the CPU, it can also simulate caches, multiprocessor memory buses, disk drives, Ethernet, consoles and other common devices. The operating systems to run this simulator are IRIX and Digital Unix. There are some other simulators such as Rsim and SimpleScalar. But they are not as powerful as SimOS or SimICS. From the summarization above, it is obvious that SimOS and SimICS are two promising candidates for the simulation of multi-processors with shared physical memory. SimICS and SimOS have similar design goals to provide a fast instruction-level simulation kernel and provide a functional interface to the OS to make it possible to run completely unmodified system and application binaries on the simulated hardware platform. Unlike the SimOS system, the SimICS system is capable of modeling hardware-level events, such as cache misses, at a reasonable slowdown of less than 100[17], which means that the host will execute less than 100 instructions to simulate each instruction on the simulated target. The major advantage of SimICS over SimOS is improved simulation speed using highly optimized codes for fast event handling and a simple processor pipeline. SimICS has the ability to change the simulation parameters easily and to create hardware models. Furthermore, SimICS provides effective tools for debugging and profiling while the debugging process in SimOS is harder because of its C++ features. However, SimICS is proprietary and thus the internal details of the simulator are not available to the public. This makes it difficult for users to add or modify new hardware features [18]. 8

16 There are other simulators, such as GEMS or TFSim, based in SimICS, that provide accurate timing models but they are focused to specific systems. For example, GEMS is a SimICS based simulator for Sparc-based computers [19]. In conclusion, SimICS is a suitable simulator for shared-memory multi-processor simulations. 2.2 Introduction to SimICS Virtutech SimICS is an efficient, instrumented, system level instruction set simulator [1]. As mentioned in last section, it is a full system simulation platform which could simulate almost everything in the computer system including processors, buses, disks, video memory, etc. Host and target are the two fundamental terms used in SimICS, which are worth being clarified here. Host defines the computer on which you are running SimICS. It can also refer to the architecture (x86) or the model (Sun SunFire) of computer that runs the simulator, or to the host platform (combination of an architecture and an operating system, like x86-linux) [1]. This project uses x86-linux. Target refers to the computer or architecture or the model of computer simulated by SimICS. The target system is simulated at the instruction set architecture (ISA) level, which is the lowest level of hardware that software has access to. The simulated target system has its own screen and operates like a real system except being slower; the simulation speed depends on the host machine. The target system has read-only access to the real hard disk by setting up SimICSfs file system. SimICS is sufficiently fast to run realistic workloads. It can not only run the target system but also gather a large amount of information during simulation. 9

17 2.2.1 Inside SimICS Module There are a lot of pre-compiled standard modules included in the SimICS installation package. They could be used in any SimICS model. The standard module mentioned in my work is: memory-space. I will describe this in next section. Custom modules can extend the functionality of SimICS. There are two kinds of modules in SimICS: devices that model the functional behaviour of real devices, and extensions that add functionality to SimICS [2]. There is however no hard distinction between the two kinds. A SimICS module is usually written in C or C++. Python scripts can also be used but is not preferable for performance-critical modules and devices. The SimICS API provides a number of mechanisms that can be used for a module to interact with other modules or the user in some way, in which the most important ones are classes, objects, interfaces, haps and events. Classes and Objects Most SimICS modules implement classes and instantiate objects from classes. They create objects that provide new functionality through their attributes and commands. A SimICS class describes an object type and its interface, and register attributes which acts as data members for all objects instantiated from the class. When implementing a class, the module must register the class in SimICS. The classes registered in a module should be listed in the module s Makefile, which is used to build up the target module. Classes and modules are totally separate entities, thus it is possible for a module to declare several classes or none at all [2]. Interfaces 10

18 More complex interaction between a module and SimICS (or between modules) uses interfaces. An interface requires any class that implements this interface, to provide its own set of functions and register the interface with SimICS. SimICS also allows the users to write their own interfaces. In this work the SimICS standard interface used is: timing_model. It will be discussed more in Section Use of SimICS A command-line interface is used to control SimICS by entering a single SimICS command or invoking a command scripted through Python script files. Configuration of a target describes to SimICS what the simulated machine looks like in an object-oriented way. Each processor, device etc. is represented as an object instantiated from a certain class defined by module files. The machine configuration in SimICS is either represented as a file (.conf) written in a special-purpose configuration language, or dynamically generated at run-time by Python scripts [1]. SimICS uses two functions to load and save a configuration file respectively. The user can edit and modify a saved configuration file with extra care. SimICS includes ready-to-run configurations, most of which are not written as.conf files, but as Python scripts manipulating the configuration objects. This provides a greater flexibility and a better interface to users. SimICS supports to checkpoint a simulation which allows running an application to a point and save the entire state of the simulated machine to disk. While most forms of statistics gathered during simulation are not saved. At any time SimICS can use checkpoint to restore the simulation at that particular state and all the later simulations will start from the checkpoint. 11

19 2.3 Memory Transactions in SimICS CPUs and devices can initiate memory transactions in SimICS. For a CPU, the requested virtual address is typically translated by the memory management unit (MMU) to the physical address. Then the access is performed using the physical address. Device transactions are handled in the same way in spite of skipping the translation phase. A memory-space maps a physical address to an object that can accept a memory transaction, like RAM, a flash-memory or a device. An access performed in a memory-space is automatically propagated to the right target (device or memory) [1]. SimICS allows observing and sometimes modifying the memory transactions passing through the memory system. This is done by a memory hierarchy interface provided by memory-spaces. This interface is actually composed of two different interfaces: timing-model and snoop-memory, which work at different phase of a memory transaction. The timing-model interface of a memory space is called before the memory transaction is actually executed. The timing-model doesn t see or contain any data but the addresses accessed. The snoop-memory interface of a memory space provides access to a memory transaction after it has been performed. The advantage of this interface is that the actual value of load operations is accessible. Figure 2.1 is a figure cited [1] showing the transaction path through SimICS Memory System. 12

20 Figure 2.1 Transaction Path through SimICS Memory System Timing Model A timing model in SimICS tells the simulator core the time a memory operation will spend. It can modify the timing of transaction by returning a stall time, which is the amount of cycles the processor will stall before reissuing the transaction. Timing model can t be used to see the value or modify the result of a load operation since the memory transaction is performed after the call of a timing model. 13

21 2.4 Multiprocessor Simulation in SimICS SimICS can model systems with several processors; each with their own clock frequency [1].SimICS serializes execution to improve the performance since perfect synchronization is exceedingly slow. SimICS divides time into segments and serializes the execution of processors within a segment, the length of which is referred to as quantum. SimICS schedules the processors in a round-robin fashion, which means when a particular processor P has finished its quantum, all other processors will finish their quantum before execution returns to P [1]. SimICS doesn t define the order of serialization and maintains strict sequential consistency. The quantum is set by the command cpu-switch-time specified in cycles (the cycle of the first processor in the system). It is set to 1 for a perfectly synchronization simulation, which will simulate quite slowly. Since simulator overhead will be caused by a processor switch, the quantum shouldn t be set too low to make the multi-processor simulation run efficiently. The default value is That means during each quantum, the first processor will execute 1000 steps, and the other processors each 1000 steps if they have the same frequency as the first processor, not necessarily in a certain order. 14

22 3 Inter-process Communication (IPC) This chapter includes the concept of interprocess communication (IPC) and the comparison of several forms of IPC in common use, and gives a detailed description of Sockets which are used in this work. 3.1 IPC Overview System on chip design and Network on chip design become more and more popular nowadays. Before manufacturing the real system, high quality simulations for these complicated systems are necessary. To simulate and analyze the working function and performance of these systems, it is crucial to deal well with the network communications. When referring to network communications, it needs to find appropriate mechanism to handle the information exchange between one or more threads in one or more processes. Inter-process communications are such kind of techniques which describes various ways to exchange data between threads in one or more processes. Inter-process communications offer methods such as message passing, synchronization, shared memory and remote procedure calls (RPC), etc. to realize the efficient and fast data transfer and sharing. The factors determining the specific IPC method which is implemented are the bandwidth and latency of communication between the threads, and the type of data being communicated. Fortunately, there are so many experiences of IPC mechanisms for one-to-one communications. Low level broadcast protocol and high level programming tools are preferred. But the research on IPC mechanisms for many to many communications needs to step forward. 15

23 In general, a process can send a communication in one of two ways: blocking or non-blocking. After sending a blocking communication, the process goes into the waiting state until it receives a response. Non-blocking communication allows the process to continue execution after sending the communication. Both types of communication are useful [3]. Persistence and name space are two major features of IPC. Persistence Persistence of any type of IPC is defined as how long an object of that type stays in existence. It can be process-persistent, kernel-persistent or filesystem-persistent. The users should be aware of the persistence of the IPC object type when choosing for a given application. A process-persistent IPC object remains in existence until the last process that holds the object open closes the object. Examples are pipes and FIFOs [4]. A kernel-persistent IPC object remains in existence until the kernel reboots or until the object is explicitly deleted. Examples are System V message queues, semaphores, and shared memory. Posix message queues, semaphores, and shared memory must be at least kernel-persistent, but may be filesystem-persistent, depending on the implementation [4]. A filesystem-persistent IPC object remains in existence until the object is explicitly deleted. The object retains its value even if the kernel reboots. Posix message queues, semaphores, and shared memory have this property, if they are implemented using mapped files (not a requirement) [4]. 16

24 Name spaces Another feature of each type of IPC is its name space: how IPC objects are identified by the processes and threads that use the IPC object. When two unrelated processes use some type of IPC to exchange information between themselves; the IPC object must have a name or identifier of some form so that one process (often a server) can create the IPC object and other processes (often one or more clients) can specify that same IPC object. The set of possible names for a given type of IPC is called its name space [4]. With all forms of IPC other than half-duplex pipes, the name space is important, using which the client and the server connect with each other to exchange messages. There are single-host (non-networked) IPC and IPC across a network. In practice, single-host IPC is often much faster and sometimes simpler than IPC across a network. History and experience have shown a need for both. 3.2 Single-host (non-networked) IPC There are two major styles of single-host (non-networked) IPC: message passing and shared memory. The two are logically equivalent given one, you can build an interface that implements the other [3]. Nevertheless, it may be easier to write some programs using one rather than the other. In addition, one may be more efficient or easier to implement than the other depending on the hardware platform Message Passing When using message passing, each communication unit has its own message send/receive unit. As shown in figure3.1, the message is stored at the senders/receivers at the end points instead of on the communication link. 17

25 msg msg CPU1 CPU2 Figure 3.1 Message passing communication Applications in which units operate relatively autonomously are natural candidates for message passing communication. Message passing is the natural implementation of communication in many 8-bit microcontrollers that do not normally operate with external memory [4]. Pipe Pipes were one of the most primitive forms and the first widely used form of IPC. A pipe is half-duplex or unidirectional mechanism, providing a one-way flow of byte stream data communication between processes within the same system. When a two-way communication is desired, we need to create two pipes and use one for each data flow direction as well as a lot of caution in case of deadlock. When a pipe is created by invoking a certain system call, a pair of file descriptors is created: one is open for reading, while the other is open for writing. Pipes are process-persistent. After the last process that has pipe open for reading closes the pipe, the data maintained within the kernel is discarded and the pipe is removed. Data flowing through the pipe is transient. Once read from the read descriptor, the data cannot be read again and the system makes sure that the data is read from the pipe in the same order as the data is written to the pipe. It is also assured that the data won t get lost in the communication unless one of the processes (the sender or the receiver) exits prematurely. 18

26 The problem with pipes is that they can be used only by related processes since they have no names. When describing Unix processes, the term related means the processes have some ancestor in common. This is another way of saying that these related processes were generated from this ancestor by one or more forks [4]. FIFO The biggest disadvantage of pipes is that they can be used only between processes that have a common ancestor since pipes have no names. FIFOs (also called Named pipes) fixed this problem. FIFO stands for first in, first out. Similar to the working of a pipe, a FIFO provides a one-way (half-duplex) flow of byte stream data. As with a pipe, a FIFO has process persistence since after the last process that has FIFO open closes the FIFO the data in the FIFO is discarded. The main difference between a FIFO and a pipe is that a FIFO has a pathname within the file system associated with it, allowing unrelated processes to access a single FIFO; while the pipe can be used only between processes with the same ancestor. Message queue A message queue can be thought of as a linked list of messages. Threads with adequate permission can put messages onto the queue, and threads with adequate permission can remove messages from the queue [4]. A message is composed of a message data and a message type, by using which the messages don t have to be read in a FIFO order as in the case with FIFOs or pipes. It is not required that some process is waiting for a message to arrive on a queue before some process writes a message to the queue. This is in contrast to pipes and FIFOs, for which it makes no sense to have a writer unless there s also a reader existing. A process can write some messages to a queue, terminate, and have the messages read by another process at a later time. 19

27 Another difference between message queues and pipes/ FIFOs is that message queues have kernel persistence while for the latter after the last close of the pipe or the FIFO all the data remaining in the pipe or the FIFO is discarded Shared Memory Shared memory communication can be seen as a memory block used as a communication device, in which all the data are stored in the communication link/memory [3]. Shared memory declares a given section of memory to be used by several processors in parallel. Figure3.2 shows an example of shared memory communication implemented on a bus. Memory CPU1 Shared location CPU2 Write Read Bus Figure 3.2 Shared memory communication implemented on a bus[3] Shared memory is the fastest form of IPC. One problem with the forms of IPC pipes, FIFOs and message queues is that when two processes communicate the information has to go through the kernel. While by letting two or more processes share a region of memory, no kernel involvement occurs in exchanging information between the processes, i.e. the processes don t execute any system call into the kernel to pass the data. 20

28 Sharing a same region of memory, the processes might try to alter the memory area at the same time. To make the shared memory form safe avoid destroying or missing messages, some cooperation and synchronization mechanisms such as semaphore are required between the processes that are storing or fetching information to and from the shared memory. Semaphore Semaphore is a language-level synchronization construct. A semaphore can be regarded as a counter and synchronizes multiple processes sharing a memory region by atomic test-and-set operation. It is often used as a locking mechanism to prevent processes from accessing a particular resource while another process is performing operations on it. When using semaphores, any process that wants to access the shared memory location has to use a set of operation to check if the semaphore s value equals an initiative positive integer. If it does, it decreases the counter s value and access is allowed. If it does not, the calling process is blocked until the counter s value reaches the certain integer. There is another type of operation which will release the semaphore by incrementing the semaphore s value. This operation can possibly awake one or more processes waiting on the semaphore which can carry out the checking operation to see if the access is allowed. 3.3 Sockets Prior to the 4BSD 1 facilities, Unix has been quite weak in the aspect of Interprocess communication, when the only standard mechanism of IPC were pipes. As mentioned in the above, pipes are quite restrictive in that the two communicating processes must 1 BSD (Berkeley Software Distribution, sometimes called Berkeley Unix) is the name of Unix versions distributed by the University of California, Berkeley. It is also used as the collective name for the descendants of these distributions. 21

29 have an ancestor in common. Earlier attempts at extending the Unix IPC facilities have a major problem that they have tied the IPC facilities to the Unix file system. Consequently, the 4.3BSD IPC is an independent subsystem, which allows the processes to rendezvous either through a Unix file system-like name spaces or through a network name spaces. The basic building block of 4BSD IPC is the socket. A socket is an endpoint of communication between processes. It is much like a full-duplex channel. The sockets can not only be used for the communication between processes in a single system but also be used to transfer information between processes in two computers connected by network The Client Server Model The client server model is used in most interprocess communications. The terms client/server refer to two processes communicating with each other, in which one process, the client makes a request for a service from another process, the server and the server response to the request. The client server model can be used not only for processes in a single computer but also for the processes in separate host on the internet. One important point is that before the connection is established, the client needs to know the existence as well as the address of the server, while the server does not need to know the existence or the address of the client. After the connection is established, both the client and the server can send and receive information. A good analogy of the client server model is that a person gives another person a phone call. As is said in the above, a socket is an end point of an interprocess communication. The client and server processes each establish their own socket and get connected 22

30 with somewhat different system calls. The steps for establishing a typical client-server connection are as follows: Server Client 1. Create a server socket. 1. Create a client socket. 2. Bind the socket to an address and wait for connections from clients. 3. Attempt to connect to the server. 4. Accept the client s connection attempt. 5. Send and receive data. 5. Send and receive data. 6. Close the connection. 6. Close the connection. First, the server establishes a listening socket and waits for connection attempts. The client creates its own socket and tries to connect to the server. The server accepts the connection attempt and the data can be exchanged. Either socket can close the connection when all data required has been passed through the socket connection Use of Sockets Once a socket is created, two properties need to be specified: the communication domain and the socket type. Generally, sockets exchange data only with sockets in the same communication domain (it may be possible to cross domain boundaries by performing some translation process) and of the same type (though with underlying communication protocols supports, nothing prevents communication between sockets of different types). 23

31 Communication domain A communication domain is an abstraction introduced to bundle common properties of processes communicating through sockets [7]. There are three separate communication domains supported by the 4.3BSD IPC facilities: the Unix domain, the Internet domain and the NS domain. The first two domains are widely used:the Unix domain is used when the communicating processes share a common file system; while in the Internet domain the communicating processes are running on separate hosts connected on the Internet. The Unix domain protocols are an alternative to the non-network interprocess communication methods, when the communicating processes are on the same host. The advantage of using Unix domain sockets over some non-network IPC forms is that the API is similar to the networked client/server. When the communicating processes are on the same host, the advantage of using Unix domain sockets over TCP protocols, is that Unix domain sockets are often twice as fast as a TCP socket (to be talked more about later). A socket is created without names. Processes have no way to reference it and no messages could be received consequently if there is no association by using the address of the socket. In Unix domain the address of a socket is a pathname within the file system. In the Internet domain, the address of a socket is composed of the host machine s Internet address and a port number on that host. A port is an entry point to a process that resides on a host. In a client/server model, a server listens to the port for incoming requests and a client connects to the port and requests the service. Then the server responds to the requests via the port. Port numbers are 16 bit unsigned integers, i.e. there are logical ports with port numbers 1~ A port can be assigned for a particular service. Ports with lower numbers 1~1023 are reserved to identify 24

32 well-known services. For example, for every TCP/IP implementation that supports FTP, FTP server is assigned the port number 21(decimal). Generally, ports numbers above 2000 are available. Socket type Sockets are typed according to the communication properties visible to the application. Currently there are four types sockets available to a user: stream sockets, datagram sockets, raw sockets and sequenced packet socket, in which the former two types are widely used. A stream socket provides two-way, reliable, sequenced, and unduplicated flow of data with no record boundaries [7]. The communication interface provided by a connected stream socket pair is much identical to that of pipes except the bidirectional data flow. A datagram socket supports a two-way flow of data which can t make sure of the reliability. A process on a datagram socket may receive duplicated messages or receive messages in an order different from the one in which the messages were sent. On datagram socket record boundaries in data are preserved. Datagram sockets closely model the facilities found in many contemporary packet switched networks such as the Ethernet [7] Communication Protocol To create a socket, except the need to specify the communication domain and the socket types, a particular communication protocol may also be required. It is possible to specify a protocol or leave it unspecified. When the protocol is unspecified ( the relevant value be 0), the operating system will choose an appropriate protocol according to the communication domain and the requested socket type. For example, in Internet domain, the system will select TCP for stream sockets and UDP for datagram sockets by default. 25

33 Transmission Control Protocol (TCP) TCP, Transmission Control Protocol, is a full-duplex, stream-based, connection-oriented transport protocol for data communications in network applications. The term connection-oriented describes a means of transmitting data which requires an end-to-end connection to be established before any data can be sent. TCP uses a handshake mechanism to establish connections to avoid erroneous initialization of connections. The TCP transfers a continuous stream of octets between its users by dividing the byte stream into appropriately sized segments for transmission through a network. TCP provides reliability. It covers retransmission of lost packets, discarding duplicated packets, sequence control and recovering the damaged data. TCP provides retransmission of lost packets by requiring an acknowledgement from the receiver. When TCP sends data to the other end, it requires an acknowledgement in turn. If the acknowledgement is not received within a timeout interval, the TCP will retransmit the data automatically and wait for a longer interval. TCP will give up after some number of attempts to send data with a total amount of time spent depending on the implementation (typically 4~10 minutes). TCP only provides reliable delivery of data and notification of failure but does not guarantee that the other end will receive the data (this is impossible). TCP can discard duplicated packets and guarantee ordered data transfer by assigning a sequence number to each octet transmitted. If TCP receives duplicate data, it can detect and discard the duplicate data. If the segments arrive out of order, the receiving TCP will correctly order the data according to the octets sequence numbers. TCP checks that no data is damaged by adding a checksum to each segment transmitted, checking it at the receiving TCP end and discarding damaged segments. 26

34 TCP provides flow control. TCP uses the advertised window with every acknowledgement to indicate an allowed range of octets numbers that the sender may transmit at any one time. The window is the number of room currently available in the receive buffer to make sure that the receive buffer will not be overflowed by the sender. The window s size changes dynamically: it decreases when the buffer receives data from the sender and increases when the receiving applications read data from the buffer. The Phases of TCP communication are as follow: 1) Set up a connection 2) Transfer data over the connection 3) Release the connection User Datagram Protocol (UDP) UDP, User (Unreliable) Datagram Protocol is a simple, unreliable, connectionless protocol. The term connectionless means that the no additional connection setup is needed when transmitting the data. The application writes a message to a UDP socket, and then the message is encapsulated in a datagram and sent to its destination. The packet is sent on the network with a destination address to permit the delivery without previous arrangements. The problem with networking programming using UDP is that UDP is lack of reliability. UDP itself does not provide anything like sequence numbers, acknowledgments, timeouts, so datagrams might be lost, duplicated and received out of order. If a UDP datagram reaches the destination with errors detected by the checksum or if the datagram is lost in the delivery, it won t be retransmitted automatically. If a UDP datagram is duplicated, two copies can be delivered to the receiving application. Also, datagrams sent to the same destination, might arrive out of order. All these cases should be handled by the UDP applications. 27

35 UDP provides no flow control. A fast UDP sender might transmit datagrams at a rate that the UDP receiver cannot keep up with [5]. Normally most UDP applications are used when requiring exchanging small amount of data. The use of UDP can avoid the overhead of connection establishment and termination which are needed in TCP. Since UDP is connectionless, no long-term relationship between a UDP client and server is needed. An advantage of UDP over TCP is that it can be used for multicast and broadcast operations, which may save network resources when requiring transmitting the same data to several recipients. In contrast, a TCP connection is always point-to-point. 28

36 4 NoC simulation based on SystemC 4.1 Introduction of SystemC High integration has given rise to a trend to integrate entire complex systems, consisting of a heterogeneous mixture of hardware and software components, onto system-on-chip (SoC) designs [8]. This trend brings the engineers new challenges in implementing specification, partition and verification of such hardware-software designs. A traditional method in hardware-software co-design is the use of multiple languages ( with C/C++ for software design and hardware description languages such as VHDL and Verilog for hardware ) and heterogeneous programming environments, which leads to heavy communication overhead and it is error-prone to translate C/C++ models to synthesizable HDLs in the design flows. In response to the needs of advanced processing technology, SystemC has been developed to supply a standardized modelling language intended to enable system level design and IP exchange at multiple abstraction levels, for system containing both hardware and software components[9]. SystemC is a C++ library provided by the Open SystemC Initiative (). It supplies a single language framework based on standard C++ to support the description of hardware, software and interfaces in a C++ environment as well. It supports various levels of abstraction, ranging from high-level functional model to clock cycle accurate RTL model and also supports the refinement of high level models down to lower levels abstraction. 29

37 4.2 SystemC Design Methodology The system design methodology in use today usually starts from writing a C/C++ model and verifying that it works as expected. Then the parts of C/C++ model to be implemented in hardware are manually translated into HDLs for actual hardware implementation, which is tedious and error prone. Besides, changes in the HDL model will make the C/C++ model out of date and tests created for validating the C/C++ model has to be converted to the HDL environment as well. Compared with the traditional approach for system design, SystemC offers many advantages: The design uses a single language and no translation work between languages is needed. This also means that the developed resources such as testbenches can be easily reused to save development time. It uses a gradual refinement methodology to add the necessary hardware and timing constructs, which makes the changes implementation and bug detection easier. What s more, the SystemC approach offers high level modelling which can result in higher productivity. Figure4.1 [10] shows a design flow of SystemC. 30

38 SystemC Model Simulation Refinement Synthesis Rest of process Figure 4.1 SystemC design methodology for hardware 4.3 SystemC Language Architecture The SystemC language architecture is shown in Figure4.2 based on [11][12]. 31

39 Layered Libraries Verification Library, Static Dataflow, etc Elementary Channels Signal, Timer, Mutex, Semaphore, FIFO, etc Core Language Module Ports Processes Events Interfaces Channels Methodology-specific Libraries Master/Slave library, etc. Data types Utilities Report handling, Tracing Bits and bit-vectors Arbitrary precision integers Fixed-point numbers 4-valued logic types Logic-vectors C++ user defined types C++ Language Standard Figure 4.2 SystemC 2.0 Language Architecture There are some important concepts from the architecture diagram: The language builds on standard C++. Upper layers are built on top of the lower layers. Lower layers may be used separately without needing the upper layers. The standard SystemC class library contains four categories: the core language, data types, elementary channels serving as communication mechanisms and utilities. The SystemC Core language provides a minimal set of modeling constructs for structural description (using modules), concurrency (using processes), communication and synchronization (by means of channels, interfaces and events). 32