See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/259910831

FPGA implemented reduced Ethernet MAC

Conference Paper · December 2013

DOI: 10.1109/CogInfoCom.2013.6719258

CITATIONS READS
2 2,190

2 authors:

Jozsef Suto Stefan Oniga

University of Debrecen Universitatea Tehnica Cluj-Napoca
20 PUBLICATIONS   115 CITATIONS    69 PUBLICATIONS   367 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

ANNs for FPGA design libraries View project

All content following this page was uploaded by Stefan Oniga on 28 January 2014.

The user has requested enhancement of the downloaded file.

FPGA implemented reduced Ethernet MAC
József Sütő Stefan Oniga
University of Debrecen University of Debrecen
Faculty of Informatics Faculty of Informatics
Debrecen, Hungary Debrecen, Hungary
sutojozsef90@gmail.com istvan.oniga@inf.unideb.hu

Abstract —This paper presents an implementation MAC (RMAC) can be useful when IP cores are not
of a reduced Ethernet MAC. The reduced MAC is applicable.
simple and not resource wasteful. Therefore it is
suitable to every project which includes network II. THE SOFT MAC
communication. It is especially useful to low
performance FPGAs. In practice the FPGA boards In our work we have made the implementation
are well applicable to implement network protocols, using a Digilent NEXYS_3 SPARTAN-6 FPGA
because the implemented protocols will work in board. Xilinx provides Ethernet IP core with
parallel. The main topics of the article cover the base evaluation license but it expire after a specific
concept of reduced MAC, the implemented network period of time. Moreover, the generated hardware is
protocols and characteristics. time limited. The RMAC includes the two essential
network protocols: DHCP and ARP. The
Keywords—FPGA; PHY; MAC; MII; Ethernet transmitter and receiver parts are detached from
other network units thus the interface between PHY
I. INTRODUCTION (Physical Layer device) and MAC influences only
this component. The whole MAC built from blocks
FPGA (Field-Programmable Gate Array) therefore every block is portable.
provides a better solution to implement network We tested the RMAC in a medium-speed data
protocols than microcontrollers or other devices acquisition system. Figure 1 shows the test
with sequential instruction execution, because the environment and the structure of implemented
parts of the network will work independently and blocks.
do not have to wait for the end of the previous
operation.
Today, there are many device manufacturers, which
support C/C++ or other compilers and built-in
libraries to network communication. Thereby users
can create elementary network communication
simply. Obviously, programming in a high level
programming language is easier than in hardware
description language. Using built-functions we can
save time. On the other hand, in some cases the
built-functions not work well. For instance,
sometimes when a device want to use IP address
from DHCP, but DHCP server (or agent) isn’t
available on the network, the program in the device
will freezes or won’t work appropriately.
Usually device selection depends on the purpose. In
complex data acquisition systems where
information is transmitted on Ethernet, one of the
best decisions is to use FPGA based equipment.
FPGA provides well scalable, flexible and powerful
solution. Often FPGA manufacturers give IP
(Intellectual Property) cores to Ethernet but those
cores are not available to every FPGA type.
Furthermore, IP core is not modifiable while an
own module can be created according to the
purpose. Another important indicator is the FPGA
utilization. Sometimes in complex projects the
Fig. 1. Structure of implemented blocks
available sources are not enough. Thus a reduced
The dark grey components are the soft MAC while
other components are parts of the test environment.
Every MAC component comprises little modules
which made in HDL (Hardware Description
Language).
III. OPERATION OF MAC
A. MII interface
The NEXYS_3 has a 10/100 Mbit Ethernet
PHY with MII (Media Independent Interface)
interface between PHY and MAC. Currently the
reduced MAC is supported to MII interface only.
The PHY covers the physical layer of the network,
while FPGA controls the MAC. The MII interface
decomposes every byte into two nibbles (half byte).
A nibble transition requires one clock cycle. In this
interface the byte order and bit order are contrary.
The last four checksum bytes order are opposite
compared to packet byte order. Figure 2 shows how
to combine the two nibbles into one byte and the
bit-byte order organization.
Fig. 2. Byte disassembly and bit-byte order
B. Packet structure
In RMAC the packet sending includes the
packet editing which is a lengthy process, because
the packet builds up byte by byte.
Developers should treat some essential rules, like
the maximum size that is 1500 bytes and the
minimum size is 46 bytes of the Ethernet frame
payload. If the payload of the frame is less than 46
bytes the packet composer module fills the packet
with dummy data (zeros). Consequently, outgoing
data packets include the header of layers with fixed
length and a dynamic message part.
Actually RMAC uses UDP transport protocol. In
some cases using UDP transport protocol is more
advantageous than TCP, for example when you
want to use the maximum bandwidth for data
acquisition. Otherwise TCP is the preferred
protocol. On figure 3 we can see the applied
outgoing packet structure.
Fig. 3. Packet structure
This is an IPv4 packet with UDP transport protocol.
C. IP address request from DHCP
First time when the client (FPGA board) is
attached to the network, the RMAC (DHCP
component) will require an IP address from DHCP
server (in most cases via DHCP relay agent). The
client broadcasts DHCP DISCOVER on the subnet
with 0.0.0.0 source address. In the DHCP
DISCOVER the client indicates that is capable for
autoconfiguration or not. If DHCP server is
unavailable or it could not configure the node
(DHCP OFFER option 116 value is 0) RMAC will
try to use a static IP address. A time-counter
measures the elapsed time from the sending
moment of the DHCP DISCOVER in order to avoid
halt if DHCP is not available. When the counter
exceeds the time limit (some seconds) the reduced
MAC ignores DHCP module and restores a static IP
from memory.
When DHCP server configures the client it
broadcasts back DHCP OFFER which contains the
offered IP address. The DHCP component in
RMAC takes out the offered IP and stores it in
registers. Later this address will be pasted into
source address of outgoing packets. Next the client
broadcasts DHCP REQUEST which signs that the step is the packet sending. The HDL modules create
offered IP was accepted. Finally, DHCP ACK different outgoing packets. For every packet
terminates the communication between DHCP composer there is a separated frame check sequence
server and client. It indicates that IP has been calculator. In the frame check sequence calculation
distributed. After a given period (option 58) the process the exact scheduling is very important,
client should renew the requested IP address. In the because the calculation will drift and the result will
ideal case this communication includes two be incorrect. If the frame check sequence is invalid
messages: DHCP REQUEST and DHCP ACK. the receiver node will discard the packet.
Differently from previous DHCP REQUEST it Continuously more processes operate parallel in
contains the actual IP address. A simple but not RMAC which will be concatenated at appropriate
elegant solution for this task is renewing the IP in time. One solution for this task is pipelining. In this
every hour. Thus the HDL code will be a little case processes shift relative one to each other.
simpler. In order to check the outgoing bitstream (packet),
simulation may provide a good option. From the
D. ARP component simulation we can find out mistakes. Figure 4
shows the simulation of the RMAC in ISim.
In order to communicate in subnet we have to
implement the Address Resolution Protocol (ARP).
The node should know the MAC address of the
router or other nodes. The ARP module in RMAC
is responsible for ARP REQUEST, ARP REPLY
and gratuitous ARP sending. The Target Hardware
Address (THA) in the ARP REQUEST is zero.
When the node wants to know the MAC address to
IP address it activates the ARP module which
broadcasts the ARP REQUEST. When the target
node catches ARP REQUEST, it answers back with
ARP REPLY. The Sender Hardware Address
(SHA) contains the demanded MAC address. The
receiver module focuses on incoming ARP
messages and reads out useful information from
ARP packet. If the SHA of an incoming ARP
REPLY is equal with the ARP REQUEST’s THA, Fig. 4. Simulation
the ARP module delivers the target MAC address to
On figure 4 the two upper signals are the base 100
the outgoing packet composer which inserts it into
MHz clock signal of the board and the 25 MHz
Hardware Address of an outgoing message.
clock signal from PHY. The next four wires are
Gratuitous ARP is useful when the FPGA node
indicators. The first wire indicates the start of
wants to use static IP address. By this packet
packet transition. When this line is high a new
RMAC detects duplicate IP address on the subnet.
packet will be sent. The second wire indicates the
The Sender Protocol Address (SHA) of this packet
duration of packet transition. While this wire is
is zero because we should avoid overwriting the
high, the packet transition is in process. The third
cache table of nodes on the subnet. When RMAC
wire is the TXEN (TX enable) line of PHY. TXEN
detects IP address collision (our node is the
marks the validity of output data lines. This wire
offender) it will select an APIPA (Automatic
should be controled independently of clock signal.
Private IP Addressing) IP address or will wait for
Finally, the fourth wire signs the frame check
an available IP from DHCP server.
sequence calculation process. When the wire goes
to low the frame check sequence calculation ends
IV. IMPLEMENTATION
and the calculated value attaches to the end of
packet.
Actually the reduced MAC is capable of
The first bus is an address counter which points to
simplified Ethernet communication. Only the
the current byte in the packet. The second bus
essential network protocols have been
shows the current byte while the third is the current
implemented.
nibble. The last bus is the calculated frame check
The first step in RMAC implementation is the reset
sequence. On figure 4 we can observe the
of PHY, because PHY sends clock signal after reset
disassembly of a byte into two nibble and
(it depends on PHY type). On the test board
additionally the byte and checksum order. In
(NEXYS 3) the main clock frequency is 100 MHz
addition, on figure 4 we can see pipelining between
therefore developers have to pay attention to
buses.
cooperation between two different clock
Since at the same time only one module can use the
frequencies. The second and the most important
data and control lines of the PHY therefore in the
 TOP module of the HDL code there is a multiplexer
