EE281FINALREPORT

1

Abstract – Our project was to implement a fully-
functioning User Datagram Protocol (UDP) protocol in
hardware. We used two Field Programmable Gate Array
(FPGA) development boards, one to act as sender and one
to act as receiver. We made sure to include complete UDP
segment headers of the correct size, though due to input
limitations, we could only send or receive data from ports
0 through 3. We also included the correct checksum
calculation consistent with UDP, and we demonstrated the
multiplexing and de-multiplexing functions of a transport
layer protocol.
I. Introduction
The objective of our project was to build a
transport layer platform that implemented the
complete User Datagram Protocol (UDP). We built
a fully-functional protocol in hardware, making sure
to include a properly-calculated checksum with
wrapping addition, and multiplexing/de-
multiplexing capability so that our platform could
distinguish between separate ports and sockets.
As mentioned, we built this platform in hardware,
using two FGPA development boards to represent
two hosts- one a sender, and the other a receiver.
The boards were connected with jumper wires to
simulate a network layer between the boards. We
also included the capability of introducing an error
by transmitting a wrong bit after the checksum is
calculated.
Our goal was not to build a UDP platform that
would serve a commercial application, but rather to
build a platform that would allow a user to explore
the protocol itself. Our completed project presents
a fully-functioning UDP protocol implementation
that would be good for a student to use to explore
how the protocol works. It would allow them to
send data to desired ports, view the data and
checksum values, to observe how data is only sent
to correct sockets, and to observe what happens if
an error occurs during transmission of a UDP
segment.
In addition, our project would be useful to a
designer. Designers often build transport layer
implementations in hardware instead of software
because it is faster. By building our project in
hardware, we present a ready-made platform a
designer can use to customize their own hardware
implementation. They can use our platform to
make changes to their design to improve speed, or
reduce area and power, or whatever other
customization they desire. They can also add
features that go beyond the requirements of the
protocol to build their own proprietary
implementation.
II. Background and Related Work
There are two basic transport layer protocols that
are used in almost all internet applications: the
Transmission Control Protocol (TCP) and UDP.
TCP is more widely used, but UDP still finds use in
applications where some data loss is acceptable.
TCP is definitely more robust- it includes
acknowledgements, handshaking, re-transmissions,
and a host of other features that make it desirable
for most applications. However it is fairly complex
because of this. UDP on the other hand is very
simple. It does incorporate error detection, but it
does not perform any handshaking, retransmissions,
or acknowledgement features. This makes it less
useful for applications where every packet must
arrive at the destination, but it does make it faster.
It therefore finds some application in time sensitive
applications that tolerate some data loss, such as
audio and video media streaming, but is not used for
downloading or file transfers.
The basic UDP segment contains four header
fields, each 16 bits long. The first two header fields
Implementation of User Datagram Protocol in
Hardware with FPGAs
Aditya Gulkotwar, Jagbir Kalirai, Karan Patil, and Evan Wahlin

2
are the source port and the destination port [1].
Only the destination port is necessary for proper
operation, because combined with the destination
IP, the two pieces of information uniquely identify a
socket to the application layer on a host. The
source port is still included so that if a response is
required from the destination it can use the original
source port as the new destination.
The third header field is the length field. UDP
allows a variable amount of data in the data field,
and the length header indicates the number of bytes
of the entire UDP segment including the variable-
length data field. [1]
The last header field is the checksum. This is
what allows UDP to perform error detection, which
is necessary in case segments are being transmitted
over a bad line. The checksum is calculated by
adding every two bytes in the entire segment
(excluding the checksum field itself). Any carry-
out is wrapped around and added as a carry-in to the
sum. A 1’s complement operation is then
performed on the calculated sum and this is stored
in the checksum field. [1]
To verify data integrity on the receiver side, the
same checksum is calculated but without the 1’s
complement. It is then added with the checksum
that arrived with the segment. If there were no
errors, this final sum should equal 0xFFFF. It is
possible that if there is more than one error in the
transmitted data that the final calculation will still
result in a value of 0xFFFF, erroneously indicating
that the data is correct, but the chances of this
happening are vanishingly small under normal
circumstances.
Once an error is detected, UDP often handles it
by simply throwing out that segment. It does not
include any kind of action to resend the data; that is
considered the responsibility of the application layer
when using UDP.
UDP may be simple, and it may not have an
effective way of handling errors and segment loss,
but it is still often used and there is still much
interest in developing it further as a protocol. One
application that it has been considered for is Peer to
Peer (P2P) file sharing. TCP is can be a lot less
efficient due to the presence of acknowledgements
and the distributed nature of P2P, so interest has
been shown in developing UDP for P2P
applications [2].
UDP also has no congestion control, unlike TCP,
so interest has been shown in introducing such
congestion control in applications where it would be
suitable for UDP, such as transmission of radar data
over next generation wireless connections [3].
Energy usage of UDP has also been a concern,
and in one paper it was found to be less efficient
than the Datagram Congestion Control Protocol
(DCCP) [4]. Another paper creates an entirely new
application layer protocol, named UAP, that is
based on UDP and attempts to introduce many of
the missing features that are absent from UDP itself
[5].
All of these explorations in other papers show
where our project can be useful. If one is interested
in actually building a new protocol, such as UAP,
they can do it on top of our UDP design and see
how well it works. Or they can add features to our
existing UDP design, for example, to make it
suitable for P2P applications. They can also use our
platform to explore energy efficiency or speed of a
particular UDP implementation and try to improve
it.
III. Project Description
A) Goals
Our ultimate goal was of course to build a
functioning UDP protocol. To accomplish this, we
first had to decide what it meant to implement a
protocol. It wouldn’t mean build a UDP protocol
intended for use in actual internet applications- this
already exists as a feature of just about every
network connected device. So to accomplish our
goal we decided to basically build a simulation of a
UDP protocol.
From there we decided to use two development
boards, one to act as a sender of UDP segments and
one to act as receiver. We decided that we would
build a simple bus protocol between the two boards
to act as a network layer that would provide reliable
data transfer between the two hosts.
In order to show how the protocol functions, we
had to have the capability of introducing errors as
well, and our connection between the two boards
would be essentially completely reliable. So we
decided to include the capability of introducing an
error into the data stream.

