Design of the Forwarding Subsystem in a Ethernet

Switch in VHDL
Abhishek Koneru Mike Adams Jonathan Reshef
Department of Electrical and Computer Engineering
Duke University
Durham, NC 27708

Introduction

In Ethernet Local Area Network(LAN), switches are used to connect different LAN segments.
A switch is a data link layer (layer 2) interconnection device. Each host in a LAN segment is
connected to a port in the switch and has its own media access control (MAC) address. The switch
identifies the host using its MAC address. Communication between hosts occurs through the switch
in the form of data packets called frames. The host that is sending a frame is called the source and
the host to which it is sending the frame is called the destination. The main function of the switch is
to control the dataflow through the network and appropriately route a frame from the source to the
desired destination without flooding the whole network.
According to ANSI/IEEE Standard 802.1D, 1998 Edition, the main functions of the switch
are as follows (mentioning only the ones relevant to this project):
Frame reception
Discard on received frame in error
Forwarding of received frames
Selection of traffic class, following the application of filtering information
Queuing of frames by traffic class
Frame discard to ensure that a maximum transit delay is not exceeded
Selection of queued frames for transmission
Frame transmission
Based on the functions that the switch performs, it can be divided into four subsystems, namely
Receive Subsystem, Forwarding Subsystem, Table Subsystem and Transmit Subsystem. The
Receive Subsystem is mainly responsible for receiving the frames and discarding erroneous frames.
The Forwarding Subsystem is responsible for forwarding the received frames to the appropriate
port. Transmit Subsystem is responsible for ensuring the minimum inter-frame gap and frame
transmission. The Table Subsystem provides the Forwarding Subsystem with information for
making forwarding decisions by learning the source addresses.
In this project, we have designed the Forwarding Subsystem in VHDL and integrated it with
the other Subsystems. The design and simulation of our Subsystem was carried in Altera Quartus
13.0SP1. We also loaded our design onto an FPGA and tested its functionality.
The rest of the report is organized as follows. Section 2 discusses the design of the Forwarding Subsystem in detail. Section 3 presents the simulation results. Section 4 presents the
hardware test results. Finally, Section 5 concludes the report.
1

Forwarding Subsystem

The Forwarding Subsystem is roughly partitioned into three intra-system componentsthe receive
controller, the table controller, and the router. A high level block diagram of the subsystem depicting
these components is shown in Fig. 1. A Quartus-generated RTL view of the subsystem is shown in 2.

Figure 1: Block diagram of the Forwarding Subsystem. The subsystem interfaces with four receive
ports on the leftmost side of the diagram. Frame data is read from these ports by the receive controller and used to populate the internal FIFO buffers. Table lookup requests are initiated by the
Table controller and the results pushed onto the destination port buffer. The router uses destination port information to send frame data to the appropriate transmit port or all transmit ports if no
destination port is known.
The receive controller is responsible for monitoring the four receive ports, reading frame data
from the ports when available, and populating the five internal forwarding buffers with frame data
and metadata. The receive controller probes each receive port in a round robin fashion until a
port is identified containing at least one valid frame. When an identification is made, the receive
controller reads frame length and frame data from the port. Frame length is pushed onto the internal
frame length FIFO and frame data is routed to the internal data FIFO. The receive controller uses
shift registers to extract the 6-byte source and destination addresses from the data stream. These
addresses are pushed onto the internal source and destination address FIFOs. The source port is
known to the receive controller as the target portthe port it is currently reading data from. This
value is pushed onto the source port FIFO buffer.
The table controller monitors the empty signal of the source address FIFO. When this signal is deasserted, the table controller knows that the source port, source address, and destination
address buffers all contain at least one word of valid data. When this happens, the table controller
checks the table ready signal to see if the table is ready to conduct a transaction. When table
ready is asserted, the table controller issues a read request to the source port, source address, and
destination address buffers. The table controller asserts data valid to table when the data values
become available. Table latches the values, looks up the destination port, and responds with the port
number in the event of a hit, or a broadcast flag in the event of a miss. The table controller latches
the table response signal and pushes it onto the destination port buffer.
The router monitors the empty signal of the destination port buffer. When this signal is de2

Figure 2: Forwarding Subsystem RTL view. Unfortunately, the Quartus auto-generate layout makes
this graphic very opaque. Please refer to 1 for a more easily digestible view of the subsystem.

asserted, the router knows that all necessary metadata is available to route the current frame being
read by the receive controller. The router issues a read request to the destination port buffer and uses
the value received to target a single transmit port or all transmit ports in the event of a broadcast.
The router then issues read requests to the frame length and data buffers and sends data to the target
transmit port or ports.
2.1

Receive Interface Controller

