simulation the concentrated-noc: cmesh-noc and ctorus-noc

7/31/2019 Simulation the Concentrated-NOC: CMesh-NOC and CTorus-NOC

1/5

Simulation the Concentrated-NOC:

CMesh-NOC and CTorus-NOC

Teamour Esmaeili

Dep.of Computer EngineeringDareShahr Branch,

Islamic Azad University, Iran

Ghazal Lak



Akram Noori Rad



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 TermsS

CMesh-NOC (Concentrated-Mesh-Network-On-Chip), CTorus-NOC (Concentrated-Torus-Network-On-Chip).

mmmmmmmmmm mmmmmmmmmm

1 INTRODUCTION

etwork on chip (NoC) has emerged as a leadingalternative for implementing interconnections for amulti-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 throughputof NoC [2]. Routing methods have been classied in litera-

ture in several ways. One way to classify them is sourcerouting and distributed routing [3]. In source routing thewhole path from the source PE to the destination PE ispre-computed and provided in packet header while dis-tributed routing uses packet header only including desti-nation address and the path is computed dynamically bythe 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 NOC ARCHITECTURES

A key point on the NoC performance is the interconnecttopology. A NoC topology should be regular and simpleso 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 interconnecttemplate called Spin (Scalable, Programmable, IntegratedNetwork) 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 isreplicated four times at any level of the tree. The size ofthe 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 ofnumber of functional IPs.Kumar et al. proposed a mesh-based interconnect archi-cTRcdaT RP[[TS 6[XRWk T6WX-Level Integration of Commu-nicating Heterogeneous Elements) [5]. This architectureR]bXbcb U P] p ] TbW U bfXcRWTb X]cTaR]]TRcX]V

computational resources (IPs) placed along with theswitches. Every switch, except those at the edges, is con-nected to four neighboring switches and one IP block. Inthis case, the number of switches is equal to the numberof 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 switchand a resource.Dally and Towles [6,7] proposed a 2D torus as an NoCarchitecture. The Torus architecture is basically the sameas a regular mesh but the switches at the edges are con-nected to the switches at the oppositeedge through wrap-around channels. Every switch hasfive 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 regularand 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 leavesand switches placed at the vertices. A pair of coordinatesis 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


2/5

level and p denotes its position within that level. In gen-eral, at the lowest level, there are N functional IPs withaddresses ranging from 0 to (N o(). 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 parentports. 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 downlinks corresponding to child ports and two up links corre-sponding to parent ports, then the total number ofswitches 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]. Theypropose the Concentrated Mesh (CMesh) reported in Fig-

ure 1, which is a mesh whose nodes are grouped in sets of4 and the links on the borders are connected with modedistant set of nodes in a way similar to Torus.

The authors discuss also the idea of duplicating certainNoC topologies, such as Mesh and CMesh, to improve thesystem performance. An extensive analysis of NoC archi-tectures is presented also by Pande et al. and Jayasimha etal. in [14,15].

Literature proposes also many other hybrid solutionswhere the NoC is built ad-hoc rather than on a fixed to-pology. This NoC require a previous knowledge of theflow of data that the NoC will have to handle. Examples

of tools generating ad-hoc networks are Xpipes fromUniversity of Bologna and Standford [16,17], Cosi [18] from Berkeley University and the work ofSrinivasan 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 thesystem at higher level of abstractions, whereas structuraland physical design view reduces the abstraction level tologic gate and transistor level respectively. At behavioraldesign level, a SoC is realized as a collection of compo-nents which are modeled as blocks and connections alongwith 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





3/5

perfect candidate for simulating and evaluating NoCs atbehavioral design level. The individual blocks of a NoCare 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 usedin NS-2. Any form of topology ranging from mesh, torus,fat tree to even a fully connected network can easily becreated in NS-2. In contrast to traditional networks, a NoC has considerably short distance wires (4.5 mm in a20mm 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 bandwidthattributes 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 andlarge area networks. Due to similarities between NoCsand networks, NS-2 has been a choice of many NoC re-searchers to simulate and observe the behavior of a NoCat a higher abstraction level of design. It has a huge vari-ety of protocols and various topologies can be createdwith little effort. Moreover, customized protocols forNoCs can easily be incorporated into NS-2. Theparameters for routers and links can easily be scaleddown to reflect the real situation on a chip. Based on thisfact, we have successfully simulated a hundred node 2Dmesh 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 theNoC designers to realize new design paradigms for thisnovel communication architecture. Furthermore, we hopethat this paper would motivate network researchers tomake a valuable contribution toward NoCs, hence open-ing a new dimension of research.NS-2 is an object-oriented, discrete event driven networksimulator developed at UC Berkely and written in C++and OTcl [21].NS-2 is a very common tool used for simulating local andwide area networks. It implements network protocols

such as TCP and UPD; traffic source behavior such asFTP, 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 alsoimplements 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 tothe existing code, besides adding new protocols aandfunctionalities to it. This makes it very popular among thenetworking community which can easily evaluate thefunctionality of their new proposed and novel designs fornetwork 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 developa new routing protocol, you have to write it in C++ andadd it into the NS-2 library. In order to check the func-tionality of this protocol, you use TCL scripting throughwhich you can create the required topology, define pa-

rameters for links and nodes, and perform simulations torealize your own protocol in action.Besides above mentioned functionality of NS-2, a Net-work AniMator (NAM) is also provided with NS-2 inorder to visualize and interact with the system at run-time. Finally, graphs can be created from the producedresults to evaluate and analyze the performance of thesystem.

4. SIMULATION RESULTS

In this section, simulation results are presented. We havesimulated 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 1st

view of the CMesh-noc





4/5

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 SystemSynthesis (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, packetswitched, on-chip micro-network. In Design, Auto-mation and Test in Europe (DATEn05), 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 ofthe Design Automation Conference, pages 684l689,June 2001.

[7] W. J. Dally and B. Towles. Principles and Practices ofInterconnection 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. CRCPress, 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 basedon mapping and simulation models. In DSD n07: Pro-ceedings of the 10th Euromicro Conference on DigitalSystem Design Architectures, Methods and Tools,pages 543l546, 2007.

[11]M.Coppola, R.Locatelli, G.Maruccia, L.Pieralisi, andA.Scandurra. Networks on chip: A new paradigm forsystems on chip design. In System-on-Chip, 2004.Proceedings. 2004 International Symposium on, page15, 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 thenon-scalability of bus based SoCs. In 14th ACM GreatLakes symposium on VLSI, (GLSVLSI n04), pages192l195, April 2004.

[13] J. Balfour and W. J. Dally. Design tradeo s for tiledCMP on-chip networks. In ACM/IEEE (SCm05)Conf. Supercomputing, pages 187l198, 2006.

[14] P.P.Pande, C. Grecu, , M.Jones, A.Ivanov, andR.Saleh. Performance evaluation and design trade-

Fig.4. the 2nd view of the CMesh-noc

Fig.5. Concentrated Mesh NoC





5/5

o s 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 di erent andhow 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 andTest in Europe, February 2004.

[17]A. Jalabert, S. Murali, L. Benini, and G. De Micheli. xpipesCompiler: A tool for instantiating applicationspecific 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-es184l190, 2007.

[20] Rochit Rajsumman, "System-on-a-chip: Design andTest'', Artech House Publishers, 2000.

[21] Network Simulator (NS-2) web site: http://www-mash.cs.berkeley.edu/ns.




simulation the concentrated-noc: cmesh-noc and ctorus-noc

Documents