3
As for the details of the protocol itself, we had
two main foci. First, we made sure to include a
proper checksum calculation. This would require
the addition of custom designed adders. Second, we
wanted to demonstrate the multiplexing and de-
multiplexing features of UDP. To that end we
included in our design the ability to send and
receive from different port numbers, and to
distinguish between them from different sockets on
the receiver side.
B) Tools
Our first step was to decide what to use as hosts.
We decided to use two FPGA development boards
in order to build our design in hardware and make it
easy to customize. The first question was what kind
of boards to choose. We had access to Altera
boards as well as boards from Microsemi, and we
settled on the latter.
Features were important on these boards, because
we needed some mechanism for inputting and
displaying data. We wanted to use a UART-based
serial terminal to input data and display results, but
we were not sure if this would be practical, so we
settled on using switches and push-buttons to input
data and LEDs to display data.
For this reason we chose two Microsemi Igloo
Starter Kits, because they contained 8 LEDs, 8 dip
switches, and 4 push buttons which allowed for a
range of potential inputs and outputs. Microsemi
designs include UART IP cores which could have
been used for terminal communication, but they
required use of a processor, and unfortunately the
Igloo boards do not contain an embedded processor.
However we still settled on this board because it
had the largest amount of LEDs and input switches.
All of the coding and testing work was performed
within the Microsemi Integrated Development
Environment (IDE) known as Libero.
In summary, the following tools were used:
-2 Microsemi FPGA Igloo Starter Kits
- Libero IDE v11.3
- Synopsys Synplify Pro ME
- Mentor Graphics ModelSim ME
- verilog design language
- 9 jumper wires (to simulate network layer
transmission between boards)
IV. Project Approach
A) High-Level Design Considerations and
Multiplexing
By Jagbir Kalirai
Once we had decided which board would work
best for our application, we needed to come up with
a way to implement the design. There are two major
aspects that are important to making this project
successful. First, we needed to figure out what data
we wanted to display on the LEDs and how to
utilize the switches and push buttons to do so. Once
we had a solid understanding on how the switches
and push buttons would input data and how the
LEDs displayed it, we needed to decide how the
details of the protocol would be implemented on the
FPGAs.
The UDP segments were constructed on the
Source FPGA and sent to the Destination FPGA via
hardwired connection. Fig. 1 below displays a high
level representation of our design. We wanted
someone with basic knowledge of the UDP protocol
to be able to use our board and fully visualize the
workings of the protocol. Because of this, we
wanted to display the crucial aspects of UDP. This
includes data, checksum from the source board (1’s
complimented), source port number, destination
port number, error indicator and the checksum
result on the destination board. Since we are dealing
with 16 bit data and checksums, but only have 8
LEDs, we needed to create a combination of
switches to elegantly display the data. Figures 2
and 3 below shows how the position of switches 0
through 7 corresponds with a particular function of
the protocol or what is being displayed on the
LEDs. For example, if SW0 and SW1 are both on
(set to 1), the LEDs will display the least significant
bits of the checksum (bits 8 – 15) for the
corresponding board.
Fig. 1: High Level Representation of the Design

4
Note that because of the basic limitations of using
switches and pushbuttons as input, we decided to
only use ports 0-3. The segment header fields are
still fully implemented as 16 bit fields though, so if
ports of any value are implemented in the future the
design can handle it.
Fig. 2: Switches and Push Button Functionalities for
Source FPGA
Fig. 3: Switches and Push Button Functionalities for
Destination FPGA
The Source board has more functionality tied with
the switches since it’s here that we decide which
source port (SW6 and 7) to send the data from, and
whether we want to introduce an error or not
(SW5). Since we have two switches (4
combinations) controlling the source port, we
decided to have the same amount of ports on the
destination board as well. We utilized the four push
buttons to act as the destination port number. On the
source FPGA, push buttons 0 through 3 determine
which destination port the data is being sent to. On
the destination FPGA, the four push buttons allow
you to view the data on that particular port. This
demonstrates the multiplexing and de-multiplexing
capabilities of UDP. Fig. 4 below shows the
‘Display Status’ (SW4 on the source board and
SW2 on the destination board). The Display Status
lets the user view the source and destination port
numbers as well as if an error was introduced /
received.
Fig. 4: LED Array ‘Display Status’ Configuration
Now that we understand how the switches and
push buttons interact with the LEDs, let’s see how
the protocol is created using block diagrams. Fig. 5
shows the block diagram of the source FPGA. The
16 bit fixed data is selected from a memory bank,
and the source and destination port numbers
selected via switches and push buttons. The length
is calculated based on the amount of data taken
from memory. In our design this is a fixed 2 bytes.
These data make up three out of the four fields in
the UDP header. The adder and 1’s compliment
blocks are required to compute the checksum,
which makes up the final UDP header field.
Depending on the configuration of SW5, an error
can be introduced after the UDP segment has been
assembled. The segment is broken into eight bit
chunks and sent to the destination board serially
through the multiplexer. The source FPGA contains
LED logic which displays information based on the
switches and push buttons.

