NoC Simulator

Initial structural description
Once an overview of the design methodology has been described it's time to move on to the system structural description.
The system has two parallel architectures:
1-Structural architecture: Called NoC-Framework. Describes the NoC.
2-Control architecture: Executes the simulation. It's the system's core. It's event based and decides how and when the functions are done.

NoC-Framework
The NoC-Framework is the structural architecture.
It's conformed of a list of commutation elements (A.K.A. routers).
The routers will be interconnected following the real topology as it is shown in the figure.




The router is the basic structural unit of the system. Contains routing information, virtual channels structure, ports, arbitration modules, etc.

Besides the structural components(ports, Virtual channels, etc.), the router also implements behavioral components that define some of the NoC main characteristics:
-Input Virtual Channel selection
-Arbiter and output Virtual Channel allocation
-Output Virtual Channel selection
-Traffic generation unit

Besides these behavioral components implemented in the router structure, the NoC-Framework also has one behavioral component common to all routers, that's the Routing module, which is defined globally in the NoC-Framework and decides the route for every packet.

All behavioral components are modular by using the methodology already explained, so it's possible to define one new NoC behavior by just coding a sub-module, which is easy because you can focus on the NoC characteristic is being described, thus forgetting the environment.

System Core:
-It is the Control architecture that executes the simulation. It is event based and decides how an when the functions are done.
-The central element is a list, in which the less timed event will be extracted for being executed.
-Each type of event belongs to a NoC operation.

Example: Dealing a new out.
In the figure there is a list with many events. The less timed event is "C:1; E:O; P:E", representing Cycle 1, event type Out, Port East, so this event will be extracted and the Out operation will be executed.





-The list of events is sorted by execution time and event type.
-The system time will be updated once all the events of the current time are attended.

Basic design description
Once the specifications are closed, the next step is the design process.
At this point is time to remember that our system has some input parameters in a design space, then the simulation runs, and at the end we have output data in terms of Latency and throughput.

Input parameters ---> Simulation ---> Output (Latency and Throughput)


The design approach is to design with modularity and flexibility goals in mind.
To achieve these goals the implementation is based on a C++ Object Oriented Code with a strong use of STL (Standard Template Library). With the Object Oriented Code an invisibility top-to-bottom is pursued as is shown in the figure.


One of the conclusions of the study of NoC was that the design space was huge in architectural possibilities. So it isn't realistic to design a system covering all the possibilities.
The goal is to design a base system, in which it is possible to add modules that describes some NoC architectural behaviour. Thus, the base system would cover a big design space, but the thesis would implement just one module for each NoC characteristic. So an implementation for many topologies, arbiters, flow control, commutation, routing and traffics rules is, as it is said before, ruled out.
The challenge is to built a good Base system. A good base system needs a study of common parts in the NoC design space. So each architectural main characteristic needs an examination to identify common parts between the different implementations.
After deciding which is the design space your base system is going to cover, the next step is to design the system. This design should have in mind one big quote "Adding new architectural descriptions must be easy if they are on the original design space".
One way of facing this quote is designing a modular system, in which each module describes a new behaviour of one NoC characteristic. Since the modules should be simple, the system needs an environment that implements functions to make easy adding modules to it.



My solution for these challenges was implementing modularity based on derived classes:

-System's core accesses the base class.
-All design space possibilities implemented in derived classes.

As an example, with this implementation the routing element is able to have modules describing X-Y routing algorithm, modules describing the XY- Adaptative routing algorithm and others describing other type of routing algorithm. All these description would be implemented in derived classes of routing.

