Computer Laboratory

Course pages 2013–14

Four-Port Non-Learning Switch


Overview

The first project that you will undertake will be the implementation of a four-port non-learning switch design. You will be given a simple repeater design as a starting point. This project is designed to familiarize you with the NetFPGA platform and associated tools. As part of this process you will also develop a small number of tests to verify the operation of your switch—if you follow the test methodology then your tests should work in both simulation and on the actual hardware.


Getting started

You are given the verilog code for a simple system that forwards all the received packets to Ethernet port 1. (see the Source Code link). A set of tests is provided with the design to test it forwards packets to port 1. Your tasks in this part are:

  1. Fix the input arbiter. The provided input arbiter is not operating as an arbiter, instead it is reading only from input 0. You must modify the input arbiter so that it reads each input in round-robin fashion. The arbiter should operate at the packet level, i.e., once it starts reading a packet from an input it should transfer the entire packet before servicing the next input. If no packet is available at an input it should proceed to the next input. At the completion of this task (before completing the second task) your design should read data from all Ethernet ports and forward that data as follows:
    • Packets sent in port 0 are forwarded to port 1
    • Packets sent in port 1 are forwarded to port 1
    • Packets sent in port 2 are forwarded to port 1
    • Packets sent in port 3 are forwarded to port 1
  2. Implement the output port lookup module. The output port lookup module currently functions as a repeater that sends all packets out Ethernet port 1. You must modify this so that it implements a non-learning switch. That is, packets should be forwarded to all ports except the receiving port.
  3. Implement additional tests. The provided tests verify that the design forwards packets from Ethernet port 0 to Ethernet port 1 only. You should write an additional test that sends a packet in on each Ethernet port and verifies the packet is seen on the corresponding output ports. Care should be taken to ensure that different packets are sent in each port so that the output can be verified.

Required functionality

Your non-learning switch must support the following functionality:

  • Packet forwarding. Received packets must be forwarded out on all Ethernet ports except the receiving port

How-to guide: a suggested procedure for getting from A to B

We recommend that you follow the following process:

  1. Read the docs! Useful links include:
  2. Verilog Review
  3. Follow the steps outlined in the Hardware lab setup instructions.
    Verify that the Xilinx and iSim tools work,
    verify that you can run simulations (with nf_test.py sim) and
    hardware tests (with nf_test.py hw).
  4. Edit nf10_input_arbiter.v (located in ~/netfpga/lib/hw/std/pcores/nf10_input_arbiter_v1_00_a/hdl/verilog) to process packets from all inputs instead of just Ethernet port 0. Locations where you need to modify the code are labelled with a FIXME comment.
  5. Create simulation tests to verify that the updated input arbiter functions correctly with the existing Output Port Lookup module (see ~/netfpga/lib/hw/std/pcores/nf10_router_output_port_lookup_v1_00_a/hdl/verilog). You should verify that:
    • Packets sent in port 0 are forwarded to port 1
    • Packets sent in port 1 are forwarded to port 1
    • Packets sent in port 2 are forwarded to port 1
    • Packets sent in port 3 are forwarded to port 1
  6. Synthesize your design.
  7. Write hardware tests to test your design in hardware and verify your design
  8. Edit nf10_router_output_port_lookup.v (~/netfpga/lib/hw/std/pcores/nf10_router_output_port_lookup_v1_00_a/hdl/verilog) to implement a 4-port non-learning Ethernet switch.
  9. Create simulation tests to verify the switch:
    • packets are broadcast on all ports other than the ones they were received on
  10. Simulate your new design
  11. Write hardware tests and verify the new behavior

You now have a non-learning Ethernet switch!


Milestones

E-mail update of tool setup
(Fri 17-Jan)

Send a brief e-mail (a few lines) letting us know whether you succeeded in getting the tools to work and the sample design to synthesize.

Operational input ariter with basic repeater
(Wed 22-Jan)

Your input arbiter should process packets from all input ports. The output port lookup module should be unmodified such that:

  • Packets sent in port 0 are forwarded to port 1
  • Packets sent in port 1 are forwarded to port 1
  • Packets sent in port 2 are forwarded to port 1
  • Packets sent in port 3 are forwarded to port 1

You should also have at least one simulation test and one hardware test to test this functionality.`

The sourcecode, tests and bitfile must be submitted.
Hardware Design Document
(Wed 29-Jan)

The first deliverable is the initial version of your design, and is worth a
substantial portion of the points for this class.

This first version should contain:

  • An introduction describing the feature set of the product. i.e. what will it do? Be specific: does it handle ARP packets? Does it provide statistics? This should include all of the features that will be in your final router. You will be able to edit this later, but be adventurous (but realistic) now.
  • An architectural description of your router. In particular it must contain a block diagram that shows how you have partitioned your design into different functional modules and the data and control flow between them. You must show the buffering/congestion points in your design - where can packets be lost due to lack of resources?
  • A brief description of the functionality of each module. What does the module do? What are its expectations regarding adjacent modules? Provide pseudo code for any interesting algorithms such as your longest prefix match algorithm, and how your design analyzes each incoming packet.
  • Later you will need to add a section describing each hardware register and table, as well a separate section describing the tests needed to verify the design.

Working non-learning switch design

(Wed 29-Jan)

The sourcecode, tests and bitfile for the non-learning switch must be submitted.

Test summary

(Wed 29-Jan)

A short summary of the tests you performed to verify the correctness of your switch.
This document should include a list (and description) of all simulation and hardware
tests that you ran.

Simulations: Sample simulation tests are provided in the test directory of the project. These can be invoked with the
nf_test.py command with the sim parameter. These tests are setup to automatically
verify the result when the test completes. Your tests should be structured in a
similar manner.

Note: The ––gui parameter can be passed to nf_test.py to
invoke the graphical version of iSim to allow interactive debugging.

Hardware tests: Sample hardware tests are
provided in the test directory of the project. These can be invoked with the
nf_test.py command with the hw parameter. These tests are setup to automatically
verify the result when the test completes. Your tests should be structured in a
similar manner.