Fig. 3 shows the interface with the Receive Subsystem. Receive indicates that is contains at
least one complete frame by asserting data valid. When the receive controller sees this, it pulls
frame length and frame data from the receive port by asserting frame length rd for one cycle and
frame data read for a number of cycles equal to the length of the frame. Frame length information
is communicated over the frame length bus and frame data is communicated byte-serially over the
frame data bus.
A block diagram of the receive controller is shown in Fig. 4. The target receive port is set
by a modulo 4 counter, whose enable signal is controller by the receive FSM. The target port
acts as the select signal for a multiplexer and demultiplixer which effectively abstract away the
four receive interfaces, presenting a single target receive interface to the rest of the receive controller.
The data bus of the target receive port is routed to the destination address, source address,
and data buffers. The length bus of the target port is routed to the length buffer. The target port
signal is routed to the source port buffer. The write request signals of all five buffers are managed by
the receive FSM. Not shown in the diagram are byte-serial-to-parallel shift registers which convert
the byte-wide data stream to 6-byte-wide source and destination addresses. These shift registers are
integrated into the source and destination address buffers.
The receive FSM is the core of the receive controller. It manages the enable signal for
the target port counter, the read request signals for the target receive port, and the write request
signals for the five data and metadata FIFO buffers. Fig. 5 shows a state diagram of the receive FSM.
The FSM initializes and resets to the Listen state. The FSM transitions to the Read Length
3

Figure 3: Receive port interface.

Figure 4: Receive controller block diagram.

state when target data valid is asserted, indicating that the target receive port contains a complete
frame. THe FSM transitions from Read Length to Read Data unconditionally after one cycle.
The FSM stays in Read Data until its internal counter equals the frame length - 1. The FSM then
4

transitions to a Final state and then back to the Listen state.

The Receive FSM drives seven Moore outputs corresponding to the target receive port length
and data read signals and the five internal buffer write request signals. The receive FSM drives one
Mealy output corresponding to the mod 4 count enable signal. The Moore and Mealy outputs are
shown in Fig. 6.

Figure 5: Receive FSM state diagram. Some outputs are concealed not shown for space concerns.

Figure 6: Receive FSM Moore and Mealy outputs.

2.2

Table Interface

Fig. 7 shows the Table interface. When Forwarding has a full set of frame metadata and table read
is asserted, the Table controller issues a read request to the source port, source address, and destination address buffers to update the src port, src addr, and dst addr buses. The Table controller
then asserts fwd data valid to inform the Table subsystem that the interface contains valid data.
Table latches the data and conducts a destination port lookup. Table puts the destination port on
the dst port bus and asserts tbl data valid to inform the Table controller that the interface contains
valid data. The the Table controller latches the destination port data and issues a write request to the
destination port buffer.
Fig. 8 shows a state diagram of the Table controller FSM. The FSM initializes and resets to
the Idle state. The FSM waits in this state until table ready is asserted, at which point it transitions
to the Table Ready state. The FSM transitions to the FIFO Read Request state when fwd has data
is asserted, indicating that an entire set of frame metadata is buffered. The FSM issues read requests
to the source port, source address, and destination address FIFOs for one clock cycle and then
transitions to the Data Valid state, where it asserts fwd data valid to inform Table that the interface
contains valid data. The FSM then transitions to the Wait state, where it remains until Table asserts
tbl data valid. When this occurs, the FSM asserts the Mealy output dest port wrreq and transitions
back to the Idle state.
5

Figure 7: Table interface.

Figure 8: Table FSM state diagram showing Moore and Mealy outputs.

2.3

Transmit Interface Controller (Router)

Fig. 9 shows the interface of the Forwarding Subsytem with the Transmit Subsystem. The
Forwarding Subsystem uses the signal data valid to indicate that there is valid data on the buses
frame data and frame length. Before asserting the data valid signal for a transmit port, the
Forwarding Subsystem also probes the buf space bus to check if there is enough space in the
Transmit Subsystem buffer to fit a complete frame.
The movement of data through the interface between the Forwarding Subsystem and the
Transmit Subsystem is controlled by the router. The state transition diagram of the router FSM is
shown in Fig. 10. The router monitors the destination port buffer for destination port addresses.
This wait state of the FSM corresponds to State A in the figure. Whenever it sees a port address, it
reads that address by asserting the read request signal of the destination port buffer and transitions
into State B. The read request signal for the frame length buffer is also asserted during this transition
so that the router has the frame length in the next cycle. In State B, the router makes the decision of
broadcasting the frame or transmitting it to a target port by looking at the destination port address.
If it has to broadcast the frame, then the router moves from State B to State C. Otherwise, it moves
to State D. While making this transition, the router synchronously loads the frame length onto a
down-counter. In States C and D, the router asserts the read request signal of the data buffer in the
6

Figure 9: Transmit Interface.

Figure 10: Router FSM state transition diagram.

