SystemC - NS-2 Co-simulation using HSN

Verona, 12/09/2005 SystemC - NS-2 Co-simulation using HSN Giovanni Perbellini 1 REQUIRED BACKGROUND 2 2 GOAL 2 3 WHAT IS SYSTEMC? 2 4 WHAT IS NS-2? 2 5 WHAT IS HSN? 3 6 HARDWARE-NETWORK COSIMULATION 3 6.1 SYSTEMC-NS2 COSIMULATION INTERFACES... 4 6.1.1 NS-2... 4 6.1.2 SYSTEMC... 4 7 CASE STUDY (VOIP) 6 7.1 SYSTEMC TRANSACTOR... 7 7.2 NS-2 TCL CODE... 8 7.3 EXECUTING THE HARDWARE-NETWORK COSIMULATION... 10 8 REFERENCES 11 1

1 Required Background Students interested in learning the cosimulation between SystemC and NS-2 are required to know the fundamentals of C/C++ language and basic concepts related to modeling and synthesizing digital systems. 2 Goal The goal of this lecture consists of describing the basic concepts related to the cosimulation between the SystemC language (to design an hardware device) and NS-2 simulator (to model a Network infrastructure). Students will learn to: design a SystemC VoIP device connected to the NS-2 Simulator; model a NS-2 UDP/IP Network connected to a SystemC design. 3 What is SystemC? SystemC is a C++ class library and a methodology that you can use to effectively create a cycle-accurate model of software algorithms, hardware architecture, and interfaces of your SoC (System On a Chip) and system-level designs. You can use SystemC and standard C++ development tools to create a system-level model, quickly simulate to validate and optimize the design, explore various algorithms, and provide the hardware and software development team with an executable specification of the system. An executable specification is essentially a C++ program that exhibits the same behavior as the system when executed. C or C++ are the language choice for software algorithm and interface specifications because they provide the control and data abstractions necessary to develop compact and efficient system descriptions. Most designers are familiar with these languages and the large number of development tools associated with them. The SystemC Class Library provides the necessary constructs to model system architecture including hardware timing, concurrency, and reactive behavior that are missing in standard C++. Adding these constructs to C would require proprietary extensions to the language, which is not an acceptable solution for the industry. The C++ object-oriented programming language provides the ability to extend the language through classes, without adding new syntactic constructs. SystemC provides these necessary classes and allows designers to continue to use the familiar C++ language and development tools. More Informations in [1] and [2]. 4 What is NS-2? NS (version 2) is an object-oriented, discrete event driven network simulator developed at UC Berkely written in C++ and OTcl (Tcl script language with Object-oriented extensions). It implements network protocols such as TCP and UPD, traffic source behavior such as FTP, Telnet, Web, CBR and VBR, router queue management mechanism such as Drop Tail, RED and CBQ, routing algorithms such as Dijkstra, and more. NS also implements multicasting and some of the MAC layer protocols for LAN simulations. More informations in [3] and [4]. 2

