report star topology using noc router

1 | P a g e

MAJOR PROJECT REPORT ON

IMPLEMENTATION OF

Submitted in Partial Fulfillment of the requirements for the award of

ELECTRONICS AND COMMUNICATION ENGINEERING

DEPARTMENT OF ELECTRONICS & COMM.

B.T.KUMAON INSTITUTE OF TECHNOLOGY DWARAHAT

UTTRAKHAND TECHNICAL UNIVERSITY, DEHRADUN

MAJOR PROJECT REPORT ON

IMPLEMENTATION OF STAR TOPOLOGY FOR NOC ROUTER USING VERILOG


Degree of

Bachelor of Technology

in


Submitted by

VINOD DEOLAL (110180102135)

VIKAS TIWARI (110180102133)

SHIVAM SAINI (110180102116)

Under the supervision of

Mr. Vikash Sharma

DEPARTMENT OF ELECTRONICS & COMM. ENGINEERING

B.T.KUMAON INSTITUTE OF TECHNOLOGY DWARAHAT


FOR NOC ROUTER USING



ENGINEERING

B.T.KUMAON INSTITUTE OF TECHNOLOGY DWARAHAT-263653


2 | P a g e

This is to certify that the

Topology for NoC Router

No.110180102116), Vikas Tiwari

