Research ArticleModeling and Simulation of Network-on-Chip Systems withDEVS and DEUS

Michele Amoretti

Centro Interdipartimentale SITEIAPARMA Universita degli Studi di Parma Parco Area delle Scienze 181a 43124 Parma Italy

Correspondence should be addressed to Michele Amoretti micheleamorettiuniprit

Received 30 August 2013 Accepted 13 February 2014 Published 17 April 2014

Academic Editors J Sarangapani and A Zaravinos

Copyright copy 2014 Michele Amoretti This is an open access article distributed under the Creative Commons Attribution Licensewhich permits unrestricted use distribution and reproduction in any medium provided the original work is properly cited

Networks on-chip (NoCs) provide enhanced performance scalability modularity and design productivity as compared withprevious communication architectures for VLSI systems on-chip (SoCs) such as buses and dedicated signal wires Since the NoCdesign space is very large and high dimensional evaluation methodologies rely heavily on analytical modeling and simulationUnfortunately there is no standardmodeling framework In this paper we illustrate how to design and evaluate NoCs by integratingthe Discrete Event System Specification (DEVS)modeling framework and the simulation environment called DEUSThe advantageof such an approach is that both DEVS and DEUS support modularitymdashthe former being a sound and complete modelingframework and the latter being an open general-purpose platform characterized by a steep learning curve and the possibilityto simulate any system at any level of detail

1 Introduction

Efficient on-chip communication is a primary factor inthe performance of large core-count systems Indeed theresearch community has directed substantial attention to net-works on-chip (NoCs) which use packet-switched networksfor communications within large VLSI systems on-chip(SoCs) [1] NoCs provide enhanced performance scalabil-ity modularity and design productivity as compared withprevious communication architectures such as buses anddedicated signal wires

In a NoC system modules like processor cores memo-ries and specialized IP blocks exchange data using a networkas a ldquopublic transportationrdquo subsystem for the informationtraffic A NoC is constructed from multiple point-to-pointdata links interconnected by switches such that messagescan be relayed from any source module to any destinationmodule over several links by making routing decisions at theswitches Such a definition based on switches is usually inter-preted so that a single shared bus a single router or a point-to-point networks are not NoCs but practically all othertopologies are A NoC is similar to a modern telecommu-nications network using digital bit-packet switching overmultiplexed links

TheNoC design space is very large and high dimensionalIt includes the optimization of topology routing mechanismcongestion control methodologies link capacities number ofbuffers and virtual channels per link and others Thus thereis an increasing need for effective tools for rapid performanceanalysis Current NoC evaluation methodologies rely heavilyon analytical modeling and simulation Unfortunately thereis no standard modeling framework Moreover the avail-able simulators use proprietary configuration languages arehardly portable and are usually not interoperable with othertools To cover the existing and future NoC diversities NoCsimulators should be more modular scalable extendible andfully parametric

To cope with these issues Ahmadinejad et al proposeda NoC model [2] based on the Discrete Event SystemSpecification (DEVS) [3] which is widely recognized asa sound and complete modeling framework with a largecommunity of researchers and practitioners Ahmadine-jad et al implemented their NoC model in DEVS-Suite(httpdevs-suitesimsourceforgenet) a parallel DEVS simu-lator with support for (i) automating design of experiments incombination with (ii) animating models and (iii) generatingdata trajectories at run-time Our approach is different as wechoose a general-purpose simulation environment namely

Hindawi Publishing Corporatione Scientific World JournalVolume 2014 Article ID 982569 9 pageshttpdxdoiorg1011552014982569

2 The Scientific World Journal

DEUS (httpcodegooglecompdeus) [4] we provided itwith DEVS support then we used it to simulate DEVS-basedNoCmodels DEUS is characterized by a steep learningcurve and the possibility to simulate highly dynamic complexsystemsmdashsuch as peer-to-peer networks markets virtualresources in data centers cellular automata and othersmdashat anany level of detail Moreover it is provided with a set of visualtools for the design configuration and analysis of parallelparametric simulationsThe advantage of using DEUS is thatit allows formemory-efficient dynamic reconfiguration of thesimulated model

The paper is organized as follows In Section 2 we presentthe state of the art in NoC simulation In Section 3 we recalltheDEVS formalism In Section 4 we summarize the featuresof the DEUS simulator focusing on the recently added DEVSsupport In Section 5 we illustrate an example of modularDEVS-based NoC model and its simulation with DEUSFinally in Section 6 we conclude the paper and also proposefuture work

2 State of the Art

Most NoC simulators are written in C++ or System C (asystem description language based on C++) while few ofthem are written in Java (which produces less efficient butmore portable codewith respect toC++ and SystemC)Noneof the simulation tools described in the followingmdashwhichare those that are currently developedmaintainedmdashused awidely accepted modeling framework for which it is almostimpossible to develop a model with one tool and then usedit with another tool

BookSim was initially developed by Dally andTowles for their seminal book about interconnectionnetworks [5] The current version (released in 2010) isBookSim 20 (httpnocsstanfordeducgi-bintraccgiwikiResourcesBookSim) which supports a wide range oftopologies such as mesh torus and flattened butterflynetworks provides diverse routing algorithms and includesseveral options for customizing the networkrsquos router micro-architecture BookSim is written in C++ and uses a LEXand YACC generated parser to process the configuration filethat must be passed to the simulator Each simulation hasthree basic phases warm-up measurement and drain Thelength of the warm-up andmeasurement phases is a multipleof a basic sample periodThe current latency and throughput(rate of accepted packets) for the simulation are printed aftereach sample periodThe overall throughput is determined bythe lowest throughput of all the destinations in the networkbut the average throughput is also displayed Most of thesimulatorrsquos components are designed to be modular so taskssuch as adding a new routing algorithm topology or routermicroarchitecture should not require a complete redesign ofthe code

TOPAZ (httpcodegooglecomptpzsimul) is ageneral-purpose interconnection network simulator whichallows modelling a wide variety of message routers (frombuffered crossbar to rotary router) with different trade-offsbetween speed and precision [6] The design of the tool is

object oriented and its implementation is in C++ languageIn TOPAZ each network is constructed hierarchically Thesimulator builds the network and the links (topology) thenthe network builds all the routers and finally the routersbuild its intrinsic components and interconnect them Eachsimulated structure is associated with two C++ classescomponents and flows The components are descriptivecharacterizing each structure and its relationship with theremaining components of the system The flows establishhow the stream of the information will move inside thecomponent As an example for a buffer structure thecomponent will determine its size number of ports or delaywhile the flow will determine its behavior according to theflow control selected During the running phase all systemcomponents are iteratively visited and all dependent flowsare simulated While TOPAZ is a time-driven simulationtool some flows can internally be constructed as finite statemachines making these components event driven Thesimulator supports parallel execution using standard POSIXthreads

The NOXIM simulator (httpnoximsourceforgenet)is developed using System C and provides a commandline interface for defining several parameters of a NoCIn particular the user can customize the network sizebuffer size packet size distribution routing algorithmselection strategy packet injection rate traffic time dis-tribution traffic pattern and hot-spot traffic distributionThe simulator allows NoC evaluation in terms of through-put delay and power consumption Such information isdelivered to the user both in terms of average and per-communication results In detail the user is allowed to collectdifferent evaluation metrics including the total number ofreceived packetsflits global average throughput maxminglobal delay total energy consumption per-communicationsdelaythroughputenergy and others [7]

NIRGAM (httpnirgamecssotonacuk) is a SystemC based discrete event cycle accurate NoC simulator Itprovides substantial support to experiment with NoC designin terms of routing algorithms and applications on varioustopologies NIRGAM models a NoC as a 2-dimensionalinterconnection of tiles Each tile consists of a core connectedto a routerswitch by a bidirectional core channel A tileis connected to neighbor tiles by bidirectional channelsConfigurable NoC parameters are the topology size (119898 times 119899)the clock frequency the buffer depth the flit size and thevirtual channels Currently supported routing algorithms areonly 119883119884 odd even and source

HNOCS (httphnocseewtechnionacil) is an opensource implementation of a NoC simulation frameworkusing OMNeT++ As an event driven simulation engineOMNeT++ provides C++ APIs to a rich set of servicesthat can be used to model configure describe the networktopology collect simulation data and perform analysis [8]HNOCS supports heterogeneous NoCs with variable linkcapacities and number of VCs per each unidirectional portHeterogeneous NoCs [9] offer better performance comparedto homogeneous NoCs since SoCs and CMPs are heteroge-neous in terms of module-to-module traffic requirements

The Scientific World Journal 3

Few simulators are specially designed for being exe-cuted on parallelmulticore architectures One of them isGraphite (httpgroupscsailmiteducarbonpage id=111)which provides high performance for fast design spaceexploration and software development Its high efficiency isbalanced by the lack of portability it is written in C++ butbasically it works only with Debian Linux HORNET(httpcsgcsailmiteduhornet) is also written in C++ andrequires the Boost C++ library and Python 25TheHORNETNoC system model is composed of a number of inter-connected tiles Each tile comprises a processing element(PE) which can be a MIPS CPU simulator or a script-driven injector or a Pin front-end a bridge that convertspackets to flits and finally the network switch node itselfSince each tile can be run in a separate thread intertilecommunication is synchronized using fine-grained locks Toavoid unnecessary synchronization each tile has a privateindependently initialized Mersenne Twister random numbergenerator and collects its own statistics at the end of thesimulation the per-tile statistics are collected and combinedinto whole-system statistics [10]

3 DEVS Modeling

DEVS [3] is a formalism which allows representing anysystemhaving a finite number of changes in a finite interval oftime In thatway systemsmodeled by PetriNets StateChartsEvent Graphs and even Difference Equations can be seen asparticular cases of DEVS models

In its most general definition a DEVS (atomic) model isa structure

119872 = ⟨119883 119878 119884 120575int 120575ext 120582 119905119886⟩ (1)

where

(i) 119883 is the set of input values(ii) 119878 is a set of states(iii) 119884 is the set of output values(iv) 120575int 119878 rarr 119878 is the internal transition function(v) 120575ext 119876 times 119883 rarr 119878 is the external transition function

where 119876 = (119904 119890) | 119904 isin 119878 0 le 119890 le 119905119886(119904) is the total

state set (119890 is the time elapsed since last transition)(vi) 120582 119878 rarr 119884 is the output function(vii) 119905

119886 119878 rarr R+ is the time for which the system stays in

state 119904 if no external event occurs

The external transition function dictates the systemrsquosnew state when an external event occurs Such a state isdetermined by the input (119909) the current state (119904) and howlong the system has been in that state (119890)

The input trajectory is a series of external events affectingthe system The state trajectory is affected by external eventsin 119883 but also by internal events The output trajectorydepicts the output events that are produced by the outputfunction just before applying the internal transition functionat internal events

JobProcessor

Job⟨X S Y 120575int 120575ext 120582 ta⟩

Figure 1 DEVS model of a processor

Functions 120575int 120575ext 120582 and 119905119886can be either deterministic

or stochasticFor example a simple DEVS model for a processor

(Figure 1) is the following

(i) 119883 = 119877

(ii) 119878 = ldquoidlerdquo ldquobusyrdquo times R+ times 119877

(iii) 119884 = 119877

(iv) 120575int(phase 120590 job) = (ldquoidlerdquo 120590 job)

(v)

120575ext (phase 120590 job 119890 119909)

=

(ldquobusyrdquo 119875119879119909 119909) if phase = ldquoidlerdquo

(ldquobusyrdquo 119875119879 job minus 119890 job) if phase = ldquobusyrdquo

(2)

(vi) 120582(ldquobusyrdquo 120590 job) = job

(vii) 119905119886(phase 120590 job) = 120590

where 119877 is the set of jobs the processor can receive andgenerate 120590 is the time the processor stays in one of thetwo possible phases that is ldquoidlerdquo or ldquobusyrdquo and 119875119879job isthe processing time needed to execute a job The internaltransition function is evaluated each time a job is done Theexternal transition function is evaluated each time a new jobis received by the processor If the processor is idle the newjob 119909 is acquired and executed for which the state of theprocessor changes to ldquobusyrdquo and the remaining time in suchstate 120590 is set to 119875119879

119909 If the processor is busy the incoming

job is discarded and the remaining time in current state isupdated to 119875119879job minus 119890

DEVS modeling is made easier with the introduction ofinput and output ports by re-defining 119883 and 119884 as follows

(i) 119883 = (119901 V) | 119901 isin InPorts V isin 119883in is the set of inputports and values

(ii) 119884 = (119901 V) | 119901 isin OutPorts V isin 119884out is the set ofoutput ports and values

DEVS coupled models are built from components that arespecified asDEVSmodelsThe specification ofDEVS coupledmodels in case of DEVS with ports is the following

119873 = ⟨119883 119884119863 119872119889119889 isin 119863 EICEOC IC Select⟩ (3)

4 The Scientific World Journal

EIC EOCICICP0 P1 P2

⟨X S Y 120575int 120575ext 120582 ta⟩ ⟨X S Y 120575int 120575ext 120582 ta⟩ ⟨X S Y 120575int 120575ext 120582 ta⟩

Figure 2 DEVS coupled model of a pipeline made by three processors in series

where(i) 119883 is the set of input ports and values(ii) 119884 is the set of output ports and values(iii) 119863 is the set of component names(iv) for each 119889 isin 119863 119872

119889is a DEVS model

(v) EIC is the external input coupling that connectsexternal inputs to component inputs

(vi) EOC is the external output coupling that connectscomponent outputs to external outputs

(vii) IC is the internal coupling that connects componentoutputs to component inputs

(viii) Select 2119863

minus rarr 119863 is the tie-breaking function(used to serialize imminent component actions)

In DEVS coupled models no direct feedback is allowedAs an example we construct a simple DEVS coupled

model by placing three processors in series to form a pipeline(Figure 2) The formal specification is as follows

(i) InPorts = ldquoinrdquo(ii) 119883in = 119877(iii) 119883 = (ldquoinrdquo V) | V isin 119877(iv) OutPorts = ldquooutrdquo(v) 119884out = 119877(vi) 119884 = (ldquooutrdquo V) | V isin 119877(vii) 119863 = 1198750 1198751 1198752(viii) 119872

0= 1198721= 1198722= 119872

(ix) EIC = [(119873 ldquoinrdquo) (1198750 ldquoinrdquo)](x) EOC = [(1198752 ldquooutrdquo) (119873 ldquooutrdquo)](xi) IC = [(1198750 ldquooutrdquo) (1198751 ldquoinrdquo)] [(1198751 ldquooutrdquo)

(1198752 ldquoinrdquo)](xii) Select = 120575int firstThe Select rule is important in the case of coupled

processors having imminent outputs For example if 1198750 and1198751 generate output at the same time there are two possiblechoices for 1198751 (a) to apply 120575int which would allow acceptingthe input coming from 1198750 or (b) to apply 120575ext first whichwould result in discarding the input because of ldquobusyrdquo stateIn this example model the 119878119890119897119890119888119905 function dictates that thefunction to be applied first is 120575int

An important subset of DEVS coupled models is consti-tuted by parallelDEVS coupledmodels [3]TheparallelDEVSspecification allows multiple ports to receive values at thesame time without the need of the Select

4 Simulation of DEVS Models with DEUS

Discrete event simulation works by maintaining a list ofevents sorted by their scheduling times Executing eventsresults in new events being scheduled and inserted into theevent list aswell as events being deleted and removed from theevent list A problem that arises in discrete event simulationis that of simultaneous events for which different orderings ofactivation result in different evolutions of the simulationTheapproach employed by most simulation packages is to definea priority among the components Zeigler et al defined ahierarchical simulator for hierarchicalDEVS coupledmodelsconsisting of devs-simulators and devs-coordinators [3]Shortly each DEVS atomic model is simulated by a devs-simulator and each DEVS coupled model is simulated bya devs-coordinator which manages the simulators of thesubcomponents As these can be themselves DEVS coupledmodels a devs-coordinator is able to manage also devs-coordinators

The general-purpose simulation tool called DEUS [4]follows a different approach (Although their names suggesta connection between them DEVS and DEUS are completelyindependent) Its Java API allows developers to implement(by subclassing) (i) nodes that is the entities which interactin a complex system leading to emergent behaviors suchas humans pets cells robots or intelligent agents [11 12](ii) events for example node births and deaths interactionsamong nodes interactionswith the environment logs and soon and (iii) processes either stochastic or deterministic onesconstraining the timeliness of events

DEUS has been designed having in mind the three basicconcepts listed above and no specific modeling tool at allNevertheless it is possible to map DEUS concepts to DEVSonesmdashfor example a DEUS node can be the implementationof a DEVS model

Once specific Java classes have been implemented it ispossible to configure a simulation with the DEUS graphicaluser interface which includes the following

(i) the Visual Editor for the generation of XML docu-ments describing the simulations

(ii) the Automator for the execution of parametric simu-lations and the automatic generation of statistics (in aGnuplot-compliant format)

Last but not least DEUS supports parallel (multicore andordistributed) simulations [13]

Figure 3 illustrates how DEUS simulation models interms of XML configuration files and Java code are created

The Scientific World Journal 5

DEVS modeldefinition and

codingDEUSvisualeditor

XMLconfig

file

log

files

Control

Results

DEUS

DEUS

engine

simulationcode

DEUSautomator

Figure 3 Discrete event simulation with DEUS driven by DEVSmodels

(using also a Visual Editor) and then executed by means oftheAutomator and the EngineThe former allows performingsensitivity analysis by setting ranges for node and processparameters The Engine is the core of DEUS managing theevent queue and the simulation loop

A node represents a dynamic system characterized bya set of possible states whose transition functions maybe implemented either in the source code of the eventsassociated with the node or in the source code of the nodeitself Multiscale modeling of complex systems is achievedby means of connected heterogeneous nodes DEUS comeswith a library of predefined common processes andmany others can be implemented by the user Recently weadded DEVS support by means of a new package whichincludes the general-purpose classesDevsAtomicModel

andDevsCoupledModel both implementing theDevsModel

interface (see Figure 4) In next section we describe amodular DEVS-based NoC model and its simulation withDEUS

5 NoC Example

We considered a NoC system consisting of amesh of switchesand resources (ie processor cores ormemory blocks) whichare placed on slots formed by the switches like the onedescribed by Sun et al [14] and sketched in Figure 5 Wemodeled resources and switches and the whole NoC usingDEVS coupled modelsThemesh is an119898times119899 grid of switcheseach one being connected either to a core or to a memoryblock For simplicity resources are alternatedmdashthat is core -memory block - core - and so forthmdashon both axes

A switch is modeled as a DEVS model with input andoutput ports which are coupled respectively with output andinput ports of other switches or resources As illustrated in

DevsModel

DevsAtomicModel DevsCoupledModel

SpecializedAtomicModule SpecializedCoupledModule

A inherits from B

A contains B

B

A

A

B

Figure 4 Class diagram of the package for DEVS support in DEUSwe recently introduced

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Core Core

Core Core

Core Core

Figure 5 Example NoC consisting of a mesh of switches andresources (cores and memory blocks)

Figure 6 the switch itself is a DEVS coupled model made oftwo DEVS atomic models one representing a queue and theother representing the system that implements the switchinglogic To model their interaction we use the followingstrategy When the switching logic completes a job (iedecides the destination of a message and forwards it) it doessend a ldquonext-msgrdquo input to the queue to make the latterprovide a new message The DEVS model of the queue isdefined as follows

(i) 119883 = 1198771015840

(ii) 119878 = ldquoemptyrdquo ldquo1rdquo ldquo119870rdquo times R+ times 119877

(iii) 119884 = 119877

(iv) there is no 120575int as the queue is a passive module

6 The Scientific World Journal

Msg

Switch

Queueldquonext-msgrdquo

Switchinglogic

Msg

New msgfrom queueldquoidlerdquoldquoemptyrdquo

ldquo1rdquo

ldquo2rdquo

ldquo3rdquoldquoKrdquo

Q[0]

ldquobusyrdquoOutput msg andldquonext-msgrdquo to the queue

middot middot middot

Figure 6 DEVSmodels of the switch in the proposedNoC example

(v)

120575ext (phase 120590msg 119890 119909)

=

(ldquo1rdquo 120590 119909 119909)if phase = ldquoidlerdquo 119909 = ldquonext-msgrdquo

(ldquo119894 + 1rdquo 120590msg)if phase = ldquo119894rdquo 119894 isin [1 119870 minus 1] 119909 = ldquonext-msgrdquo

(phase 120590 minus 119890msg)if phase = ldquo119870rdquo 119909 = ldquonext-msgrdquo

(ldquo119894 minus 1rdquo 120590msg)if phase = ldquo119894rdquo 119894 isin [2 119870] 119909 = ldquonext-msgrdquo

(ldquoidlerdquo 120590 120601)if phase isin ldquo1rdquo ldquoidlerdquo 119909 = ldquonext-msgrdquo

(4)

(vi) 120582(phase 120590msg) = 120601 if phasE= ldquoidlerdquo

msg if phase = ldquoidlerdquo

(vii) 119905119886(phase 120590msg) = 120590

where 119877 = ldquoget-datardquo ldquoput-datardquo ldquostore-datardquo is the set ofmessages that can be generated by core and memories 1198771015840 =119877cupldquonext-msgrdquo and119870 is themaximumnumber ofmessagesthat can be enqueued The output message is the one storedat the head of the queue If the queue is empty there is nooutputmdashwe use 120601 to represent the output in this case

