Simulation the Concentrated-NOC:

CMesh-NOC and CTorus-NOC

Teamour Esmaeili
Dep.of Computer Engineering
DareShahr Branch,
Islamic Azad University, Iran
Ghazal Lak
Dep.of Computer Engineering
DareShahr Branch,
Islamic Azad University, Iran
Akram Noori Rad
Dep.of Computer Engineering
DareShahr Branch,
Islamic Azad University, Iran
AbstractSThe Concentrated Mesh (CMesh) is a mesh whose nodes are grouped in sets of 4 and the links on the borders are
connected with mode distant set of nodes in a way similar to Torus. By concentrating a set of four nodes together, the size of the
mesh can be reduced to 4*4 thereby reducing the average hop count each message must incur but increasing the radix of each
router to accommodate the four node connections. We explore the use of a concentrated mesh and concentrated torus. We
simulated our NoC architecture using the widely used network simulator ns-2 and have obtained good performance.
Index TermsSCMesh-NOC (Concentrated-Mesh-Network-On-Chip), CTorus-NOC (Concentrated-Torus-Network-On-Chip).
~~~~~~~~~~ ~~~~~~~~~~
1 INTRODUCTION
etwork on chip (NoC) has emerged as a leading
alternative for implementing interconnections for a
multi-cores System on Chip (SoC) for its good scal-
ability and high bandwidth [1]. As one of the communica-
tion infrastructure of NoC, routing algorithms have im-
portant impaction on the average delay and throughput
of NoC [2]. Routing methods have been classied in litera-
ture in several ways. One way to classify them is source
routing and distributed routing [3]. In source routing the
whole path from the source PE to the destination PE is
pre-computed and provided in packet header while dis-
tributed routing uses packet header only including desti-
nation address and the path is computed dynamically by
the participation of routers on the path. With source rout-
ing, all routing decisions are made inside the source PE.
With distributed routing, all routing decisions are dy-
namically made in the routers in the network.
2 NOCARCHITECTURES
A key point on the NoC performance is the interconnect
topology. A NoC topology should be regular and simple
so to allow the use of simple and efficient routing algo-
rithms. Simplicity in fact is directly bounded to the max-
imum frequency a circuit can run.
Guerrier and Greiner proposed a generic interconnect
template called Spin (Scalable, Programmable, Integrated
Network) for on-chip packet switched interconnections,
where a fat-tree architecture is used to interconnect IP
blocks [4].
In fat tree, every node has four children and the parent is
replicated four times at any level of the tree. The size of
the network grows as (NlogN)/8. The functional IP
blocks reside at the leaves and the switches reside at the
vertices. In this architecture, the number of switches con-
verges to S = 3N/4 where N is the system size in terms of
number of functional IPs.
Kumar et al. proposed a mesh-based interconnect archi-
lecluie caIIed CIich e(Chip-Level Integration of Commu-
nicating Heterogeneous Elements) [5]. This architecture
consisls of an n n nesh of svilches inleiconnecling
computational resources (IPs) placed along with the
switches. Every switch, except those at the edges, is con-
nected to four neighboring switches and one IP block. In
this case, the number of switches is equal to the number
of IPs. IPs and the switches are connected through com-
munication channels. A channel consists of two unidirec-
tional links between two switches or between a switch
and a resource.
Dally and Towles [6,7] proposed a 2D torus as an NoC
architecture. The Torus architecture is basically the same
as a regular mesh but the switches at the edges are con-
nected to the switches at the opposite
edge through wrap-around channels. Every switch has
five ports, one connected to the local resource and the
others connected to the closest neighboring switches.
Again, the number of switches is S = N. The long end-
around connections can yield excessive delays. However,
this can be avoided by folding the torus.
ST Microelectronics proposed Octagon [KO] and its evo-
lution for NoC Spidergon [8-11]. Spidergon has a regular
and point-to-point topology which is symmetric with ver-
tex and edge-transitivity.
Pande Grecu and Ivanov proposed an interconnect
template following a Butterfly Fat-Tree (BFT) [12] archi-
tecture. In our network, the IPs are placed at the leaves
and switches placed at the vertices. A pair of coordinates
is used to label each node, (l, p), where l denotes a nodes
N
JOURNAL OF COMPUTING, VOLUME 4, ISSUE 6, JUNE 2012, ISSN (Online) 2151-9617
https://sites.google.com/site/journalofcomputing
WWW.JOURNALOFCOMPUTING.ORG 149
level and p denotes its position within that level. In gen-
eral, at the lowest level, there are N functional IPs with
addresses ranging from 0 to (N 1). The pair (0, N) de-
notes the locations of IPs at that lowest level. Each switch,
denoted by S(l, p), has four child ports and two parent
ports. The IPs are connected to N = 4 switches at the first
level. In the jth level of the tree, there are N = 2j + 1
switches.
The number of switches in the butterfly fat tree archi-
tecture converges to a constant independent of the num-
ber of levels. If we consider a 4-ary tree, with four down
links corresponding to child ports and two up links corre-
sponding to parent ports, then the total number of
switches in level j = 1 is N/4. At each subsequent level,
the number of required switches reduces by a factor of 2.
In this way, the total number of switches approaches S =
N/2 , as N grows arbitrarily large [12].
Balfour and Dally present a very comprehensive anal-
ysis of NoC topologies and architectures in [13]. They
propose the Concentrated Mesh (CMesh) reported in Fig-
ure 1, which is a mesh whose nodes are grouped in sets of
4 and the links on the borders are connected with mode
distant set of nodes in a way similar to Torus.
The authors discuss also the idea of duplicating certain
NoC topologies, such as Mesh and CMesh, to improve the
system performance. An extensive analysis of NoC archi-
tectures is presented also by Pande et al. and Jayasimha et
al. in [14,15].
Literature proposes also many other hybrid solutions
where the NoC is built ad-hoc rather than on a fixed to-
pology. This NoC require a previous knowledge of the
flow of data that the NoC will have to handle. Examples
of tools generating ad-hoc networks are Xpipes from
University of Bologna and Standford [16,
17], Cosi [18] from Berkeley University and the work of
Srinivasan et al. [19].
3 SIMULATION METHODOLOGY
3.1 Simulating NoCs with NS-2
A SoC design process involves three major stages; Behav-
ioral design, Structural design and Physical design [20].
The behavioral design specifies the functionality of the
system at higher level of abstractions, whereas structural
and physical design view reduces the abstraction level to
logic gate and transistor level respectively. At behavioral
design level, a SoC is realized as a collection of compo-
nents which are modeled as blocks and connections along
with protocols that govern the communication. Consider-
ing the above mentioned scenario, it is clear that NS-2 is a
Fig.2. Concentrated Torus NoC
Fig.1. Concentrated Mesh NoC
JOURNAL OF COMPUTING, VOLUME 4, ISSUE 6, JUNE 2012, ISSN (Online) 2151-9617
https://sites.google.com/site/journalofcomputing
WWW.JOURNALOFCOMPUTING.ORG 150
perfect candidate for simulating and evaluating NoCs at
behavioral design level. The individual blocks of a NoC
are defined as "nodes'' and connections as "links'' in NS-2.
Similarly, protocols can be defined over the blocks as
"agents'' with relevant applications if any.
Using the graphical animation of NS-2 (NAM), the behav-
ior of the protocols can be observed interactively. It is
quite convenient to realize various regular as well as ir-
regular topologies using the TCL scripting language used
in NS-2. Any form of topology ranging from mesh, torus,
fat tree to even a fully connected network can easily be
created in NS-2. In contrast to traditional networks, a
NoC has considerably short distance wires (4.5 mm in a
20mm x 20mm chip, for instance) and very large band-
width (ranging from 8 Gbits/sec to 16 Gbits/sec). This
can be realized by setting the link delay and bandwidth
attributes of the links accordingly in NS-2.
3.2 NS-2 network simulator
NS-2 is an open source, object-oriented and discrete event
driven network simulator written in C++ and OTcl. Its a
very common and widely used tool to simulate small and
large area networks. Due to similarities between NoCs
and networks, NS-2 has been a choice of many NoC re-
searchers to simulate and observe the behavior of a NoC
at a higher abstraction level of design. It has a huge vari-
ety of protocols and various topologies can be created
with little effort. Moreover, customized protocols for
NoCs can easily be incorporated into NS-2. The
parameters for routers and links can easily be scaled
down to reflect the real situation on a chip. Based on this
fact, we have successfully simulated a hundred node 2D
mesh based NoC using our reliable protocol for safe
delivery of packets. The purpose of this paper is to show the network com-
munity the similarities that exist between general net-
works and NoCs and show how NS-2 is facilitating the
NoC designers to realize new design paradigms for this
novel communication architecture. Furthermore, we hope
that this paper would motivate network researchers to
make a valuable contribution toward NoCs, hence open-
ing a new dimension of research.
NS-2 is an object-oriented, discrete event driven network
simulator developed at UC Berkely and written in C++
and OTcl [21].
NS-2 is a very common tool used for simulating local and
wide area networks. It implements network protocols
such as TCP and UPD; traffic source behavior such as
FTP, Telnet, Web, CBR and VBR; router queue manage-
ment mechanism such as Drop Tail, RED and CBQ; rout-
ing algorithms such as Dijkstra, and a lot more. NS-2 also
implements multicasting and some of the MAC layer pro-
tocols for LAN simulations. The simulator is open source,
hence, allowing anyone and everyone to make changes to
the existing code, besides adding new protocols aand
functionalities to it. This makes it very popular among the
networking community which can easily evaluate the
functionality of their new proposed and novel designs for
network research. The simulator is developed in two lan-
guages: C++ and OTcl. C++ is used for detailed imple-
mentations of protocols like TCP or any customized ones.
TCL scripting, on the other hand, is the front-end inter-
preter for NS-2 used for constructing commands and con-
figuration interfaces. For example, if you want to develop
a new routing protocol, you have to write it in C++ and
add it into the NS-2 library. In order to check the func-
tionality of this protocol, you use TCL scripting through
which you can create the required topology, define pa-
rameters for links and nodes, and perform simulations to
realize your own protocol in action.
Besides above mentioned functionality of NS-2, a Net-
work AniMator (NAM) is also provided with NS-2 in
order to visualize and interact with the system at run-
time. Finally, graphs can be created from the produced
results to evaluate and analyze the performance of the
system.
4. SIMULATION RESULTS
In this section, simulation results are presented. We have
simulated different levels of CMesh-NOC (Concentrated-
Mesh-Network-On-Chip) and CTorus-NOC (Concen-
trated-Torus-Network-On-Chip) by using NS-2 simulator.
Each of the topologies is simulated in different size. Fig-
ures of simulation are shown below.
4.1. The simulation of CMesh-NOC
Figures 3 to 4 show different views of CMesh-NOC (Con-
centrated-Mesh-Network-On-Chip).
Fig.3. the 1
st
view of the CMesh-noc
JOURNAL OF COMPUTING, VOLUME 4, ISSUE 6, JUNE 2012, ISSN (Online) 2151-9617
https://sites.google.com/site/journalofcomputing
WWW.JOURNALOFCOMPUTING.ORG 151
4.2. The simulation of CMesh-Torus
Figure 5 shows the CTorus-NOC (Concentrated-Torus-
Network-On-Chip).
REFERENCES
[1] Jian Wang, Yubai Li, Song CHAI, Qicong Peng.
Bandwidth-Aware Application Mapping for NoC-
Based MPSoCs. Journal of Computational Informa-
tion Systems, 7 (1): 152 { 159, 2011.
[2] Ogras U Y, Jingcao Hu, Radu Marculescu. Key re-
search problems in NoC design: a holistic perspec-
tive. Proc. Hardware-Software Co-Design and System
Synthesis (CODES +ISSS). Pages 69 { 74, 2005.
[3] Ma Liwei, Sun Yihe. On-chip network evolution us-
ing NetC. In: Proceedings of VLSI Design, Automa-
tion and Test. Hsinchu, China: IEEE, pages 249 { 252,
2005.
[4] A. Greiner L. Mortiez A. Adriahantenaina, H. Char-
lery and C.A. Zeferino. SPIN: A scalable, packet
switched, on-chip micro-network. In Design, Auto-
mation and Test in Europe (DATE05), page 20070,
Washington, DC, USA, 2003. IEEE Computer Society.
[5] A. Kumar, A. Jantsch, M. Millberg, J. Oberg, J.P Soin-
inen, M. Forsell, K. Tiensyrja, and A. Hemani. A net-
work on chip architecture and design methodology.
In in Proc. Symp. VLSI, page 117, Washington, DC,
USA, 2002. IEEE Computer Society.
[6] W. J. Dally and B. Towles. Route packets, not wires:
On-chip interconnection networks. In Proceedings of
the Design Automation Conference, pages 684-689,
June 2001.
[7] W. J. Dally and B. Towles. Principles and Practices of
Interconnection Networks. Morgan Kaufmann Pub-
lishers, San Mateo, CA, 2004.
[8] M. Coppola, M. D. Grammatikakis, R. Locatelli, G.
Maruccia, and L. Pieralisi. Design of Cost-Efficient In-
terconnect Processing Units: Spidergon STNoC. CRC
Press, Inc., Boca Raton, FL, USA, 2008.
[9] M. Coppola, R. Locatelli, G. Maruccia, L. Pieralisi,
and A. Scandurra. Spidergon: A NoC modeling para-
digm. In Proc. 2004 International Symposium on Sys-
tem-on-Chip, page 15, November 2004.
[10] L. Bononi, N. Concer, M. Grammatikakis, M. Coppo-
la, and R. Locatelli. Noc topologies exploration based
on mapping and simulation models. In DSD 07: Pro-
ceedings of the 10th Euromicro Conference on Digital
System Design Architectures, Methods and Tools,
pages 543-546, 2007.
[11] M.Coppola, R.Locatelli, G.Maruccia, L.Pieralisi, and
A.Scandurra. Networks on chip: A new paradigm for
systems on chip design. In System-on-Chip, 2004.
Proceedings. 2004 International Symposium on, page
15, Washington, DC, USA, 2004. IEEE Computer So-
ciety.
[12] C. Grecu, P.P. Pande, A. Ivanov, and R. Saleh. Struc-
tured interconnect architecture: a solution for the
non-scalability of bus based SoCs. In 14th ACM Great
Lakes symposium on VLSI, (GLSVLSI 04), pages
192-195, April 2004.
[13] J. Balfour and W. J. Dally. Design tradeos for tiled
CMP on-chip networks. In ACM/IEEE (SC~05)
Conf. Supercomputing, pages 187-198, 2006.
[14] P.P.Pande, C. Grecu, , M.Jones, A.Ivanov, and
R.Saleh. Performance evaluation and design trade-
Fig.4. the 2nd view of the CMesh-noc
Fig.5. Concentrated Mesh NoC
JOURNAL OF COMPUTING, VOLUME 4, ISSUE 6, JUNE 2012, ISSN (Online) 2151-9617
https://sites.google.com/site/journalofcomputing
WWW.JOURNALOFCOMPUTING.ORG 152
os for network-on-chip interconnect architectures.
IEEE Trans. on Computers, Dec 2005.
[15] Jayasimha, B. Zafar, and Y. Hoskote. On-chip inter-
connection networks: Why they are dierent and
how to compare them. blogs.intel.com.
[16] A. Jalabert, L. Benini, S. Murali, and G. De Micheli.
XpipesCompiler: a tool for instantiating application-
specific NoCs. In Conf. on Design, Automation and
Test in Europe, February 2004.
[17] A. Jalabert, S. Murali, L. Benini, and G. De Micheli.
xpipesCompiler: A tool for instantiating application
specific Networks on Chip. In in Proc. Design, Auto-
mation and Test in Europe Conf., Paris, France, 2004.
[18] A. Pinto. A platform-based approach to communica-
tion synthesis for embedded systems. May 2008.
[19] K. Srinivasan, K. S. Chatha, and G. Konjevod. Appli-
cation specific network-on-chip design with guaran-
teed quality approximation algorithms. In Proceed-
ings of the Design Automation Conference, pag-
es184-190, 2007.
[20] Rochit Rajsumman, "System-on-a-chip: Design and
Test'', Artech House Publishers, 2000.
[21] Network Simulator (NS-2) web site: http://www-
mash.cs.berkeley.edu/ns.
JOURNAL OF COMPUTING, VOLUME 4, ISSUE 6, JUNE 2012, ISSN (Online) 2151-9617
https://sites.google.com/site/journalofcomputing
WWW.JOURNALOFCOMPUTING.ORG 153