Deolal (Roll No. 110180102135

the award of Bachelor of

Engineering of the Bipin Tripathi Kumaon Institute of Technology Dwarahat,

Uttarakhand Technical University, Dehradun

work carried out by them under my supervision and guidance.

Mr. Vikash Sharma Dr. R.S. Prasad

PROJECT GUIDE

Bipin Tripathi Kumaon InstDepartment of Electronics and Communication Engineering

Dwarahat (Almora)

CERTIFICATE

This is to certify that the Major Project entitled “Implementation of Star

Topology for NoC Router” which is being submitted by Shivam Saini

Vikas Tiwari (Roll No. 110180102133) and Vinod Kumar

(Roll No. 110180102135) for the partial fulfillment of the requirements for

Bachelor of Technology in Electronics Communication

Bipin Tripathi Kumaon Institute of Technology Dwarahat,

Uttarakhand Technical University, Dehradun is a record of candi

work carried out by them under my supervision and guidance.


PROJECT GUIDE PROFESSOR

Bipin Tripathi Kumaon Institute of TechnologyDepartment of Electronics and Communication Engineering

Dwarahat (Almora) – 263653, Uttarakhand

Implementation of Star

Shivam Saini(Roll

Vinod Kumar

for the partial fulfillment of the requirements for

Electronics Communication

Bipin Tripathi Kumaon Institute of Technology Dwarahat,

is a record of candidate’s own


PROFESSOR & HEAD

tute of Technology Department of Electronics and Communication Engineering

3 | P a g e

ACKNOWLEDGEMENT

We take this opportunity to express my profound gratitude and deep regards to my

guide Mr. Vikas Sharma for his exemplary guidance, monitoring and constant

encouragement throughout the project. The blessing, help and guidance given by

him time to time shall carry us a long way in the journey of life on which we are

about to embark.

We are grateful to Dr. R.S. Prasad (Head of Department, Electronics and

Communication Engineering) for being a great motivator and for providing

necessary facilities in the department.

We also take this opportunity to express a deep sense of gratitude to all ECE staff

members for their cordial support, valuable information and guidance, which helped

us in completing this task through various stages.

Lastly, we thank almighty, my parents, brother and friends for their constant

encouragement without which this assignment would not be possible.

Date

Place Shivam saini

110180102116

Vikas Tiwari

110180102133

Vinod Kumar Deolal

110180102135

4 | P a g e

TABLE OF CONTENTS .

CERTIFICATE i

ACKNOWLEDGEMENT ii

TABLE OF CONTENT iii

LIST OF FIGURES v

ABSTRACT vi

Chapter1

Introduction 1.1 Introduction to NOC router for SOC communication…………….….………....……..1 1.2 Requirement for NOC router……………………………………….………….…..…..1 1.3 NOC Router Architecture……………………………………………….…….……….2

Chapter 2 Introduction To VERILOG

2.1 Hardware descriptive languages (HDL)………………………………………………..3 2.2 Verilog HDL…………………………………………………………………………...3 2.3 Levels of Design abstraction…………………………………………………………...3 2.4 Components of a Verilog Module……………………………………………………...4 2.5 Gate level Modeling…………………………………………………………………....4 2.6 Behavioral Modeling…………………………………………………………………...5 2.7 Operator types……………………………………………………………………….....5 2.8 Initial statement………………………………………………………………………...5 2.9 Always statement……………………………………………………………………....6

Chapter 3 3.1 Arbiter

3.1.1 Round Robin Arbiter Design…………………………………………………..7 3.1.2 Bus Arbiter Design…………………………………………………………….7 3.1.3 Truth table for 4x4 Priority Logic Block………………………………………8 3.1.4 Assumptions for Arbiter Design…………………………………………….....9

3.2 Routing Engine and Look Up Table ……….………………………………...9 3.3 Crossbar Switch…………………………………………………………………..10

3.3.1 Flowchart for crossbar switch………………………….……………………….11

3.4 FIFO Buffer 3.4.1 Working of Circular FIFO Buffer…………………………………….……….....11

5 | P a g e

3.4.2 Flowchart for circular FIFO……………………………………………………...12

Chapter 4 Star topology Implementation of NoC Router

4.1 NoC Topologies……………………………………………………………………13 4.2 Star Topology………………………………………………………………………14

4.3 Data flow in Star topology ………………………………………………………...15

Chapter 5 Simulations and Results 5.1 Input Arbiter

5.1.1. Schematic Diagram..............................................................................................17 5.1.2. Simulation Result.................................................................................................17 5.1.3. Design Summary..................................................................................................18

5.2 Routing Engine and Look Up table 5.2.1. Schematic Diagram..............................................................................................18 5.2.2. Simulation Result.................................................................................................19 5.2.3. Design Summary..................................................................................................19

5.3 Crossbar Switch 5.3.1. Schematic Diagram..............................................................................................19 5.3.2. Simulation Result.................................................................................................20 5.3.3. Design Summary..................................................................................................20

5.4 FIFO Buffer 5.4.1. Schematic Diagram...............................................................................................21 5.4.2. Simulation Result..................................................................................................21 5.4.3. Design Summary...................................................................................................21

5.4 Combined Module for Router 5.5.1. Schematic Diagram...............................................................................................22 5.5.2. Simulation Result..................................................................................................22 5.5.3. Design Summary...................................................................................................22

5.5 Star Topology 5.5.1. Schematic Diagram...............................................................................................23 5.5.2. Simulation Result..................................................................................................24 5.5.3. Design Summary...................................................................................................25

APPENDIX 1

Verilog Code……………………………………………………………………............26

APPENDIX 2 Test Bench Code……………………………………………………………………......38

REFERENCES…………………………………………………………………………...53

6 | P a g e

LIST OF FIGURES .

1. NoC Architecture………………………………………………………………..2

2. Logic Diagram of 4x4 Bus Arbiter……………………………………………...7

3. Routing Engine……………………………………………………………….....9

4. Crossbar Switch………………………………………………………………..10

5. Working of Circular FIFO……………………………………………………..12

6. NoC Topologies………………………………………………………………..14

7. Data flow in Star Topology…………………………………………………….16

7 | P a g e

ABSTRACT

In the deep sub micron Tech (180nm channel width) size is continuously shrinking and bandwidth

requirement is increasing, traditional shared bus architecture will no longer be able to meet the

requirements for SoC communication. The problems associated with global bus structure are first,

large capacity load for bus driver which causes large delay and huge power consumption; second

there can be only one transaction over the shared bus at a time. The bus performance is also

degraded if slow device is accessing it. Third is in DSM era design of long, wide spaghetti like

bus is a real challenge.

For effective communication between the various components on chip Router is used which

provide routing functionality with low complexity and high performance. The low latency and

high speed by allowing routing function to each input port at the same time and distributed

arbiters which gives higher level of parallelism. In the project we presented STAR TOPOLOGY

Implementation for Noc Router.

Star topology has advantage that addition of extra devices is simple and the data flow is done

through HUB. We have designed Routers, each router having four modules Arbiter, LUT and

Routing engine, cross bar Switch And Fifo buffer.

In our project we have Implemented four routers in Star connection in which all data flow is

controlled by the HUB. Each Router is connected with some processing device which gives or

requires the data to/from other devices.

8 | P a g e

CHAPTER 1 Introduction

1.1 Introduction to NOC router for SOC communication

As predicted by the International Technology Roadmap for Semiconductors (ITRS) for the next

5 to 10 years, System-on-Chips (SoCs), using 32nm transistors operating below one volt, will

grow to multi-billion transistors running at a frequency of 10GHz or higher. One of the major

challenges in designing such highly integrated SoCs will be to find an effective way to integrate

pre-designed Intellectual Property (IP) cores for power and performance concerns . As the device

feature size is continuously shrinking and the bandwidth requirements are increasing, traditional

bus-based SoC architectures have been found creating a performance bottleneck. Network-on-

Chips (NoCs) thus have emerged as a promising alternative to overcome those limitations of bus-

bused architectures by employing a packet-based micro-network for inter-IP communication. In

general, a packet-based NoC consists of routers.

The network interface is between the routers and the IP and the interconnection network. The

major challenges faced by NoC designs include scalability, energy efficiency, and re-

configurability. In designing a NoC system, the interconnection network is the key in addressing

these challenges. Numerous interconnection network topologies have been considered for NoCs,

including mesh, torus, fat tree, honeycomb, and a few others. However, the aforementioned

interconnection topologies are either not scalable or not reconfigurable.

In our project we are implementing two output modules of the router i.e. CROSSBAR MATRIX

and CIRCULAR FIFO BUFFER. Also, we are integrating these modules into a single

COMBINED MODULE. FPGA used is Kintex-7 FPGA board.

1.2 Requirement for NOC Router

Interconnection structure among the memories and processing elements determines the

performance of the system.

Three structures for interconnection

Shared bus: Easy to implement, only one processing at a time.

Crossbar switch network: several processors can access memory at same time: no of

switches increased.

9 | P a g e

Shared (multiport) memories: all processor have direct path to every memory: complex

controller inside memory.

As Size decreases with advancement of tech. BUS structure can’t be used due to following

drawbacks:

• Global Bus implies large capacity load for bus drivers that Causes delay and huge power

consumption.

• One transaction at a time in over shared bus.

• Bus performance degraded if a slow device is accessing it.

• Challenge to implement long &wide buses in Chip.

• Physical info is important in bus design while in embedded it is very hard to predict.

1.3 NOC Router Architecture

Fig 1.Router architecture

For 4 Input 4 output architecture of synchronous NoC router is as shown above.

The Router has following modules:

1. Input Arbiter

2. Routing Engine and Look up Table: Routing engine provides control signals to mux in crossbar

matrix

10 | P a g e

3.4x4 crossbars Matrix

4. Circular FIFO Buffer

CHAPTER 2. INTRODUCTION TO VERILOG

2.1 Hardware description languages (HDL)

They describe behavior of the system.

They make models independent of technology.

They model complete systems.

They speed up simulation of large systems.

High level Design is carried out at a level higher than the Gate level.

They CAE tool independent

2.2 Verilog HDL

In the semiconductor and electronic design industry, Verilog is a hardware description

language(HDL) used to model electronic systems. Verilog HDL, not to be confused

with VHDL (a competing language), is most commonly used in the design, verification, and

implementation of digital logic chips at the register transfer level (RTL) of abstraction. It is also

used in the verification of analog and mixed-signal circuits. The designers of Verilog wanted a

language with syntax similar to the C programming language, which was already widely used in

engineering software development. Verilog is case-sensitive, has a basic preprocessor (though

less sophisticated than that of ANSI C/C++), and equivalent control flow keywords (if/else, for,

while, case, etc.), and compatible operator precedence. Syntactic differences include variable

declaration (Verilog requires bit-widths on net/reg type), demarcation of procedural blocks

(begin/end instead of curly braces {}), and many other minor differences.

2.3 Levels of Design abstraction

Verilog is both a behavioral and a structural language. Each Verilog module can be

defined at four levels of abstraction depending upon the need of the design.

• Behavioral or algorithmic level: This is the highest level of abstraction provided by

Verilog HDL. A module can be implemented in terms of the desired design algorithm

without concern for the hardware implementation details. Designing at this level is very

similar to C programming.

11 | P a g e

• Dataflow level: At this level, the module is designed by specifying the data flow. The

designer is aware of how data flows between hardware registers and how the data is

processed in the design.

• Gate level: The module is implemented in terms of logic gates and interconnections

between these gates. Design at this level is similar to describing a design in terms of a gate

level logic diagram.

• Switch level: This is the lowest level of abstraction provided by Verilog. A module can

be implemented in terms of switches, storage nodes, and the interconnections between

them. Design at this level requires knowledge of switch-level implementation details.

The RTL description uses a combination of behavioral and dataflow constructs that is

acceptable to the synthesis tool.

2.4 Components of a Verilog Module

A Verilog design consists of a hierarchy of modules. Modules encapsulate design hierarchy, and

communicate with other modules through a set of declared input, output, and bidirectional ports.

Internally, a module can contain any combination of the following: net/variable declarations

(wire, reg, integer, etc.), concurrent and sequential statement blocks, and instances of other

modules (sub-hierarchies). Sequential statements are placed inside a begin/end block and

executed in sequential order within the block. But the blocks themselves are executed

concurrently, qualifying Verilog as a dataflow language.

Verilog's concept of 'wire' consists of both signal values (4-state: "1, 0, floating, undefined"), and

strengths (strong, weak, etc.) This system allows abstract modeling of shared signal-lines, where

multiple sources drive a common net. When a wire has multiple drivers, the wire's (readable)

value is resolved by a function of the source drivers and their strengths.

A subset of statements in the Verilog language is synthesizable. Verilog modules that conform to

a synthesizable coding-style, known as RTL (register transfer level), can be physically realized by

synthesis software. Synthesis-software algorithmically transforms the (abstract) Verilog source

into a netlist, a logically-equivalent description consisting only of elementary logic primitives

(AND, OR, NOT, flip-flops, etc.) that are available in a specific FPGA or VLSI technology.

Further manipulations to the netlist ultimately lead to a circuit fabrication blueprint (such as

a photo mask set for an ASIC or a bitstream file for an FPGA).

2.5 Gate level Modeling

• A digital system is described in terms of gates

• One-to-one correspondence between the logic circuit diagram and the Verilog description

• Verilog supports basic logic gates as predefined primitives(and, or, xor, nand, nor, xnor)

• These primitives are instantiated like modules except that they are predefined in Verilog

12 | P a g e

• Gates have one scalar output and multiple scalar inputs. The first terminal in the list of

gates is always an output.

2.6 Behavioral Modeling

• Decisions early in the project w.r.t. the architecture for a given algorithm.

• Design functionality can be described in an algorithmic manner (behavior)

• always and initial are the two structured procedure statements. All other behavioral

statements can appear only inside these statements.

• Verilog is a concurrent language unlike C

• always and initial statements cannot be nested. Each statement starts at simulation time 0

and represents an activity flow.

2.7 Operator types

1. Arithmetic: *, /, +, -, %(modulus),**(exponent)

2. Logical: !, &&, ||

3. Relational: >, <, >=, <=

4. Equality: ==, !=, ===(case equality including x and z) , !==

5. Bitwise operators: ~, &, |, ^, ^~ or ~^

6. Reduction: &, ~&, |, ~|, ^, ^~ or ~^

7. Shift: >>, <<, >>> (Arithmetic right shift), <<<

8. Concatenation: { }

9. Replication: { { } }

10. Conditional: ?:

2.8 Initial statement

• All statements inside an initial statement constitute an initial block.

• An initial block starts at time 0, executes exactly once during a simulation and then does

not execute again. All initial blocks start executing concurrently at time 0.

• Each block finishes execution independent of other blocks.

• Multiple behavioral statements must be grouped using the keywords begin and end

13 | P a g e

• Initial blocks are used for

executed only once during the simulation.

2.9 Always statement

• All behavioral statements inside an always statement constitute an always block.

• Starts at time ‘0’ and executes the statements in the always block continuously in a

looping fashion.

• Models a block of activity that is repeated continuously in a digital circuit.

Initial blocks are used for initialization, monitoring, waveform generation that

executed only once during the simulation.

All behavioral statements inside an always statement constitute an always block.

Starts at time ‘0’ and executes the statements in the always block continuously in a

Models a block of activity that is repeated continuously in a digital circuit.

, monitoring, waveform generation that must be

All behavioral statements inside an always statement constitute an always block.

Starts at time ‘0’ and executes the statements in the always block continuously in a

Models a block of activity that is repeated continuously in a digital circuit.

14 | P a g e

CHAPTER 3 COMPONENTS OF ROUTER

In this noc router we have implemented Arbiter, Routing engine and lookup table, crossbar matrix

and FIFO buffer using Verilog HDL in Xilinx ISE Design Suite 14.1. Then simulation results of

both modules and combined modules are shown in next chapter.

3.1 ARBITER

Input arbiter controls the arbitration of the input ports or channels and resolves

connection problem. It keeps the updated status of all the ports and knows which port is

free and which port is communicating with each other. Arbiter also solves the problem of

multiple requests coming at single output port. We are using round robin arbitration algorithm in

our simulation. The round robin arbiter scheduled the packets with same priority and destined to

the same output. The round robin operates on the principle that an input channel requests

which was served has the lowest priority in the next round arbitration.

3.1.1 ROUND-ROBIN ARBITER DESIGN

A round-robin token passing bus or switch arbiter guarantees fairness (no starvation)

among masters and allows any unused time slot to be allocated to a master whose round-robin

turn is later but who is ready now. The worst-case wait time is proportional to number of

requestors minus one. The protocol of a round-robin token passing bus or switch arbiter works as

follows. In each cycle, one of the masters (in round-robin order) has the highest priority

(i.e., owns the token) for access to a shared resource. If the token-holding master does not need

the resource in this cycle, the master with the next highest priority who sends a request

can be granted the resource, and the highest priority master then passes the token to the next

master in round-robin order.

3.1.2 Bus Arbiter Design

15 | P a g e

Fig. 2. Logic diagram of 4x4 bus arbiter block

It works on three process request, grant and Accept.

Step1- Request

Each unmatched input sends a request to every output which for which it has a queued cell.

Step2- Grant

In an unmatched output receives any requests, it chooses the one that appears next in a fixed,

round-robin schedule starting from the highest priority element. The output notifies each input

whether or not its request was granted. The pointer to the highest Priority element of the round-

robin schedule is incremented (modulo N) to one location Beyond the granted input if the grant is

accepted in Step 3 of the first iteration.

Step 3- Accept

If an unmatched input receives a grant, it accepts the one that appears next in a fixed, round-robin

schedule starting from the highest priority element.

3.1.3 Truth Table for 4x4 Priority Logic Block

16 | P a g e

Consider a scenario with four processors as bus masters connected to the same bus with one large

shared memory on the bus as a slave. Suppose the token is 4 (token=4’b0100, which means

processor 2 has the token), and only processor 0 (which uses req[0]) and processor 1 (req[1]) want

to access the memory at this cycle. Token=4’b0100 leads to the enabling of only Priority Logic 2

in Fig. 1. In Priority Logic 2, the connection to in[0] (req[2] from processor 2) indicates the

highest priority. Since req[3] is connected to in[1] of Priority Logic 2 in Fig. 1, processor 3 has

the next highest priority. However, since neither processor 2 nor processor 3 make a request, in[2]

which is connected to req[0] is next in line in priority. Thus, processor 0 is granted access to the

memory, and then the memory controller of the accessed memory sends an ack signal, whose

connection to the BA, indicating when the memory transaction is successfully completed. Next,

which could be several processor clock cycles later, the token is passed to processor 3 (the 4-bit

ring counter is rotated when the ack signal is received) in which case the token is 4’b1000.

3.1.4 ASSUMPTION FOR ARBITER DESIGN

There are three independent requests say r1, r2, r3. In the project three inputs is given as in

detailed when the input is given through the r1, r2, r3 then after the processing it shows result in

form of g1, g2, g3.

It is assumed that the priority in the order r1>r2> r3. Highest priority among the input’s is r1, then

r2 and lowest priority is r3 . When the high priority work is given to the high priority input then

when request is sent to the high priority input then acknowledge is send immediately and process

on work start on the input. Duration of access time (Timeout period) is programmed through the

independent processor and the data bus. Duration of execution or responding the programme

access time (time out period) play important role for executing the input signals. If any signal is

given to the input according to the priority but arbiter does not respond in given time then whole

process repeat again in certain time period and same acknowledge is given by certain time and

grant signal generate in timeout period then process further start, otherwise further process

become stop and process of acknowledge and grant repeat again and again.

3.2 ROUTING ENGINE WITH LOOKUP TABLE

In proposed work the function of routing engine is received packets routing to the destination

output ports. It inspects the input data stream, an address from which a data packet is coming, and

determines a destination address and output port. Routing algorithm, this defines as the path taken

by a packet between the source and the destination. Here we use the XY routing algorithm. This

way we implemented X (source address) – y (destination address) algorithm of routing. A XY

routing algorithm mainly used in NOC because for its simplicity. Is the look-up table; containing

the parameter (rotation, translation, etc.) values for the movement of each joint. Here look-up

table provides a set of source-destination address data pairs. Routing engine “takes a look” into

the look-up table and matches source packet address to the destination one. For the purpose of a

practical design simulation, we decided for ATM protocol packets. ATM provides functionality

that is similar to both circuit switching and packet switching networks. ATM uses the

17 | P a g e

asynchronous time-division multiplexing that encodes data into small and fixed size packets. In

Fig. ATM cell which consists of a 5-byte header and a 48-byte payload.

Fig 3 routing engine

3.3 Introduction to Crossbar Switch

In a network, a cross-bar switch is a device that is capable of channelling data between any two

devices that are attached to it up to its maximum number of ports. The paths set up between

devices can be fixed for some duration or changed when desired and each device-to-device path

(going through the switch) is usually fixed for some period. The crossbar provides a logical

connection between an input port and an output port. It consists of four horizontal buses (rows)

and four vertical buses (columns). A horizontal bus intersects a vertical bus at a crosspoint.

In NOC router the design of crossbar used 4-in-1 multiplexer array structure which enables each

input data channel to be connected to each output data channel. Crossbar-matrix is controlled by

two bit selected (sel) signals that are coming as process out from the routing engine. Crossbar –

based systems can be significantly less expensive than bus or ring systems with equivalent

performance because the crossbar allows multiple data transfers to take place simultaneously.

Input packets from input channel0 to input channel4 to each crossbar multiplexer. Thus every

crossbar multiplexer is having four packets as input. Output of every crossbar depends on bits

occurs on select lines of that particular crossbar multiplexer. The crossbar output lines are inputs

to output FIFO buffers.

Fig 4 cross bar switches

18 | P a g e

The above diagram shows functionality of cross bar switch. Every input data channel is connected

with every data channel. The grant signals control the flow of input data through the cross bar

switch and hence decides which input channel is connected to which output channel at a particular

instant. In NOC router the crossbar switch decides the input to the FIFO buffers in similar fashion

FLOW CHART

3.4 Introduction to FIFO Buffer

Provides temporary storage of data.

Variable size as per requirement.

Used to transfer data between devices with different clocks.

Two pointers for read and write are used.

19 | P a g e

Circular FIFO is required.

Size means number of variab

Two FIFO is used for input and output.

3.4.1 Working of Circular FIFO Buffer

RP: Read pointer

WP: Write Pointer

Fig 5

3.4.2 FlOW CHART

Circular FIFO is required.

Size means number of variables & depth means no of bits in one variable.

Two FIFO is used for input and output.

Working of Circular FIFO Buffer

Fig 5 circular fifo

les & depth means no of bits in one variable.

20 | P a g e

4

Chapter 4 STAR TOPOLOGY IMPLEMENTATION OF NOC ROUTER 4.1 NOC TOPOLOGIES Network topology refers to the shape of the network. How the different nodes in a network are

connected to each other and how they communicate are determined by the network's

topology.

Mesh topology comes in two types. They are full mesh and partial mesh. Full mesh

means that a node is connected to every other node in the network; this is a very costly

method and mostly used to connect busses.

Partial mesh means that a node doesn’t have to be directly connected to all other nodes. This type

of mesh is not as costly as full mesh, but the disadvantage is less redundancy.

2D-array is a type of mesh in which nodes form a two dimensional grid where each node

is connected to the four adjacent routers. The routers at the edges have only two or three

21 | P a g e

connections since they don’t have more adjacent routers. The number of nodes will then become

CxR where C is the number of columns and R is the number of rows.

Torus is a topology, which is similar to the 2D-array in which nodes form a regular cyclic 2-

dimensional grid. Here all routers have four connections since a torus basically is a mesh with

wrap-around on the edges.

Star topology uses a central hub to which all recourses are connected. All

communication between resources is then passed through the central hub.

Ring topology when the resources are connected to each other in a ring. Every resource is

then connected to its two neighbours communication with other resources then has to pass

through the neighbours.

Bus topology means that several resources use the samecommunication channel.

Octagon Topology is one of the type of ring topology. It consists of several eight paths

so it is called as octagon.

Binary Tree Topology(BFT) has a central root node that is connected to one or more

nodes of a lower hierarchy. In a symmetrical hierarchy, each node in the network has a

specific fixed number of nodes connected to those at a lower level. Scalable,

Programmable, Integrated Network (SPIN) architecture. This architecture implements the

topology similar to Butterfly Fat Tree Topology with some changes. In this topology router in

each level consists of same number of parent ports and child ports. This type of topological

structure provides higher throughput compared with Butterfly Fat Tree Topology.

In an ordinary local area network this can results in collisions, caused by two resources sending a

packet at the same time. If you want to avoid collisions it is a possible to let the resources send

their packet in a time slot, which is unique for each resource

22 | P a g e

4.2 STAR TOPOLOGY

Star networks are one of the most common computer network topologies. In its simplest form, a

star network consists of one central switch or hub which acts as a conduit to transmit messages.

This consists of a central node, to which all other nodes are connected; this central node provides

a common connection point for all nodes through a hub. In star topology, every node (computer

workstation or any other peripheral) is connected to a central node called a hub or switch. The

switch is the server and the peripherals are the clients. Thus, the hub and leaf nodes, and the

transmission lines between them, form a graph with the topology of a star. If the central node

is passive, the originating node must be able to tolerate the reception of an echo of its own

transmission, delayed by the two-way transmission time (i.e. to and from the central node) plus

any delay generated in the central node. An active star network has an active central node that

usually has the means to prevent echo-related problems.

ADVANTAGES

23 | P a g e

Better performance: Star topology prevents the passing of data packets through an

excessive number of nodes. At most, 3 devices and 2 links are involved in any

communication between any two devices.

Isolation of devices: Each device is inherently isolated by the link that connects it to the

hub. This makes the isolation of individual devices straightforward and amounts to

disconnecting each device from the others. This isolation also prevents any non-

centralized failure from affecting the network.

Benefits from centralization: As the central hub is the bottleneck, increasing its capacity,

or connecting additional devices to it, increases the size of the network very easily.

Centralization also allows the inspection of traffic through the network. This

facilitates analysis of the traffic and detection of suspicious behavior.

Easy to detect faults and to remove parts.

No disruptions to the network when connecting or removing devices.

Installation and configuration is easy since every one device only requires a link and one

input/output port to connect it to any other device(s).

DISADVANTAGES Reliance on central device: star topology relies on the central device (the switch, hub or

computer). This device is a single point of failure -- if this device fails, the whole network will

fail in turn.

Higher costs: the need for a central device increases costs compared to the bus and ring

topologies. The star topology also requires more cable when using Ethernet cables than ring and

bus topologies.

Limited capacity for nodes: as this type of network needs all connections to go through a central

device the amount of nodes in a network is limited by this factor whereas bus and ring topologies

are not limited in such a way

4.3 DATA FLOW IN STAR TOPOLOGY In our project we have implemented star topology with 4 routers. All the 4 Routers are connected to the hub, which is responsible for creating connections between routers depending upon the source and destination address. Each router have 4 inputs and 4 outputs. The inputs are from any processing device which is adjacent to the transmitting router and the output of destination router will going to be the input for processing device which is adjacent to the destination router. As we are having 4 routers so the address requires only 2 bits.

ROUTER ADDRESS

24 | P a g e

R1 00 R2 01 R3 10 R4 11

HUB establishes the connection depending upon the source and destination address. Suppose in address field we have 0010 this means the source router is router R1 and destination Router is R3. Now we have to swap the outputs which means outputs of router R1 will appear on the output of router R3.

Fig 7 data flow in star topology

CHAPTER 5. RESULTS AND SIMULATION

25 | P a g e

5.1 INPUT ARBITER Input to the arbiter are four request signals, clock and reset. Output of the module are four grant signals according to the priority of inputs. 5.1.1 SCHEMATIC DIAGRAM To see schematic diagram

1. Click on implementation tab. 2. Synthesis the module. 3. Click on view RTL schematic option. 4. Choose the module for which schematic is required.

5.1.2 SIMULATION

To see simulation results

1. Click on simulation tab. 2. Select the test bench code for the module. 3. Click on behavioral syntax check. 4. Click on simulate behavioral model.

26 | P a g e

5.1.3 DESIGN SUMMARY

To check design summary for components utilize 1. Under implementation tab click on synthesize –XST

2. Double click on design summary/report.

5.2 ROUTING ENGINE AND LOOKUP TABLE 5.2.1 SCHEMATIC DIAGRAM

27 | P a g e

5.2.2 SIMULATION


5.3 CROSSBAR MATRIX Input to this module are in1,in2,in3,in4 each of 8 bit. Four grant signals gnt1,gnt2,gnt3,gnt4 each of one bit are taken. Output is decided on the basis of grant signals. If value of first grant signal is high then first input in1 will be transferred to all the four outputs and so on for every grant signal.

5.3.1SCHEMATIC DIAGRAM

28 | P a g e

5.3.2SIMULATION


5.4 FIFO BUFFER

input to the module are data_in of 8 bit for input data, clk for syncronisation, e (enable) of 1 bit to

enable the fifo,read signal of 1 bit for read operation, write signal of 1 bit for write operation and

reset signal of 1 bit to make buffer reset.

Outputs are data_out of 8 bit to pop the value from the buffer

29 | P a g e

5.4.1SCHEMATIC DIAGRAM

5.4.2 SIMULATION


30 | P a g e

5.5 COMBINED MODULE for ROUTER Inputs of this module are in1,in2,in3,in4, Clk,Reset,Write and Read.

Outputs are data_out0,data_out1,data_out2,data_out3.

5.5.1 SCHEMATIC DIAGRAM

5.5.2 SIMULATION RESULT

5.5.3.DESIGN SUMMARY

31 | P a g e

5.6Module for Star Topology

5.6.1SCEMATIC DIAGRAM

32 | P a g e

5.6.2 SIMULATION RESULT

For inputs

For control signals

33 | P a g e

For outputs


34 | P a g e

APPENDIX 1

VERILOG CODE FOR INPUT ARBITER

module arbitter(req0,req1,req2,req3,gnt0,gnt1,gnt2,gnt3,rst,clk); input wire [0:7]req0,req1,req2,req3; input rst,clk; output gnt0,gnt1,gnt2,gnt3; reg gnt0=0; reg gnt1=0; reg gnt2=0; reg gnt3=0; reg temp0=0; reg temp1=0; reg temp2=0; reg temp3=0; always@(posedge clk) begin if(rst) begin gnt0=0; gnt1=0; gnt2=0; gnt3=0; end else begin gnt0=temp0; gnt1=temp1; gnt2=temp2; gnt3=temp3; end end always@(req0,req1,req2,req3) begin if (!req0 && !req1 && !req2 && !req3)begin temp0=0; temp1=0; temp2=0; temp3=0; end else if (!req0 && !req1 && !req2 && req3) begin temp0=0; temp1=0;

35 | P a g e

temp2=0; temp3=1; end else if (!req0 && !req1 && req2 && (!req3 || req3)) begin temp0=0; temp1=0; temp2=1; temp3=0; end else if (!req0 && req1 && (!req2 || req2) && (req3 || !req3)) begin temp0=0; temp1=1; temp2=0; temp3=0; end else if (req0 && (!req1 || req1) && (!req2 || req2) && (req3||!req3)) begin temp0=1; temp1=0; temp2=0; temp3=0; end else begin temp0=0; temp1=0; temp2=0; temp3=0; end end endmodule

VERILOG CODE FOR LOOK UP TABLE

module lut(w,x,y,z,E1,E2,E3,E4);

input w,x,y,z;

output E1,E2,E3,E4; reg E1=0; reg E2=0; reg E3=0; reg E4=0; parameter one=1; parameter zero=0; always @(w,x,y,z)begin if (w==1)begin

36 | P a g e

E1<=one; E2<=zero; E3<=zero; E4<=zero; end else if (x==1) begin E1<=zero; E2<=one; E3<=zero; E4<=zero; end else if (y==1) begin E1<=zero; E2<=zero; E3<=one; E4<=zero; end else if (z==1) begin E1<=zero; E2<=zero; E3<=zero; E4<=one; end else begin E1<=zero; E2<=zero; E3<=zero; E4<=zero; end end endmodule

VERILOG CODE FOR CROSSBAR MATRIX

module C_Switch(gnt1,gnt2,gnt3,gnt4,In1,In2,In3,In4,dat1,dat2,dat3,dat4);

input gnt1,gnt2,gnt3,gnt4; input [0:7] In1,In2,In3,In4; output [0:7] dat1,dat2,dat3,dat4; reg [0:7]dat1=8'b00000000;

37 | P a g e

reg [0:7]dat2=8'b00000000; reg [0:7]dat3=8'b00000000; reg [0:7]dat4=8'b00000000; always @(gnt1 or gnt2 or gnt3 or gnt4 or In1 or In2 or In3 or In4) begin case({gnt1,gnt2,gnt3,gnt4}) 4'b1000:begin dat1<=In1; dat2<=In1; dat3<=In1; dat4<=In1; end 4'b0100:begin dat1<=In2; dat2<=In2; dat3<=In2; dat4<=In2; end 4'b0010:begin dat1<=In3; dat2<=In3; dat3<=In3; dat4<=In3; end 4'b0001:begin dat1<=In4; dat2<=In4; dat3<=In4; dat4<=In4; end default:begin dat1<=8'b00000000; dat2<=8'b00000000; dat3<=8'b00000000; dat4<=8'b00000000; end endcase end endmodule

VERILOG CODE FOR FIFO BUFFER

module fifo(e,clk, rst, write, data_in, read, data_out); input clk, rst, write, read,e; input [7:0] data_in; output [7:0] data_out; reg [2:0] read_ptr=3'b000;

38 | P a g e

reg [2:0] write_ptr=3'b000; reg [3:0] count=4'b0000 ; reg [7:0] data_out; reg stack_full=1'b0; reg stack_empty=1'b1; reg [7:0] stack [7:0]; always@(posedge clk)begin case(count) 4'b0000 :stack_empty=1'b1; 4'b1000 :stack_full=1'b1; default :begin stack_empty=1'b0; stack_full=1'b0;end endcase end always @ (posedge clk or posedge rst)begin if (rst == 1) begin data_out <= 0; read_ptr <= 0; write_ptr <= 0; count <= 0; end else if (write && (!read) && (!stack_full) && (count<0111) && e) begin stack [write_ptr] <= data_in; if(write_ptr<3'b111) write_ptr <= write_ptr + 1'b1; else write_ptr<=3'b000; count <= count + 1'b1; end else if ((!write) && read && (!stack_empty) && (count<0111) && e) begin data_out <=stack[read_ptr]; if(read_ptr<3'b111) read_ptr <= read_ptr + 1'b1; else read_ptr<=3'b000; count <= count - 1'b1; end else if (write && read && stack_empty && (count<0111) && e) begin stack [write_ptr] <= data_in; if(write_ptr<3'b111) write_ptr <= write_ptr + 1'b1;

39 | P a g e

else write_ptr<=3'b000; count <= count + 1'b1; end else if (write && read && stack_full && (count<0111) && e) begin data_out <= stack[read_ptr]; if(read_ptr<3'b111) read_ptr <= read_ptr + 1'b1; else read_ptr<=3'b000; count <= count - 1'b1; end else if (write && read && (!stack_empty) && (!stack_full) && (count<0111) && e) begin stack [write_ptr] <= data_in; if(write_ptr<3'b111) write_ptr <= write_ptr + 1'b1; else write_ptr<=3'b000; data_out <= stack[read_ptr]; if(read_ptr<3'b111) read_ptr <= read_ptr + 1'b1; else read_ptr<=3'b000; end end endmodule

VERILOG CODE FOR COMBINED MODULE OF ROUTER module router(in0,in1,in2,in3,Rst,Read,Write,Clk,data_out0,data_out1,data_out2,data_out3); input [0:7]in0,in1,in2,in3; input Clk,Rst,Read,Write; output data_out0,data_out1,data_out2,data_out3; wire[0:7]data_out0,data_out1,data_out2,data_out3; wire G1,G2,G3,G4,E1,E2,E3,E4; wire [0:7] L0,L1,L2,L3; arbitter mod1(.req0(in0),.req1(in1),.req2(in2),.req3(in3),.rst(Rst),.clk(Clk),.gnt0(G1),.gnt1(G2),.gnt2(G3),.gnt3(G4)); lut mod2 (.w(G1),.x(G2),.y(G3),.z(G4),.E1(E1),.E2(E2),.E3(E3),.E4(E4));

40 | P a g e

C_Switch mod3(.di1(in0),.di2(in1),.di3(in2),.di4(in3),.gnt1(G1),.gnt2(G2),.gnt3(G3),.gnt4(G4),.d1(L0),.d2(L1),.d3(L2),.d4(L3)); fifo f1(.e(E1),.clk(Clk), .rst(Rst), .write(Write), .data_in(L0), .read(Read), .data_out(data_out0)); fifo f2(.e(E2),.clk(Clk), .rst(Rst), .write(Write), .data_in(L1), .read(Read), .data_out(data_out1)); fifo f3(.e(E3),.clk(Clk), .rst(Rst), .write(Write), .data_in(L2), .read(Read), .data_out(data_out2)); fifo f4(.e(E4),.clk(Clk), .rst(Rst), .write(Write), .data_in(L3), .read(Read), .data_out(data_out3)); endmodule

VERILOG CODE FOR STAR TOPOLOGY

module star(r1i1,r1i2,r1i3,r1i4,r2i1,r2i2,r2i3,r2i4,r3i1,r3i2,r3i3,r3i4,r4i1,r4i2,r4i3,r4i4, r1ou1,r1ou2,r1ou3,r1ou4,r2ou1,r2ou2,r2ou3,r2ou4,r3ou1,r3ou2,r3ou3,r3ou4,r4ou1,r4ou2,r4o3,r4ou4,srcadr,dstadr,RESET,CLOCK,w1,w2,w3,w4,r1,r2,r3,r4);

input RESET,CLOCK,w1,w2,w3,w4,r1,r2,r3,r4; input [0:1]srcadr,dstadr; input [0:7]r1i1,r1i2,r1i3,r1i4,r2i1,r2i2,r2i3,r2i4,r3i1,r3i2,r3i3,r3i4,r4i1,r4i2,r4i3,r4i4; output reg [0:7]r1ou1,r1ou2,r1ou3,r1ou4,r2ou1,r2ou2,r2ou3,r2ou4,r3ou1,r3ou2,r3ou3,r3ou4,r4ou1,r4ou2,r4ou3,r4ou4; wire [0:7]r1o1,r1o2,r1o3,r1o4,r2o1,r2o2,r2o3,r2o4,r3o1,r3o2,r3o3,r3o4,r4o1,r4o2,r4o3,r4o4; router R1 (.in0(r1i1),.in1(r1i2),.in2(r1i3),.in3(r1i4),.Rst(RESET),.Read(r1),.Write(w1),.Clk(CLOCK),.data_out0(r1o1),.data_out1(r1o2),.data_out2(r1o3),.data_out3(r1o4)); router R2 (.in0(r2i1),.in1(r2i2),.in2(r2i3),.in3(r2i4),.Rst(RESET),.Read(r2),.Write(w2),.Clk(CLOCK),.data_out0(r2o1),.data_out1(r2o2),.data_out2(r2o3),.data_out3(r2o4)); router R3 (.in0(r3i1),.in1(r3i2),.in2(r3i3),.in3(r3i4),.Rst(RESET),.Read(r3),.Write(w3),.Clk(CLOCK),.data_out0(r3o1),.data_out1(r3o2),.data_out2(r3o3),.data_out3(r3o4)); router R4 (.in0(r4i1),.in1(r4i2),.in2(r4i3),.in3(r4i4),.Rst(RESET),.Read(r4),.Write(w4),.Clk(CLOCK),.data_out0(r4o1),.data_out1(r4o2),.data_out2(r4o3),.data_out3(r4o4)); always @(posedge CLOCK) begin case({srcadr,dstadr}) 4'b0001 : begin r2ou1<=r1o1; r2ou2<=r1o2; r2ou3<=r1o3; r2ou4<=r1o4; r1ou1<=0; r1ou2<=0; r1ou3<=0; r1ou4<=0;

41 | P a g e

r3ou1<=0; r3ou2<=0; r3ou3<=0; r3ou4<=0; r4ou1<=0; r4ou2<=0; r4ou3<=0; r4ou4<=0; end 4'b0010 : begin r3ou1<=r1o1; r3ou2<=r1o2; r3ou3<=r1o3; r3ou4<=r1o4; r2ou1<=0; r2ou2<=0; r2ou3<=0; r2ou4<=0; r1ou1<=0; r1ou2<=0; r1ou3<=0; r1ou4<=0; r4ou1<=0; r4ou2<=0; r4ou3<=0; r4ou4<=0; end 4'b0011 : begin r4ou1<=r1o1; r4ou2<=r1o2; r4ou3<=r1o3; r4ou4<=r1o4; r2ou1<=0; r2ou2<=0; r2ou3<=0; r2ou4<=0; r1ou1<=0; r1ou2<=0; r1ou3<=0; r1ou4<=0; r3ou1<=0; r3ou2<=0; r3ou3<=0; r3ou4<=0; end

42 | P a g e

4'b0100 : begin r1ou1<=r2o1; r1ou2<=r2o2; r1ou3<=r2o3; r1ou4<=r2o4; r2ou1<=0; r2ou2<=0; r2ou3<=0; r2ou4<=0; r3ou1<=0; r3ou2<=0; r3ou3<=0; r3ou4<=0; r4ou1<=0; r4ou2<=0; r4ou3<=0; r4ou4<=0; end 4'b0110 : begin r3ou1<=r2o1; r3ou2<=r2o2; r3ou3<=r2o3; r3ou4<=r2o4; r2ou1<=0; r2ou2<=0; r2ou3<=0; r2ou4<=0; r1ou1<=0; r1ou2<=0; r1ou3<=0; r1ou4<=0; r4ou1<=0; r4ou2<=0; r4ou3<=0; r4ou4<=0; end 4'b0111 : begin r4ou1<=r2o1; r4ou2<=r2o2; r4ou3<=r2o3; r4ou4<=r2o4; r2ou1<=0; r2ou2<=0; r2ou3<=0; r2ou4<=0; r1ou1<=0; r1ou2<=0;

43 | P a g e

r1ou3<=0; r1ou4<=0; r3ou1<=0; r3ou2<=0; r3ou3<=0; r3ou4<=0; end 4'b1000 : begin r1ou1<=r3o1; r1ou2<=r3o2; r1ou3<=r3o3; r1ou4<=r3o4; r2ou1<=0; r2ou2<=0; r2ou3<=0; r2ou4<=0; r3ou1<=0; r3ou2<=0; r3ou3<=0; r3ou4<=0; r4ou1<=0; r4ou2<=0; r4ou3<=0; r4ou4<=0; end 4'b1001 : begin r2ou1<=r3o1; r2ou2<=r3o2; r2ou3<=r3o3; r2ou4<=r3o4; r1ou1<=0; r1ou2<=0; r1ou3<=0; r1ou4<=0; r3ou1<=0; r3ou2<=0; r3ou3<=0; r3ou4<=0; r4ou1<=0; r4ou2<=0; r4ou3<=0; r4ou4<=0; end 4'b1011 : begin r4ou1<=r3o1; r4ou2<=r3o2;

44 | P a g e

r4ou3<=r3o3; r4ou4<=r3o4; r2ou1<=0; r2ou2<=0; r2ou3<=0; r2ou4<=0; r1ou1<=0; r1ou2<=0; r1ou3<=0; r1ou4<=0; r3ou1<=0; r3ou2<=0; r3ou3<=0; r3ou4<=0; end 4'b1100: begin r1ou1<=r4o1; r1ou2<=r4o2; r1ou3<=r4o3; r1ou4<=r4o4; r2ou1<=0; r2ou2<=0; r2ou3<=0; r2ou4<=0; r3ou1<=0; r3ou2<=0; r3ou3<=0; r3ou4<=0; r4ou1<=0; r4ou2<=0; r4ou3<=0; r4ou4<=0; end 4'b1101: begin r2ou1<=r4o1; r2ou2<=r4o2; r2ou3<=r4o3; r2ou4<=r4o4; r1ou1<=0; r1ou2<=0; r1ou3<=0; r1ou4<=0; r3ou1<=0; r3ou2<=0; r3ou3<=0; r3ou4<=0; r4ou1<=0;

45 | P a g e

r4ou2<=0; r4ou3<=0; r4ou4<=0; end 4'b1110: begin r3ou1<=r4o1; r3ou2<=r4o2; r3ou3<=r4o3; r3ou4<=r4o4; r2ou1<=0; r2ou2<=0; r2ou3<=0; r2ou4<=0; r1ou1<=0; r1ou2<=0; r1ou3<=0; r1ou4<=0; r4ou1<=0; r4ou2<=0; r4ou3<=0; r4ou4<=0; end default : begin r1ou1<=0; r1ou2<=0; r1ou3<=0; r1ou4<=0; r2ou1<=0; r2ou2<=0; r2ou3<=0; r2ou4<=0; r3ou1<=0; r3ou2<=0; r3ou3<=0; r3ou4<=0; r4ou1<=0; r4ou2<=0; r4ou3<=0; r4ou4<=0; end endcase end endmodule

46 | P a g e

APPENDIX 2

TESTBENCH CODE FOR INPUT ARBITER module testarb; // Inputs reg [0:7]req0; reg [0:7]req1; reg [0:7]req2; reg [0:7]req3; reg rst; reg clk; // Outputs wire gnt0; wire gnt1; wire gnt2; wire gnt3; // Instantiate the Unit Under Test (UUT) arbitter uut ( .req0(req0), .req1(req1), .req2(req2), .req3(req3), .gnt0(gnt0), .gnt1(gnt1), .gnt2(gnt2), .gnt3(gnt3), .rst(rst), .clk(clk) ); initial begin req0 = 0; req1 = 0; req2 = 0; req3 = 0; rst = 0; clk=0; end always #5 clk=~clk; initial begin // Initialize Inputs #10; req0=8'b11111111; req1=0;

47 | P a g e

req2=0; req3=0; #20; req0=0; req1=0; req2=8'b10101010; req3=0; #20 req0=0; req1=0; req2=8'b10111010; req3=0; #20; #20 req0=0; req1=0; req2=0; req3=8'b11111111; #20; req0=8'b10111110; req1=8'b00011000; req2=8'b10110000; req3=8'b10000000; #20; req0=0; #20; req1=0; #20; req2=0; #20; $finish; end endmodule

TESTBENCH CODE FOR LUT

module luttest; // Inputs reg w; reg x; reg y; reg z; // Outputs wire E1;

48 | P a g e

wire E2; wire E3; wire E4; lut uut ( .w(w), .x(x), .y(y), .z(z), .E1(E1), .E2(E2), .E3(E3), .E4(E4) ); initial begin w = 0; x = 0; y = 0; z = 0; #10; end initial begin #10; w=1; x=0; y=0; z=0; #10; w=0; x=1; y=0; z=0; #10; w=0; x=0; y=1; z=0; #10; w=0; x=0; y=0; z=1; #10; $finish; end endmodule

49 | P a g e

TESTBENCH CODE FOR CROSSBAR SWITCH

module Cswitch_Test;

reg gnt1;

reg gnt2;

reg gnt3;

reg gnt4;

reg [0:7] In1;

reg [0:7] In2;

reg [0:7] In3;

reg [0:7] In4;

wire [0:7] dat1;

wire [0:7] dat2;

wire [0:7] dat3;

wire [0:7] dat4;

C_Switch uut (

.gnt1(gnt1),

.gnt2(gnt2),

.gnt3(gnt3),

.gnt4(gnt4),

.In1(In1),

.In2(In2),

.In3(In3),

.In4(In4),

.dat1(dat1),

.dat2(dat2),

.dat3(dat3),

.dat4(dat4)

);

initial begin

gnt1 = 0;

gnt2 = 0;

gnt3 = 0;

gnt4 = 0;

In1 = 0;

In2 = 0;

In3 = 0;

In4 = 0;

#20

50 | P a g e

In1=8'b11111111;

In2=8'b00001111;

In3=8'b11001100;

In4=8'b11100011;

gnt1 = 1;

gnt2 = 0;

gnt3 = 0;

gnt4 = 0;

#20

gnt1 = 0;

gnt2 = 1;

gnt3 = 0;

gnt4 = 0;

#20

gnt1 = 0;

gnt2 = 0;

gnt3 = 1;

gnt4 = 0;

#20

gnt1 = 0;

gnt2 = 0;

gnt3 = 0;

gnt4 = 1;

#20

$finish;

end

endmodule

TESTBENCH CODE FOR FIFO BUFFER

module fifo_test; reg clk; reg rst; reg write; reg [7:0] data_in; reg read; reg e; wire [7:0] data_out;

51 | P a g e

wire stack_full; wire stack_empty; wire [2:0] read_ptr; wire [2:0] write_ptr; wire [3:0] count; fifo uut ( .clk(clk), .rst(rst), .write(write), .data_in(data_in), .read(read), .data_out(data_out), .stack_full(stack_full), .stack_empty(stack_empty), .read_ptr(read_ptr), .write_ptr(write_ptr), .count(count), .e(e) ); initial begin clk = 0; rst = 0; write = 0; data_in = 0; read = 0; e=1; end always #10 clk = ~clk; initial begin rst = 1'b 0; e=1; #20 write = 1'b 1; data_in = 8'b11110011; #20 write = 1'b0; #20 write = 1'b 1; data_in = 8'b11111000; #20 write = 1'b0; #20 write = 1'b 1; data_in = 8'b11110011; #20 write = 1'b0;

52 | P a g e

e=0; #20 write = 1'b 1; data_in = 8'b11100001; #20 write = 1'b0; e=1; #20 read = 1'b 1; #20 read = 1'b0; #20 read = 1'b 1; #20 read = 1'b0; #20 write = 1'b 1; data_in = 8'b10010011; #20 write = 1'b0; #20 write = 1'b 1; data_in = 8'b00001111; #20 write = 1'b0; #20 write = 1'b 1; data_in = 8'b10000011; #20 write = 1'b0; #20 write = 1'b 1; data_in = 8'b00000011; #20 write = 1'b0; #20 write = 1'b 1; data_in = 8'b10110010; #20 write = 1'b0; #20 write = 1'b 1; data_in = 8'b00001011; #20 write = 1'b0;

#20 read = 1'b 1; #20 read = 1'b0;

#20 read = 1'b 1; #20 read = 1'b0; #20 read = 1'b 1; #20 read = 1'b0;

#20 read = 1'b 1; #20 read = 1'b0; #20 read = 1'b 1; #20 read = 1'b0; #20 read = 1'b 1; #20 read = 1'b0; #20 read = 1'b 1;

53 | P a g e

#20 read = 1'b0; #20 read = 1'b 1; #20 read = 1'b0; #20 rst = 1'b1; #20; $finish; end endmodule TESTBENCH CODE FOR ROUTER

module Router_test; // Inputs reg [0:7] in0; reg [0:7] in1; reg [0:7] in2; reg [0:7] in3; reg Rst; reg Read; reg Write; reg Clk; // Outputs wire [0:7] data_out0; wire [0:7] data_out1; wire [0:7] data_out2; wire [0:7] data_out3; // Instantiate the Unit Under Test (UUT) router uut ( .in0(in0), .in1(in1), .in2(in2), .in3(in3), .Rst(Rst), .Read(Read), .Write(Write), .Clk(Clk), .data_out0(data_out0), .data_out1(data_out1), .data_out2(data_out2), .data_out3(data_out3) ); initial begin in0 = 0;

54 | P a g e

in1 = 0; in2 = 0; in3 = 0; Rst = 1; Read = 0; Write = 0; Clk = 0; end always #5 Clk=~Clk; initial begin #20; Rst=0; Read = 1; in0 = 8'b11111111; in1 = 8'b11100000; in2 = 8'b00111100; in3 = 8'b01010100; #10; Read=0; Write =1; #20; Read=1; Write=0; in0 = 8'b00000000; #20; Write=1; #20; #10; Read=0; Write =1; #20; Read=1; Write=0; in1 = 8'b00000000; #20; Write=1; #20; #10; Read=0; Write =1; #20; Read=1; Write=0; in2 = 8'b00000000; #20;

55 | P a g e

Write=1; #20; $finish; end endmodule

TESTBENCH CODE FOR STAR TOPOLOGY

module startest;

reg [0:7] r1i1;

reg [0:7] r1i2;

reg [0:7] r1i3;

reg [0:7] r1i4;

reg [0:7] r2i1;

reg [0:7] r2i2;

reg [0:7] r2i3;

reg [0:7] r2i4;

reg [0:7] r3i1;

reg [0:7] r3i2;

reg [0:7] r3i3;

reg [0:7] r3i4;

reg [0:7] r4i1;

reg [0:7] r4i2;

reg [0:7] r4i3;

reg [0:7] r4i4;

reg [0:1] srcadr;

reg [0:1] dstadr;

reg RESET;

reg CLOCK;

reg w1;

reg w2;

reg w3;

reg w4;

reg r1;

reg r2;

reg r3;

reg r4;

wire [0:7] r1ou1;

wire [0:7] r1ou2;

wire [0:7] r1ou3;

wire [0:7] r1ou4;

wire [0:7] r2ou1;

wire [0:7] r2ou2;

56 | P a g e

wire [0:7] r2ou3;

wire [0:7] r2ou4;

wire [0:7] r3ou1;

wire [0:7] r3ou2;

wire [0:7] r3ou3;

wire [0:7] r3ou4;

wire [0:7] r4ou1;

wire [0:7] r4ou2;

wire [0:7] r4ou3;

wire [0:7] r4ou4;

star uut (

.r1i1(r1i1),

.r1i2(r1i2),

.r1i3(r1i3),

.r1i4(r1i4),

.r2i1(r2i1),

.r2i2(r2i2),

.r2i3(r2i3),

.r2i4(r2i4),

.r3i1(r3i1),

.r3i2(r3i2),

.r3i3(r3i3),

.r3i4(r3i4),

.r4i1(r4i1),

.r4i2(r4i2),

.r4i3(r4i3),

.r4i4(r4i4),

.r1ou1(r1ou1),

.r1ou2(r1ou2),

.r1ou3(r1ou3),

.r1ou4(r1ou4),

.r2ou1(r2ou1),

.r2ou2(r2ou2),

.r2ou3(r2ou3),

.r2ou4(r2ou4),

.r3ou1(r3ou1),

.r3ou2(r3ou2),

.r3ou3(r3ou3),

.r3ou4(r3ou4),

.r4ou1(r4ou1),

.r4ou2(r4ou2),

57 | P a g e

.r4ou3(r4ou3),

.r4ou4(r4ou4),

.srcadr(srcadr),

.dstadr(dstadr),

.RESET(RESET),

.CLOCK(CLOCK),

.w1(w1),

.w2(w2),

.w3(w3),

.w4(w4),

.r1(r1),

.r2(r2),

.r3(r3),

.r4(r4)

);

initial begin

r1i1 = 0;

r1i2 = 0;

r1i3 = 0;

r1i4 = 0;

r2i1 = 0;

r2i2 = 0;

r2i3 = 0;

r2i4 = 0;

r3i1 = 0;

r3i2 = 0;

r3i3 = 0;

r3i4 = 0;

r4i1 = 0;

r4i2 = 0;

r4i3 = 0;

r4i4 = 0;

srcadr = 0;

dstadr = 0;

RESET = 1;

CLOCK = 0;

w1 = 0;

w2 = 0;

w3 = 0;

w4 = 0;

r1 = 0;

r2 = 0;

58 | P a g e

r3 = 0;

r4 = 0;

#5;

end

always #2 CLOCK=~CLOCK;

initial begin

#20;

RESET = 0;

srcadr=00;

dstadr=01;

w1=1;

w2=1;

w3=1;

w4=1;

r1i1=8'b00000000;

r1i2=8'b11111111;

r1i3=8'b00000000;

r1i4=8'b00000000;

#10;

w1=0;

w2=0;

w3=0;

w4=0;

r1=1;

r2=1;

r3=1;

r4=1;

#10;

#20;

srcadr=01;

dstadr=10;

w1=1;

w2=1;

w3=1;

w4=1;

r2i1=8'b11100000;

r2i2=8'b00000000;

r2i3=8'b00000000;

r2i4=8'b00000000;

59 | P a g e

#10;

w1=0;

w2=0;

w3=0;

w4=0;

r1=1;

r2=1;

r3=1;

r4=1;

#10;

#20;

srcadr=00;

dstadr=11;

w1=1;

w2=1;

w3=1;

w4=1;

r1i1=8'b00110000;

r1i2=8'b00000000;

r1i3=8'b00000000;

r1i4=8'b00000000;

#10;

w1=0;

w2=0;

w3=0;

w4=0;

r1=1;

r2=1;

r3=1;

r4=1;

#10;

#20;

srcadr=11;

dstadr=10;

w1=1;

w2=1;

w3=1;

w4=1;

r4i1=8'b00000000;

r4i2=8'b00000000;

r4i3=8'b00000000;

60 | P a g e

r4i4=8'b00010100;

#10;

w1=0;

w2=0;

w3=0;

w4=0;

r1=1;

r2=1;

r3=1;

r4=1;

#10;

#20;

srcadr=10;

dstadr=01;

w1=1;

w2=1;

w3=1;

w4=1;

r2i1=8'b00000000;

r2i2=8'b00000000;

r2i3=8'b00110100;

r2i4=8'b00000000;

#10;

w1=0;

w2=0;

w3=0;

w4=0;

r1=1;

r2=1;

r3=1;

r4=1;

#10;

#20;

$finish;

end

// Add stimulus here

Endmodule

61 | P a g e

REFERENCES

[1] Arivu P, Shanmugasundaram N, Kamalanathan C, Dr.S.Valarmathi ,Master of Engineering Student - BIT,Sathyamangalam. Associate Professor-BIT,Sathyamangalam. Professor-BIT,Sathyamangalam. “Design of Synchronous NoC Router for System-on-Chip Communication and Implement in FPGA using VHDL” . [2] Marko R. Ili , Vladimir Z. Petrovi and Goran S. Jovanovi “Simulation of synchronous Network-onchip router for System-on-chip communication” 20th Telecommunications forum TELFOR 2012 [3] Anuprita.S. Kale, Prof. M.A.Gaikwad “Design and Analysis of On-Chip Router for Network on Chip” [4] http://eewiki.net/pages/viewpage.action?pageld=20939499 [5]http://www.design-reuse.com/articles/10496/a-comparision-of-network-on-chip-and-busses.html