The core and the switching logic system are modeled asthe processor illustrated in Section 3The switching logic sys-tem receives incoming messages and routes them accordingto the 119883119884 routing strategy [15]mdashfirst in 119909- or horizontal-direction to the correct column and then in 119910- or verticaldirection to the destination switch In general any specificswitching algorithm can be ldquopluggedrdquo into the model

The memory block illustrated in Figure 7 is modeled asfollows

(i) 119883 = 119877 times 119860(ii) 119878 = ldquoidlerdquo ldquo119882rdquo ldquo119877rdquo times R+ times 119877(iii) 119884 = 119872[119886] forall119886 isin 119860(iv) there is no 120575int as the memory block is a passive

module

Commandaddress OutputMemory

block

Read datagiven the address

Readcompleted

New datato be written

ldquoRrdquo

ldquoidlerdquo

ldquoWrdquoWrite

completed

Figure 7 DEVS models of the memory block in the proposed NoCexample

(v)

120575ext (phase 120590 data 119890 address command)

=

(phase 120590 minus 119890 data)if phase = ldquoidlerdquo

(ldquo119877rdquo 119875119879read 119872 [address])if phase = ldquoidlerdquo command = ldquoreadrdquo

(ldquo119882rdquo 119875119879write 120601)

if phase = ldquoidlerdquo command = ldquowriterdquo

(5)

(vi) 120582(phase 120590 output) = 120601 if phase = ldquo119877rdquo

output if phase=ldquo119877rdquo

(vii) 119905119886(phase 120590 output) = 120590

where 119877 = ldquoreadrdquo ldquowriterdquo is the set of commands thememory block can handle 119860 is the set of addresses and 120601

means no outputTo perform DEUS-based simulation we mapped

the DEVS models to the following Java classesCore MemoryBlock Switch (composed by Queue andSwitchingLogic) Mesh The class diagram in Figure 8illustrates the relations between such classes the basicclasses DevsAtomicModel andDevsCoupledModel andtheDevsModel interface In the diagram shaded classes arethose provided by the devs package we recently added toDEUS

According to the DEUS approach it is not necessaryto explicitly model links among network nodes Parameterslike link delay and maximal bandwidth can be embeddedeither in the Java classes representing the resources or in thescheduling processes of events that describe the internodecommunications (ie packet delivery) For this example weadopted the former approach

The Scientific World Journal 7

DevsModel

DevsAtomicModel DevsCoupledModel

Queue Switching Switchlogic Core MeshMemoryblock

A inherits from B

A contains B

B

A

A

B

Figure 8 Class diagram illustrating the DEVS-to-DEUS mappingfor the proposed NoC example

In detail we defined a specific recv( ) method in everyclass implementing a DEVS model Such a method imple-ments the logic described by the 120575ext and 120582 functions For thecore the recv( ) method handles the following messages

(i) ldquoput-datardquo the core enters the ldquobusyrdquo state and sendsa ldquofinish-procrdquo message to itself to be received whenthe processing phase is completed (this is just a trickto exit the ldquobusyrdquo state)

(ii) ldquofinish-procrdquo the core enters the ldquoidlerdquo state andsends a ldquostore-datardquo message to a randomly selectedmemory block with a random double isin [0 1] as apayload

For thememory block the recv( )method handles the follow-ing messages

(i) ldquoget-datardquo the memory block sends a ldquoput-datardquomessage to the core that issued the ldquoget-datardquomessagewith the mean of its stored values as a payload

(ii) ldquostore-datardquo the memory stores the payload of themessage if the memory is full the less recent valueis discarded to make room for the new one

The recv( ) method of the switch passes the message to thesame method of the queue instance where the message isstored if there is roommdashotherwise it is dropped After adelay which depends on the state of the queue (ie on thelength of the queue) and on the service rate of the switchinglogic themessage is passed to the switching logic itself whichcomputes the next hopmdashit may be another switch or thecorememory block connected to the current switchThe totaldelay for a message to pass through a switch and be deliveredto the next module is given by the sum of the followingcomponents

(i) time spent in the queue(ii) time for computing the next hop(iii) transmission time

Table 1 Experiment configuration

Number of rows 119898 = 4

Number of columns 119899 = 4

Transmission delay Exponential with mean value 1 nsSwitching logic delay Exponential with mean value 5 nsMax queue length 119870 = 3 5 7 Memory block size 119878 = 100

Memory block processingtime Uniform with max value 100 ns

Core processing time Uniform with max value 10 ns

Task interarrival time Exponential with mean value120583 = 2 4 6 ns

Then we defined a SendMessageEvent class whose run( )method just calls the appropriate recv( ) on the messagedestination Instances of SendMessageEvent are generated asa consequence of a ldquonew taskrdquo event (see below for details) orduring amessage propagation process which always involvesa couple of modules (with one exception discussed below)

For eachNewTaskEvent an idle core is randomlyselected to start a ldquoget-datardquo message propagation (as illus-trated in Figure 9 where involved modules are uniformlyshaded and arrows show the information flow) Once thedestination memory block has been reached the latter mod-ule starts ldquoput-datardquo message propagation towards the corewhich started it all When such a core receives the ldquoput-datardquo message it enters the ldquobusyrdquo state The processing taskends with a SendMessageEvent the core schedules on itself(according to its 120575int function) to enter to ldquoidlerdquo state and senda ldquodata-storerdquo message to a randomly chosen memory blockOf course any other interaction scheme could have beenimplemented

In general such a DEVS+DEUS model and simulationallows evaluating different routing strategies (either static ordynamic) and queuemanagementmechanisms implementedin the switches Example parameters we may consider in thiscontext are the communication load (a measure of averagetraffic in the network) the packet delay [14] and the averagethroughput of switches

To measure variables over the simulated virtual timespecific logging events as well as visualization eventsmust beimplemented and periodically scheduled For this examplewe implemented aLogNetworkStatsEvent which computesperformance indices such as the the Hit Ratio that is thenumber of completed tasks versus the number of issued ones

Table 1 illustrates the configuration of the simulations weexecutedmdashwith 10 runs each one being characterized by adifferent seed for the random number generator

The task interarrival time is such that on the average eachcore starts a new task every 120583 sdot8 ge 16 ns which is higher thanthe core processing time This is a reasonable configurationbut it is not sufficient to guarantee a 100Hit Ratio which isinfluenced by several factorsmdashsuch as the max queue length119870 the size of the mesh and the delays of the switches andmemory blocks For a simulated system lifetime of 100ms

8 The Scientific World Journal

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Core Core

Core Core

Core Core

(a) ldquoGet-datardquo

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Core Core

Core Core

Core Core

(b) ldquoPut-datardquo

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Core Core

Core Core

Core Core

(c) Processing

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Core Core

Core Core

Core Core

(d) ldquoData-storerdquo

Figure 9 An example of the simulated interaction scenario started by aNewTaskEvent For each phase involved modules are uniformlyshaded and arrows show the information flow

we obtained the results illustrated in Figure 10 where the HitRatio is shown as a function of 120583 and 119870 Simulation timeranges from few seconds (when120583 gt 20) to fewminutes (when120583 lt 10) on a MacBook Pro with 24GHz Intel Core 2 Duoand 4GB 1066MHz DD3 RAM

6 Conclusions

In this paper we have illustrated how to model NoCs bymeans of the DEVS formalism and to simulate such modelswith the DEUS simulation tool The proposed approach hastwomain advantages First DEVS and its dialects allowmod-elling almost any scenario including concurrent executions

Second the DEUS simulation environment is portable effi-cient providedwith useful tools for the rapid configuration ofhighly automated simulationsThe combination of DEVS andDEUS allows studying NoCs models with the desired levelof detail and efficiently comparing different configurations ofparameters

Regarding future work we plan to implement and shareother NoC models and simulations with different networktopologies and routing algorithms Moreover we are inter-ested in defining DEVS models of NoCs with Quality ofService (QoS) constraints and using DEUS to check whethersuch constraints are respected QoS refers to the levels ofguarantees given for data transfers Guarantees are relatedto timing (min throughput max latency and max latency

The Scientific World Journal 9

0

20

40

60

80

100

0 10 20 30 40 50

HR

120583

K = 3

k = 7

(a)

0

20

40

60

80

100

2 3 4 5 6 7 8

HR

K

120583 = 2

120583 = 6

120583 = 20

(b)

Figure 10 Hit Ratio as a function of 120583 (a) and 119870 (b)

jitter) integrity (max error rate and max packet loss) andpacket delivery (in-order or out- of-order)

Conflict of Interests

The author declares that there is no conflict of interestsregarding the publication of this paper

References

[1] L Benini and G de Micheli ldquoNetworks on chips a new SoCparadigmrdquo Computer vol 35 no 1 pp 70ndash78 2002

[2] H Ahmadinejad F Refan and H S Sarjoughian ldquoNoC simu-lation modeling in DEVS-suiterdquo in Proceedings of Symposiumon Theory of Modeling amp Simulation DEVS Integrative MampSSymposium (TMS-DEVS rsquo11) Boston Mass USA April 2011

[3] B P Zeigler H Praehofer and T G Kim Theory of Modelingand Simulation Academic Press Orlando Fla USA 2ndedition 2000

[4] M Amoretti M Picone F Zanichelli and G Ferrari ldquoSim-ulating mobile and distributed systems with DEUS and ns-3rdquoin Proceedings of International Conference on High PerformanceComputing and Simulation (HPCS 2013) pp 107ndash114 HelsinkiFinland July 2013

[5] W J Dally and B Towles Principles and Practices of Interconnec-tion NetWorks Morgan Kaufmann San Francisco Calif USA2003

[6] P Abad P Prieto L Menezo A Colaso V Puente and J AGregorio ldquoTOPAZ an open-source interconnection networksimulator for chip multiprocessors and supercomputersrdquo inProceedings of 6th IEEEACM International Symposium onNetworks on Chip (NoCS rsquo12) pp 99ndash106 Lyngby DenmarkMay 2012

[7] G Ascia V Catania M Palesi and D Patti ldquoImplementationand analysis of a new selection strategy for adaptive routing innetworks-on-chiprdquo IEEETransactions on Computers vol 57 no6 pp 809ndash820 2008

[8] Y Ben-Itzhak E Zahavi I Cidon and A Kolodny ldquoHNOCSmodular open-source simulator for heterogeneous NoCsrdquo inProceedings of the SAMOS International Conference on Embed-ded Computer Systems Architectures Modeling and Simulationpp 51ndash57 Samos Island Greece July 2012

[9] M Kreutz C A Marcon L Carro F Wagner and A ASusin ldquoDesign space exploration comparing homogeneous andheterogeneous network-on-chip architecturesrdquo in Proceedingsof the 18th ACM Symposium on Integrated Circuits and SystemsDesign pp 190ndash195 Florianopolis Brazil September 2005

[10] M Lis P Ren M H Cho et al ldquoScalable accurate multicoresimulation in the 1000-core erardquo in Proceedings of the IEEEInternational Symposium on Performance Analysis of Systemsand Software (ISPASS rsquo11) pp 175ndash185 Austin Tex USA April2011

[11] M Amoretti ldquoAmodeling framework for unstructured supern-ode networksrdquo IEEE Communications Letters vol 16 no 10 pp1707ndash1710 2012

[12] M Picone M Amoretti and F Zanichelli ldquoEvaluating therobustness of the DGT approach for smartphone-based vehicu-lar networksrdquo inProceedings of the 36thAnnual IEEEConferenceon Local Computer Networks (LCN rsquo11) pp 820ndash826 BonnGermany October 2011

[13] M Amoretti M Picone S Bonelli and F Zanichelli ldquoParallelamp distributed simulation with DEUSrdquo in Proceedings of theInternational Conference on High Performance Computing andSimulation (HPCS rsquo11) pp 600ndash606 Istanbul Turkey July 2011

[14] Y R Sun S Kumar and A Jantsch ldquoSimulation and evaluationof a network on chip architecture using ns-2rdquo in Proceedings ofthe IEEE NorChip Conference Copenhagen Denmark Novem-ber 2002

[15] M Dehyadgari M Nickray A Afzali-Kusha and Z NavabildquoEvaluation of pseudo adaptive XY routing using an objectoriented model for NOCrdquo in Proceedings of the 17th 2005International Conference onMicroelectronics (ICM rsquo05) pp 204ndash208 Islamabad Pakistan December 2005

Submit your manuscripts athttpwwwhindawicom

Computer Games Technology

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Distributed Sensor Networks

International Journal of

Advances in

FuzzySystems

Hindawi Publishing Corporationhttpwwwhindawicom

Volume 2014

International Journal of

ReconfigurableComputing

Hindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Applied Computational Intelligence and Soft Computing

thinspAdvancesthinspinthinsp

Artificial Intelligence

HindawithinspPublishingthinspCorporationhttpwwwhindawicom Volumethinsp2014

Advances inSoftware EngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Electrical and Computer Engineering

Journal of

Journal of

Computer Networks and Communications

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporation

httpwwwhindawicom Volume 2014

Advances in

Multimedia

International Journal of

Biomedical Imaging

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

ArtificialNeural Systems

Advances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

RoboticsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Computational Intelligence and Neuroscience

Industrial EngineeringJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Human-ComputerInteraction

Advances in

Computer EngineeringAdvances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

2 The Scientific World Journal

DEUS (httpcodegooglecompdeus) [4] we provided itwith DEVS support then we used it to simulate DEVS-basedNoCmodels DEUS is characterized by a steep learningcurve and the possibility to simulate highly dynamic complexsystemsmdashsuch as peer-to-peer networks markets virtualresources in data centers cellular automata and othersmdashat anany level of detail Moreover it is provided with a set of visualtools for the design configuration and analysis of parallelparametric simulationsThe advantage of using DEUS is thatit allows formemory-efficient dynamic reconfiguration of thesimulated model

The paper is organized as follows In Section 2 we presentthe state of the art in NoC simulation In Section 3 we recalltheDEVS formalism In Section 4 we summarize the featuresof the DEUS simulator focusing on the recently added DEVSsupport In Section 5 we illustrate an example of modularDEVS-based NoC model and its simulation with DEUSFinally in Section 6 we conclude the paper and also proposefuture work

2 State of the Art

Most NoC simulators are written in C++ or System C (asystem description language based on C++) while few ofthem are written in Java (which produces less efficient butmore portable codewith respect toC++ and SystemC)Noneof the simulation tools described in the followingmdashwhichare those that are currently developedmaintainedmdashused awidely accepted modeling framework for which it is almostimpossible to develop a model with one tool and then usedit with another tool

BookSim was initially developed by Dally andTowles for their seminal book about interconnectionnetworks [5] The current version (released in 2010) isBookSim 20 (httpnocsstanfordeducgi-bintraccgiwikiResourcesBookSim) which supports a wide range oftopologies such as mesh torus and flattened butterflynetworks provides diverse routing algorithms and includesseveral options for customizing the networkrsquos router micro-architecture BookSim is written in C++ and uses a LEXand YACC generated parser to process the configuration filethat must be passed to the simulator Each simulation hasthree basic phases warm-up measurement and drain Thelength of the warm-up andmeasurement phases is a multipleof a basic sample periodThe current latency and throughput(rate of accepted packets) for the simulation are printed aftereach sample periodThe overall throughput is determined bythe lowest throughput of all the destinations in the networkbut the average throughput is also displayed Most of thesimulatorrsquos components are designed to be modular so taskssuch as adding a new routing algorithm topology or routermicroarchitecture should not require a complete redesign ofthe code

TOPAZ (httpcodegooglecomptpzsimul) is ageneral-purpose interconnection network simulator whichallows modelling a wide variety of message routers (frombuffered crossbar to rotary router) with different trade-offsbetween speed and precision [6] The design of the tool is

object oriented and its implementation is in C++ languageIn TOPAZ each network is constructed hierarchically Thesimulator builds the network and the links (topology) thenthe network builds all the routers and finally the routersbuild its intrinsic components and interconnect them Eachsimulated structure is associated with two C++ classescomponents and flows The components are descriptivecharacterizing each structure and its relationship with theremaining components of the system The flows establishhow the stream of the information will move inside thecomponent As an example for a buffer structure thecomponent will determine its size number of ports or delaywhile the flow will determine its behavior according to theflow control selected During the running phase all systemcomponents are iteratively visited and all dependent flowsare simulated While TOPAZ is a time-driven simulationtool some flows can internally be constructed as finite statemachines making these components event driven Thesimulator supports parallel execution using standard POSIXthreads

The NOXIM simulator (httpnoximsourceforgenet)is developed using System C and provides a commandline interface for defining several parameters of a NoCIn particular the user can customize the network sizebuffer size packet size distribution routing algorithmselection strategy packet injection rate traffic time dis-tribution traffic pattern and hot-spot traffic distributionThe simulator allows NoC evaluation in terms of through-put delay and power consumption Such information isdelivered to the user both in terms of average and per-communication results In detail the user is allowed to collectdifferent evaluation metrics including the total number ofreceived packetsflits global average throughput maxminglobal delay total energy consumption per-communicationsdelaythroughputenergy and others [7]

NIRGAM (httpnirgamecssotonacuk) is a SystemC based discrete event cycle accurate NoC simulator Itprovides substantial support to experiment with NoC designin terms of routing algorithms and applications on varioustopologies NIRGAM models a NoC as a 2-dimensionalinterconnection of tiles Each tile consists of a core connectedto a routerswitch by a bidirectional core channel A tileis connected to neighbor tiles by bidirectional channelsConfigurable NoC parameters are the topology size (119898 times 119899)the clock frequency the buffer depth the flit size and thevirtual channels Currently supported routing algorithms areonly 119883119884 odd even and source

HNOCS (httphnocseewtechnionacil) is an opensource implementation of a NoC simulation frameworkusing OMNeT++ As an event driven simulation engineOMNeT++ provides C++ APIs to a rich set of servicesthat can be used to model configure describe the networktopology collect simulation data and perform analysis [8]HNOCS supports heterogeneous NoCs with variable linkcapacities and number of VCs per each unidirectional portHeterogeneous NoCs [9] offer better performance comparedto homogeneous NoCs since SoCs and CMPs are heteroge-neous in terms of module-to-module traffic requirements

The Scientific World Journal 3

Few simulators are specially designed for being exe-cuted on parallelmulticore architectures One of them isGraphite (httpgroupscsailmiteducarbonpage id=111)which provides high performance for fast design spaceexploration and software development Its high efficiency isbalanced by the lack of portability it is written in C++ butbasically it works only with Debian Linux HORNET(httpcsgcsailmiteduhornet) is also written in C++ andrequires the Boost C++ library and Python 25TheHORNETNoC system model is composed of a number of inter-connected tiles Each tile comprises a processing element(PE) which can be a MIPS CPU simulator or a script-driven injector or a Pin front-end a bridge that convertspackets to flits and finally the network switch node itselfSince each tile can be run in a separate thread intertilecommunication is synchronized using fine-grained locks Toavoid unnecessary synchronization each tile has a privateindependently initialized Mersenne Twister random numbergenerator and collects its own statistics at the end of thesimulation the per-tile statistics are collected and combinedinto whole-system statistics [10]

3 DEVS Modeling

DEVS [3] is a formalism which allows representing anysystemhaving a finite number of changes in a finite interval oftime In thatway systemsmodeled by PetriNets StateChartsEvent Graphs and even Difference Equations can be seen asparticular cases of DEVS models

In its most general definition a DEVS (atomic) model isa structure

119872 = ⟨119883 119878 119884 120575int 120575ext 120582 119905119886⟩ (1)

where

(i) 119883 is the set of input values(ii) 119878 is a set of states(iii) 119884 is the set of output values(iv) 120575int 119878 rarr 119878 is the internal transition function(v) 120575ext 119876 times 119883 rarr 119878 is the external transition function

where 119876 = (119904 119890) | 119904 isin 119878 0 le 119890 le 119905119886(119904) is the total

state set (119890 is the time elapsed since last transition)(vi) 120582 119878 rarr 119884 is the output function(vii) 119905

119886 119878 rarr R+ is the time for which the system stays in

state 119904 if no external event occurs

The external transition function dictates the systemrsquosnew state when an external event occurs Such a state isdetermined by the input (119909) the current state (119904) and howlong the system has been in that state (119890)

The input trajectory is a series of external events affectingthe system The state trajectory is affected by external eventsin 119883 but also by internal events The output trajectorydepicts the output events that are produced by the outputfunction just before applying the internal transition functionat internal events

JobProcessor

Job⟨X S Y 120575int 120575ext 120582 ta⟩

Figure 1 DEVS model of a processor

Functions 120575int 120575ext 120582 and 119905119886can be either deterministic

or stochasticFor example a simple DEVS model for a processor

(Figure 1) is the following

(i) 119883 = 119877

(ii) 119878 = ldquoidlerdquo ldquobusyrdquo times R+ times 119877

(iii) 119884 = 119877

(iv) 120575int(phase 120590 job) = (ldquoidlerdquo 120590 job)

(v)

120575ext (phase 120590 job 119890 119909)

=

(ldquobusyrdquo 119875119879119909 119909) if phase = ldquoidlerdquo

(ldquobusyrdquo 119875119879 job minus 119890 job) if phase = ldquobusyrdquo