which permits or suspends the outputs of a module.
Every implemented module built from logic gates
in FPGA. Generally the generated logic circuit is
rather complex thus the regeneration of the project
requires more and more time as the project is
increasing. Since the reduced MAC is relatively
small, the regeneration not requires much time.
Figure 5 presents the size of RMAC in SPARTAN-
6 XC6SLX16.
Fig. 5. Routed design
During one clock period a nibble will appear on the
data lines thus sending one byte requires two clock
periods. In HDL code a register (one bit wide)
keeps track which nibble (the first or second) will
be sent out. The actual nibble can be a starting point
to synchronize processes. In our concept the packet
composer method comprise an address counter
register which passes through the packet and
indicates the number of current byte (the first bus
on figure 4). When the address counter reaches the
end of the packet, it sets its default value (zero).
On the receiver side using network analyzer
software (for instance Wireshark) users can monitor
the incoming messages from FPGA. In the
Wireshark they can see the structure of the message
and the software indicates checksum errors.
Furthermore, Wireshark provides extensive packet-
filtering options.
V. CONCLUSION
We use the presented RMAC in a data acquisition
system and works properly. Now it utilize 810 slice
registers (4%) and 1200 slice LUTs (12%) in
SPARTAN-6 XC5SLX16 FPGA.
In the future the reduced MAC will be expanded
with some other useful protocols such as ICMP.
Moreover, we want to support the GMII (Gigabit
View publication stats
Media Independent Interface) interface. Since the
network protocols are independent of interface
between PHY and MAC, thus we have to modify
Ethernet component (figure 1) only if we want to
support other interfaces.
One of the main differences between GMII and MII
is the byte format because in GMII a byte will be
transmitted in one clock cycle.
ACKNOWLEDGMENT
The publication/poster was supported by the
TÁMOP - 4.2.2.C-11/1/KONV-2012-0001 project.
The project has been supported by the European
Union, co-financed by the European Social Fund.
REFERENCES
[1.] József Petrényi, Windows Server TCP/IP foundations
1.vol V1.0, Microsoft Hungary 2010.
[2.] Andrew S. Tanenbaum, Computer networks,
fourth edition, 1996 Person education Inc. Publishing
as Prentice Hall PTR Upper Saddle River, New
Jersey 07458, Copyright 2003.
[3.] SMSC LAN8710A/LAN8710Ai, Small footprint
MII/RMII 10/100 Ethernet transceiver with HP auto
MDIX and flex PWR technology, revision 1.3, 03-
02-02
[4.] Xilinx, LogiCORE IP tri-mode Ethernet MAC v4.5
user guide, UG138 March 1, 2011.
[5.] Xilinx, PicoBlaze 8-bit embedded microcontroller
user guide for extended Spartan-3 and Virtex-5
FPGAs. Introducing PicoBlaze for Spartan-6, Viretx-
6, and 7 Series FPGAs, UG129 June 22, 2011.
[6.] Xilinx, PicoBlaze for Spartan-6, Virtex-6 and 7
Series (KCPSM6), Ken Chapman, 30 April 2012,
Release: 4
[7.] József Petrényi, Windows Server TCP/IP foundations
2.vol V1.0, Microsoft Hungary, 2010.
[8.] F. Nagy, J. Imrek, G. Hegyesi, I. Valastyán,
J.Molnár, Time synchronization feasibility test on
1000base-t Ethernet, http://www.atomki.hu/
PhD/tamop/3_felev/20121211/publikaciok/10_nagyfe
renc_2012.pdf
[9.] Peter J. Ashenden, Digital design an embedded
approach using VERILOG, 2008, ISBN: 978-0-12-
369527-7
[10.] Weng Fook Lee, Verilog coding for logic
synthesis, Wiley, 2003, ISBN: 0-471-429767
[11.] Hegyesi G., Imrek J., Kalinka G., Molnar J., Novak
D., Végh J., Balkay L., Emri M., Molnar G., Tron L.,
Bagamery I., Bukki T., Rozsa S., Szabo Z., Kerek A.,
Development of an FPGA-based data acquisition
module for small animal PET, Nuclear Science
Symposium Conference Record, 2004 IEEE
[12.] Thomas L. Floyd, Digital fundamentals, 10/E, 2009,
ISBN-10: 0132359235, ISBN-13: 9780132359238
[13.] Lofgren A., Lodesten L., Sjoholm S., Hansson H., An
analysis of FPGA-based UDP/IP stack parallelism for
embedded Ethernet connectivity, NORCHIP
Conference, 2005. 23rd, p. 94 - 97
[14.] Khalilzad N.M., Yekeh F., Asplund L., Pordel M.,
FPGA implementation of real-time Ethernet
communication using RMII interface,
Communication Software and Networks (ICCSN),
2011 IEEE 3rd International Conference on, p. 35 -
39
[15.] Xilinx Systems Engineering Group, Gigabit system
reference design, XAPP536 (v1.1) June 3, 2004