Home Tools SCNSL


SystemC Network Simulation Library (SCNSL) is an extension of SystemC to allow modelling packet-based networks such as wireless networks, ethernet, field bus, etc. As done by basic SystemC for signals on the bus, SCNSL provides primitives to model packet trasmission, reception, contention on the channel and wireless path loss. The use of SCNSL allows the easy and complete modelling of distributed applications of networked embedded systems such as wireless sensor networks, routers, and distributed plant controllers. The advantages of SCNSL are:

  • simplicity: a single language/tool, i.e., Systems, is used to model both the system (i.e., CPU, memory, periferals) and the communication network;
  • efficiency: faster simulations can be performed since no external network simulator is required;
  • re-use: SystemC IP blocks can be re-used
  • scalability: support of different abstraction levels in the design description
  • openness: several tools available for SystemC can be exploited seamlessly
  • extensibility: the use of standard SystemC and the source code availability guarantee the extensibility of the library to meet design-specific constraints

Figure 1: SCNSL architecture.

The tool is available on Sourceforge website. Figure 1 shows the main components of SCNSL. Tasks are used to model the devices under development. Thus, tasks shall be implemented by designers either at RTL or TLM level. From the point of view of a network simulator, a task is just a producer or consumer of packets and therefore its implementation is not relevant to the simulation kernel. However, for the system designer, task implementation is crucial and many operations are connected to its modelling, i.e., change of abstraction level, validation, fault injection, HW/SW partitioning, mapping to an available platform, synthesis, and so forth. For this reason, the class TaskProxy has been introduced to decouple task implementation from the backend which simulates the network. Each Task instance is connected to one or more TaskProxy instances and, from the perspective of the network simulation kernel, the TaskProxy instance is the interface of the task. Vice versa, from the point of view of the application, each TaskProxy provides the primitives for network communication. This solution allows keeping a stable interface between the TaskProxy and the simulation kernel and, at the same time, to let complete freedom in the modelling choices for the task, e.g., interconnections of basic blocks or finite-state machines. Two different TaskProxy interfaces are provided depending on the abstraction level of the connected Task (i.e., RTL or TLM). It is worth noting that other SystemC libraries can also be used in task implementation, e.g., reused IP blocks and other libraries such as the well-known SystemC Verification Library. These libraries may simplify designer’s work even if they are outside the scope of network simulation. Tasks are hosted on Nodes, which are the abstraction of physical devices. Tasks deployed on different nodes shall communicate by using network communication, while tasks deployed on the same node shall communicate by using standard SystemC communication primitives.

The Channel class represents the network simulation kernel interface. A channel is the abstraction of the transmission medium, and thus it shall simulate all communication aspects including packet collisions. Standard SystemC channels are generally used to model interconnections between HW components and, therefore, they can be used to model network at physical level. However, many general purpose network simulators reproduce transmissions at packet level to speed up simulations. SCNSL follows this approach, providing models for wired (full-duplex, half-duplex and unidirectional) and wireless channels.

Communication protocols are a key concept for a network simulation. Users could require implementing protocols ex-novo, in case protocols are under design, or they could rely on protocol models provided by the simulator. To allow maximum flexibility, SCNSL supports both these possibilities. In particular, users can implement protocols inside tasks. On the other hand, standard protocol models are provided in optional backend components, namely Communicators. A communicator is a SCNSL component implementing the Communicator interface. New capabilities and behaviour can be easily added by extending this class. Communicators can be interconnected each other to create chains. Each valid chain shall have on one end a TaskProxy instance and, on the other end, a Node; hence transmitted packets will move from the source TaskProxy to the Node, traversing zero or more intermediate communicators, then they shall be transmitted by using a channel model, and finally they will eventually traverse the communicators placed between the destination node and the destination TaskProxy. In this way, it is possible to modify the simulation behaviour by just creating a new communicator and placing its instance between TaskProxies and nodes. Communicators can be used to implement not only protocols, but also buffers to store packets, simulation tracing facilities, etc. Another critical point in the design of the tool has been the concept of packet. Generally, packet format depends on the corresponding protocol even if some features are always present, e.g., the length and source/destination addresses. System design requires a bit-accurate description of packet contents to test parsing functionality while from the point of view of the network simulator the strictly required fields are the length for bit-rate computation and some flags to mark collisions (if routing is performed by the simulator, source/destination addresses are used too). Furthermore, the smaller the number of different packet formats, the more efficient is the simulator implementation. To meet these opposite requirements in SCNSL, an internal packet format is used by the simulator while the system designer can use other different packet formats according to protocol design. The conversion between the user packet format and the internal packet format is performed in the TaskProxy.


Last Updated ( Saturday, 18 May 2013 22:50 )  


Successful final review meeting
On Thursday, May 25th, the final COMPLEX review meeting has been held in Brussels.


Final public deliverables uploaded

All public COMPLEX deliverables are now available in the Deliverables section.


COMPLEX @ ISCUG'2013 conference
14-15 April, 2013 - Noida, India


Newsflash RSS Feed