5 What is HSN? Modern embedded systems exhibit an increasingly large quantity of communication capabilities. The devices should be, often, casually accessible, mobile or embedded in the environment, sometimes in hostile conditions and connected to a network structure. The design of such a system involves two main aspects: the design of the system itself, in terms of hardware and software; and the design of the communication mechanism used by the system to communicate with other systems. The hardware part is usually designed by creating a model of the hardware components with a hardware description language such as SystemC. Having a model of the system, it is possible to simulate and verify it. Once the model is correct the real hardware can be synthesized starting from its description. In this way the so produced hardware will behave exactly in the same way of the model. If the system is a networked system, the interaction with other systems is an important factor to be considered during the design. In fact, the behavior of the device can vary in function of the traffic on the network, the network topology end so on. Therefore, when a network device is simulated it is important to simulate also the interaction with other devices, i.e. the network. The network can be usually modelled with the NS-2 Simulator. The use of a hardware-network co-simulation permits to merge the analysis of the behavior of the internal components of the system, and the external behavior when other systems communicate with the device under project. A more accurate documentation about this topic can be found in [5]. This kind of co-simulation leads to a more accurate design procedure, because the designer can handle a wider range of factors, not only the internal ones. Another important interaction, to be considered during the design of a system, is that between the hardware and the software. Usually a system is a set of ad-hoc devices and a CPU running an operating system and a set of applications. The software can be simulated by using an Instruction Set Simulator (ISS) which represents the CPU of the system, while the other ad-hoc devices can be modeled and simulated with SystemC. In this way, a hardware-software co-simulation can help the designer to exactly define the interaction between the running software and the hardware. More accurate information about this topic can be found in [6] and [7]. A more generic approach consists in a generic hardware-software-network (HSN) cosimulation. This kind of co-simulation handles all the main aspects of the design of a networked system. To learn more about this topics, refer to [8]. The HSN co-design tool allows to design a networked system without having to know how to set up all the necessary tools needed by the co-simulation. The following Sections describe the only cosimulation between SystemC and NS-2. 6 Hardware-Network cosimulation The hardware-network cosimulation included in HSN is based on the timing accurate integration of the system-level modeling language SystemC and the network simulation environment NS-2. More information in [5]. 3