(2)

(vi) 120582(ldquobusyrdquo 120590 job) = job

(vii) 119905119886(phase 120590 job) = 120590

where 119877 is the set of jobs the processor can receive andgenerate 120590 is the time the processor stays in one of thetwo possible phases that is ldquoidlerdquo or ldquobusyrdquo and 119875119879job isthe processing time needed to execute a job The internaltransition function is evaluated each time a job is done Theexternal transition function is evaluated each time a new jobis received by the processor If the processor is idle the newjob 119909 is acquired and executed for which the state of theprocessor changes to ldquobusyrdquo and the remaining time in suchstate 120590 is set to 119875119879

119909 If the processor is busy the incoming

job is discarded and the remaining time in current state isupdated to 119875119879job minus 119890

DEVS modeling is made easier with the introduction ofinput and output ports by re-defining 119883 and 119884 as follows

(i) 119883 = (119901 V) | 119901 isin InPorts V isin 119883in is the set of inputports and values

(ii) 119884 = (119901 V) | 119901 isin OutPorts V isin 119884out is the set ofoutput ports and values

DEVS coupled models are built from components that arespecified asDEVSmodelsThe specification ofDEVS coupledmodels in case of DEVS with ports is the following

119873 = ⟨119883 119884119863 119872119889119889 isin 119863 EICEOC IC Select⟩ (3)

4 The Scientific World Journal

EIC EOCICICP0 P1 P2

⟨X S Y 120575int 120575ext 120582 ta⟩ ⟨X S Y 120575int 120575ext 120582 ta⟩ ⟨X S Y 120575int 120575ext 120582 ta⟩

Figure 2 DEVS coupled model of a pipeline made by three processors in series

where(i) 119883 is the set of input ports and values(ii) 119884 is the set of output ports and values(iii) 119863 is the set of component names(iv) for each 119889 isin 119863 119872

119889is a DEVS model

(v) EIC is the external input coupling that connectsexternal inputs to component inputs

(vi) EOC is the external output coupling that connectscomponent outputs to external outputs

(vii) IC is the internal coupling that connects componentoutputs to component inputs

(viii) Select 2119863

minus rarr 119863 is the tie-breaking function(used to serialize imminent component actions)

In DEVS coupled models no direct feedback is allowedAs an example we construct a simple DEVS coupled

model by placing three processors in series to form a pipeline(Figure 2) The formal specification is as follows

(i) InPorts = ldquoinrdquo(ii) 119883in = 119877(iii) 119883 = (ldquoinrdquo V) | V isin 119877(iv) OutPorts = ldquooutrdquo(v) 119884out = 119877(vi) 119884 = (ldquooutrdquo V) | V isin 119877(vii) 119863 = 1198750 1198751 1198752(viii) 119872

0= 1198721= 1198722= 119872

(ix) EIC = [(119873 ldquoinrdquo) (1198750 ldquoinrdquo)](x) EOC = [(1198752 ldquooutrdquo) (119873 ldquooutrdquo)](xi) IC = [(1198750 ldquooutrdquo) (1198751 ldquoinrdquo)] [(1198751 ldquooutrdquo)

(1198752 ldquoinrdquo)](xii) Select = 120575int firstThe Select rule is important in the case of coupled

processors having imminent outputs For example if 1198750 and1198751 generate output at the same time there are two possiblechoices for 1198751 (a) to apply 120575int which would allow acceptingthe input coming from 1198750 or (b) to apply 120575ext first whichwould result in discarding the input because of ldquobusyrdquo stateIn this example model the 119878119890119897119890119888119905 function dictates that thefunction to be applied first is 120575int

An important subset of DEVS coupled models is consti-tuted by parallelDEVS coupledmodels [3]TheparallelDEVSspecification allows multiple ports to receive values at thesame time without the need of the Select

4 Simulation of DEVS Models with DEUS

Discrete event simulation works by maintaining a list ofevents sorted by their scheduling times Executing eventsresults in new events being scheduled and inserted into theevent list aswell as events being deleted and removed from theevent list A problem that arises in discrete event simulationis that of simultaneous events for which different orderings ofactivation result in different evolutions of the simulationTheapproach employed by most simulation packages is to definea priority among the components Zeigler et al defined ahierarchical simulator for hierarchicalDEVS coupledmodelsconsisting of devs-simulators and devs-coordinators [3]Shortly each DEVS atomic model is simulated by a devs-simulator and each DEVS coupled model is simulated bya devs-coordinator which manages the simulators of thesubcomponents As these can be themselves DEVS coupledmodels a devs-coordinator is able to manage also devs-coordinators

The general-purpose simulation tool called DEUS [4]follows a different approach (Although their names suggesta connection between them DEVS and DEUS are completelyindependent) Its Java API allows developers to implement(by subclassing) (i) nodes that is the entities which interactin a complex system leading to emergent behaviors suchas humans pets cells robots or intelligent agents [11 12](ii) events for example node births and deaths interactionsamong nodes interactionswith the environment logs and soon and (iii) processes either stochastic or deterministic onesconstraining the timeliness of events

DEUS has been designed having in mind the three basicconcepts listed above and no specific modeling tool at allNevertheless it is possible to map DEUS concepts to DEVSonesmdashfor example a DEUS node can be the implementationof a DEVS model

Once specific Java classes have been implemented it ispossible to configure a simulation with the DEUS graphicaluser interface which includes the following

(i) the Visual Editor for the generation of XML docu-ments describing the simulations

(ii) the Automator for the execution of parametric simu-lations and the automatic generation of statistics (in aGnuplot-compliant format)

Last but not least DEUS supports parallel (multicore andordistributed) simulations [13]

Figure 3 illustrates how DEUS simulation models interms of XML configuration files and Java code are created

The Scientific World Journal 5

DEVS modeldefinition and

codingDEUSvisualeditor

XMLconfig

file

log

files

Control

Results

DEUS

DEUS

engine

simulationcode

DEUSautomator

Figure 3 Discrete event simulation with DEUS driven by DEVSmodels

(using also a Visual Editor) and then executed by means oftheAutomator and the EngineThe former allows performingsensitivity analysis by setting ranges for node and processparameters The Engine is the core of DEUS managing theevent queue and the simulation loop

A node represents a dynamic system characterized bya set of possible states whose transition functions maybe implemented either in the source code of the eventsassociated with the node or in the source code of the nodeitself Multiscale modeling of complex systems is achievedby means of connected heterogeneous nodes DEUS comeswith a library of predefined common processes andmany others can be implemented by the user Recently weadded DEVS support by means of a new package whichincludes the general-purpose classesDevsAtomicModel

andDevsCoupledModel both implementing theDevsModel

interface (see Figure 4) In next section we describe amodular DEVS-based NoC model and its simulation withDEUS

5 NoC Example

We considered a NoC system consisting of amesh of switchesand resources (ie processor cores ormemory blocks) whichare placed on slots formed by the switches like the onedescribed by Sun et al [14] and sketched in Figure 5 Wemodeled resources and switches and the whole NoC usingDEVS coupled modelsThemesh is an119898times119899 grid of switcheseach one being connected either to a core or to a memoryblock For simplicity resources are alternatedmdashthat is core -memory block - core - and so forthmdashon both axes

A switch is modeled as a DEVS model with input andoutput ports which are coupled respectively with output andinput ports of other switches or resources As illustrated in

DevsModel

DevsAtomicModel DevsCoupledModel

SpecializedAtomicModule SpecializedCoupledModule

A inherits from B

A contains B

B

A

A

B

Figure 4 Class diagram of the package for DEVS support in DEUSwe recently introduced

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Core Core

Core Core

Core Core

Figure 5 Example NoC consisting of a mesh of switches andresources (cores and memory blocks)

Figure 6 the switch itself is a DEVS coupled model made oftwo DEVS atomic models one representing a queue and theother representing the system that implements the switchinglogic To model their interaction we use the followingstrategy When the switching logic completes a job (iedecides the destination of a message and forwards it) it doessend a ldquonext-msgrdquo input to the queue to make the latterprovide a new message The DEVS model of the queue isdefined as follows

(i) 119883 = 1198771015840

(ii) 119878 = ldquoemptyrdquo ldquo1rdquo ldquo119870rdquo times R+ times 119877

(iii) 119884 = 119877

(iv) there is no 120575int as the queue is a passive module

6 The Scientific World Journal

Msg

Switch

Queueldquonext-msgrdquo

Switchinglogic

Msg

New msgfrom queueldquoidlerdquoldquoemptyrdquo

ldquo1rdquo

ldquo2rdquo

ldquo3rdquoldquoKrdquo

Q[0]

ldquobusyrdquoOutput msg andldquonext-msgrdquo to the queue

middot middot middot

Figure 6 DEVSmodels of the switch in the proposedNoC example

(v)

120575ext (phase 120590msg 119890 119909)

=

(ldquo1rdquo 120590 119909 119909)if phase = ldquoidlerdquo 119909 = ldquonext-msgrdquo

(ldquo119894 + 1rdquo 120590msg)if phase = ldquo119894rdquo 119894 isin [1 119870 minus 1] 119909 = ldquonext-msgrdquo

(phase 120590 minus 119890msg)if phase = ldquo119870rdquo 119909 = ldquonext-msgrdquo

(ldquo119894 minus 1rdquo 120590msg)if phase = ldquo119894rdquo 119894 isin [2 119870] 119909 = ldquonext-msgrdquo

(ldquoidlerdquo 120590 120601)if phase isin ldquo1rdquo ldquoidlerdquo 119909 = ldquonext-msgrdquo

(4)

(vi) 120582(phase 120590msg) = 120601 if phasE= ldquoidlerdquo

msg if phase = ldquoidlerdquo

(vii) 119905119886(phase 120590msg) = 120590

where 119877 = ldquoget-datardquo ldquoput-datardquo ldquostore-datardquo is the set ofmessages that can be generated by core and memories 1198771015840 =119877cupldquonext-msgrdquo and119870 is themaximumnumber ofmessagesthat can be enqueued The output message is the one storedat the head of the queue If the queue is empty there is nooutputmdashwe use 120601 to represent the output in this case

The core and the switching logic system are modeled asthe processor illustrated in Section 3The switching logic sys-tem receives incoming messages and routes them accordingto the 119883119884 routing strategy [15]mdashfirst in 119909- or horizontal-direction to the correct column and then in 119910- or verticaldirection to the destination switch In general any specificswitching algorithm can be ldquopluggedrdquo into the model

The memory block illustrated in Figure 7 is modeled asfollows

(i) 119883 = 119877 times 119860(ii) 119878 = ldquoidlerdquo ldquo119882rdquo ldquo119877rdquo times R+ times 119877(iii) 119884 = 119872[119886] forall119886 isin 119860(iv) there is no 120575int as the memory block is a passive

module

Commandaddress OutputMemory

block

Read datagiven the address

Readcompleted

New datato be written

ldquoRrdquo

ldquoidlerdquo

ldquoWrdquoWrite

completed

Figure 7 DEVS models of the memory block in the proposed NoCexample

(v)

120575ext (phase 120590 data 119890 address command)

=

(phase 120590 minus 119890 data)if phase = ldquoidlerdquo

(ldquo119877rdquo 119875119879read 119872 [address])if phase = ldquoidlerdquo command = ldquoreadrdquo

(ldquo119882rdquo 119875119879write 120601)

if phase = ldquoidlerdquo command = ldquowriterdquo

(5)

(vi) 120582(phase 120590 output) = 120601 if phase = ldquo119877rdquo

output if phase=ldquo119877rdquo

(vii) 119905119886(phase 120590 output) = 120590

where 119877 = ldquoreadrdquo ldquowriterdquo is the set of commands thememory block can handle 119860 is the set of addresses and 120601

means no outputTo perform DEUS-based simulation we mapped

the DEVS models to the following Java classesCore MemoryBlock Switch (composed by Queue andSwitchingLogic) Mesh The class diagram in Figure 8illustrates the relations between such classes the basicclasses DevsAtomicModel andDevsCoupledModel andtheDevsModel interface In the diagram shaded classes arethose provided by the devs package we recently added toDEUS

According to the DEUS approach it is not necessaryto explicitly model links among network nodes Parameterslike link delay and maximal bandwidth can be embeddedeither in the Java classes representing the resources or in thescheduling processes of events that describe the internodecommunications (ie packet delivery) For this example weadopted the former approach

The Scientific World Journal 7

DevsModel

DevsAtomicModel DevsCoupledModel

Queue Switching Switchlogic Core MeshMemoryblock

A inherits from B

A contains B

B

A

A

B

Figure 8 Class diagram illustrating the DEVS-to-DEUS mappingfor the proposed NoC example

In detail we defined a specific recv( ) method in everyclass implementing a DEVS model Such a method imple-ments the logic described by the 120575ext and 120582 functions For thecore the recv( ) method handles the following messages

(i) ldquoput-datardquo the core enters the ldquobusyrdquo state and sendsa ldquofinish-procrdquo message to itself to be received whenthe processing phase is completed (this is just a trickto exit the ldquobusyrdquo state)

(ii) ldquofinish-procrdquo the core enters the ldquoidlerdquo state andsends a ldquostore-datardquo message to a randomly selectedmemory block with a random double isin [0 1] as apayload

For thememory block the recv( )method handles the follow-ing messages

(i) ldquoget-datardquo the memory block sends a ldquoput-datardquomessage to the core that issued the ldquoget-datardquomessagewith the mean of its stored values as a payload

(ii) ldquostore-datardquo the memory stores the payload of themessage if the memory is full the less recent valueis discarded to make room for the new one

The recv( ) method of the switch passes the message to thesame method of the queue instance where the message isstored if there is roommdashotherwise it is dropped After adelay which depends on the state of the queue (ie on thelength of the queue) and on the service rate of the switchinglogic themessage is passed to the switching logic itself whichcomputes the next hopmdashit may be another switch or thecorememory block connected to the current switchThe totaldelay for a message to pass through a switch and be deliveredto the next module is given by the sum of the followingcomponents

(i) time spent in the queue(ii) time for computing the next hop(iii) transmission time

Table 1 Experiment configuration

Number of rows 119898 = 4

Number of columns 119899 = 4

Transmission delay Exponential with mean value 1 nsSwitching logic delay Exponential with mean value 5 nsMax queue length 119870 = 3 5 7 Memory block size 119878 = 100

Memory block processingtime Uniform with max value 100 ns

Core processing time Uniform with max value 10 ns

Task interarrival time Exponential with mean value120583 = 2 4 6 ns

Then we defined a SendMessageEvent class whose run( )method just calls the appropriate recv( ) on the messagedestination Instances of SendMessageEvent are generated asa consequence of a ldquonew taskrdquo event (see below for details) orduring amessage propagation process which always involvesa couple of modules (with one exception discussed below)

For eachNewTaskEvent an idle core is randomlyselected to start a ldquoget-datardquo message propagation (as illus-trated in Figure 9 where involved modules are uniformlyshaded and arrows show the information flow) Once thedestination memory block has been reached the latter mod-ule starts ldquoput-datardquo message propagation towards the corewhich started it all When such a core receives the ldquoput-datardquo message it enters the ldquobusyrdquo state The processing taskends with a SendMessageEvent the core schedules on itself(according to its 120575int function) to enter to ldquoidlerdquo state and senda ldquodata-storerdquo message to a randomly chosen memory blockOf course any other interaction scheme could have beenimplemented

In general such a DEVS+DEUS model and simulationallows evaluating different routing strategies (either static ordynamic) and queuemanagementmechanisms implementedin the switches Example parameters we may consider in thiscontext are the communication load (a measure of averagetraffic in the network) the packet delay [14] and the averagethroughput of switches

To measure variables over the simulated virtual timespecific logging events as well as visualization eventsmust beimplemented and periodically scheduled For this examplewe implemented aLogNetworkStatsEvent which computesperformance indices such as the the Hit Ratio that is thenumber of completed tasks versus the number of issued ones

Table 1 illustrates the configuration of the simulations weexecutedmdashwith 10 runs each one being characterized by adifferent seed for the random number generator

The task interarrival time is such that on the average eachcore starts a new task every 120583 sdot8 ge 16 ns which is higher thanthe core processing time This is a reasonable configurationbut it is not sufficient to guarantee a 100Hit Ratio which isinfluenced by several factorsmdashsuch as the max queue length119870 the size of the mesh and the delays of the switches andmemory blocks For a simulated system lifetime of 100ms

8 The Scientific World Journal

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Core Core

Core Core

Core Core

(a) ldquoGet-datardquo

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Core Core

Core Core

Core Core

(b) ldquoPut-datardquo

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Core Core

Core Core

Core Core

(c) Processing

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Core Core

Core Core

Core Core

(d) ldquoData-storerdquo

Figure 9 An example of the simulated interaction scenario started by aNewTaskEvent For each phase involved modules are uniformlyshaded and arrows show the information flow

we obtained the results illustrated in Figure 10 where the HitRatio is shown as a function of 120583 and 119870 Simulation timeranges from few seconds (when120583 gt 20) to fewminutes (when120583 lt 10) on a MacBook Pro with 24GHz Intel Core 2 Duoand 4GB 1066MHz DD3 RAM

6 Conclusions

In this paper we have illustrated how to model NoCs bymeans of the DEVS formalism and to simulate such modelswith the DEUS simulation tool The proposed approach hastwomain advantages First DEVS and its dialects allowmod-elling almost any scenario including concurrent executions

Second the DEUS simulation environment is portable effi-cient providedwith useful tools for the rapid configuration ofhighly automated simulationsThe combination of DEVS andDEUS allows studying NoCs models with the desired levelof detail and efficiently comparing different configurations ofparameters

Regarding future work we plan to implement and shareother NoC models and simulations with different networktopologies and routing algorithms Moreover we are inter-ested in defining DEVS models of NoCs with Quality ofService (QoS) constraints and using DEUS to check whethersuch constraints are respected QoS refers to the levels ofguarantees given for data transfers Guarantees are relatedto timing (min throughput max latency and max latency

The Scientific World Journal 9

0

20

40

60

80

100

0 10 20 30 40 50

HR

120583

K = 3

k = 7

(a)

0

20

40

60

80

100

2 3 4 5 6 7 8

HR

K

120583 = 2

120583 = 6

120583 = 20

(b)

Figure 10 Hit Ratio as a function of 120583 (a) and 119870 (b)

jitter) integrity (max error rate and max packet loss) andpacket delivery (in-order or out- of-order)

Conflict of Interests

The author declares that there is no conflict of interestsregarding the publication of this paper

References

[1] L Benini and G de Micheli ldquoNetworks on chips a new SoCparadigmrdquo Computer vol 35 no 1 pp 70ndash78 2002

[2] H Ahmadinejad F Refan and H S Sarjoughian ldquoNoC simu-lation modeling in DEVS-suiterdquo in Proceedings of Symposiumon Theory of Modeling amp Simulation DEVS Integrative MampSSymposium (TMS-DEVS rsquo11) Boston Mass USA April 2011

[3] B P Zeigler H Praehofer and T G Kim Theory of Modelingand Simulation Academic Press Orlando Fla USA 2ndedition 2000

[4] M Amoretti M Picone F Zanichelli and G Ferrari ldquoSim-ulating mobile and distributed systems with DEUS and ns-3rdquoin Proceedings of International Conference on High PerformanceComputing and Simulation (HPCS 2013) pp 107ndash114 HelsinkiFinland July 2013

[5] W J Dally and B Towles Principles and Practices of Interconnec-tion NetWorks Morgan Kaufmann San Francisco Calif USA2003

[6] P Abad P Prieto L Menezo A Colaso V Puente and J AGregorio ldquoTOPAZ an open-source interconnection networksimulator for chip multiprocessors and supercomputersrdquo inProceedings of 6th IEEEACM International Symposium onNetworks on Chip (NoCS rsquo12) pp 99ndash106 Lyngby DenmarkMay 2012

[7] G Ascia V Catania M Palesi and D Patti ldquoImplementationand analysis of a new selection strategy for adaptive routing innetworks-on-chiprdquo IEEETransactions on Computers vol 57 no6 pp 809ndash820 2008

[8] Y Ben-Itzhak E Zahavi I Cidon and A Kolodny ldquoHNOCSmodular open-source simulator for heterogeneous NoCsrdquo inProceedings of the SAMOS International Conference on Embed-ded Computer Systems Architectures Modeling and Simulationpp 51ndash57 Samos Island Greece July 2012

[9] M Kreutz C A Marcon L Carro F Wagner and A ASusin ldquoDesign space exploration comparing homogeneous andheterogeneous network-on-chip architecturesrdquo in Proceedingsof the 18th ACM Symposium on Integrated Circuits and SystemsDesign pp 190ndash195 Florianopolis Brazil September 2005

[10] M Lis P Ren M H Cho et al ldquoScalable accurate multicoresimulation in the 1000-core erardquo in Proceedings of the IEEEInternational Symposium on Performance Analysis of Systemsand Software (ISPASS rsquo11) pp 175ndash185 Austin Tex USA April2011

[11] M Amoretti ldquoAmodeling framework for unstructured supern-ode networksrdquo IEEE Communications Letters vol 16 no 10 pp1707ndash1710 2012