5
Fig. 5: Block Diagram of Source FPGA
Similar features were implemented on the
destination FPGA. Fig. 6 below corresponds to the
workings of the destination board. The data is
received in eight bit chunks and gets de-
multiplexed. The UDP segment bits go through
several adders to determine the result of the
checksum. This result is then added to the received
checksum value. If there were no errors introduced,
the final result should be 16 bits of consecutive 1s.
The information being displayed on the
destination FPGA LEDs consists of 37 total bits as
shown in the figure below. These 37 bits include 16
bits of data, 16 bits of the checksum calculation
result, 2 bits each for the source and destination
ports, and 1 bit if an error was detected. This
information needs to be collected from the
incoming UDP segment and the checksum result. If
the UDP segment was sent to port 3 (for example),
the 37 bits of data would be stored into a memory
location associated with port 3.
These memory locations act as a buffer to hold
the data until the application layer decides what to
do with it. A de-multiplexer is used to connect to
each of the four memory locations to the LED
outputs, and push buttons 0 through 3 are used to
select which memory location to display on to the
LEDs. Depending on the positions of switches 0
through 7, various data (from the 37 bits) can be
displayed. Because of the need for numerous
memory locations- 37 bits for every port- the de-
multiplexer is expressed in our code as a series of
conditional if-else statements and case statements.
An example is shown below:
if (socket_num == 1) begin
if (~show_status) begin
led <= #0 status1;
end else begin
….
case (~which_disp) // pulled-up input DIPs
2'h0: led <= #0 mem1[8]; // MSB Data
2'h1: led <= #0 mem1[9]; // LSB Data
2'h2: led <= #0 mem1[6]; // MSB Chksum
2'h3: led <= #0 mem1[7]; // LSB Chksum
default: led <= #0 0;
endcase
end
end
end
This portion of the code illustrates the de-
multiplexing. If one pushes the button for port 1,
then the socket_num will equal 1. Then the output
on the LEDs will be based on what is stored in
“mem1”. By distinguishing between the ports, this
portion of the code performs the de-multiplexing.
Fig. 6: Block Diagram of Destination FPGA
B) Design of Checksum Calculation
By Evan Wahlin
In order to accurately create the UDP protocol,
there were two main features we made sure to
include. First, we had to demonstrate the ability of
UDP to deliver data to the correct sockets. This
was done by multiplexing the data on the source
board and de-multiplexing the data on the
destination board and sending it to a simulated
socket. This is shown in the previous section.
When a push button on the source board is pressed
it multiplexes the segment from that associated port
and sends it to the destination board. The data is
then de-multiplexed by pressing a push button on

6
the destination board, each one representing a
socket associated with the destination port, and
displayed on the LEDs.
The second major feature of UDP that we
included was the calculation of the checksum. UDP
does not contain a lot of features, but one feature it
does include is error detection. The process of
calculating the checksum is described above, but we
still had to implement it.
First it is important to understand that our design
philosophy was to create everything as much as
possible at the hardware level. This would allow
for a designer to modify portions of our design at
that same level with the goal of exploring
improvements in speed, area, and power use. To
this end we felt it was critical to build a hardware
based adder.
We settled on the choice of a type of parallel-
prefix adder (PPA) called a Kogge-Stone (KS)
adder. A standard (non-PPA) adder, called a ripple-
carry adder, works by adding each bit of each input
number in series, so that the 2nd
sum bit is not
calculated until the 1st
one completes, and the 16th
bit has to wait until all of the preceding 15 bits
finish adding. This is simple to design, but is slow.
A PPA on the other hand works by evaluating all
of the input bits simultaneously, determining
whether a “propagate” or a “generate” is produced.
A propagate indicates that if a carry bit comes into
that block, then a carry bit will go out. A generate
indicates that regardless of the state of the carry-in
bit, a carry-out will be produced. By combining
these two, it is possible to calculate the results of all
of the bit additions in a parallel manner, making for
a much faster calculation.
A sample diagram for a 4-bit K-S adder is shown
below in Fig. 7. Each colored block contains a
combination of propagate and generate logic, and
the sum is calculated in the blocks on the lowest
horizontal level. A sample Propogate-Generate
block that we used in our project is shown below:
/// pg block
module pg (a, b, g, p );
input a, b;
output p, g;
assign g = a&b;
assign p = a^b;
endmodule
The design of our 16-bit K-S adder was based on
two 8-bit K-S adders connected in series, and each
8-bit K-S adder was an implementation similar to
two of the displayed sample 4-bit K-S adders
connected in series. A small example of how the
blocks were connected is shown in the code below:
//level one
pg pg7 (a[7], b[7], g17, p17);
pg pg6 (a[6], b[6], g16, p16);
pg pg5 (a[5], b[5], g15, p15);
pg pg4 (a[4], b[4], g14, p14);
pg pg3 (a[3], b[3], g13, p13);
pg pg2 (a[2], b[2], g12, p12);
pg pg1 (a[1], b[1], g11, p11);
pg pg0 (a[0], b[0], g10, p10);
That is just one level and each of those values
represents a wire. This type of adder clearly has a
lot of wiring involved.
Fig. 7: Four-Bit Kogge-Stone Adder [6]
One feature that the checksum calculation
contains, but that is normally missing from adder
design, is the ability to wrap. If there is any carry-
out from the 16th
bit of the sum calculation, UDP
states that it should be added to the lowest bit of the
sum. Implementing this, however, was a simple