6.1 SystemC-NS2 cosimulation interfaces The SystemC and NS-2 simulators provide the components to allow the timing accurate data exchange among them. 6.1.1 NS-2 From the NS-2 simulator side, a new Agent has been created to allow the data exchange with SystemC. This Agent, called ns_sc, implements a gateway between NS-2 and SystemC. The next line creates a ns_sc Agent (configured using the systemc keyword): set agent0 [new Agent/ns_sc 20 "systemc" 10] This line tells the NS-2 simulator to create a ns_sc Agent, named agent0, bound to: ns_in SystemC port at address 10; ns_out SystemC port at address 20. Next figure shows this idea: SystemC 10 sc_ns_transactor_tl3 20 ns_in ns_out NS-2 agent0 (ns_sc) 6.1.2 SystemC From the SystemC side, the new ports ns_in and ns_out have been added to allow the user to send/receive a packet to/from a NS-2 object. They are derived by the template classes sc_in and sc_out, they are of a generic type and they are managed by two methods read() and and write(), which are an extension of the standard methods managing sc_in and sc_out ports. A SystemC process with a bidirectional communication with NS- 2 is simply defined as follows: SC MODULE(m) { ns_in *in_port = new ns_in(10); // port to receive a packet from NS-2 ns_out *out_port = new ns_out(20); // port to send a packet to NS-2... // standard ports to communicate with other modules SC CTOR(m) { SC METHOD(proc1); sensitive << in port; void proc1(); To send(read) a packet to(from) NS-2, the process must simply manipulate the ports as follows: void m::proc1(){ 4

... Packet p; p =... // the packet is explicitly built out_port.write((void*)&p, sizeof(packet)); // packet sent in_port.read((void*)&p, sizeof(packet); // Read from NS-2 5

7 Case Study (VoIP) The case study used to describe the cosimulation between SystemC and NS-2 is V-CLIP (Voice Client Over IP), a multimedia embedded system for transmitting voice over IP. It is composed of: Voice Signal Generator: it is used to generate voice data to verify the correctness of the application. ADPCM Coder: it performs data compression by exploiting the Adaptive Differential Pulse Code Modulation algorithm. Huffman Coder: it further improves the data compression by encoding the most frequent input symbols with the shorter sequence of output symbols. RTP Packet Generator: it performs data packetization according to the Real-Time Transport Protocol and it sends data over the network. SystemC-NS2 transactor: it connects the VoIP SystemC model with NS-2 Simulator using the interfaces described in Section 5.2.1. SystemC Voice Signal Generator ADPCM Coder Huffman Coder (optional) NS2 System Agent socket RTP Packet Generator socket SystemC-NS2 Transactor The Voice signal generated by the TLM3 SystemC model is sent (using the ns_out port) to the NS-2 Network that simulates a UDP Network; once crossed the NS-2 network, the UDP packets exit from the simulator and are received by a Voice Player. In [2] has been already described the ADPCM coder module; therefore, in this report, about the SystemC V-CLIP implementation, we only described the NS-2 interface (sc_ns_transactor_tl3). 6

To compile and simulate the SystemC VoIP design connected to NS-2 Simulator it is necessary to use the HSN SystemC (in this case has been used systemc-2.1.v1-hsn). On the other hand to perform the NS-2 netowrk cosimulation with SystemC, it is necessary to use the HSN NS-2 Network simulator (in this case has been used nsallinone.2.28-hsn). 7.1 SystemC transactor Following is shown the OSCI TLM3 SystemC code to implement the SystemC-NS2 transactor module (called sc_ns_transactor_tl3). SC_MODULE(sc_ns_transactor_TL3), virtual basic_slave_base <ADDRESS_TYPE, DATA_TYPE_ns> { public: //Ports //get data from rtp module sc_export<if_type> target_port_sc_ns_transactor; //put data to NS-2 network simulator ns_out *out; //Functions void end_of_elaboration(); basic_status write(const ADDRESS_TYPE &,const DATA_TYPE_ns &); basic_status read(const ADDRESS_TYPE &,DATA_TYPE_ns &); //Construct SC_CTOR(sc_ns_transactor_TL3) { target_port_sc_ns_transactor(*this); out=new ns_out(20); end_module(); ; #include "sc_ns_transactor_tl3.h" void sc_ns_transactor_tl3 :: end_of_elaboration(){ basic_status sc_ns_transactor_tl3::write(const ADDRESS_TYPE &a, const DATA_TYPE_ns &d){ unsigned int delay; out->write((void *)(d->abuf),d->len); // wait next samples delay= (unsigned int)(((d->len-12)*8*1000000.0)/ (SAMPLERATE*BITPERSAMPLE)+0.5); wait(delay, SC_US); return basic_protocol::success; basic_status sc_ns_transactor_tl3::read(const ADDRESS_TYPE &a, DATA_TYPE_ns &d){ 7

return basic_protocol::success; The module sc_ns_transactor_tl3 includes a sc_export port named target_port_sc_ns_transactor to receive the data from the rtp module. Moreover, it includes a ns_out port (called out) to inject data into the NS-2 Simulator that simulates a UDP network described follow. In the constructor, the module creates the ns_out port with the address 20. The tcl code to implement the NS-2 Network introduced above, is reported in the next section. 7.2 NS-2 Tcl code The network is composed of four nodes, as shown in the following figure. On the first (node 0) and the last (node 3) node is attached one NS agent each. Node 0 is associated to a ns_sc agent which receives packets from the SystemC domain. The tap agent is attached to the node 3 to redirect the traffic towards the real network and then to the player application. 8

First of all, you need to create a RealTime simulator object. This is done with the command: set ns [new Simulator] $ns use-scheduler RealTime The following line informs the NS-2 Scheduler to execute a SystemC-NS2 cosimulation. $ns set cosim_type 2 Now we open a file for writing that is going to be used for the nam trace data. #### Open files for statistics ##### set tracefile [open vclip1.tr w] $ns trace-all $tracefile set namfile [open vclip1.nam w] $ns namtrace-all $namfile The next step is to add a 'finish' procedure that closes the trace file and starts nam. proc finish { { global ns global namfile global tracefile $ns flush-trace close $namfile close $tracefile $ns close-channel exit 0 The following four lines define the four network nodes. set Node0 [$ns node] set Node1 [$ns node] set Node2 [$ns node] set Node3 [$ns node] The next lines connecte the four nodes. These lines tell the simulator object to connect the nodes Node0 with Node1, Node1 with Node2 and finally Node2 with Node3 using a duplex link with the bandwidth 500 kbit, a delay of 200ms and a DropTail queue. $ns duplex-link $Node0 $Node1 500kb 200ms DropTail $ns duplex-link $Node1 $Node2 500kb 200ms DropTail $ns duplex-link $Node2 $Node3 500kb 200ms DropTail The next lines create a ns_sc agent and attach it to the node Node0. set agent0 [new Agent/ns_sc 20 "systemc" 10] 9

$agent0 set class_ 1 $agent0 set fid_ 1 $agent0 set packetsize_ 2000 $ns attach-agent $Node0 $agent0 The next step is to define the IP-UDP Network Object to inject UDP traffic from the simulator into the live network via UDP Socket at 127.0.0.1:4460 address. set ipnet [new Network/IP/UDP] $ipnet open writeonly $ipnet connect 127.0.0.1 4460 The Network ipnet object is connected to a Tap Agent called agent3. #### Create the Tap Agent #### set agent3 [new Agent/Tap] $agent3 network $ipnet The next line attaches the agent3 Tap Agent to node Node3. $ns attach-agent $Node3 $agent3 Now the two agents have to be connected with each other. $ns connect $agent0 $agent3 The next line tells the simulator object to execute the 'finish' procedure after 30.0 seconds of simulation time. $ns at 30.0 "finish" The last line finally starts the simulation. $ns run Now it is possible to save the file (e.g. vclip1.tcl) and start the simulation. 7.3 Executing the Hardware-Network cosimulation After the SystemC simulation executable and the vclip1.tcl simulation script are built, you run the cosimulation by executing before the SystemC simulation executable (the batch program that executes the simulation) and then by executing the NS-2 simulation script (the tcl script generated in the previous Section). For example, to run the cosimulation between the SystemC module simulating the VoIP design, named run, and the NS-2 UDP network described in the vclip1.tcl simulation script, type the following commands: First, start a VoIP client to receive the voice data sent by V-CLIP (e.g. a speaker); 10

simply type run < speech.raw at the command prompt and press return to simulate the SystemC VoIP example with speech.raw as a source; nse vclip1.tcl to start the NS-2 network simulation to transfer data from SystemC VoIP to speaker. To visualize the NS-2 result it is possible to use a Network Animator (NAM). 8 References [1] Giovanni Perbellini, An Introduction to SystemC, 2005, Internal Report. [2] Giovanni Perbellini, Transaction Level Modeling in SystemC, 2005, Internal Report. [3] Giovanni Perbellini, An Introduction to NS-2, 2005, Internal Report. [4] Giovanni Perbellini, Network Advanced Modeling in NS-2, 2005, Internal Report. [5] F.Fummi, P.Gallo, S.Martini, G.Perbellini, M.Poncino, F.Ricciato, A Timing-Accurate Modeling and Simulation Environment for Networked Embedded Systems, Proceedings of "ACM/IEEE Design Automation Conference (DAC)", Los Angeles, CA, 2-6 June 2003, pp. 42-47. [6] F.Fummi, S.Martini, G.Perbellini, M.Poncino, Native ISS-SystemC Integration for the Co-Simulation of Multi-Processor SoC, Proceedings of "IEEE Design Automation and Test in Europe Conference (DATE)", Paris, France, 16-20 February 2004, pp. 564-569. [7] F. Fummi, M. Poncino, M. Loghi, S. Martini, G. Perbellini, M. Monguzzi, Virtual Hardware Prototyping Through Timed Hardware-Software Co-Simulation, Proceedings of IEEE Design Automation and Test in Europe Conference (DATE), Munich, Germany, 7-11 March, 2005. [8] F. Fummi, S. Martini, G. Perbellini, M. Poncino, F. Ricciato, M. Turolla, Heterogeneous Co-Simulation of Networked Embedded Systems, Proceedings of "IEEE Design Automation and Test in Europe Conference (DATE)", Paris, France, 16-20 February 2004, pp. 168-173. 11