[12] M Picone M Amoretti and F Zanichelli ldquoEvaluating therobustness of the DGT approach for smartphone-based vehicu-lar networksrdquo inProceedings of the 36thAnnual IEEEConferenceon Local Computer Networks (LCN rsquo11) pp 820ndash826 BonnGermany October 2011

[13] M Amoretti M Picone S Bonelli and F Zanichelli ldquoParallelamp distributed simulation with DEUSrdquo in Proceedings of theInternational Conference on High Performance Computing andSimulation (HPCS rsquo11) pp 600ndash606 Istanbul Turkey July 2011

[14] Y R Sun S Kumar and A Jantsch ldquoSimulation and evaluationof a network on chip architecture using ns-2rdquo in Proceedings ofthe IEEE NorChip Conference Copenhagen Denmark Novem-ber 2002

[15] M Dehyadgari M Nickray A Afzali-Kusha and Z NavabildquoEvaluation of pseudo adaptive XY routing using an objectoriented model for NOCrdquo in Proceedings of the 17th 2005International Conference onMicroelectronics (ICM rsquo05) pp 204ndash208 Islamabad Pakistan December 2005

Submit your manuscripts athttpwwwhindawicom

Computer Games Technology

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Distributed Sensor Networks

International Journal of

Advances in

FuzzySystems

Hindawi Publishing Corporationhttpwwwhindawicom

Volume 2014

International Journal of

ReconfigurableComputing

Hindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Applied Computational Intelligence and Soft Computing

thinspAdvancesthinspinthinsp

Artificial Intelligence

HindawithinspPublishingthinspCorporationhttpwwwhindawicom Volumethinsp2014

Advances inSoftware EngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Electrical and Computer Engineering

Journal of

Journal of

Computer Networks and Communications

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporation

httpwwwhindawicom Volume 2014

Advances in

Multimedia

International Journal of

Biomedical Imaging

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

ArtificialNeural Systems

Advances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

RoboticsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Computational Intelligence and Neuroscience

Industrial EngineeringJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Human-ComputerInteraction

Advances in

Computer EngineeringAdvances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

The Scientific World Journal 3

Few simulators are specially designed for being exe-cuted on parallelmulticore architectures One of them isGraphite (httpgroupscsailmiteducarbonpage id=111)which provides high performance for fast design spaceexploration and software development Its high efficiency isbalanced by the lack of portability it is written in C++ butbasically it works only with Debian Linux HORNET(httpcsgcsailmiteduhornet) is also written in C++ andrequires the Boost C++ library and Python 25TheHORNETNoC system model is composed of a number of inter-connected tiles Each tile comprises a processing element(PE) which can be a MIPS CPU simulator or a script-driven injector or a Pin front-end a bridge that convertspackets to flits and finally the network switch node itselfSince each tile can be run in a separate thread intertilecommunication is synchronized using fine-grained locks Toavoid unnecessary synchronization each tile has a privateindependently initialized Mersenne Twister random numbergenerator and collects its own statistics at the end of thesimulation the per-tile statistics are collected and combinedinto whole-system statistics [10]

3 DEVS Modeling

DEVS [3] is a formalism which allows representing anysystemhaving a finite number of changes in a finite interval oftime In thatway systemsmodeled by PetriNets StateChartsEvent Graphs and even Difference Equations can be seen asparticular cases of DEVS models

In its most general definition a DEVS (atomic) model isa structure

119872 = ⟨119883 119878 119884 120575int 120575ext 120582 119905119886⟩ (1)

where

(i) 119883 is the set of input values(ii) 119878 is a set of states(iii) 119884 is the set of output values(iv) 120575int 119878 rarr 119878 is the internal transition function(v) 120575ext 119876 times 119883 rarr 119878 is the external transition function

where 119876 = (119904 119890) | 119904 isin 119878 0 le 119890 le 119905119886(119904) is the total

state set (119890 is the time elapsed since last transition)(vi) 120582 119878 rarr 119884 is the output function(vii) 119905

119886 119878 rarr R+ is the time for which the system stays in

state 119904 if no external event occurs

The external transition function dictates the systemrsquosnew state when an external event occurs Such a state isdetermined by the input (119909) the current state (119904) and howlong the system has been in that state (119890)

The input trajectory is a series of external events affectingthe system The state trajectory is affected by external eventsin 119883 but also by internal events The output trajectorydepicts the output events that are produced by the outputfunction just before applying the internal transition functionat internal events

JobProcessor

Job⟨X S Y 120575int 120575ext 120582 ta⟩

Figure 1 DEVS model of a processor

Functions 120575int 120575ext 120582 and 119905119886can be either deterministic

or stochasticFor example a simple DEVS model for a processor

(Figure 1) is the following

(i) 119883 = 119877

(ii) 119878 = ldquoidlerdquo ldquobusyrdquo times R+ times 119877

(iii) 119884 = 119877

(iv) 120575int(phase 120590 job) = (ldquoidlerdquo 120590 job)

(v)

120575ext (phase 120590 job 119890 119909)

=

(ldquobusyrdquo 119875119879119909 119909) if phase = ldquoidlerdquo

(ldquobusyrdquo 119875119879 job minus 119890 job) if phase = ldquobusyrdquo

(2)

(vi) 120582(ldquobusyrdquo 120590 job) = job

(vii) 119905119886(phase 120590 job) = 120590

where 119877 is the set of jobs the processor can receive andgenerate 120590 is the time the processor stays in one of thetwo possible phases that is ldquoidlerdquo or ldquobusyrdquo and 119875119879job isthe processing time needed to execute a job The internaltransition function is evaluated each time a job is done Theexternal transition function is evaluated each time a new jobis received by the processor If the processor is idle the newjob 119909 is acquired and executed for which the state of theprocessor changes to ldquobusyrdquo and the remaining time in suchstate 120590 is set to 119875119879

119909 If the processor is busy the incoming

job is discarded and the remaining time in current state isupdated to 119875119879job minus 119890

DEVS modeling is made easier with the introduction ofinput and output ports by re-defining 119883 and 119884 as follows

(i) 119883 = (119901 V) | 119901 isin InPorts V isin 119883in is the set of inputports and values

(ii) 119884 = (119901 V) | 119901 isin OutPorts V isin 119884out is the set ofoutput ports and values

DEVS coupled models are built from components that arespecified asDEVSmodelsThe specification ofDEVS coupledmodels in case of DEVS with ports is the following

119873 = ⟨119883 119884119863 119872119889119889 isin 119863 EICEOC IC Select⟩ (3)

4 The Scientific World Journal

EIC EOCICICP0 P1 P2

⟨X S Y 120575int 120575ext 120582 ta⟩ ⟨X S Y 120575int 120575ext 120582 ta⟩ ⟨X S Y 120575int 120575ext 120582 ta⟩

Figure 2 DEVS coupled model of a pipeline made by three processors in series

where(i) 119883 is the set of input ports and values(ii) 119884 is the set of output ports and values(iii) 119863 is the set of component names(iv) for each 119889 isin 119863 119872

119889is a DEVS model

(v) EIC is the external input coupling that connectsexternal inputs to component inputs

(vi) EOC is the external output coupling that connectscomponent outputs to external outputs

(vii) IC is the internal coupling that connects componentoutputs to component inputs

(viii) Select 2119863

minus rarr 119863 is the tie-breaking function(used to serialize imminent component actions)

In DEVS coupled models no direct feedback is allowedAs an example we construct a simple DEVS coupled

model by placing three processors in series to form a pipeline(Figure 2) The formal specification is as follows

(i) InPorts = ldquoinrdquo(ii) 119883in = 119877(iii) 119883 = (ldquoinrdquo V) | V isin 119877(iv) OutPorts = ldquooutrdquo(v) 119884out = 119877(vi) 119884 = (ldquooutrdquo V) | V isin 119877(vii) 119863 = 1198750 1198751 1198752(viii) 119872

0= 1198721= 1198722= 119872

(ix) EIC = [(119873 ldquoinrdquo) (1198750 ldquoinrdquo)](x) EOC = [(1198752 ldquooutrdquo) (119873 ldquooutrdquo)](xi) IC = [(1198750 ldquooutrdquo) (1198751 ldquoinrdquo)] [(1198751 ldquooutrdquo)

(1198752 ldquoinrdquo)](xii) Select = 120575int firstThe Select rule is important in the case of coupled

processors having imminent outputs For example if 1198750 and1198751 generate output at the same time there are two possiblechoices for 1198751 (a) to apply 120575int which would allow acceptingthe input coming from 1198750 or (b) to apply 120575ext first whichwould result in discarding the input because of ldquobusyrdquo stateIn this example model the 119878119890119897119890119888119905 function dictates that thefunction to be applied first is 120575int

An important subset of DEVS coupled models is consti-tuted by parallelDEVS coupledmodels [3]TheparallelDEVSspecification allows multiple ports to receive values at thesame time without the need of the Select

4 Simulation of DEVS Models with DEUS

Discrete event simulation works by maintaining a list ofevents sorted by their scheduling times Executing eventsresults in new events being scheduled and inserted into theevent list aswell as events being deleted and removed from theevent list A problem that arises in discrete event simulationis that of simultaneous events for which different orderings ofactivation result in different evolutions of the simulationTheapproach employed by most simulation packages is to definea priority among the components Zeigler et al defined ahierarchical simulator for hierarchicalDEVS coupledmodelsconsisting of devs-simulators and devs-coordinators [3]Shortly each DEVS atomic model is simulated by a devs-simulator and each DEVS coupled model is simulated bya devs-coordinator which manages the simulators of thesubcomponents As these can be themselves DEVS coupledmodels a devs-coordinator is able to manage also devs-coordinators

The general-purpose simulation tool called DEUS [4]follows a different approach (Although their names suggesta connection between them DEVS and DEUS are completelyindependent) Its Java API allows developers to implement(by subclassing) (i) nodes that is the entities which interactin a complex system leading to emergent behaviors suchas humans pets cells robots or intelligent agents [11 12](ii) events for example node births and deaths interactionsamong nodes interactionswith the environment logs and soon and (iii) processes either stochastic or deterministic onesconstraining the timeliness of events

DEUS has been designed having in mind the three basicconcepts listed above and no specific modeling tool at allNevertheless it is possible to map DEUS concepts to DEVSonesmdashfor example a DEUS node can be the implementationof a DEVS model

Once specific Java classes have been implemented it ispossible to configure a simulation with the DEUS graphicaluser interface which includes the following

(i) the Visual Editor for the generation of XML docu-ments describing the simulations

(ii) the Automator for the execution of parametric simu-lations and the automatic generation of statistics (in aGnuplot-compliant format)

Last but not least DEUS supports parallel (multicore andordistributed) simulations [13]

Figure 3 illustrates how DEUS simulation models interms of XML configuration files and Java code are created

The Scientific World Journal 5

DEVS modeldefinition and

codingDEUSvisualeditor

XMLconfig

file

log

files

Control

Results

DEUS

DEUS

engine

simulationcode

DEUSautomator

Figure 3 Discrete event simulation with DEUS driven by DEVSmodels

(using also a Visual Editor) and then executed by means oftheAutomator and the EngineThe former allows performingsensitivity analysis by setting ranges for node and processparameters The Engine is the core of DEUS managing theevent queue and the simulation loop

A node represents a dynamic system characterized bya set of possible states whose transition functions maybe implemented either in the source code of the eventsassociated with the node or in the source code of the nodeitself Multiscale modeling of complex systems is achievedby means of connected heterogeneous nodes DEUS comeswith a library of predefined common processes andmany others can be implemented by the user Recently weadded DEVS support by means of a new package whichincludes the general-purpose classesDevsAtomicModel

andDevsCoupledModel both implementing theDevsModel

interface (see Figure 4) In next section we describe amodular DEVS-based NoC model and its simulation withDEUS

5 NoC Example

We considered a NoC system consisting of amesh of switchesand resources (ie processor cores ormemory blocks) whichare placed on slots formed by the switches like the onedescribed by Sun et al [14] and sketched in Figure 5 Wemodeled resources and switches and the whole NoC usingDEVS coupled modelsThemesh is an119898times119899 grid of switcheseach one being connected either to a core or to a memoryblock For simplicity resources are alternatedmdashthat is core -memory block - core - and so forthmdashon both axes

A switch is modeled as a DEVS model with input andoutput ports which are coupled respectively with output andinput ports of other switches or resources As illustrated in

DevsModel

DevsAtomicModel DevsCoupledModel

SpecializedAtomicModule SpecializedCoupledModule

A inherits from B

A contains B

B

A

A

B

Figure 4 Class diagram of the package for DEVS support in DEUSwe recently introduced

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Core Core

Core Core

Core Core

Figure 5 Example NoC consisting of a mesh of switches andresources (cores and memory blocks)

Figure 6 the switch itself is a DEVS coupled model made oftwo DEVS atomic models one representing a queue and theother representing the system that implements the switchinglogic To model their interaction we use the followingstrategy When the switching logic completes a job (iedecides the destination of a message and forwards it) it doessend a ldquonext-msgrdquo input to the queue to make the latterprovide a new message The DEVS model of the queue isdefined as follows

(i) 119883 = 1198771015840

(ii) 119878 = ldquoemptyrdquo ldquo1rdquo ldquo119870rdquo times R+ times 119877

(iii) 119884 = 119877

(iv) there is no 120575int as the queue is a passive module

6 The Scientific World Journal

Msg

Switch

Queueldquonext-msgrdquo

Switchinglogic

Msg

New msgfrom queueldquoidlerdquoldquoemptyrdquo

ldquo1rdquo

ldquo2rdquo

ldquo3rdquoldquoKrdquo

Q[0]

ldquobusyrdquoOutput msg andldquonext-msgrdquo to the queue

middot middot middot

Figure 6 DEVSmodels of the switch in the proposedNoC example

(v)

120575ext (phase 120590msg 119890 119909)

=

(ldquo1rdquo 120590 119909 119909)if phase = ldquoidlerdquo 119909 = ldquonext-msgrdquo

(ldquo119894 + 1rdquo 120590msg)if phase = ldquo119894rdquo 119894 isin [1 119870 minus 1] 119909 = ldquonext-msgrdquo

(phase 120590 minus 119890msg)if phase = ldquo119870rdquo 119909 = ldquonext-msgrdquo

(ldquo119894 minus 1rdquo 120590msg)if phase = ldquo119894rdquo 119894 isin [2 119870] 119909 = ldquonext-msgrdquo

(ldquoidlerdquo 120590 120601)if phase isin ldquo1rdquo ldquoidlerdquo 119909 = ldquonext-msgrdquo

(4)

(vi) 120582(phase 120590msg) = 120601 if phasE= ldquoidlerdquo

msg if phase = ldquoidlerdquo

(vii) 119905119886(phase 120590msg) = 120590

where 119877 = ldquoget-datardquo ldquoput-datardquo ldquostore-datardquo is the set ofmessages that can be generated by core and memories 1198771015840 =119877cupldquonext-msgrdquo and119870 is themaximumnumber ofmessagesthat can be enqueued The output message is the one storedat the head of the queue If the queue is empty there is nooutputmdashwe use 120601 to represent the output in this case

The core and the switching logic system are modeled asthe processor illustrated in Section 3The switching logic sys-tem receives incoming messages and routes them accordingto the 119883119884 routing strategy [15]mdashfirst in 119909- or horizontal-direction to the correct column and then in 119910- or verticaldirection to the destination switch In general any specificswitching algorithm can be ldquopluggedrdquo into the model

The memory block illustrated in Figure 7 is modeled asfollows

(i) 119883 = 119877 times 119860(ii) 119878 = ldquoidlerdquo ldquo119882rdquo ldquo119877rdquo times R+ times 119877(iii) 119884 = 119872[119886] forall119886 isin 119860(iv) there is no 120575int as the memory block is a passive

module

Commandaddress OutputMemory

block

Read datagiven the address

Readcompleted

New datato be written

ldquoRrdquo

ldquoidlerdquo

ldquoWrdquoWrite

completed

Figure 7 DEVS models of the memory block in the proposed NoCexample

(v)

120575ext (phase 120590 data 119890 address command)

=

(phase 120590 minus 119890 data)if phase = ldquoidlerdquo

(ldquo119877rdquo 119875119879read 119872 [address])if phase = ldquoidlerdquo command = ldquoreadrdquo

(ldquo119882rdquo 119875119879write 120601)

if phase = ldquoidlerdquo command = ldquowriterdquo

(5)

(vi) 120582(phase 120590 output) = 120601 if phase = ldquo119877rdquo

output if phase=ldquo119877rdquo

(vii) 119905119886(phase 120590 output) = 120590

where 119877 = ldquoreadrdquo ldquowriterdquo is the set of commands thememory block can handle 119860 is the set of addresses and 120601

means no outputTo perform DEUS-based simulation we mapped

the DEVS models to the following Java classesCore MemoryBlock Switch (composed by Queue andSwitchingLogic) Mesh The class diagram in Figure 8illustrates the relations between such classes the basicclasses DevsAtomicModel andDevsCoupledModel andtheDevsModel interface In the diagram shaded classes arethose provided by the devs package we recently added toDEUS

According to the DEUS approach it is not necessaryto explicitly model links among network nodes Parameterslike link delay and maximal bandwidth can be embeddedeither in the Java classes representing the resources or in thescheduling processes of events that describe the internodecommunications (ie packet delivery) For this example weadopted the former approach

The Scientific World Journal 7

DevsModel

DevsAtomicModel DevsCoupledModel

Queue Switching Switchlogic Core MeshMemoryblock

A inherits from B

A contains B

B

A

A

B

Figure 8 Class diagram illustrating the DEVS-to-DEUS mappingfor the proposed NoC example

In detail we defined a specific recv( ) method in everyclass implementing a DEVS model Such a method imple-ments the logic described by the 120575ext and 120582 functions For thecore the recv( ) method handles the following messages

(i) ldquoput-datardquo the core enters the ldquobusyrdquo state and sendsa ldquofinish-procrdquo message to itself to be received whenthe processing phase is completed (this is just a trickto exit the ldquobusyrdquo state)

(ii) ldquofinish-procrdquo the core enters the ldquoidlerdquo state andsends a ldquostore-datardquo message to a randomly selectedmemory block with a random double isin [0 1] as apayload

For thememory block the recv( )method handles the follow-ing messages

(i) ldquoget-datardquo the memory block sends a ldquoput-datardquomessage to the core that issued the ldquoget-datardquomessagewith the mean of its stored values as a payload

(ii) ldquostore-datardquo the memory stores the payload of themessage if the memory is full the less recent valueis discarded to make room for the new one

The recv( ) method of the switch passes the message to thesame method of the queue instance where the message isstored if there is roommdashotherwise it is dropped After adelay which depends on the state of the queue (ie on thelength of the queue) and on the service rate of the switchinglogic themessage is passed to the switching logic itself whichcomputes the next hopmdashit may be another switch or thecorememory block connected to the current switchThe totaldelay for a message to pass through a switch and be deliveredto the next module is given by the sum of the followingcomponents

(i) time spent in the queue(ii) time for computing the next hop(iii) transmission time

Table 1 Experiment configuration

Number of rows 119898 = 4

Number of columns 119899 = 4

Transmission delay Exponential with mean value 1 nsSwitching logic delay Exponential with mean value 5 nsMax queue length 119870 = 3 5 7 Memory block size 119878 = 100

Memory block processingtime Uniform with max value 100 ns

Core processing time Uniform with max value 10 ns

Task interarrival time Exponential with mean value120583 = 2 4 6 ns

Then we defined a SendMessageEvent class whose run( )method just calls the appropriate recv( ) on the messagedestination Instances of SendMessageEvent are generated asa consequence of a ldquonew taskrdquo event (see below for details) orduring amessage propagation process which always involvesa couple of modules (with one exception discussed below)

For eachNewTaskEvent an idle core is randomlyselected to start a ldquoget-datardquo message propagation (as illus-trated in Figure 9 where involved modules are uniformlyshaded and arrows show the information flow) Once thedestination memory block has been reached the latter mod-ule starts ldquoput-datardquo message propagation towards the corewhich started it all When such a core receives the ldquoput-datardquo message it enters the ldquobusyrdquo state The processing taskends with a SendMessageEvent the core schedules on itself(according to its 120575int function) to enter to ldquoidlerdquo state and senda ldquodata-storerdquo message to a randomly chosen memory blockOf course any other interaction scheme could have beenimplemented

In general such a DEVS+DEUS model and simulationallows evaluating different routing strategies (either static ordynamic) and queuemanagementmechanisms implementedin the switches Example parameters we may consider in thiscontext are the communication load (a measure of averagetraffic in the network) the packet delay [14] and the averagethroughput of switches

To measure variables over the simulated virtual timespecific logging events as well as visualization eventsmust beimplemented and periodically scheduled For this examplewe implemented aLogNetworkStatsEvent which computesperformance indices such as the the Hit Ratio that is thenumber of completed tasks versus the number of issued ones

Table 1 illustrates the configuration of the simulations weexecutedmdashwith 10 runs each one being characterized by adifferent seed for the random number generator

The task interarrival time is such that on the average eachcore starts a new task every 120583 sdot8 ge 16 ns which is higher thanthe core processing time This is a reasonable configurationbut it is not sufficient to guarantee a 100Hit Ratio which isinfluenced by several factorsmdashsuch as the max queue length119870 the size of the mesh and the delays of the switches andmemory blocks For a simulated system lifetime of 100ms