Forwarding Subsystem and then moves to States E and F respectively. The counter enable (Enables
the down-counter in the router) is asserted when the router moves from States C and D to E and F
respectively. In State E, the router asserts the data valid of all the transmit ports whose buf space is
greater than the frame length. In State F, the router asserts the data valid signal of the target port if
the buf space of the target port is greater than the frame length. The router remains in State E or in
State F until the counter output becomes 0. When the counter output becomes 0, the router moves
back to State A and waits for a new destination port address.
In the FSM of the router, all the output signals are mealy outputs since all of them are dependent on the FSM state and some input signal.
2.4
2.4.1

Software Simulation
Forward Subsystem

To conduct software simulation we built a Receive port emulator and a formal VHDL testbench. The
receive port emulator exactly mimicked the behavior of the real receive port at the Forward interface
7

and could be loaded with up to three arbitrary frame. A Table emulator was not required because
the Table subsystem was functional at the time of testing. The testbench managed the receive port
emulators and provided stimuli for the other Forward subsystem input signals. The testbench loaded
the first receive port emulator with a frame featuring a source address A, destination address B, and
10 bytes of data. The second receive port was loaded with a frame featuring a source address B and
destination address A.
The full waveform simulation results of the testbench run are shown in Fig. 11. The simulation behaved as expected. The first frame was read and broadcast to all transmit ports because the
table did not have a record of its destination port. The second frame was sent only to transmit port
0 because Table updated its CAM to map port 0 to MAC address A after transmission of the first
frame.

Figure 11: Waveform results of Forward Subsystem testbench.

Figure 12: Zoomed waveform view of RCV 0 interface. Frame length information is read one clock
cycle after tbl data valid is asserted as highlighted in the top smaller orange circle. Frame data
reading begins two cycles later and lasts for 22 cyclethe length of the frameas highlighted in the
bottom larger orange circle.

Figure 13: Zoomed waveform view of RCV 1 interface. Frame length information is read after RCV
0 frame reading has completed as highlighted in the top smaller orange circle. Frame data reading
begins two cycles later and lasts for 22 cyclethe length of the frameas highlighted in the bottom
larger orange circle.

2.4.2

Full System

The full system integration was tested in simulation using a phy simulator written by the receive
team. The phy simulator was preloaded with a single valid frame and was programmed to begin
transmission upon assertion of a trigger signal. The waveform result of the simulation is shown in
Fig. 17. The full system behaved exactly as expected. The frame was broadcast as received to all
transmit ports. We did not test a target send case.
8

Figure 14: Zoomed waveform view of Table interface. Top left circle highlights metadata for the
first frame being sent to the table. The bottom left circle highlights the Tables responsewhich sends
a 7 for the destination port indicating a CAM miss. The top right circle highlights metadata for the
second frame being send to the table. The bottom right circle highlights the Tables response. This
time, the Table sends a 0 for the destination port because its CAM was updated after processing the
first frame lookup.

Figure 15: Zoomed waveform view of Transmit interface showing first frame data being broadcast
to all four transmit ports. The large red circle highlights the four Transmit data valid signals. They
are all high in this case consistent with the broadcast condition.

3
3.1

Hardware Test Results

Forward Subsystem

To test the functionality of our design in hardware, we loaded it along with the test bench described
in the previous section, onto a Altera DE2 FPGA board. Our goal was to match the hardware test
results with the simulation results. As we can see from Fig. 18 and Fig. 19, the hardware test results
actually match the simulation results. The hardware test was run at speed.
3.2

Full System

We executed a single elementary full system hardware test at speed. We loaded the phy emulator
used in the full system software simulation onto one of DE2 board. We loaded the full system
ethernet switch onto a second DE2 board and connected them via ribbon cable. We probed a single
transmission port phy interface with the logic analyzer and triggered the phy emulator to send a
frame. The logic analyzer waveform results of the test are shown in Fig. 20. The test worked as
expectedthe frame was transmitted exaclty as it was received.

Conclusion

In this report, we presented the design of the Forwarding Subsystem in a ethernet switch. The
Forwarding Subsystem was partitioned into three intra-subsystems the receive controller, the table
controller, and the router. A detailed description of the FSMs used in each of these intra-subsystems
is included. Finally, the simulation results and the hardware test results of the Forwarding Subsystem
and Full System were presented.

Figure 16: Zoomed waveform view of Transmit interface showing second frame data being sent
to only the transmit port 0. The large red circle highlights the four Transmit data valid signals.
Only data valid corresponding to the zeroth transmit port is asserted consistent with a targeted frame
transmission.

Figure 17: Waveform

Figure 18: Logic analyzer waveform view of Forward subsystem Hardware test after the first frame
is sent. The red circle highlights the first frame being broadcast to both transmit ports.

10

Figure 19: Logic analyzer waveform view of Forward subsystem Hardware test after the second
frame is sent. The red circle highlights the second frame being selectively sent to the zeroth transmit
port as expected.

11

Figure 20: Logic analyzer waveform view of full system hardware test. The bottom left circle highlights frame transmission to the receive port from the phy emulator. The top right circle highlights
frame transmission from the transmit port to the phy.

12