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 Inst
Department 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 Technology
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

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.3. Design Summary..................................................................................................19
5.3 Crossbar Switch
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.3. Design Summary...................................................................................................22
5.5 Star Topology
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

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.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
dat2<=In2;
dat3<=In2;
dat4<=In2;
end
dat2<=In3;
dat3<=In3;
dat4<=In3;
end
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

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)
else
read_ptr<=3'b000;
count <= count - 1'b1;
end
else if (write && read && (!stack_empty) && (!stack_full) && (count<0111) && e) begin
else
write_ptr<=3'b000;
data_out <= stack[read_ptr];
if(read_ptr<3'b111)
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));
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,r4o
u2,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,r4
ou4;
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),.d
ata_out1(r1o2),.data_out2(r1o3),.data_out3(r1o4));
router R2
router R3
router R4
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;
// 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_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

Report star topology using noc router

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (7)

Similaire à Report star topology using noc router

Similaire à Report star topology using noc router (20)

Dernier

Dernier (20)

Report star topology using noc router