8 The Scientific World Journal

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Core Core

Core Core

Core Core

(a) ldquoGet-datardquo

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Core Core

Core Core

Core Core

(b) ldquoPut-datardquo

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Core Core

Core Core

Core Core

(c) Processing

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Core Core

Core Core

Core Core

(d) ldquoData-storerdquo

Figure 9 An example of the simulated interaction scenario started by aNewTaskEvent For each phase involved modules are uniformlyshaded and arrows show the information flow

we obtained the results illustrated in Figure 10 where the HitRatio is shown as a function of 120583 and 119870 Simulation timeranges from few seconds (when120583 gt 20) to fewminutes (when120583 lt 10) on a MacBook Pro with 24GHz Intel Core 2 Duoand 4GB 1066MHz DD3 RAM

6 Conclusions

In this paper we have illustrated how to model NoCs bymeans of the DEVS formalism and to simulate such modelswith the DEUS simulation tool The proposed approach hastwomain advantages First DEVS and its dialects allowmod-elling almost any scenario including concurrent executions

Second the DEUS simulation environment is portable effi-cient providedwith useful tools for the rapid configuration ofhighly automated simulationsThe combination of DEVS andDEUS allows studying NoCs models with the desired levelof detail and efficiently comparing different configurations ofparameters

Regarding future work we plan to implement and shareother NoC models and simulations with different networktopologies and routing algorithms Moreover we are inter-ested in defining DEVS models of NoCs with Quality ofService (QoS) constraints and using DEUS to check whethersuch constraints are respected QoS refers to the levels ofguarantees given for data transfers Guarantees are relatedto timing (min throughput max latency and max latency

The Scientific World Journal 9

0

20

40

60

80

100

0 10 20 30 40 50

HR

120583

K = 3

k = 7

(a)

0

20

40

60

80

100

2 3 4 5 6 7 8

HR

K

120583 = 2

120583 = 6

120583 = 20

(b)

Figure 10 Hit Ratio as a function of 120583 (a) and 119870 (b)

jitter) integrity (max error rate and max packet loss) andpacket delivery (in-order or out- of-order)

Conflict of Interests

The author declares that there is no conflict of interestsregarding the publication of this paper

References

[1] L Benini and G de Micheli ldquoNetworks on chips a new SoCparadigmrdquo Computer vol 35 no 1 pp 70ndash78 2002

[2] H Ahmadinejad F Refan and H S Sarjoughian ldquoNoC simu-lation modeling in DEVS-suiterdquo in Proceedings of Symposiumon Theory of Modeling amp Simulation DEVS Integrative MampSSymposium (TMS-DEVS rsquo11) Boston Mass USA April 2011

[3] B P Zeigler H Praehofer and T G Kim Theory of Modelingand Simulation Academic Press Orlando Fla USA 2ndedition 2000

[4] M Amoretti M Picone F Zanichelli and G Ferrari ldquoSim-ulating mobile and distributed systems with DEUS and ns-3rdquoin Proceedings of International Conference on High PerformanceComputing and Simulation (HPCS 2013) pp 107ndash114 HelsinkiFinland July 2013

[5] W J Dally and B Towles Principles and Practices of Interconnec-tion NetWorks Morgan Kaufmann San Francisco Calif USA2003

[6] P Abad P Prieto L Menezo A Colaso V Puente and J AGregorio ldquoTOPAZ an open-source interconnection networksimulator for chip multiprocessors and supercomputersrdquo inProceedings of 6th IEEEACM International Symposium onNetworks on Chip (NoCS rsquo12) pp 99ndash106 Lyngby DenmarkMay 2012

[7] G Ascia V Catania M Palesi and D Patti ldquoImplementationand analysis of a new selection strategy for adaptive routing innetworks-on-chiprdquo IEEETransactions on Computers vol 57 no6 pp 809ndash820 2008

[8] Y Ben-Itzhak E Zahavi I Cidon and A Kolodny ldquoHNOCSmodular open-source simulator for heterogeneous NoCsrdquo inProceedings of the SAMOS International Conference on Embed-ded Computer Systems Architectures Modeling and Simulationpp 51ndash57 Samos Island Greece July 2012

[9] M Kreutz C A Marcon L Carro F Wagner and A ASusin ldquoDesign space exploration comparing homogeneous andheterogeneous network-on-chip architecturesrdquo in Proceedingsof the 18th ACM Symposium on Integrated Circuits and SystemsDesign pp 190ndash195 Florianopolis Brazil September 2005

[10] M Lis P Ren M H Cho et al ldquoScalable accurate multicoresimulation in the 1000-core erardquo in Proceedings of the IEEEInternational Symposium on Performance Analysis of Systemsand Software (ISPASS rsquo11) pp 175ndash185 Austin Tex USA April2011

[11] M Amoretti ldquoAmodeling framework for unstructured supern-ode networksrdquo IEEE Communications Letters vol 16 no 10 pp1707ndash1710 2012

[12] M Picone M Amoretti and F Zanichelli ldquoEvaluating therobustness of the DGT approach for smartphone-based vehicu-lar networksrdquo inProceedings of the 36thAnnual IEEEConferenceon Local Computer Networks (LCN rsquo11) pp 820ndash826 BonnGermany October 2011

[13] M Amoretti M Picone S Bonelli and F Zanichelli ldquoParallelamp distributed simulation with DEUSrdquo in Proceedings of theInternational Conference on High Performance Computing andSimulation (HPCS rsquo11) pp 600ndash606 Istanbul Turkey July 2011

[14] Y R Sun S Kumar and A Jantsch ldquoSimulation and evaluationof a network on chip architecture using ns-2rdquo in Proceedings ofthe IEEE NorChip Conference Copenhagen Denmark Novem-ber 2002

[15] M Dehyadgari M Nickray A Afzali-Kusha and Z NavabildquoEvaluation of pseudo adaptive XY routing using an objectoriented model for NOCrdquo in Proceedings of the 17th 2005International Conference onMicroelectronics (ICM rsquo05) pp 204ndash208 Islamabad Pakistan December 2005

Submit your manuscripts athttpwwwhindawicom

Computer Games Technology

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Distributed Sensor Networks

International Journal of

Advances in

FuzzySystems

Hindawi Publishing Corporationhttpwwwhindawicom

Volume 2014

International Journal of

ReconfigurableComputing

Hindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Applied Computational Intelligence and Soft Computing

thinspAdvancesthinspinthinsp

Artificial Intelligence

HindawithinspPublishingthinspCorporationhttpwwwhindawicom Volumethinsp2014

Advances inSoftware EngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Electrical and Computer Engineering

Journal of

Journal of

Computer Networks and Communications

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporation

httpwwwhindawicom Volume 2014

Advances in

Multimedia

International Journal of

Biomedical Imaging

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

ArtificialNeural Systems

Advances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

RoboticsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Computational Intelligence and Neuroscience

Industrial EngineeringJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Human-ComputerInteraction

Advances in

Computer EngineeringAdvances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

4 The Scientific World Journal

EIC EOCICICP0 P1 P2

⟨X S Y 120575int 120575ext 120582 ta⟩ ⟨X S Y 120575int 120575ext 120582 ta⟩ ⟨X S Y 120575int 120575ext 120582 ta⟩

Figure 2 DEVS coupled model of a pipeline made by three processors in series

where(i) 119883 is the set of input ports and values(ii) 119884 is the set of output ports and values(iii) 119863 is the set of component names(iv) for each 119889 isin 119863 119872

119889is a DEVS model

(v) EIC is the external input coupling that connectsexternal inputs to component inputs

(vi) EOC is the external output coupling that connectscomponent outputs to external outputs

(vii) IC is the internal coupling that connects componentoutputs to component inputs

(viii) Select 2119863

minus rarr 119863 is the tie-breaking function(used to serialize imminent component actions)

In DEVS coupled models no direct feedback is allowedAs an example we construct a simple DEVS coupled

model by placing three processors in series to form a pipeline(Figure 2) The formal specification is as follows

(i) InPorts = ldquoinrdquo(ii) 119883in = 119877(iii) 119883 = (ldquoinrdquo V) | V isin 119877(iv) OutPorts = ldquooutrdquo(v) 119884out = 119877(vi) 119884 = (ldquooutrdquo V) | V isin 119877(vii) 119863 = 1198750 1198751 1198752(viii) 119872

0= 1198721= 1198722= 119872

(ix) EIC = [(119873 ldquoinrdquo) (1198750 ldquoinrdquo)](x) EOC = [(1198752 ldquooutrdquo) (119873 ldquooutrdquo)](xi) IC = [(1198750 ldquooutrdquo) (1198751 ldquoinrdquo)] [(1198751 ldquooutrdquo)

(1198752 ldquoinrdquo)](xii) Select = 120575int firstThe Select rule is important in the case of coupled

processors having imminent outputs For example if 1198750 and1198751 generate output at the same time there are two possiblechoices for 1198751 (a) to apply 120575int which would allow acceptingthe input coming from 1198750 or (b) to apply 120575ext first whichwould result in discarding the input because of ldquobusyrdquo stateIn this example model the 119878119890119897119890119888119905 function dictates that thefunction to be applied first is 120575int

An important subset of DEVS coupled models is consti-tuted by parallelDEVS coupledmodels [3]TheparallelDEVSspecification allows multiple ports to receive values at thesame time without the need of the Select

4 Simulation of DEVS Models with DEUS

Discrete event simulation works by maintaining a list ofevents sorted by their scheduling times Executing eventsresults in new events being scheduled and inserted into theevent list aswell as events being deleted and removed from theevent list A problem that arises in discrete event simulationis that of simultaneous events for which different orderings ofactivation result in different evolutions of the simulationTheapproach employed by most simulation packages is to definea priority among the components Zeigler et al defined ahierarchical simulator for hierarchicalDEVS coupledmodelsconsisting of devs-simulators and devs-coordinators [3]Shortly each DEVS atomic model is simulated by a devs-simulator and each DEVS coupled model is simulated bya devs-coordinator which manages the simulators of thesubcomponents As these can be themselves DEVS coupledmodels a devs-coordinator is able to manage also devs-coordinators

The general-purpose simulation tool called DEUS [4]follows a different approach (Although their names suggesta connection between them DEVS and DEUS are completelyindependent) Its Java API allows developers to implement(by subclassing) (i) nodes that is the entities which interactin a complex system leading to emergent behaviors suchas humans pets cells robots or intelligent agents [11 12](ii) events for example node births and deaths interactionsamong nodes interactionswith the environment logs and soon and (iii) processes either stochastic or deterministic onesconstraining the timeliness of events

DEUS has been designed having in mind the three basicconcepts listed above and no specific modeling tool at allNevertheless it is possible to map DEUS concepts to DEVSonesmdashfor example a DEUS node can be the implementationof a DEVS model

Once specific Java classes have been implemented it ispossible to configure a simulation with the DEUS graphicaluser interface which includes the following

(i) the Visual Editor for the generation of XML docu-ments describing the simulations

(ii) the Automator for the execution of parametric simu-lations and the automatic generation of statistics (in aGnuplot-compliant format)

Last but not least DEUS supports parallel (multicore andordistributed) simulations [13]

Figure 3 illustrates how DEUS simulation models interms of XML configuration files and Java code are created

The Scientific World Journal 5

DEVS modeldefinition and

codingDEUSvisualeditor

XMLconfig

file

log

files

Control

Results

DEUS

DEUS

engine

simulationcode

DEUSautomator

Figure 3 Discrete event simulation with DEUS driven by DEVSmodels

(using also a Visual Editor) and then executed by means oftheAutomator and the EngineThe former allows performingsensitivity analysis by setting ranges for node and processparameters The Engine is the core of DEUS managing theevent queue and the simulation loop

A node represents a dynamic system characterized bya set of possible states whose transition functions maybe implemented either in the source code of the eventsassociated with the node or in the source code of the nodeitself Multiscale modeling of complex systems is achievedby means of connected heterogeneous nodes DEUS comeswith a library of predefined common processes andmany others can be implemented by the user Recently weadded DEVS support by means of a new package whichincludes the general-purpose classesDevsAtomicModel

andDevsCoupledModel both implementing theDevsModel

interface (see Figure 4) In next section we describe amodular DEVS-based NoC model and its simulation withDEUS

5 NoC Example

We considered a NoC system consisting of amesh of switchesand resources (ie processor cores ormemory blocks) whichare placed on slots formed by the switches like the onedescribed by Sun et al [14] and sketched in Figure 5 Wemodeled resources and switches and the whole NoC usingDEVS coupled modelsThemesh is an119898times119899 grid of switcheseach one being connected either to a core or to a memoryblock For simplicity resources are alternatedmdashthat is core -memory block - core - and so forthmdashon both axes

A switch is modeled as a DEVS model with input andoutput ports which are coupled respectively with output andinput ports of other switches or resources As illustrated in

DevsModel

DevsAtomicModel DevsCoupledModel

SpecializedAtomicModule SpecializedCoupledModule

A inherits from B

A contains B

B

A

A

B

Figure 4 Class diagram of the package for DEVS support in DEUSwe recently introduced

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Core Core

Core Core

Core Core

Figure 5 Example NoC consisting of a mesh of switches andresources (cores and memory blocks)

Figure 6 the switch itself is a DEVS coupled model made oftwo DEVS atomic models one representing a queue and theother representing the system that implements the switchinglogic To model their interaction we use the followingstrategy When the switching logic completes a job (iedecides the destination of a message and forwards it) it doessend a ldquonext-msgrdquo input to the queue to make the latterprovide a new message The DEVS model of the queue isdefined as follows

(i) 119883 = 1198771015840

(ii) 119878 = ldquoemptyrdquo ldquo1rdquo ldquo119870rdquo times R+ times 119877

(iii) 119884 = 119877

(iv) there is no 120575int as the queue is a passive module

6 The Scientific World Journal

Msg

Switch

Queueldquonext-msgrdquo

Switchinglogic

Msg

New msgfrom queueldquoidlerdquoldquoemptyrdquo

ldquo1rdquo

ldquo2rdquo

ldquo3rdquoldquoKrdquo

Q[0]

ldquobusyrdquoOutput msg andldquonext-msgrdquo to the queue

middot middot middot

Figure 6 DEVSmodels of the switch in the proposedNoC example

(v)

120575ext (phase 120590msg 119890 119909)

=

(ldquo1rdquo 120590 119909 119909)if phase = ldquoidlerdquo 119909 = ldquonext-msgrdquo

(ldquo119894 + 1rdquo 120590msg)if phase = ldquo119894rdquo 119894 isin [1 119870 minus 1] 119909 = ldquonext-msgrdquo

(phase 120590 minus 119890msg)if phase = ldquo119870rdquo 119909 = ldquonext-msgrdquo

(ldquo119894 minus 1rdquo 120590msg)if phase = ldquo119894rdquo 119894 isin [2 119870] 119909 = ldquonext-msgrdquo

(ldquoidlerdquo 120590 120601)if phase isin ldquo1rdquo ldquoidlerdquo 119909 = ldquonext-msgrdquo

(4)

(vi) 120582(phase 120590msg) = 120601 if phasE= ldquoidlerdquo

msg if phase = ldquoidlerdquo

(vii) 119905119886(phase 120590msg) = 120590

where 119877 = ldquoget-datardquo ldquoput-datardquo ldquostore-datardquo is the set ofmessages that can be generated by core and memories 1198771015840 =119877cupldquonext-msgrdquo and119870 is themaximumnumber ofmessagesthat can be enqueued The output message is the one storedat the head of the queue If the queue is empty there is nooutputmdashwe use 120601 to represent the output in this case

The core and the switching logic system are modeled asthe processor illustrated in Section 3The switching logic sys-tem receives incoming messages and routes them accordingto the 119883119884 routing strategy [15]mdashfirst in 119909- or horizontal-direction to the correct column and then in 119910- or verticaldirection to the destination switch In general any specificswitching algorithm can be ldquopluggedrdquo into the model

The memory block illustrated in Figure 7 is modeled asfollows

(i) 119883 = 119877 times 119860(ii) 119878 = ldquoidlerdquo ldquo119882rdquo ldquo119877rdquo times R+ times 119877(iii) 119884 = 119872[119886] forall119886 isin 119860(iv) there is no 120575int as the memory block is a passive

module

Commandaddress OutputMemory

block

Read datagiven the address

Readcompleted

New datato be written

ldquoRrdquo

ldquoidlerdquo

ldquoWrdquoWrite

completed

Figure 7 DEVS models of the memory block in the proposed NoCexample

(v)

120575ext (phase 120590 data 119890 address command)

=

(phase 120590 minus 119890 data)if phase = ldquoidlerdquo

(ldquo119877rdquo 119875119879read 119872 [address])if phase = ldquoidlerdquo command = ldquoreadrdquo

(ldquo119882rdquo 119875119879write 120601)

if phase = ldquoidlerdquo command = ldquowriterdquo

(5)

(vi) 120582(phase 120590 output) = 120601 if phase = ldquo119877rdquo

output if phase=ldquo119877rdquo

(vii) 119905119886(phase 120590 output) = 120590

where 119877 = ldquoreadrdquo ldquowriterdquo is the set of commands thememory block can handle 119860 is the set of addresses and 120601

means no outputTo perform DEUS-based simulation we mapped

the DEVS models to the following Java classesCore MemoryBlock Switch (composed by Queue andSwitchingLogic) Mesh The class diagram in Figure 8illustrates the relations between such classes the basicclasses DevsAtomicModel andDevsCoupledModel andtheDevsModel interface In the diagram shaded classes arethose provided by the devs package we recently added toDEUS

According to the DEUS approach it is not necessaryto explicitly model links among network nodes Parameterslike link delay and maximal bandwidth can be embeddedeither in the Java classes representing the resources or in thescheduling processes of events that describe the internodecommunications (ie packet delivery) For this example weadopted the former approach

The Scientific World Journal 7

DevsModel

DevsAtomicModel DevsCoupledModel

Queue Switching Switchlogic Core MeshMemoryblock

A inherits from B

A contains B

B

A

A

B

Figure 8 Class diagram illustrating the DEVS-to-DEUS mappingfor the proposed NoC example

In detail we defined a specific recv( ) method in everyclass implementing a DEVS model Such a method imple-ments the logic described by the 120575ext and 120582 functions For thecore the recv( ) method handles the following messages

(i) ldquoput-datardquo the core enters the ldquobusyrdquo state and sendsa ldquofinish-procrdquo message to itself to be received whenthe processing phase is completed (this is just a trickto exit the ldquobusyrdquo state)

(ii) ldquofinish-procrdquo the core enters the ldquoidlerdquo state andsends a ldquostore-datardquo message to a randomly selectedmemory block with a random double isin [0 1] as apayload

For thememory block the recv( )method handles the follow-ing messages

(i) ldquoget-datardquo the memory block sends a ldquoput-datardquomessage to the core that issued the ldquoget-datardquomessagewith the mean of its stored values as a payload

(ii) ldquostore-datardquo the memory stores the payload of themessage if the memory is full the less recent valueis discarded to make room for the new one

The recv( ) method of the switch passes the message to thesame method of the queue instance where the message isstored if there is roommdashotherwise it is dropped After adelay which depends on the state of the queue (ie on thelength of the queue) and on the service rate of the switchinglogic themessage is passed to the switching logic itself whichcomputes the next hopmdashit may be another switch or thecorememory block connected to the current switchThe totaldelay for a message to pass through a switch and be deliveredto the next module is given by the sum of the followingcomponents

(i) time spent in the queue(ii) time for computing the next hop(iii) transmission time

Table 1 Experiment configuration

Number of rows 119898 = 4

Number of columns 119899 = 4

Transmission delay Exponential with mean value 1 nsSwitching logic delay Exponential with mean value 5 nsMax queue length 119870 = 3 5 7 Memory block size 119878 = 100

Memory block processingtime Uniform with max value 100 ns

Core processing time Uniform with max value 10 ns

Task interarrival time Exponential with mean value120583 = 2 4 6 ns

Then we defined a SendMessageEvent class whose run( )method just calls the appropriate recv( ) on the messagedestination Instances of SendMessageEvent are generated asa consequence of a ldquonew taskrdquo event (see below for details) orduring amessage propagation process which always involvesa couple of modules (with one exception discussed below)

For eachNewTaskEvent an idle core is randomlyselected to start a ldquoget-datardquo message propagation (as illus-trated in Figure 9 where involved modules are uniformlyshaded and arrows show the information flow) Once thedestination memory block has been reached the latter mod-ule starts ldquoput-datardquo message propagation towards the corewhich started it all When such a core receives the ldquoput-datardquo message it enters the ldquobusyrdquo state The processing taskends with a SendMessageEvent the core schedules on itself(according to its 120575int function) to enter to ldquoidlerdquo state and senda ldquodata-storerdquo message to a randomly chosen memory blockOf course any other interaction scheme could have beenimplemented

In general such a DEVS+DEUS model and simulationallows evaluating different routing strategies (either static ordynamic) and queuemanagementmechanisms implementedin the switches Example parameters we may consider in thiscontext are the communication load (a measure of averagetraffic in the network) the packet delay [14] and the averagethroughput of switches

To measure variables over the simulated virtual timespecific logging events as well as visualization eventsmust beimplemented and periodically scheduled For this examplewe implemented aLogNetworkStatsEvent which computesperformance indices such as the the Hit Ratio that is thenumber of completed tasks versus the number of issued ones