The Thesis
As I mentioned before I just finished my M.S. Thesis(March'07) up to get the M.S. in Telecomunications engineer degree.
The M.S. in Telecomunications in Spain is a long term degree(At least six years), comprising three engineers: Electronical Engineer + Communications Engineer + Signal processing Engineer. (You may know that each of these engineers degree is 3-4 years long in most of the countries).
Getting the degree took me 7 years, but the average spending time is around 8.5 years.

Developing the Thesis took me about 15 months. I know it seems a lot, but sometimes when you love the topic you focus on your own goals(usually higher than the standards), forgetting the academic framework. By doing this work forgetting the academic standards, I earned the grade excellent(10/10) with an added distinction of honours. But to be honest, what makes me proud is the work done, not the distinction. Going deeply in a NoC project has been an amazing, and at the same time incredibly hard task. Actually, what bothers me right now is not being able to continue with my work in NoC. As I see it, I have done the REALLY difficult part, because getting all NoC concepts and designing a modular and flexible C++ simulator was the boring part, and right now I'm able to do magic with this simulator. Of course I would improve the simulator, changing its view from a base system to a view oriented to the final user with a beautiful wrapper.

Thesis Goals
The goal of the thesis is to develop a flexible characterization system for NoC architectures that supports QoS traffic. This system will characterize the behaviour of different NoC architectures under specific net characteristics. Therefore, developing a final system for the full design space is completely ruled out. Nonetheless, one of the goals is to develop a modular system that allows enlarging the range of characterized NoC. Thus, It would be easier to add new commutation, routing and flow control strategies; as well as net topologies and router architectures.

Facing the problem
Up to achieve the simulator, the first step was to study the characteristics of NoCs and at some point define a general design space of NoCs interconnection networks. A study of the Simulators was also needed for viewing what kind of simulator could be the best covering the necessities of the NoC design space and to achieve modularity goals.
These studies gave the background needed for closing the specifications, which are the break point before designing and implementing the project.

Basic Description of NoC
The communication infrastructures based in NoC has Network Elements(NE) and Network Interfaces(NI).
The packet travel across the Network Elements while the Network Interfaces provide an interface with the IP.
Using switching elements eliminate the skew of the clock signal, which is present in SoCs design with high integration level, as well as cross-talk and other sub-micra technology effects.

A NoC is described by 5 main characteristic:
* Topology: Arrangement of the Network Elements.
* Switching: The way the data is transfered from the input port to the output port.
* Routing: Determine message path.
* Flow Control: Dinanmic allocation of the channels.
* Buffering: The way the packets are store when they cannot be processed.
* Arbitration: Plans the use of channels and buffers.

These five main characteristics, in addition with other less important, generate a big architectural design space.
By using NoC in the communication infrastructure we achieved the division of computation and communication.
NoC stands out in reusability, scalability and parallelism in communications.
NoC systems fulfill power restrictions and clock distribution.

Why a simulation phase?
One limitation in the models based in NoC is the necessity of software tools with the ability to abstract the capacity of a particular communication infrastructure, therefore it allows the correspondence among the requirements of a given application and the capacities of the architecture.
The simulation phase covers the necessity of obtaining the NoC communication infrastructure suited for a particular application. This phase will increase the efficiency by selecting the appropriate parameters, allowing a better latency and throughput. If the needed NoC were simpler than the one used at first, the simulation phase would improve the area and the power consumption.

Utopian Transport Company Example
A similar example of the network analysis is the logistic of an utopian road transport company where you can control the traffic lights and signals, the insertion rate of new traffic, the number of roads, the ratio of low-traffic(trailers) and fast-traffic(ferraris), the policy of the roads(for example one road just for Ferraris or one just for trucks), and a lot of more possibilities.
The number of variables influencing both the latency and the capacity of the system is too big, despite I only showed a few. Due to this huge number of variables you cannot take pen&paper and design the best values of these variables in your particular situation, thus the solution is approaching the optimization problem with a simulation phase that gives you the best values for your particular situation.
An example that shows simple traffic situations was designed and written by Martin Treiber. In that example you can evaluate traffic situations, how all the variables fit together; how the traffic insertion rate, the ratio of traffic type and the behaviour of every vehicle in conflict situations are critical in the performance of the traffic system.
Now click the link and play a little bit.
This simple example can helps to understand the importance of modeling a correct system.
But imagine a more complex example, with 40 roads, 80 crossroads, 50 traffic lights, 30 origin packets nodes(therefor vehicles origin nodes) , 50 destination packets nodes(therefor vehicles destination nodes), different traffic insertion rates and different insertion patterns per origin node. Now you are able to figure out how important could be the model phase in a "real example".

As in the traffic example in NoC there are variables that determine the latency and the capacity of the network.
I have described 5 main characteristic defining a NoC, but in the modeling process there are much more variables. Each of the main characteristic can be splited in sub-characteristics. Therefor the number of modeling variables depends on the complexity of a particular sub-caractaristic. But the NoC architectural variables are NOT the only ones presented in the simulator. As in the traffic example there are other components defining the behaviour of, for example, the traffic generation rate, traffic ratio, traffic insertion pattern, simulation time and traffic weight among others components.

First of all what was the goal of my thesis?
Design and write a Simulator for NoC.

What's NoC?
Network on chip.
They are an alternative to the communications on chip. NoCs are based on networks instead using traditional buses or peer to peer connections.

What are the problems?
The classic(buses, p2p) interconnection networks has a lot of problems in the next communication infrastructures.
The key point is how the design of an integrated circuit is changing to a model with a lot of IPs.


Peer-to-Peer(p2p):
Not reusable.
bad scalability (Area cost increase a lot with the number of IPs)




Buses:
Reusable
One transaction at a time.
bad scalability(Performance divided for the number of IPs)


Global problems:
Long lines.
Skew.
With a lot of IPs, the power consumption of the interconnection network become important.

Why the model is changing into a one with more IPs and the number of IPs will grow and grow?
As you may know a chip has different independent cores or IPs with different functions.
For example an MPEG2 Integrated Circuit (IC) has different blocks for:
-transform coding with 8x8 DCT
-quantization of the DCT coefficients
-prediction of the DC coefficient
-code bitstream elements
-etc.
Or in the other hand, if we look to a more heterogeneous IC, we could have an IP for MPEG codin and others units for the DSP, UARTs, or general processing.

This are the facts:
-Design cost is growing and growing (a)
-Time-in-the-Market of a product is smaller than ever (b)
-(a)(b) -> A design needs to be used in several generations or different families for being amortized. (1)
-The Time-to-Market is a key point. Time for design is smaller than ever. (2)
-(1)(2) -> The design process is changing to a one that reuse a lot of IPs. The number of IPs per chips is growing and growing.

In this section I will include files from the source code to the thesis materials.
-Code(Under GPL v.2)
-Short presentation

I just finished my Thesis, which is an amazing simulator for NoCs, and I have realized it's going to be really difficult to find a job related to the topic of the thesis and continue working in it.
So my point here is just upload some info of my work for all you. I guess you might be a PHD stutend with a similar thesis, a University Professor or a worker in a company with some product related to the topic(i.e. Xilinx, IBM or Arteris). So if you are interesting in my work I can help you or you can just download it.