7
matter of connecting the carry-out from the adder to
the carry-in, literally wrapping it into itself. The
code is shown here:
wire c, c_inter;
add_8 a_low( a[7:0], b[7:0], c, s[7:0], c_inter);
add_8 a_hig( a[15:8], b[15:8], c_inter, s[15:8], c);
In this code, wire “c” represents the carry-out of
the most significant 8-bit adder, and it is fed directly
to the carry-in of the least significant 8-bit adder.
After designing a simple 16-bit K-S adder, the
question became how to utilize it in our design. We
had to use our adder to compute the total sum of
four different segment fields: the source port, the
destination port, the length, and a 2-byte data field.
Each of these was 16 bits wide. We considered
calculating them sequentially. This would require
three additions, but it would take three clock cycles
to complete.
Instead we decided to improve performance by
instead instantiating three of the 16-bit adders and
calculating sums in parallel. This would reduce the
potential speed of summation by up to 50%,
because it would require only two layers of
calculation. However, it would take up more area,
using 3 adders instead of 1. A diagram of this
implementation is shown below in Fig. 8. The code
is a lot simpler though than if it were coded
sequentially. The instantiation of all three adders is
shown below:
input [15:0] sp, dp, l, d;
output [15:0] s;
wire [15:0] a, b;
add_16 a1(sp, dp, a);
add_16 a2(l, d, b);
add_16 a3(a, b, s);
Fig. 8: Parallel Adders
On the source side, the checksum was then
calculated by simply inverting the result of the sum.
This produced the 1’s complement result. This data
was then delivered to the buffer to be sent to the
destination board. The 1’s complement is shown by
the following code:
always @(*) begin
if (!nrst) begin
chk_sum = 0;
end else begin
chk_sum = ~sum;
end
end
This code is a combinational logic block that
assigns 0 to the checksum upon reset, and otherwise
just 1’s complements the output of the three-adder
block.
On the destination side, the same three-adder
scheme was used to calculate the checksum, but
without a 1’s complement. By simply AND-ing the
results of this calculation with the received
checksum data we could verify that the result was
0xFFFF, or all 1s. We then used a reduction-AND
on this result to determine if there was an error. A