Table 1 illustrates the configuration of the simulations weexecutedmdashwith 10 runs each one being characterized by adifferent seed for the random number generator

The task interarrival time is such that on the average eachcore starts a new task every 120583 sdot8 ge 16 ns which is higher thanthe core processing time This is a reasonable configurationbut it is not sufficient to guarantee a 100Hit Ratio which isinfluenced by several factorsmdashsuch as the max queue length119870 the size of the mesh and the delays of the switches andmemory blocks For a simulated system lifetime of 100ms

8 The Scientific World Journal

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Core Core

Core Core

Core Core

(a) ldquoGet-datardquo

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Core Core

Core Core

Core Core

(b) ldquoPut-datardquo

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Core Core

Core Core

Core Core

(c) Processing

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Core Core

Core Core

Core Core

(d) ldquoData-storerdquo

Figure 9 An example of the simulated interaction scenario started by aNewTaskEvent For each phase involved modules are uniformlyshaded and arrows show the information flow

we obtained the results illustrated in Figure 10 where the HitRatio is shown as a function of 120583 and 119870 Simulation timeranges from few seconds (when120583 gt 20) to fewminutes (when120583 lt 10) on a MacBook Pro with 24GHz Intel Core 2 Duoand 4GB 1066MHz DD3 RAM

6 Conclusions

In this paper we have illustrated how to model NoCs bymeans of the DEVS formalism and to simulate such modelswith the DEUS simulation tool The proposed approach hastwomain advantages First DEVS and its dialects allowmod-elling almost any scenario including concurrent executions

Second the DEUS simulation environment is portable effi-cient providedwith useful tools for the rapid configuration ofhighly automated simulationsThe combination of DEVS andDEUS allows studying NoCs models with the desired levelof detail and efficiently comparing different configurations ofparameters

Regarding future work we plan to implement and shareother NoC models and simulations with different networktopologies and routing algorithms Moreover we are inter-ested in defining DEVS models of NoCs with Quality ofService (QoS) constraints and using DEUS to check whethersuch constraints are respected QoS refers to the levels ofguarantees given for data transfers Guarantees are relatedto timing (min throughput max latency and max latency

The Scientific World Journal 9

0

20

40

60

80

100

0 10 20 30 40 50

HR

120583

K = 3

k = 7

(a)

0

20

40

60

80

100

2 3 4 5 6 7 8

HR

K

120583 = 2

120583 = 6

120583 = 20

(b)

Figure 10 Hit Ratio as a function of 120583 (a) and 119870 (b)

jitter) integrity (max error rate and max packet loss) andpacket delivery (in-order or out- of-order)

Conflict of Interests

The author declares that there is no conflict of interestsregarding the publication of this paper

References

[1] L Benini and G de Micheli ldquoNetworks on chips a new SoCparadigmrdquo Computer vol 35 no 1 pp 70ndash78 2002

[2] H Ahmadinejad F Refan and H S Sarjoughian ldquoNoC simu-lation modeling in DEVS-suiterdquo in Proceedings of Symposiumon Theory of Modeling amp Simulation DEVS Integrative MampSSymposium (TMS-DEVS rsquo11) Boston Mass USA April 2011

[3] B P Zeigler H Praehofer and T G Kim Theory of Modelingand Simulation Academic Press Orlando Fla USA 2ndedition 2000

[4] M Amoretti M Picone F Zanichelli and G Ferrari ldquoSim-ulating mobile and distributed systems with DEUS and ns-3rdquoin Proceedings of International Conference on High PerformanceComputing and Simulation (HPCS 2013) pp 107ndash114 HelsinkiFinland July 2013

[5] W J Dally and B Towles Principles and Practices of Interconnec-tion NetWorks Morgan Kaufmann San Francisco Calif USA2003

[6] P Abad P Prieto L Menezo A Colaso V Puente and J AGregorio ldquoTOPAZ an open-source interconnection networksimulator for chip multiprocessors and supercomputersrdquo inProceedings of 6th IEEEACM International Symposium onNetworks on Chip (NoCS rsquo12) pp 99ndash106 Lyngby DenmarkMay 2012

[7] G Ascia V Catania M Palesi and D Patti ldquoImplementationand analysis of a new selection strategy for adaptive routing innetworks-on-chiprdquo IEEETransactions on Computers vol 57 no6 pp 809ndash820 2008

[8] Y Ben-Itzhak E Zahavi I Cidon and A Kolodny ldquoHNOCSmodular open-source simulator for heterogeneous NoCsrdquo inProceedings of the SAMOS International Conference on Embed-ded Computer Systems Architectures Modeling and Simulationpp 51ndash57 Samos Island Greece July 2012

[9] M Kreutz C A Marcon L Carro F Wagner and A ASusin ldquoDesign space exploration comparing homogeneous andheterogeneous network-on-chip architecturesrdquo in Proceedingsof the 18th ACM Symposium on Integrated Circuits and SystemsDesign pp 190ndash195 Florianopolis Brazil September 2005

[10] M Lis P Ren M H Cho et al ldquoScalable accurate multicoresimulation in the 1000-core erardquo in Proceedings of the IEEEInternational Symposium on Performance Analysis of Systemsand Software (ISPASS rsquo11) pp 175ndash185 Austin Tex USA April2011

[11] M Amoretti ldquoAmodeling framework for unstructured supern-ode networksrdquo IEEE Communications Letters vol 16 no 10 pp1707ndash1710 2012

[12] M Picone M Amoretti and F Zanichelli ldquoEvaluating therobustness of the DGT approach for smartphone-based vehicu-lar networksrdquo inProceedings of the 36thAnnual IEEEConferenceon Local Computer Networks (LCN rsquo11) pp 820ndash826 BonnGermany October 2011

[13] M Amoretti M Picone S Bonelli and F Zanichelli ldquoParallelamp distributed simulation with DEUSrdquo in Proceedings of theInternational Conference on High Performance Computing andSimulation (HPCS rsquo11) pp 600ndash606 Istanbul Turkey July 2011

[14] Y R Sun S Kumar and A Jantsch ldquoSimulation and evaluationof a network on chip architecture using ns-2rdquo in Proceedings ofthe IEEE NorChip Conference Copenhagen Denmark Novem-ber 2002

[15] M Dehyadgari M Nickray A Afzali-Kusha and Z NavabildquoEvaluation of pseudo adaptive XY routing using an objectoriented model for NOCrdquo in Proceedings of the 17th 2005International Conference onMicroelectronics (ICM rsquo05) pp 204ndash208 Islamabad Pakistan December 2005

Submit your manuscripts athttpwwwhindawicom

Computer Games Technology

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Distributed Sensor Networks

International Journal of

Advances in

FuzzySystems

Hindawi Publishing Corporationhttpwwwhindawicom

Volume 2014

International Journal of

ReconfigurableComputing

Hindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Applied Computational Intelligence and Soft Computing

thinspAdvancesthinspinthinsp

Artificial Intelligence

HindawithinspPublishingthinspCorporationhttpwwwhindawicom Volumethinsp2014

Advances inSoftware EngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Electrical and Computer Engineering

Journal of

Journal of

Computer Networks and Communications

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporation

httpwwwhindawicom Volume 2014

Advances in

Multimedia

International Journal of

Biomedical Imaging

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

ArtificialNeural Systems

Advances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

RoboticsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Computational Intelligence and Neuroscience

Industrial EngineeringJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Human-ComputerInteraction

Advances in

Computer EngineeringAdvances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

The Scientific World Journal 5

DEVS modeldefinition and

codingDEUSvisualeditor

XMLconfig

file

log

files

Control

Results

DEUS

DEUS

engine

simulationcode

DEUSautomator

Figure 3 Discrete event simulation with DEUS driven by DEVSmodels

(using also a Visual Editor) and then executed by means oftheAutomator and the EngineThe former allows performingsensitivity analysis by setting ranges for node and processparameters The Engine is the core of DEUS managing theevent queue and the simulation loop

A node represents a dynamic system characterized bya set of possible states whose transition functions maybe implemented either in the source code of the eventsassociated with the node or in the source code of the nodeitself Multiscale modeling of complex systems is achievedby means of connected heterogeneous nodes DEUS comeswith a library of predefined common processes andmany others can be implemented by the user Recently weadded DEVS support by means of a new package whichincludes the general-purpose classesDevsAtomicModel

andDevsCoupledModel both implementing theDevsModel

interface (see Figure 4) In next section we describe amodular DEVS-based NoC model and its simulation withDEUS

5 NoC Example

We considered a NoC system consisting of amesh of switchesand resources (ie processor cores ormemory blocks) whichare placed on slots formed by the switches like the onedescribed by Sun et al [14] and sketched in Figure 5 Wemodeled resources and switches and the whole NoC usingDEVS coupled modelsThemesh is an119898times119899 grid of switcheseach one being connected either to a core or to a memoryblock For simplicity resources are alternatedmdashthat is core -memory block - core - and so forthmdashon both axes

A switch is modeled as a DEVS model with input andoutput ports which are coupled respectively with output andinput ports of other switches or resources As illustrated in

DevsModel

DevsAtomicModel DevsCoupledModel

SpecializedAtomicModule SpecializedCoupledModule

A inherits from B

A contains B

B

A

A

B

Figure 4 Class diagram of the package for DEVS support in DEUSwe recently introduced

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Core Core

Core Core

Core Core

Figure 5 Example NoC consisting of a mesh of switches andresources (cores and memory blocks)

Figure 6 the switch itself is a DEVS coupled model made oftwo DEVS atomic models one representing a queue and theother representing the system that implements the switchinglogic To model their interaction we use the followingstrategy When the switching logic completes a job (iedecides the destination of a message and forwards it) it doessend a ldquonext-msgrdquo input to the queue to make the latterprovide a new message The DEVS model of the queue isdefined as follows

(i) 119883 = 1198771015840

(ii) 119878 = ldquoemptyrdquo ldquo1rdquo ldquo119870rdquo times R+ times 119877

(iii) 119884 = 119877

(iv) there is no 120575int as the queue is a passive module

6 The Scientific World Journal

Msg

Switch

Queueldquonext-msgrdquo

Switchinglogic

Msg

New msgfrom queueldquoidlerdquoldquoemptyrdquo

ldquo1rdquo

ldquo2rdquo

ldquo3rdquoldquoKrdquo

Q[0]

ldquobusyrdquoOutput msg andldquonext-msgrdquo to the queue

middot middot middot

Figure 6 DEVSmodels of the switch in the proposedNoC example

(v)

120575ext (phase 120590msg 119890 119909)

=

(ldquo1rdquo 120590 119909 119909)if phase = ldquoidlerdquo 119909 = ldquonext-msgrdquo

(ldquo119894 + 1rdquo 120590msg)if phase = ldquo119894rdquo 119894 isin [1 119870 minus 1] 119909 = ldquonext-msgrdquo

(phase 120590 minus 119890msg)if phase = ldquo119870rdquo 119909 = ldquonext-msgrdquo

(ldquo119894 minus 1rdquo 120590msg)if phase = ldquo119894rdquo 119894 isin [2 119870] 119909 = ldquonext-msgrdquo

(ldquoidlerdquo 120590 120601)if phase isin ldquo1rdquo ldquoidlerdquo 119909 = ldquonext-msgrdquo

(4)

(vi) 120582(phase 120590msg) = 120601 if phasE= ldquoidlerdquo

msg if phase = ldquoidlerdquo

(vii) 119905119886(phase 120590msg) = 120590

where 119877 = ldquoget-datardquo ldquoput-datardquo ldquostore-datardquo is the set ofmessages that can be generated by core and memories 1198771015840 =119877cupldquonext-msgrdquo and119870 is themaximumnumber ofmessagesthat can be enqueued The output message is the one storedat the head of the queue If the queue is empty there is nooutputmdashwe use 120601 to represent the output in this case

The core and the switching logic system are modeled asthe processor illustrated in Section 3The switching logic sys-tem receives incoming messages and routes them accordingto the 119883119884 routing strategy [15]mdashfirst in 119909- or horizontal-direction to the correct column and then in 119910- or verticaldirection to the destination switch In general any specificswitching algorithm can be ldquopluggedrdquo into the model

The memory block illustrated in Figure 7 is modeled asfollows

(i) 119883 = 119877 times 119860(ii) 119878 = ldquoidlerdquo ldquo119882rdquo ldquo119877rdquo times R+ times 119877(iii) 119884 = 119872[119886] forall119886 isin 119860(iv) there is no 120575int as the memory block is a passive

module

Commandaddress OutputMemory

block

Read datagiven the address

Readcompleted

New datato be written

ldquoRrdquo

ldquoidlerdquo

ldquoWrdquoWrite

completed

Figure 7 DEVS models of the memory block in the proposed NoCexample

(v)

120575ext (phase 120590 data 119890 address command)

=

(phase 120590 minus 119890 data)if phase = ldquoidlerdquo

(ldquo119877rdquo 119875119879read 119872 [address])if phase = ldquoidlerdquo command = ldquoreadrdquo

(ldquo119882rdquo 119875119879write 120601)

if phase = ldquoidlerdquo command = ldquowriterdquo

(5)

(vi) 120582(phase 120590 output) = 120601 if phase = ldquo119877rdquo

output if phase=ldquo119877rdquo

(vii) 119905119886(phase 120590 output) = 120590

where 119877 = ldquoreadrdquo ldquowriterdquo is the set of commands thememory block can handle 119860 is the set of addresses and 120601

means no outputTo perform DEUS-based simulation we mapped

the DEVS models to the following Java classesCore MemoryBlock Switch (composed by Queue andSwitchingLogic) Mesh The class diagram in Figure 8illustrates the relations between such classes the basicclasses DevsAtomicModel andDevsCoupledModel andtheDevsModel interface In the diagram shaded classes arethose provided by the devs package we recently added toDEUS

According to the DEUS approach it is not necessaryto explicitly model links among network nodes Parameterslike link delay and maximal bandwidth can be embeddedeither in the Java classes representing the resources or in thescheduling processes of events that describe the internodecommunications (ie packet delivery) For this example weadopted the former approach

The Scientific World Journal 7

DevsModel

DevsAtomicModel DevsCoupledModel

Queue Switching Switchlogic Core MeshMemoryblock

A inherits from B

A contains B

B

A

A

B

Figure 8 Class diagram illustrating the DEVS-to-DEUS mappingfor the proposed NoC example

In detail we defined a specific recv( ) method in everyclass implementing a DEVS model Such a method imple-ments the logic described by the 120575ext and 120582 functions For thecore the recv( ) method handles the following messages

(i) ldquoput-datardquo the core enters the ldquobusyrdquo state and sendsa ldquofinish-procrdquo message to itself to be received whenthe processing phase is completed (this is just a trickto exit the ldquobusyrdquo state)

(ii) ldquofinish-procrdquo the core enters the ldquoidlerdquo state andsends a ldquostore-datardquo message to a randomly selectedmemory block with a random double isin [0 1] as apayload

For thememory block the recv( )method handles the follow-ing messages

(i) ldquoget-datardquo the memory block sends a ldquoput-datardquomessage to the core that issued the ldquoget-datardquomessagewith the mean of its stored values as a payload

(ii) ldquostore-datardquo the memory stores the payload of themessage if the memory is full the less recent valueis discarded to make room for the new one

The recv( ) method of the switch passes the message to thesame method of the queue instance where the message isstored if there is roommdashotherwise it is dropped After adelay which depends on the state of the queue (ie on thelength of the queue) and on the service rate of the switchinglogic themessage is passed to the switching logic itself whichcomputes the next hopmdashit may be another switch or thecorememory block connected to the current switchThe totaldelay for a message to pass through a switch and be deliveredto the next module is given by the sum of the followingcomponents

(i) time spent in the queue(ii) time for computing the next hop(iii) transmission time

Table 1 Experiment configuration

Number of rows 119898 = 4

Number of columns 119899 = 4

Transmission delay Exponential with mean value 1 nsSwitching logic delay Exponential with mean value 5 nsMax queue length 119870 = 3 5 7 Memory block size 119878 = 100

Memory block processingtime Uniform with max value 100 ns

Core processing time Uniform with max value 10 ns

Task interarrival time Exponential with mean value120583 = 2 4 6 ns

Then we defined a SendMessageEvent class whose run( )method just calls the appropriate recv( ) on the messagedestination Instances of SendMessageEvent are generated asa consequence of a ldquonew taskrdquo event (see below for details) orduring amessage propagation process which always involvesa couple of modules (with one exception discussed below)

For eachNewTaskEvent an idle core is randomlyselected to start a ldquoget-datardquo message propagation (as illus-trated in Figure 9 where involved modules are uniformlyshaded and arrows show the information flow) Once thedestination memory block has been reached the latter mod-ule starts ldquoput-datardquo message propagation towards the corewhich started it all When such a core receives the ldquoput-datardquo message it enters the ldquobusyrdquo state The processing taskends with a SendMessageEvent the core schedules on itself(according to its 120575int function) to enter to ldquoidlerdquo state and senda ldquodata-storerdquo message to a randomly chosen memory blockOf course any other interaction scheme could have beenimplemented

In general such a DEVS+DEUS model and simulationallows evaluating different routing strategies (either static ordynamic) and queuemanagementmechanisms implementedin the switches Example parameters we may consider in thiscontext are the communication load (a measure of averagetraffic in the network) the packet delay [14] and the averagethroughput of switches

To measure variables over the simulated virtual timespecific logging events as well as visualization eventsmust beimplemented and periodically scheduled For this examplewe implemented aLogNetworkStatsEvent which computesperformance indices such as the the Hit Ratio that is thenumber of completed tasks versus the number of issued ones

Table 1 illustrates the configuration of the simulations weexecutedmdashwith 10 runs each one being characterized by adifferent seed for the random number generator

The task interarrival time is such that on the average eachcore starts a new task every 120583 sdot8 ge 16 ns which is higher thanthe core processing time This is a reasonable configurationbut it is not sufficient to guarantee a 100Hit Ratio which isinfluenced by several factorsmdashsuch as the max queue length119870 the size of the mesh and the delays of the switches andmemory blocks For a simulated system lifetime of 100ms

8 The Scientific World Journal

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Core Core

Core Core

Core Core

(a) ldquoGet-datardquo

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Core Core

Core Core

Core Core

(b) ldquoPut-datardquo

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Core Core

Core Core

Core Core

(c) Processing

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Core Core

Core Core

Core Core

(d) ldquoData-storerdquo

Figure 9 An example of the simulated interaction scenario started by aNewTaskEvent For each phase involved modules are uniformlyshaded and arrows show the information flow

we obtained the results illustrated in Figure 10 where the HitRatio is shown as a function of 120583 and 119870 Simulation timeranges from few seconds (when120583 gt 20) to fewminutes (when120583 lt 10) on a MacBook Pro with 24GHz Intel Core 2 Duoand 4GB 1066MHz DD3 RAM

6 Conclusions

In this paper we have illustrated how to model NoCs bymeans of the DEVS formalism and to simulate such modelswith the DEUS simulation tool The proposed approach hastwomain advantages First DEVS and its dialects allowmod-elling almost any scenario including concurrent executions

Second the DEUS simulation environment is portable effi-cient providedwith useful tools for the rapid configuration ofhighly automated simulationsThe combination of DEVS andDEUS allows studying NoCs models with the desired levelof detail and efficiently comparing different configurations ofparameters

Regarding future work we plan to implement and shareother NoC models and simulations with different networktopologies and routing algorithms Moreover we are inter-ested in defining DEVS models of NoCs with Quality ofService (QoS) constraints and using DEUS to check whethersuch constraints are respected QoS refers to the levels ofguarantees given for data transfers Guarantees are relatedto timing (min throughput max latency and max latency

The Scientific World Journal 9

0

20

40

60

80

100

0 10 20 30 40 50

HR

120583

K = 3

k = 7

(a)

0

20

40

60

80

100

2 3 4 5 6 7 8

HR

K

120583 = 2

120583 = 6

120583 = 20

(b)

Figure 10 Hit Ratio as a function of 120583 (a) and 119870 (b)

jitter) integrity (max error rate and max packet loss) andpacket delivery (in-order or out- of-order)

Conflict of Interests

The author declares that there is no conflict of interestsregarding the publication of this paper

References

[1] L Benini and G de Micheli ldquoNetworks on chips a new SoCparadigmrdquo Computer vol 35 no 1 pp 70ndash78 2002

[2] H Ahmadinejad F Refan and H S Sarjoughian ldquoNoC simu-lation modeling in DEVS-suiterdquo in Proceedings of Symposiumon Theory of Modeling amp Simulation DEVS Integrative MampSSymposium (TMS-DEVS rsquo11) Boston Mass USA April 2011

[3] B P Zeigler H Praehofer and T G Kim Theory of Modelingand Simulation Academic Press Orlando Fla USA 2ndedition 2000

[4] M Amoretti M Picone F Zanichelli and G Ferrari ldquoSim-ulating mobile and distributed systems with DEUS and ns-3rdquoin Proceedings of International Conference on High PerformanceComputing and Simulation (HPCS 2013) pp 107ndash114 HelsinkiFinland July 2013

[5] W J Dally and B Towles Principles and Practices of Interconnec-tion NetWorks Morgan Kaufmann San Francisco Calif USA2003

[6] P Abad P Prieto L Menezo A Colaso V Puente and J AGregorio ldquoTOPAZ an open-source interconnection networksimulator for chip multiprocessors and supercomputersrdquo inProceedings of 6th IEEEACM International Symposium onNetworks on Chip (NoCS rsquo12) pp 99ndash106 Lyngby DenmarkMay 2012

[7] G Ascia V Catania M Palesi and D Patti ldquoImplementationand analysis of a new selection strategy for adaptive routing innetworks-on-chiprdquo IEEETransactions on Computers vol 57 no6 pp 809ndash820 2008

[8] Y Ben-Itzhak E Zahavi I Cidon and A Kolodny ldquoHNOCSmodular open-source simulator for heterogeneous NoCsrdquo inProceedings of the SAMOS International Conference on Embed-ded Computer Systems Architectures Modeling and Simulationpp 51ndash57 Samos Island Greece July 2012

[9] M Kreutz C A Marcon L Carro F Wagner and A ASusin ldquoDesign space exploration comparing homogeneous andheterogeneous network-on-chip architecturesrdquo in Proceedingsof the 18th ACM Symposium on Integrated Circuits and SystemsDesign pp 190ndash195 Florianopolis Brazil September 2005

[10] M Lis P Ren M H Cho et al ldquoScalable accurate multicoresimulation in the 1000-core erardquo in Proceedings of the IEEEInternational Symposium on Performance Analysis of Systemsand Software (ISPASS rsquo11) pp 175ndash185 Austin Tex USA April2011

[11] M Amoretti ldquoAmodeling framework for unstructured supern-ode networksrdquo IEEE Communications Letters vol 16 no 10 pp1707ndash1710 2012

[12] M Picone M Amoretti and F Zanichelli ldquoEvaluating therobustness of the DGT approach for smartphone-based vehicu-lar networksrdquo inProceedings of the 36thAnnual IEEEConferenceon Local Computer Networks (LCN rsquo11) pp 820ndash826 BonnGermany October 2011

[13] M Amoretti M Picone S Bonelli and F Zanichelli ldquoParallelamp distributed simulation with DEUSrdquo in Proceedings of theInternational Conference on High Performance Computing andSimulation (HPCS rsquo11) pp 600ndash606 Istanbul Turkey July 2011

[14] Y R Sun S Kumar and A Jantsch ldquoSimulation and evaluationof a network on chip architecture using ns-2rdquo in Proceedings ofthe IEEE NorChip Conference Copenhagen Denmark Novem-ber 2002

[15] M Dehyadgari M Nickray A Afzali-Kusha and Z NavabildquoEvaluation of pseudo adaptive XY routing using an objectoriented model for NOCrdquo in Proceedings of the 17th 2005International Conference onMicroelectronics (ICM rsquo05) pp 204ndash208 Islamabad Pakistan December 2005

Submit your manuscripts athttpwwwhindawicom

Computer Games Technology

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Distributed Sensor Networks

International Journal of

Advances in

FuzzySystems

Hindawi Publishing Corporationhttpwwwhindawicom

Volume 2014

International Journal of

ReconfigurableComputing

Hindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Applied Computational Intelligence and Soft Computing

thinspAdvancesthinspinthinsp

Artificial Intelligence

HindawithinspPublishingthinspCorporationhttpwwwhindawicom Volumethinsp2014

Advances inSoftware EngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Electrical and Computer Engineering

Journal of

Journal of

Computer Networks and Communications

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporation

httpwwwhindawicom Volume 2014

Advances in

Multimedia

International Journal of

Biomedical Imaging

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

ArtificialNeural Systems

Advances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

RoboticsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Computational Intelligence and Neuroscience

Industrial EngineeringJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Human-ComputerInteraction

Advances in

Computer EngineeringAdvances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

6 The Scientific World Journal

Msg

Switch

Queueldquonext-msgrdquo

Switchinglogic

Msg

New msgfrom queueldquoidlerdquoldquoemptyrdquo

ldquo1rdquo

ldquo2rdquo

ldquo3rdquoldquoKrdquo

Q[0]

ldquobusyrdquoOutput msg andldquonext-msgrdquo to the queue

middot middot middot

Figure 6 DEVSmodels of the switch in the proposedNoC example

(v)

120575ext (phase 120590msg 119890 119909)

=

(ldquo1rdquo 120590 119909 119909)if phase = ldquoidlerdquo 119909 = ldquonext-msgrdquo

(ldquo119894 + 1rdquo 120590msg)if phase = ldquo119894rdquo 119894 isin [1 119870 minus 1] 119909 = ldquonext-msgrdquo

(phase 120590 minus 119890msg)if phase = ldquo119870rdquo 119909 = ldquonext-msgrdquo

(ldquo119894 minus 1rdquo 120590msg)if phase = ldquo119894rdquo 119894 isin [2 119870] 119909 = ldquonext-msgrdquo

(ldquoidlerdquo 120590 120601)if phase isin ldquo1rdquo ldquoidlerdquo 119909 = ldquonext-msgrdquo

(4)

(vi) 120582(phase 120590msg) = 120601 if phasE= ldquoidlerdquo

msg if phase = ldquoidlerdquo

(vii) 119905119886(phase 120590msg) = 120590

where 119877 = ldquoget-datardquo ldquoput-datardquo ldquostore-datardquo is the set ofmessages that can be generated by core and memories 1198771015840 =119877cupldquonext-msgrdquo and119870 is themaximumnumber ofmessagesthat can be enqueued The output message is the one storedat the head of the queue If the queue is empty there is nooutputmdashwe use 120601 to represent the output in this case

The core and the switching logic system are modeled asthe processor illustrated in Section 3The switching logic sys-tem receives incoming messages and routes them accordingto the 119883119884 routing strategy [15]mdashfirst in 119909- or horizontal-direction to the correct column and then in 119910- or verticaldirection to the destination switch In general any specificswitching algorithm can be ldquopluggedrdquo into the model

The memory block illustrated in Figure 7 is modeled asfollows

(i) 119883 = 119877 times 119860(ii) 119878 = ldquoidlerdquo ldquo119882rdquo ldquo119877rdquo times R+ times 119877(iii) 119884 = 119872[119886] forall119886 isin 119860(iv) there is no 120575int as the memory block is a passive

module

Commandaddress OutputMemory

block

Read datagiven the address

Readcompleted

New datato be written

ldquoRrdquo

ldquoidlerdquo

ldquoWrdquoWrite

completed

Figure 7 DEVS models of the memory block in the proposed NoCexample

(v)

120575ext (phase 120590 data 119890 address command)

=

(phase 120590 minus 119890 data)if phase = ldquoidlerdquo

(ldquo119877rdquo 119875119879read 119872 [address])if phase = ldquoidlerdquo command = ldquoreadrdquo

(ldquo119882rdquo 119875119879write 120601)

if phase = ldquoidlerdquo command = ldquowriterdquo

(5)

(vi) 120582(phase 120590 output) = 120601 if phase = ldquo119877rdquo

output if phase=ldquo119877rdquo

(vii) 119905119886(phase 120590 output) = 120590

where 119877 = ldquoreadrdquo ldquowriterdquo is the set of commands thememory block can handle 119860 is the set of addresses and 120601

means no outputTo perform DEUS-based simulation we mapped

the DEVS models to the following Java classesCore MemoryBlock Switch (composed by Queue andSwitchingLogic) Mesh The class diagram in Figure 8illustrates the relations between such classes the basicclasses DevsAtomicModel andDevsCoupledModel andtheDevsModel interface In the diagram shaded classes arethose provided by the devs package we recently added toDEUS

According to the DEUS approach it is not necessaryto explicitly model links among network nodes Parameterslike link delay and maximal bandwidth can be embeddedeither in the Java classes representing the resources or in thescheduling processes of events that describe the internodecommunications (ie packet delivery) For this example weadopted the former approach

The Scientific World Journal 7

DevsModel

DevsAtomicModel DevsCoupledModel

Queue Switching Switchlogic Core MeshMemoryblock

A inherits from B

A contains B

B

A

A

B

Figure 8 Class diagram illustrating the DEVS-to-DEUS mappingfor the proposed NoC example

In detail we defined a specific recv( ) method in everyclass implementing a DEVS model Such a method imple-ments the logic described by the 120575ext and 120582 functions For thecore the recv( ) method handles the following messages

(i) ldquoput-datardquo the core enters the ldquobusyrdquo state and sendsa ldquofinish-procrdquo message to itself to be received whenthe processing phase is completed (this is just a trickto exit the ldquobusyrdquo state)

(ii) ldquofinish-procrdquo the core enters the ldquoidlerdquo state andsends a ldquostore-datardquo message to a randomly selectedmemory block with a random double isin [0 1] as apayload

For thememory block the recv( )method handles the follow-ing messages

(i) ldquoget-datardquo the memory block sends a ldquoput-datardquomessage to the core that issued the ldquoget-datardquomessagewith the mean of its stored values as a payload

(ii) ldquostore-datardquo the memory stores the payload of themessage if the memory is full the less recent valueis discarded to make room for the new one

The recv( ) method of the switch passes the message to thesame method of the queue instance where the message isstored if there is roommdashotherwise it is dropped After adelay which depends on the state of the queue (ie on thelength of the queue) and on the service rate of the switchinglogic themessage is passed to the switching logic itself whichcomputes the next hopmdashit may be another switch or thecorememory block connected to the current switchThe totaldelay for a message to pass through a switch and be deliveredto the next module is given by the sum of the followingcomponents

(i) time spent in the queue(ii) time for computing the next hop(iii) transmission time

Table 1 Experiment configuration

Number of rows 119898 = 4

Number of columns 119899 = 4

Transmission delay Exponential with mean value 1 nsSwitching logic delay Exponential with mean value 5 nsMax queue length 119870 = 3 5 7 Memory block size 119878 = 100

Memory block processingtime Uniform with max value 100 ns

Core processing time Uniform with max value 10 ns

Task interarrival time Exponential with mean value120583 = 2 4 6 ns

Then we defined a SendMessageEvent class whose run( )method just calls the appropriate recv( ) on the messagedestination Instances of SendMessageEvent are generated asa consequence of a ldquonew taskrdquo event (see below for details) orduring amessage propagation process which always involvesa couple of modules (with one exception discussed below)

For eachNewTaskEvent an idle core is randomlyselected to start a ldquoget-datardquo message propagation (as illus-trated in Figure 9 where involved modules are uniformlyshaded and arrows show the information flow) Once thedestination memory block has been reached the latter mod-ule starts ldquoput-datardquo message propagation towards the corewhich started it all When such a core receives the ldquoput-datardquo message it enters the ldquobusyrdquo state The processing taskends with a SendMessageEvent the core schedules on itself(according to its 120575int function) to enter to ldquoidlerdquo state and senda ldquodata-storerdquo message to a randomly chosen memory blockOf course any other interaction scheme could have beenimplemented

In general such a DEVS+DEUS model and simulationallows evaluating different routing strategies (either static ordynamic) and queuemanagementmechanisms implementedin the switches Example parameters we may consider in thiscontext are the communication load (a measure of averagetraffic in the network) the packet delay [14] and the averagethroughput of switches

To measure variables over the simulated virtual timespecific logging events as well as visualization eventsmust beimplemented and periodically scheduled For this examplewe implemented aLogNetworkStatsEvent which computesperformance indices such as the the Hit Ratio that is thenumber of completed tasks versus the number of issued ones

Table 1 illustrates the configuration of the simulations weexecutedmdashwith 10 runs each one being characterized by adifferent seed for the random number generator

The task interarrival time is such that on the average eachcore starts a new task every 120583 sdot8 ge 16 ns which is higher thanthe core processing time This is a reasonable configurationbut it is not sufficient to guarantee a 100Hit Ratio which isinfluenced by several factorsmdashsuch as the max queue length119870 the size of the mesh and the delays of the switches andmemory blocks For a simulated system lifetime of 100ms

8 The Scientific World Journal

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Core Core

Core Core

Core Core

(a) ldquoGet-datardquo

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Core Core

Core Core

Core Core

(b) ldquoPut-datardquo

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Core Core

Core Core

Core Core

(c) Processing

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Core Core

Core Core

Core Core

(d) ldquoData-storerdquo

Figure 9 An example of the simulated interaction scenario started by aNewTaskEvent For each phase involved modules are uniformlyshaded and arrows show the information flow

we obtained the results illustrated in Figure 10 where the HitRatio is shown as a function of 120583 and 119870 Simulation timeranges from few seconds (when120583 gt 20) to fewminutes (when120583 lt 10) on a MacBook Pro with 24GHz Intel Core 2 Duoand 4GB 1066MHz DD3 RAM

6 Conclusions

In this paper we have illustrated how to model NoCs bymeans of the DEVS formalism and to simulate such modelswith the DEUS simulation tool The proposed approach hastwomain advantages First DEVS and its dialects allowmod-elling almost any scenario including concurrent executions

Second the DEUS simulation environment is portable effi-cient providedwith useful tools for the rapid configuration ofhighly automated simulationsThe combination of DEVS andDEUS allows studying NoCs models with the desired levelof detail and efficiently comparing different configurations ofparameters

Regarding future work we plan to implement and shareother NoC models and simulations with different networktopologies and routing algorithms Moreover we are inter-ested in defining DEVS models of NoCs with Quality ofService (QoS) constraints and using DEUS to check whethersuch constraints are respected QoS refers to the levels ofguarantees given for data transfers Guarantees are relatedto timing (min throughput max latency and max latency

The Scientific World Journal 9

0

20

40

60

80

100

0 10 20 30 40 50

HR

120583

K = 3

k = 7

(a)

0

20

40

60

80

100

2 3 4 5 6 7 8

HR

K

120583 = 2

120583 = 6

120583 = 20

(b)

Figure 10 Hit Ratio as a function of 120583 (a) and 119870 (b)

jitter) integrity (max error rate and max packet loss) andpacket delivery (in-order or out- of-order)

Conflict of Interests

The author declares that there is no conflict of interestsregarding the publication of this paper

References

[1] L Benini and G de Micheli ldquoNetworks on chips a new SoCparadigmrdquo Computer vol 35 no 1 pp 70ndash78 2002

[2] H Ahmadinejad F Refan and H S Sarjoughian ldquoNoC simu-lation modeling in DEVS-suiterdquo in Proceedings of Symposiumon Theory of Modeling amp Simulation DEVS Integrative MampSSymposium (TMS-DEVS rsquo11) Boston Mass USA April 2011

[3] B P Zeigler H Praehofer and T G Kim Theory of Modelingand Simulation Academic Press Orlando Fla USA 2ndedition 2000

[4] M Amoretti M Picone F Zanichelli and G Ferrari ldquoSim-ulating mobile and distributed systems with DEUS and ns-3rdquoin Proceedings of International Conference on High PerformanceComputing and Simulation (HPCS 2013) pp 107ndash114 HelsinkiFinland July 2013

[5] W J Dally and B Towles Principles and Practices of Interconnec-tion NetWorks Morgan Kaufmann San Francisco Calif USA2003

[6] P Abad P Prieto L Menezo A Colaso V Puente and J AGregorio ldquoTOPAZ an open-source interconnection networksimulator for chip multiprocessors and supercomputersrdquo inProceedings of 6th IEEEACM International Symposium onNetworks on Chip (NoCS rsquo12) pp 99ndash106 Lyngby DenmarkMay 2012

[7] G Ascia V Catania M Palesi and D Patti ldquoImplementationand analysis of a new selection strategy for adaptive routing innetworks-on-chiprdquo IEEETransactions on Computers vol 57 no6 pp 809ndash820 2008

[8] Y Ben-Itzhak E Zahavi I Cidon and A Kolodny ldquoHNOCSmodular open-source simulator for heterogeneous NoCsrdquo inProceedings of the SAMOS International Conference on Embed-ded Computer Systems Architectures Modeling and Simulationpp 51ndash57 Samos Island Greece July 2012

[9] M Kreutz C A Marcon L Carro F Wagner and A ASusin ldquoDesign space exploration comparing homogeneous andheterogeneous network-on-chip architecturesrdquo in Proceedingsof the 18th ACM Symposium on Integrated Circuits and SystemsDesign pp 190ndash195 Florianopolis Brazil September 2005

[10] M Lis P Ren M H Cho et al ldquoScalable accurate multicoresimulation in the 1000-core erardquo in Proceedings of the IEEEInternational Symposium on Performance Analysis of Systemsand Software (ISPASS rsquo11) pp 175ndash185 Austin Tex USA April2011

[11] M Amoretti ldquoAmodeling framework for unstructured supern-ode networksrdquo IEEE Communications Letters vol 16 no 10 pp1707ndash1710 2012

[12] M Picone M Amoretti and F Zanichelli ldquoEvaluating therobustness of the DGT approach for smartphone-based vehicu-lar networksrdquo inProceedings of the 36thAnnual IEEEConferenceon Local Computer Networks (LCN rsquo11) pp 820ndash826 BonnGermany October 2011

[13] M Amoretti M Picone S Bonelli and F Zanichelli ldquoParallelamp distributed simulation with DEUSrdquo in Proceedings of theInternational Conference on High Performance Computing andSimulation (HPCS rsquo11) pp 600ndash606 Istanbul Turkey July 2011

[14] Y R Sun S Kumar and A Jantsch ldquoSimulation and evaluationof a network on chip architecture using ns-2rdquo in Proceedings ofthe IEEE NorChip Conference Copenhagen Denmark Novem-ber 2002

[15] M Dehyadgari M Nickray A Afzali-Kusha and Z NavabildquoEvaluation of pseudo adaptive XY routing using an objectoriented model for NOCrdquo in Proceedings of the 17th 2005International Conference onMicroelectronics (ICM rsquo05) pp 204ndash208 Islamabad Pakistan December 2005

Submit your manuscripts athttpwwwhindawicom

Computer Games Technology

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Distributed Sensor Networks

International Journal of

Advances in

FuzzySystems

Hindawi Publishing Corporationhttpwwwhindawicom

Volume 2014

International Journal of

ReconfigurableComputing

Hindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Applied Computational Intelligence and Soft Computing

thinspAdvancesthinspinthinsp

Artificial Intelligence

HindawithinspPublishingthinspCorporationhttpwwwhindawicom Volumethinsp2014

Advances inSoftware EngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Electrical and Computer Engineering

Journal of

Journal of

Computer Networks and Communications

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporation

httpwwwhindawicom Volume 2014

Advances in

Multimedia

International Journal of

Biomedical Imaging

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

ArtificialNeural Systems

Advances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

RoboticsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Computational Intelligence and Neuroscience

Industrial EngineeringJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Human-ComputerInteraction

Advances in

Computer EngineeringAdvances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

The Scientific World Journal 7

DevsModel

DevsAtomicModel DevsCoupledModel

Queue Switching Switchlogic Core MeshMemoryblock

A inherits from B

A contains B

B

A

A

B

Figure 8 Class diagram illustrating the DEVS-to-DEUS mappingfor the proposed NoC example

In detail we defined a specific recv( ) method in everyclass implementing a DEVS model Such a method imple-ments the logic described by the 120575ext and 120582 functions For thecore the recv( ) method handles the following messages

(i) ldquoput-datardquo the core enters the ldquobusyrdquo state and sendsa ldquofinish-procrdquo message to itself to be received whenthe processing phase is completed (this is just a trickto exit the ldquobusyrdquo state)

(ii) ldquofinish-procrdquo the core enters the ldquoidlerdquo state andsends a ldquostore-datardquo message to a randomly selectedmemory block with a random double isin [0 1] as apayload

For thememory block the recv( )method handles the follow-ing messages

(i) ldquoget-datardquo the memory block sends a ldquoput-datardquomessage to the core that issued the ldquoget-datardquomessagewith the mean of its stored values as a payload

(ii) ldquostore-datardquo the memory stores the payload of themessage if the memory is full the less recent valueis discarded to make room for the new one

The recv( ) method of the switch passes the message to thesame method of the queue instance where the message isstored if there is roommdashotherwise it is dropped After adelay which depends on the state of the queue (ie on thelength of the queue) and on the service rate of the switchinglogic themessage is passed to the switching logic itself whichcomputes the next hopmdashit may be another switch or thecorememory block connected to the current switchThe totaldelay for a message to pass through a switch and be deliveredto the next module is given by the sum of the followingcomponents

(i) time spent in the queue(ii) time for computing the next hop(iii) transmission time

Table 1 Experiment configuration

Number of rows 119898 = 4

Number of columns 119899 = 4

Transmission delay Exponential with mean value 1 nsSwitching logic delay Exponential with mean value 5 nsMax queue length 119870 = 3 5 7 Memory block size 119878 = 100

Memory block processingtime Uniform with max value 100 ns

Core processing time Uniform with max value 10 ns

Task interarrival time Exponential with mean value120583 = 2 4 6 ns

Then we defined a SendMessageEvent class whose run( )method just calls the appropriate recv( ) on the messagedestination Instances of SendMessageEvent are generated asa consequence of a ldquonew taskrdquo event (see below for details) orduring amessage propagation process which always involvesa couple of modules (with one exception discussed below)