8
reduction-AND will produce a 1 output only if
every input bit is a 1. If any zeroes were produced
in the checksum calculation, an error would result.
This operation is compactly shown in the following
code, in which the reduction AND is stated as an
“if-then” clause:
assign error = (!nrst) ? (0) : ( (done) ? ( ( chk_sum_final
!= 16'hFFFF) ? (1) : (0) ) : (0) ) ;
The main feature of a K-S adder is that it is fast.
Since we believe that speed might be of prime
importance to a user of our platform, we felt that
this would be the best choice of adder to use. This
was also why we decided upon a parallel calculation
by instantiating three adders on the source and
destination to calculate the checksum.
However, K-S adders have disadvantages. The
main one is that they take up a lot of area, and they
have a lot of wiring and routing. This can be seen
from the following Fig. 9, which (including the
grayed-out portions) shows all of the hardware and
wiring necessary for a 16-bit K-S adder. Along
with more hardware comes the fact that such an
adder will use more power.
Fig. 9: Wiring in 16-Bit Kogge-Stone Adder [7]
However, this fits in with the entire purpose of
our project. We selected a K-S adder and then
instantiated it seven times for all of the checksum
calculations, but maybe a designer is less interested
in speed. They could design a simple 16-bit ripple
carry adder, which would use significantly less
hardware, and then instantiate it just once on each
of the source and destination boards. They could
then put that in place of our adder and use our
design to still perform UDP transfers, and
potentially measure things like the speed of the
transfers and power usage.
C) Bus Protocol, Hardware, and Verilog Coding
By Aditya Gulkotwar
Checksum and multiplexing are the key features
of UDP, but it required more than that to implement
our protocol. A standard UDP design will function
based on the assumption that there is an already
existing network layer to send data to, but in our
project we had to build one ourselves. We did this
by connecting 9 jumper wires between the boards to
act as a bus.
In this project, we have used 8-pins of each
FPGA as a data bus (Data_Bus) and 1-pin as an
enable signal (SEND_ENABLE). Whenever the
enable pin is HIGH, the receiver will come to know
that sender is sending a new UDP packet. Below is
a simple block diagram showing the connection
between the two FPGA boards.
Fig. 10: Basic Communication Between Boards
Communication Steps
To understand how the communication between
boards works, imagine the following process:
(1) Let’s say sender wants to send a data from
‘Source Port’ (2) to ‘Destination Port’ (3) and 2-
byte Data (0x1A2F).
(2) Sender will calculate the number of bytes to
be sent i.e. the ‘Length’ field (10 bytes).
(3) Sender then will also calculate the
‘Checksum’ (in this case, 1’s Compliment of
(Source port + Destination Port + Length + Data)
=> 1’s Compliment of (0x1A3E) =>0xE5C1)

9
(4) Sender will then re-arrange all the data in the
following format to make 1 UDP Segment:
Source
Port
Destinat
ion Port
Length Checksu
m
Data
M
SB
LS
B
M
SB
LS
B
M
SB
LS
B
M
SB
LS
B
M
SB
LS
B
0x
00
0x
02
0x
00
0x
03
0x
00
0x
0A
0x
E5
0x
C1
0x
1A
0x
2F
Fig. 11: Transmitted UDP Segment
(5) Sender will set ‘SEND_ENABLE’ to high.
As shown in timing diagram below, 1-Byte of UDP
Segment will be sent at every Rising Edge of the
Clock.
Fig. 12: Timing Diagram of Bus Protocol
(6) As soon as the ‘SEND_ENABLE’ goes high,
the receiving UDP FPGA will sense that it has to
read the incoming UDP Segment from ‘Data_Bus’.
(7) And the receiver FPGA will sequentially save
the incoming segment (byte-by-byte) depending on
the ‘LENGTH’ field.
The send process is based on a 4-bit counter that
counts up to a decimal value of 10. We use this
simple counter application because in our project
we know we are going to be sending exactly 10
bytes. The code which illustrates this process is
shown below:
if (cnt < 4'hA) begin
send_en <= #0 1;
cnt <= #0 cnt + 1; // update to-send
if (cnt == 4'h9) begin
dout <= #0 (
(~error)?({to_send[cnt][7:4],~to_send[cnt][3],to_send[c
nt][2:0]}):(to_send[cnt][7:0]) ); // 1 UDP Segment
end else begin
dout <= #0 to_send[cnt]; // 1 UDP
Segment
In this code one can see that everything in the
“to_send” register will be sequentially sent out, with
the exception of the situation that an error has been
purposely introduced.
Hardware
Microsemi’s IGLOO board has a Crystal
Oscillator of 20 MHz. We used this oscillator to
clock all of our sequential logic. The following is
the Schematic of the crystal oscillator network on
the Igloo board.
Fig. 13: Oscillator Circuit on Microsemi IGLOO
nano Board [8]
The board we used has an active-low reset. The
reset signal is used to reset the entire design to
initial state. The board has a Schmitt Trigger circuit
to minimize the key-bouncing problem. The RC
network determines the pulse width of the ‘Reset’.
Fig. 14: Reset Circuit on Microsemi IGLOO nano
Board [8]
DIP switches serve as active-low inputs to the
FPGA. They are pulled-up by using external pull-up
resistors (RP1) to VCC (3.3V supply). It means that
when the switch is OPEN we have VCC (3.3 V) at
output; and when switch is closed, it forces the
output voltage to go low GND (0 V).
TimeGen Demo
TimeGen Demo
1 2 3 4 5 6 7 8 9 10 11 12 13
TimeGen Demo
TimeGen Demo
TimeGenDemo
TimeGenDemo
TimeGenDemo
TimeGenDemo
TimeGenDemo
TimeGenDemo
TimeGenDemo
TimeGenDemo
TimeGenDemo
TimeGen Demo
Source Port Destination Port Length Checksum Data
TimeGen
Clock
Send_Enable
Data_Bus

10
Fig. 15: Dipswitches on Microsemi IGLOO nano
Board [8]
The push button circuit is also similar to the DIP
switches. The only difference is that the switch will
be closed only when we have pressed it and will be
detected as soon as we release the switch. The push
buttons are also connected to VCC through external
pull-up resistors- they are also active-low.
Fig. 16: Push Buttons on Microsemi IGLOO nano
Board [8]
We used 8 LEDs on the IGLOO nano board to
display 8-bit information based on the DIP switches
positions. As seen from the figure the LEDs are
arranged in a “Common-Anode” configuration. It
means that to light up an LED we need to apply
logic 0 (0 V) on Cathode side. This is done to
reduce the current sinking from the FPGA chip.
Fig. 17: LED Circuit on Microsemi IGLOO nano
Board [8]
Verilog Source Design
On the source FPGA we had a small memory of
10 16-bit numbers which were to be sent from
source to destination. This was done because we
didn’t have any option to enter user defined data.
We consider this memory to be directly associated
with the application layer of the sender side.
Whatever data the sender wants to send gets
collected in this memory.
The source port and destination port are provided
by flipping the desired switched and pressing the
desired push-button as described in section 4.A.
Once we provide the source port number and the
destination port number, the source FPGA will wrap
all the information into a UDP Segment. In Verilog,
we do this by storing all the 10 bytes (UDP
Segment) of information in the “to_send” register.

11
An example of this register assignment is shown
below:
assign to_send[0] = (!nrst) ? (0) : (8'h0);
// Source Port (MSB)
assign to_send[1] = (!nrst) ? (0) : ({6'h0,(~src_port)});
// Source Port (LSB)
The “checksum” is calculated by adding all the
elements, including source and destination port
numbers, the length of the UDP segment (in bytes)
and the data. The result of the addition is wrapped
up according to the UDP protocol and we take the
1’s complement of the result. Thus we get the
checksum and we store the checksum in the
following format in the “to_send” register:
to_s
end
[0]
to_s
end
[1]
to_s
end
[2]
to_s
end
[3]
to_s
end
[4]
to_s
end
[5]
to_s
end
[6]
to_s
end
[7]
to_s
end
[8]
to_s
end
[9]
Sou
rce
Port
(M
SB)
Sou
rce
Port
(LS
B)
Des
t.
Port
(M
SB)
Des
t.
Port
(LS
B)
Len
gth
(M
SB)
Len
gth
(LS
B)
Che
cks
um
(M
SB)
Che
cks
um
(LS
B)
Dat
a
(M
SB)
Dat
a
(LS
B)
Fig. 18: Sent Data
Before sending the data out, the sender checks the
status of the ‘ERROR’ DIP switch. If the error
switch is turned ON, then while sending the packet,
the sender introduces error by flipping bit D3 of the
data (LSB). Then the source will set the
“Send_enable” to ‘1’ and start sending data
sequentially byte-by-byte from ‘Data_out’. The
error introduction is shown in part of the bus
protocol code shown at the beginning of section
4.C, specifically the following line:
if (cnt == 4'h9) begin
dout <= #0 (
(~error)?({to_send[cnt][7:4],~to_send[cnt][3],to_send[c
nt][2:0]}):(to_send[cnt][7:0]) ); // 1 UDP Segment
end
This code means that when an error is detected,
instead of sending the normal data in the “to_send”
register, it will send a modified version of that data
with bit [3] flipped. This will introduce a
deterministic error into the segment transmission.
Verilog Destination Design
We had only four push button switches on the
source FPGA for specifying the destination ports.
Thus a maximum of 4 sockets can be created with
the help of destination port number. According to
the UDP protocol, the socket gets created by a
“two-tuple” (Destination IP, Destination Port), but
in this project we were using only one interface so
we assumed Destination IP address to be same. All
these 4 sockets have 10 bytes of buffer memory
each. This memory is used by the destination board
to store the last received packet associated with that
socket (Destination Port). And when we want to
check the content of that Destination Port / Socket,
we just press the push-button associated with that
socket. This is how the de-multiplexing on the
destination board is done.
On the destination FPGA board, we have
interfaced switches and LEDs similar to that of
source FPGA. The code for the destination board is
very similar to that employed in the source board.
As the destination board senses the ‘send_enable’
signal, it starts storing the bytes from data bus into
an array of 10 bytes, similar to ‘to_send’ of source,
called ‘incoming’. Once the receiver receives all of
the 10 bytes sequentially into the array, it sets a flag
called ‘new_value’. Once this flag is set, the
destination FPGA will perform de-multiplexing just
by looking onto the 4th
byte of ‘incoming’ register
(Destination port Lower Byte) and store the content
of ‘incoming’ into the associated memory. We can
check the content of the last byte received on any of
the 4 sockets just by pressing the push-buttons on
the LEDs.
The ‘checksum’ gets re-calculated by adding all
the contents of ‘incoming’ register except the 16-
bits of received checksum. Then the result of the
addition is added directly with the 16-bit checksum
received from source FPGA in the ‘incoming’
register. This result should be equal to 0xFFFF i.e.
all bits are 1s. If all are 1s, it means that no error
was detected. But if it is not all 1s, then there was
an error. When the error is detected, the receiver
FPGA assigns a special signal to that socket which
indicates that whenever we try to see the data on
that socket, LEDs start flashing. This will indicate
to the user that an error was detected and that the
received segment is of no use. When an error is
detected, the receiver will also set the ‘error_flag’

12
in the status register to ‘1’ so that when the user is
checking for the status of that socket, he can see the
error LED glowing.
D) Simulation and Verification of Design
By Karan Patil
Simulation plays a key role in any project. Before
actually implementing the design on the board, we
need to make sure that the logic which we wrote for
the design is completely correct. This helps a lot in
debugging and saves time. For simulating any
design in Verilog, we have to create a test bench. A
test bench consists of all the test cases, possibly all
the possible combinations of valid inputs that can be
given to the design when it is implemented in the
real-time. Thus we have to use the design interfaces
to talk to the design.
This is called ‘black-box’ testing model. In this
model, we just have to provide a set of inputs to the
design and check for the functionality of the design.
In our project, we used Mentor Graphics’ Software
to view the waveforms generated after simulation.
In the waveforms, we can check the content of all
the registers used in the design and try to verify
whether the design is providing the correct results
or not. If not, then we look into the related registers
contents and try to find the source from where the
error is getting propagated. Once we are assured
that the Verilog design logic is correct, then we
program the device and check the results.
Source FPGA Simulation
We first wrote a test bench to test our source
board. Fig 19 shows the simulation design of the
source FPGA. We wrote a test bench using this
model to check the output of the signals for their
desired functions.
The elements of the design and their desired
functions are as follows:
Clk: The clock (active low), data is received
when clk goes low.
Nrst: Negative reset. Initially set to 0, when we
push the reset button on board, the nrst signal goes
high and clears all the registers.
Source Port: Selected Source port.
Destination Port: Selected Destination port.
Status: Show status, which is initially set to 0.
When a button is pressed value set to 1 and display
shows source port, destination port, and error bit (if
introduced) on the LEDs.
Which Display: Set the dip switches values to
view respective information on LEDs.
Send Enable: When enabled the source starts
sending the UDP packet.
Error: Initially set to 0, when enabled the value
is set to 1 and an error introduced before sending
the packet.
Data: Data_Out; when send enable goes high,
source starts sending the data.
LED: Initially set to 0, when a push button is
pressed, displays the respective information on
LEDs.
Fig 19: Source FPGA Simulation

13
A piece of sample code showing how we
stimulated these inputs is shown below:
src_port = 2'b10; // source port = 1
error = 1; // no error
which_disp = ~(2'b00); // MSB Data
#20;
dest_port = ~(4'b0100); // dest port 2 [D3 --- D0]
#20;
dest_port = ~(4'b0000); // dest port 2 [D3 --- D0]
#100;
show_status = 0; // Press
#40;
show_status = 1;
#100;
which_disp = ~(2'b01); // LSB Data
Figure 3 shows waveform output of the first
simulation. We can see the source port number is 1,
destination port number 2. The length is 10 bytes as
expected and we can also see the result of the
checksum calculation. Those values are the values
we tested for our design in the test bench.
Fig.20: Output of source simulation
Destination FPGA Simulation
Next we wrote a test bench to simulate our
destination board. This test was a bit more complex
because there is more information to check on the
destination board, including error conditions. Fig.
21 shows our test bench schematic for our
destination board.
The elements of the design and their desired
functions are as follows:
Clk: The clock (active low), data is received by
destination board when clk goes low.
Nrst: Negative reset. Initially set to 0, when we
push the reset button on board, the nrst signal goes
high and clears all the registers.
Source Port: Selected Source port.
Destination Port: Selected Destination port on
which data is received.
Status: Shows status (initially set to 0), when the
button is pressed the value is set to 1 and displays
source port, destination port, and error bit (if
introduced) on the LEDs.
Which Display: Set the dip switches values to
view respective information on LEDs.
Send Enable: When enabled the destination
knows something is received on some port.
Data: Data_in; when send enable goes high,
destination receives the data.
LED: Initially set to 0, when push button is
pressed, respective information is displayed on
LEDs.
Fig.21: Destination FPGA Simulation
A piece of a sample testbench is shown in the
code below:
send_en = 1;
while (i < 10) begin

14
din = send1[i];
#20; i = i + 1;
end
send_en = 0;
#40;
// chk Socket 0
sel_socket = ~(4'h1);
#20;
sel_socket = ~(4'h0);
show_status = ~(1); // show status
#20;
show_status = ~(0);
which_disp = ~(2'h0); // MSB Data
#20;
In this code we can see how we stimulated the
inputs. The data in was sent into the destination
board by cycling through 10 bytes of stored data
that was created in the testbench itself.
Figure 5 shows waveform output of the
simulation where we can see the selected socket
number is 0 i.e. the destination port number 0 but
there is no data received on that port hence the LED
output shows nothing.
Fig. 22: Destination Simulation Output 1
In the figure 6 below, the waveform output of
simulation where we can see the selected socket i.e.
the destination port number is 3 and source port
number is 1. Data received as 5ab2 and the
checksum is all 1’s which implies that no error has
occurred.
Fig. 23: Destination Simulation Output 2
V. Results
Throughout the design process we ran into issues.
First we had some problems calculating our
checksum, particularly when a segment was sent
twice to the same destination port. Our design
allowed for this, the new data overwriting the old
data. However we had errors with that. After
modifying our code we were able to fix this issue.
In the end we were able to verify the proper
functioning of every aspect of our project. We
began by just sending a packet on the source and
verifying that the correct port information, data, and
checksum calculation were displayed on the source
LEDs.
Our next step was to verify that the data was
correctly received and displayed on the destination
board, which we were able to do. We verified the
correct ports, the data, and that the checksum result
displayed 0xFFFF. We were also able to verify that
if we sent data to a particular port, say port 3, that
nothing would display on port 2. We also verified
that if we sent data to ports 2 and 3 that viewing the
destination port information would switch between
the correct data for each port. This verified our de-
multiplexing. We checked this with every available
port combination.
Finally we wanted to verify the correct operation
when an error is introduced. We introduced an
error and verified that when we displayed the
received data on the correct port that all of the
LEDs blinked. We also were able to view the
checksum result, and verify that it was not all 1s.
Further, we verified that when a segment with an
error was sent to one port, that viewing a separate

15
port still displayed the stored data and other
information for that port.
The following video shows an operation sending
data from one board to another:
https://youtu.be/AZsGN6Y0Jp8 . A second video
(https://youtu.be/CzQlzHYP-zQ) shows display of
checksum information. We have a final video
(https://youtu.be/R3m59DoTzNQ) which shows the
introduction of an error, the bad data, and the
verification that the checksum result is not 0xFFFF.
VI. Further Work
Although we believe our project would be a great
platform for exploring UDP, it has several
limitations that can be improved upon in future
designs. First is the fact that our input is limited to
stored data and by the number of switches and
pushbuttons we have. Second is that our
application layer output is limited to 8 LEDs. To
improve this, our next step would be to remove the
LED and switch implementation and instead use a
serial terminal program (like HyperTerminal) to
input custom data. This would also allow us to
choose any port number we want, not just ports 0
through 3.
Another good improvement would be to modify
our design to communicate both directions.
Currently we have one FPGA as a dedicated sender
and one as a dedicated receiver. If we implemented
it both ways, we could allow for response messages.
By combining the above two improvements, we
would have a platform that could almost fully
implement a custom application layer protocol, if
desired, on top of our transport layer design. We
could even put our design on multiple FGPAs so
that we aren’t limited to two hosts.
Another improvement that could help would be to
create some system for our design that measured
various statistics of segment transfers, such as
power usage and speed. This is of course already
included in design synthesis, but this would have to
be done for any number of different types of
segment communication (for example, if the data is
long or short, or if response messages are required).
This becomes a statistical measurement, and it
could be used to compare different implementations
of our design for someone who is trying to improve
or modify it.
Beyond UDP the next major step would be to use
our core design concepts to implement TCP itself.
This would be a big improvement, because TCP is
ubiquitous, but it would also be a big project. TCP
is a lot more complicated and involves a lot of
different features that would need to be included. It
would have to include congestion control so we
would have to think about how to simulate
congestion control and how to introduce errors.
However, once all of those challenges are
overcome, it would be a much more applicable
design if it had TCP instead of UDP.
VII. Conclusion
In the end we felt we accomplished all of our
goals with our project. We had hoped that we
would be able to implement serial terminal
communication to give our implementation a lot
more flexibility. However we knew that it may
have been unrealistic to expect that, so we were
satisfied with using the switches and LEDs as inputs
and outputs.
What was more important than the format of the
I/O was the fact that in the end our project worked,
and that even though our data was limited and our
port range was limited from 0 to 3, we still created
complete UDP segments with all of the proper
headers of the proper length. That way if the input
and outputs are ever upgraded, the rest of the design
will accommodate segments of the proper size
already. We hope that our project will be of good
use, at least as a teaching tool, if we are ever able to
include custom data and port numbers.
References
[1] Postel, J. "User Datagram Protocol." Accessed
December7,2015.
https://www.ietf.org/rfc/rfc768.txt.
[2] Yao-Nan Lien, Hong-Qi Xu, "A UDP Based
Protocol for Distributed P2P File Sharing," 2013
IEEE Eleventh International Symposium on
Autonomous Decentralized Systems (ISADS), pp.
318-324, Eighth International Symposium on
Autonomous Decentralized Systems (ISADS'07),
2007

16
[3] S.L. Bangolae, A.P. Jayasumana, V.
Chandrasekar, "TCP-friendly congestion control
mechanism for an UDP-based high speed radar
application and characterization of fairness,"
Communication Systems, International Conference
on, pp. 164-168, The 8th International Conference
on Communication Systems - Vol 1 (ICCS'02),
2002
[4] Mamun Abu-Tair, Saleem N. Bhatti, "Energy
Usage of UDP and DCCP over 802.11n," 2014
IEEE 28th International Conference on Advanced
Information Networking and Applications, pp. 313-
320, 2014 IEEE 28th International Conference on
Advanced Information Networking and
Applications, 2014
[5] Guanfeng Lv, Xudong Xu, Kaile Su, Qingliang
Chen, "UAP: A New UDP-Based Application Level
Transport Protocol," 2013 Fourth International
Conference on Networking and Distributed
Computing, pp. 3-6, 2011 Second International
Conference on Networking and Distributed
Computing, 2011
[6] "Example of a 4-bit Kogge–Stone Adder with
Zero Carry-in." Wikipedia. June 25, 2009. Accessed
December7,2015.
https://en.wikipedia.org/wiki/Kogge–
Stone_adder#/media/File:4_bit_Kogge_Stone_Adde
r_Example_new.png.
[7] "Example of a 4-bit Kogge–Stone Adder with
Zero Carry-in." Wikipedia. June 25, 2009. Accessed
December7,2015.
https://en.wikipedia.org/wiki/Kogge–
Stone_adder#/media/File:4_bit_Kogge_Stone_Adde
r_Example_new.png.
[8] "IGLOO Nano Starter Kit - User's Guide." 2013.
Accessed December 7, 2015.
http://www.microsemi.com/document-
portal/doc_view/130838-igloo-nano-starter-kit-user-
s-guide.

17
Included Figures (Full Size)
Figure 1: High Level Representation of the Design
Figure 2: Switches and Push Button Functionalities for Source FPGA

18
Figure 3: Switches and Push Button Functionalities for Destination FPGA
Figure 4: ‘Display Status’ Configuration
Figure 5: Block Diagram of Source FPGA

19
Figure 6: Block Diagram of Destination FPGA
Fig. 7: Four-Bit Kogge-Stone Adder [6]

20
Fig. 8: Parallel Adders
Fig. 9: Wiring in 16-Bit Kogge-Stone Adder [7]

21
Fig. 10: Basic Communication Between Boards
Source Port Destination
Port
Length Checksum Data
MSB LSB MSB LSB MSB LSB MSB LSB MSB LSB
0x00 0x02 0x00 0x03 0x00 0x0A 0xE5 0xC1 0x1A 0x2F
Fig. 11: Transmitted UDP Segment
Fig. 12: Timing Diagram of Bus Protocol
Fig. 13: Oscillator Circuit on Microsemi IGLOO nano Board [8]
TimeGen Demo
TimeGen Demo
1 2 3 4 5 6 7 8 9 10 11 12 13
TimeGen Demo
TimeGen Demo
TimeGenDemo
TimeGenDemo
TimeGenDemo
TimeGenDemo
TimeGenDemo
TimeGenDemo
TimeGenDemo
TimeGenDemo
TimeGenDemo
TimeGen Demo
Source Port Destination Port Length Checksum Data
TimeGen
Clock
Send_Enable
Data_Bus

22
Fig. 14: Reset Circuit on Microsemi IGLOO nano Board [8]
Fig. 15: Dipswitches on Microsemi IGLOO nano Board [8]

23
Fig. 16: Push Buttons on Microsemi IGLOO nano Board [8]
Fig. 17: LED Circuit on Microsemi IGLOO nano Board [8]

24
to_send
[0]
to_send
[1]
to_send
[2]
to_send
[3]
to_send
[4]
to_send
[5]
to_send
[6]
to_send
[7]
to_send
[8]
to_send
[9]
Source
Port
(MSB)
Source
Port
(LSB)
Dest.
Port
(MSB)
Dest.
Port
(LSB)
Length
(MSB)
Length
(LSB)
Checks
um
(MSB)
Checks
um
(LSB)
Data
(MSB)
Data
(LSB)
Fig. 18: Sent Data
Fig 19: Source FPGA Simulation
Fig.20: Output of source simulation

25
Fig.21: Destination FPGA Simulation
Fig 22: Destination Simulation Output 1

26
Fig 23: Destination Simulation Output 2

EE281FINALREPORT

More Related Content

What's hot (20)

Viewers also liked (15)

Similar to EE281FINALREPORT (20)

EE281FINALREPORT