For eachNewTaskEvent an idle core is randomlyselected to start a ldquoget-datardquo message propagation (as illus-trated in Figure 9 where involved modules are uniformlyshaded and arrows show the information flow) Once thedestination memory block has been reached the latter mod-ule starts ldquoput-datardquo message propagation towards the corewhich started it all When such a core receives the ldquoput-datardquo message it enters the ldquobusyrdquo state The processing taskends with a SendMessageEvent the core schedules on itself(according to its 120575int function) to enter to ldquoidlerdquo state and senda ldquodata-storerdquo message to a randomly chosen memory blockOf course any other interaction scheme could have beenimplemented

In general such a DEVS+DEUS model and simulationallows evaluating different routing strategies (either static ordynamic) and queuemanagementmechanisms implementedin the switches Example parameters we may consider in thiscontext are the communication load (a measure of averagetraffic in the network) the packet delay [14] and the averagethroughput of switches

To measure variables over the simulated virtual timespecific logging events as well as visualization eventsmust beimplemented and periodically scheduled For this examplewe implemented aLogNetworkStatsEvent which computesperformance indices such as the the Hit Ratio that is thenumber of completed tasks versus the number of issued ones

Table 1 illustrates the configuration of the simulations weexecutedmdashwith 10 runs each one being characterized by adifferent seed for the random number generator

The task interarrival time is such that on the average eachcore starts a new task every 120583 sdot8 ge 16 ns which is higher thanthe core processing time This is a reasonable configurationbut it is not sufficient to guarantee a 100Hit Ratio which isinfluenced by several factorsmdashsuch as the max queue length119870 the size of the mesh and the delays of the switches andmemory blocks For a simulated system lifetime of 100ms

8 The Scientific World Journal

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Core Core

Core Core

Core Core

(a) ldquoGet-datardquo

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Core Core

Core Core

Core Core

(b) ldquoPut-datardquo

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Core Core

Core Core

Core Core

(c) Processing

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Core Core

Core Core

Core Core

(d) ldquoData-storerdquo

Figure 9 An example of the simulated interaction scenario started by aNewTaskEvent For each phase involved modules are uniformlyshaded and arrows show the information flow

we obtained the results illustrated in Figure 10 where the HitRatio is shown as a function of 120583 and 119870 Simulation timeranges from few seconds (when120583 gt 20) to fewminutes (when120583 lt 10) on a MacBook Pro with 24GHz Intel Core 2 Duoand 4GB 1066MHz DD3 RAM

6 Conclusions

In this paper we have illustrated how to model NoCs bymeans of the DEVS formalism and to simulate such modelswith the DEUS simulation tool The proposed approach hastwomain advantages First DEVS and its dialects allowmod-elling almost any scenario including concurrent executions

Second the DEUS simulation environment is portable effi-cient providedwith useful tools for the rapid configuration ofhighly automated simulationsThe combination of DEVS andDEUS allows studying NoCs models with the desired levelof detail and efficiently comparing different configurations ofparameters

Regarding future work we plan to implement and shareother NoC models and simulations with different networktopologies and routing algorithms Moreover we are inter-ested in defining DEVS models of NoCs with Quality ofService (QoS) constraints and using DEUS to check whethersuch constraints are respected QoS refers to the levels ofguarantees given for data transfers Guarantees are relatedto timing (min throughput max latency and max latency

The Scientific World Journal 9

0

20

40

60

80

100

0 10 20 30 40 50

HR

120583

K = 3

k = 7

(a)

0

20

40

60

80

100

2 3 4 5 6 7 8

HR

K

120583 = 2

120583 = 6

120583 = 20

(b)

Figure 10 Hit Ratio as a function of 120583 (a) and 119870 (b)

jitter) integrity (max error rate and max packet loss) andpacket delivery (in-order or out- of-order)

Conflict of Interests

The author declares that there is no conflict of interestsregarding the publication of this paper

References

[1] L Benini and G de Micheli ldquoNetworks on chips a new SoCparadigmrdquo Computer vol 35 no 1 pp 70ndash78 2002

[2] H Ahmadinejad F Refan and H S Sarjoughian ldquoNoC simu-lation modeling in DEVS-suiterdquo in Proceedings of Symposiumon Theory of Modeling amp Simulation DEVS Integrative MampSSymposium (TMS-DEVS rsquo11) Boston Mass USA April 2011

[3] B P Zeigler H Praehofer and T G Kim Theory of Modelingand Simulation Academic Press Orlando Fla USA 2ndedition 2000

[4] M Amoretti M Picone F Zanichelli and G Ferrari ldquoSim-ulating mobile and distributed systems with DEUS and ns-3rdquoin Proceedings of International Conference on High PerformanceComputing and Simulation (HPCS 2013) pp 107ndash114 HelsinkiFinland July 2013

[5] W J Dally and B Towles Principles and Practices of Interconnec-tion NetWorks Morgan Kaufmann San Francisco Calif USA2003

[6] P Abad P Prieto L Menezo A Colaso V Puente and J AGregorio ldquoTOPAZ an open-source interconnection networksimulator for chip multiprocessors and supercomputersrdquo inProceedings of 6th IEEEACM International Symposium onNetworks on Chip (NoCS rsquo12) pp 99ndash106 Lyngby DenmarkMay 2012

[7] G Ascia V Catania M Palesi and D Patti ldquoImplementationand analysis of a new selection strategy for adaptive routing innetworks-on-chiprdquo IEEETransactions on Computers vol 57 no6 pp 809ndash820 2008

[8] Y Ben-Itzhak E Zahavi I Cidon and A Kolodny ldquoHNOCSmodular open-source simulator for heterogeneous NoCsrdquo inProceedings of the SAMOS International Conference on Embed-ded Computer Systems Architectures Modeling and Simulationpp 51ndash57 Samos Island Greece July 2012

[9] M Kreutz C A Marcon L Carro F Wagner and A ASusin ldquoDesign space exploration comparing homogeneous andheterogeneous network-on-chip architecturesrdquo in Proceedingsof the 18th ACM Symposium on Integrated Circuits and SystemsDesign pp 190ndash195 Florianopolis Brazil September 2005

[10] M Lis P Ren M H Cho et al ldquoScalable accurate multicoresimulation in the 1000-core erardquo in Proceedings of the IEEEInternational Symposium on Performance Analysis of Systemsand Software (ISPASS rsquo11) pp 175ndash185 Austin Tex USA April2011

[11] M Amoretti ldquoAmodeling framework for unstructured supern-ode networksrdquo IEEE Communications Letters vol 16 no 10 pp1707ndash1710 2012

[12] M Picone M Amoretti and F Zanichelli ldquoEvaluating therobustness of the DGT approach for smartphone-based vehicu-lar networksrdquo inProceedings of the 36thAnnual IEEEConferenceon Local Computer Networks (LCN rsquo11) pp 820ndash826 BonnGermany October 2011

[13] M Amoretti M Picone S Bonelli and F Zanichelli ldquoParallelamp distributed simulation with DEUSrdquo in Proceedings of theInternational Conference on High Performance Computing andSimulation (HPCS rsquo11) pp 600ndash606 Istanbul Turkey July 2011

[14] Y R Sun S Kumar and A Jantsch ldquoSimulation and evaluationof a network on chip architecture using ns-2rdquo in Proceedings ofthe IEEE NorChip Conference Copenhagen Denmark Novem-ber 2002

[15] M Dehyadgari M Nickray A Afzali-Kusha and Z NavabildquoEvaluation of pseudo adaptive XY routing using an objectoriented model for NOCrdquo in Proceedings of the 17th 2005International Conference onMicroelectronics (ICM rsquo05) pp 204ndash208 Islamabad Pakistan December 2005

Submit your manuscripts athttpwwwhindawicom

Computer Games Technology

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Distributed Sensor Networks

International Journal of

Advances in

FuzzySystems

Hindawi Publishing Corporationhttpwwwhindawicom

Volume 2014

International Journal of

ReconfigurableComputing

Hindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Applied Computational Intelligence and Soft Computing

thinspAdvancesthinspinthinsp

Artificial Intelligence

HindawithinspPublishingthinspCorporationhttpwwwhindawicom Volumethinsp2014

Advances inSoftware EngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Electrical and Computer Engineering

Journal of

Journal of

Computer Networks and Communications

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporation

httpwwwhindawicom Volume 2014

Advances in

Multimedia

International Journal of

Biomedical Imaging

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

ArtificialNeural Systems

Advances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

RoboticsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Computational Intelligence and Neuroscience

Industrial EngineeringJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Human-ComputerInteraction

Advances in

Computer EngineeringAdvances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

8 The Scientific World Journal

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Core Core

Core Core

Core Core

(a) ldquoGet-datardquo

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Core Core

Core Core

Core Core

(b) ldquoPut-datardquo

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Core Core

Core Core

Core Core

(c) Processing

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Switch Switch Switch Switch

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Memoryblock

Core Core

Core Core

Core Core

(d) ldquoData-storerdquo

Figure 9 An example of the simulated interaction scenario started by aNewTaskEvent For each phase involved modules are uniformlyshaded and arrows show the information flow

we obtained the results illustrated in Figure 10 where the HitRatio is shown as a function of 120583 and 119870 Simulation timeranges from few seconds (when120583 gt 20) to fewminutes (when120583 lt 10) on a MacBook Pro with 24GHz Intel Core 2 Duoand 4GB 1066MHz DD3 RAM

6 Conclusions

In this paper we have illustrated how to model NoCs bymeans of the DEVS formalism and to simulate such modelswith the DEUS simulation tool The proposed approach hastwomain advantages First DEVS and its dialects allowmod-elling almost any scenario including concurrent executions

Second the DEUS simulation environment is portable effi-cient providedwith useful tools for the rapid configuration ofhighly automated simulationsThe combination of DEVS andDEUS allows studying NoCs models with the desired levelof detail and efficiently comparing different configurations ofparameters

Regarding future work we plan to implement and shareother NoC models and simulations with different networktopologies and routing algorithms Moreover we are inter-ested in defining DEVS models of NoCs with Quality ofService (QoS) constraints and using DEUS to check whethersuch constraints are respected QoS refers to the levels ofguarantees given for data transfers Guarantees are relatedto timing (min throughput max latency and max latency

The Scientific World Journal 9

0

20

40

60

80

100

0 10 20 30 40 50

HR

120583

K = 3

k = 7

(a)

0

20

40

60

80

100

2 3 4 5 6 7 8

HR

K

120583 = 2

120583 = 6

120583 = 20

(b)

Figure 10 Hit Ratio as a function of 120583 (a) and 119870 (b)

jitter) integrity (max error rate and max packet loss) andpacket delivery (in-order or out- of-order)

Conflict of Interests

The author declares that there is no conflict of interestsregarding the publication of this paper

References

[1] L Benini and G de Micheli ldquoNetworks on chips a new SoCparadigmrdquo Computer vol 35 no 1 pp 70ndash78 2002

[2] H Ahmadinejad F Refan and H S Sarjoughian ldquoNoC simu-lation modeling in DEVS-suiterdquo in Proceedings of Symposiumon Theory of Modeling amp Simulation DEVS Integrative MampSSymposium (TMS-DEVS rsquo11) Boston Mass USA April 2011

[3] B P Zeigler H Praehofer and T G Kim Theory of Modelingand Simulation Academic Press Orlando Fla USA 2ndedition 2000

[4] M Amoretti M Picone F Zanichelli and G Ferrari ldquoSim-ulating mobile and distributed systems with DEUS and ns-3rdquoin Proceedings of International Conference on High PerformanceComputing and Simulation (HPCS 2013) pp 107ndash114 HelsinkiFinland July 2013

[5] W J Dally and B Towles Principles and Practices of Interconnec-tion NetWorks Morgan Kaufmann San Francisco Calif USA2003

[6] P Abad P Prieto L Menezo A Colaso V Puente and J AGregorio ldquoTOPAZ an open-source interconnection networksimulator for chip multiprocessors and supercomputersrdquo inProceedings of 6th IEEEACM International Symposium onNetworks on Chip (NoCS rsquo12) pp 99ndash106 Lyngby DenmarkMay 2012

[7] G Ascia V Catania M Palesi and D Patti ldquoImplementationand analysis of a new selection strategy for adaptive routing innetworks-on-chiprdquo IEEETransactions on Computers vol 57 no6 pp 809ndash820 2008

[8] Y Ben-Itzhak E Zahavi I Cidon and A Kolodny ldquoHNOCSmodular open-source simulator for heterogeneous NoCsrdquo inProceedings of the SAMOS International Conference on Embed-ded Computer Systems Architectures Modeling and Simulationpp 51ndash57 Samos Island Greece July 2012

[9] M Kreutz C A Marcon L Carro F Wagner and A ASusin ldquoDesign space exploration comparing homogeneous andheterogeneous network-on-chip architecturesrdquo in Proceedingsof the 18th ACM Symposium on Integrated Circuits and SystemsDesign pp 190ndash195 Florianopolis Brazil September 2005

[10] M Lis P Ren M H Cho et al ldquoScalable accurate multicoresimulation in the 1000-core erardquo in Proceedings of the IEEEInternational Symposium on Performance Analysis of Systemsand Software (ISPASS rsquo11) pp 175ndash185 Austin Tex USA April2011

[11] M Amoretti ldquoAmodeling framework for unstructured supern-ode networksrdquo IEEE Communications Letters vol 16 no 10 pp1707ndash1710 2012

[12] M Picone M Amoretti and F Zanichelli ldquoEvaluating therobustness of the DGT approach for smartphone-based vehicu-lar networksrdquo inProceedings of the 36thAnnual IEEEConferenceon Local Computer Networks (LCN rsquo11) pp 820ndash826 BonnGermany October 2011

[13] M Amoretti M Picone S Bonelli and F Zanichelli ldquoParallelamp distributed simulation with DEUSrdquo in Proceedings of theInternational Conference on High Performance Computing andSimulation (HPCS rsquo11) pp 600ndash606 Istanbul Turkey July 2011

[14] Y R Sun S Kumar and A Jantsch ldquoSimulation and evaluationof a network on chip architecture using ns-2rdquo in Proceedings ofthe IEEE NorChip Conference Copenhagen Denmark Novem-ber 2002

[15] M Dehyadgari M Nickray A Afzali-Kusha and Z NavabildquoEvaluation of pseudo adaptive XY routing using an objectoriented model for NOCrdquo in Proceedings of the 17th 2005International Conference onMicroelectronics (ICM rsquo05) pp 204ndash208 Islamabad Pakistan December 2005

Submit your manuscripts athttpwwwhindawicom

Computer Games Technology

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Distributed Sensor Networks

International Journal of

Advances in

FuzzySystems

Hindawi Publishing Corporationhttpwwwhindawicom

Volume 2014

International Journal of

ReconfigurableComputing

Hindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Applied Computational Intelligence and Soft Computing

thinspAdvancesthinspinthinsp

Artificial Intelligence

HindawithinspPublishingthinspCorporationhttpwwwhindawicom Volumethinsp2014

Advances inSoftware EngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Electrical and Computer Engineering

Journal of

Journal of

Computer Networks and Communications

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporation

httpwwwhindawicom Volume 2014

Advances in

Multimedia

International Journal of

Biomedical Imaging

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

ArtificialNeural Systems

Advances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

RoboticsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Computational Intelligence and Neuroscience

Industrial EngineeringJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Human-ComputerInteraction

Advances in

Computer EngineeringAdvances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

The Scientific World Journal 9

0

20

40

60

80

100

0 10 20 30 40 50

HR

120583

K = 3

k = 7

(a)

0

20

40

60

80

100

2 3 4 5 6 7 8

HR

K

120583 = 2

120583 = 6

120583 = 20

(b)

Figure 10 Hit Ratio as a function of 120583 (a) and 119870 (b)

jitter) integrity (max error rate and max packet loss) andpacket delivery (in-order or out- of-order)

Conflict of Interests

The author declares that there is no conflict of interestsregarding the publication of this paper

References

[1] L Benini and G de Micheli ldquoNetworks on chips a new SoCparadigmrdquo Computer vol 35 no 1 pp 70ndash78 2002

[2] H Ahmadinejad F Refan and H S Sarjoughian ldquoNoC simu-lation modeling in DEVS-suiterdquo in Proceedings of Symposiumon Theory of Modeling amp Simulation DEVS Integrative MampSSymposium (TMS-DEVS rsquo11) Boston Mass USA April 2011

[3] B P Zeigler H Praehofer and T G Kim Theory of Modelingand Simulation Academic Press Orlando Fla USA 2ndedition 2000

[4] M Amoretti M Picone F Zanichelli and G Ferrari ldquoSim-ulating mobile and distributed systems with DEUS and ns-3rdquoin Proceedings of International Conference on High PerformanceComputing and Simulation (HPCS 2013) pp 107ndash114 HelsinkiFinland July 2013

[5] W J Dally and B Towles Principles and Practices of Interconnec-tion NetWorks Morgan Kaufmann San Francisco Calif USA2003

[6] P Abad P Prieto L Menezo A Colaso V Puente and J AGregorio ldquoTOPAZ an open-source interconnection networksimulator for chip multiprocessors and supercomputersrdquo inProceedings of 6th IEEEACM International Symposium onNetworks on Chip (NoCS rsquo12) pp 99ndash106 Lyngby DenmarkMay 2012

[7] G Ascia V Catania M Palesi and D Patti ldquoImplementationand analysis of a new selection strategy for adaptive routing innetworks-on-chiprdquo IEEETransactions on Computers vol 57 no6 pp 809ndash820 2008

[8] Y Ben-Itzhak E Zahavi I Cidon and A Kolodny ldquoHNOCSmodular open-source simulator for heterogeneous NoCsrdquo inProceedings of the SAMOS International Conference on Embed-ded Computer Systems Architectures Modeling and Simulationpp 51ndash57 Samos Island Greece July 2012

[9] M Kreutz C A Marcon L Carro F Wagner and A ASusin ldquoDesign space exploration comparing homogeneous andheterogeneous network-on-chip architecturesrdquo in Proceedingsof the 18th ACM Symposium on Integrated Circuits and SystemsDesign pp 190ndash195 Florianopolis Brazil September 2005

[10] M Lis P Ren M H Cho et al ldquoScalable accurate multicoresimulation in the 1000-core erardquo in Proceedings of the IEEEInternational Symposium on Performance Analysis of Systemsand Software (ISPASS rsquo11) pp 175ndash185 Austin Tex USA April2011

[11] M Amoretti ldquoAmodeling framework for unstructured supern-ode networksrdquo IEEE Communications Letters vol 16 no 10 pp1707ndash1710 2012

[12] M Picone M Amoretti and F Zanichelli ldquoEvaluating therobustness of the DGT approach for smartphone-based vehicu-lar networksrdquo inProceedings of the 36thAnnual IEEEConferenceon Local Computer Networks (LCN rsquo11) pp 820ndash826 BonnGermany October 2011

[13] M Amoretti M Picone S Bonelli and F Zanichelli ldquoParallelamp distributed simulation with DEUSrdquo in Proceedings of theInternational Conference on High Performance Computing andSimulation (HPCS rsquo11) pp 600ndash606 Istanbul Turkey July 2011

[14] Y R Sun S Kumar and A Jantsch ldquoSimulation and evaluationof a network on chip architecture using ns-2rdquo in Proceedings ofthe IEEE NorChip Conference Copenhagen Denmark Novem-ber 2002

[15] M Dehyadgari M Nickray A Afzali-Kusha and Z NavabildquoEvaluation of pseudo adaptive XY routing using an objectoriented model for NOCrdquo in Proceedings of the 17th 2005International Conference onMicroelectronics (ICM rsquo05) pp 204ndash208 Islamabad Pakistan December 2005

Submit your manuscripts athttpwwwhindawicom

Computer Games Technology

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Distributed Sensor Networks

International Journal of

Advances in

FuzzySystems

Hindawi Publishing Corporationhttpwwwhindawicom

Volume 2014

International Journal of

ReconfigurableComputing

Hindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Applied Computational Intelligence and Soft Computing

thinspAdvancesthinspinthinsp

Artificial Intelligence

HindawithinspPublishingthinspCorporationhttpwwwhindawicom Volumethinsp2014

Advances inSoftware EngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Electrical and Computer Engineering

Journal of

Journal of

Computer Networks and Communications

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporation

httpwwwhindawicom Volume 2014

Advances in

Multimedia

International Journal of

Biomedical Imaging

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

ArtificialNeural Systems

Advances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

RoboticsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Computational Intelligence and Neuroscience

Industrial EngineeringJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Human-ComputerInteraction

Advances in

Computer EngineeringAdvances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Submit your manuscripts athttpwwwhindawicom

Computer Games Technology

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Distributed Sensor Networks

International Journal of

Advances in

FuzzySystems

Hindawi Publishing Corporationhttpwwwhindawicom

Volume 2014

International Journal of

ReconfigurableComputing

Hindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Applied Computational Intelligence and Soft Computing

thinspAdvancesthinspinthinsp

Artificial Intelligence

HindawithinspPublishingthinspCorporationhttpwwwhindawicom Volumethinsp2014

Advances inSoftware EngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Electrical and Computer Engineering

Journal of

Journal of

Computer Networks and Communications

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporation

httpwwwhindawicom Volume 2014

Advances in

Multimedia

International Journal of

Biomedical Imaging

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

ArtificialNeural Systems

Advances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

RoboticsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Computational Intelligence and Neuroscience

Industrial EngineeringJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Human-ComputerInteraction

Advances in

Computer EngineeringAdvances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014