Project - Learning Ethernet Switch

Overview

The first step in building an IP router is to increase your familiarity with the hardware platform and simulation environment by initially creating a simpler network device. In this project, you will create a 4-port learning Ethernet Switch on the NetFPGA platform.

Getting Started

In the hardware tutorial, you were provided with a 4-port Ethernet NIC and extended that design in a new project to create a 4-port Ethernet hub. In this project, you will take the same NIC design and modify the output_port_lookup module to create a 4-port learning Ethernet switch.

In your hardware switch, you will be directly processing raw Ethernet packets in Verilog. The following resources will be helpful in completing this project:

• Course Resources - References on Verilog programming and packet / protocol formats.
• Hardware Common Tasks - Instructions on how to perform common hardware tasks such as customizing a Verilog library module or compiling your design.
• Register Map - Specifications on the software-accessible control interface that your switch (and eventually, your router) must implement.
• Verilog Hierarchy - Diagram with the hierarchy of key Verilog modules shown

Requirements

The use of version control for all projects is mandatory. We will grade your projects by checking out a copy of your source code from the repository and compiling it ourselves. You should have read through and completed the following tasks to prepare and secure your group's repository before starting your hardware project.

1. Subversion Initial Setup
2. Subversion information
3. Subversion exercises

The following is a list of requirements for your learning Ethernet switch. All requirements must function both in the simulator and on the NetFPGA hardware. A simulator-only design does not meet project requirements.

• Your code must compile using the Xilinx tools installed on the ecs-network class server.
• Learn MAC source addresses
  • Save the MAC address and source port of all incoming packets in a forwarding table
  • The switch must be able to learn at least 16 MAC addresses
  • If the forwarding table fills up, old entries should be removed in a round-robin fashion to make space for new addresses.
  • For simplicity, old entires in your forwarding table do not have to expire. (A real switch would clear an entry after approximately 5 minutes)
• Lookup MAC destination addresses via forwarding table
  • If the address is known (hit), then the packet should only be forwarded to that port. (You can count a packet addressed to the broadcast address as a "hit", so that hits+misses=total packets received by the switch)
  • If the address is unknown (miss), then the packet should be forwarded to all ports except the source port (as was done in the hub project)
  • The number of table hits and misses should be maintained in counters
• Broadcast packets
  • Ethernet packets with the Broadcast MAC address should be forwarded out all ports except the source port.
• CPU Queues
  • Packets from the CPU queues should be discarded by setting the output queue bitvector to zero. Incoming packets should not be sent to CPU queues.
• Low-Level Software Control
  • Specific elements of your switch should be readable and writeable in software via the low-level regread / regwrite utilities (See Hardware Common Tasks). These elements are:
    • Your switch forwarding table.
    • Count of forwarding table hits / misses
  • The specific register interface that your switch (and eventually, your router) must implement is specified on the Register Map page. For this switch project, you should carefully read and implement the interface specified in the "Switch Output Port Lookup module registers" and "Reading/Writing Tables" section.
  • For this and future projects, registers should be backed by memory. Specifically, software should be able to write a value to a register, and then later read that value (or an updated value) back. This provides extra flexibility for software and decreases the state that it must track.
  • You are allowed to create additional registers for debugging purposes (provided you don't conflict with an existing register address), but you must not rely on any custom registers to provide essential functionality. (While not an essential requirement of simple switch operation, this rule becomes more important when you begin work on the next hardware router project. At the end of the final project, control software from another group should be able to correctly manage your router.)
• High-Level Software Control
  • Based on the provided regread / regwrite utilities and low-level register access, you should write a testing program that can perform the following functions:
    • Display forwarding table state
    • Display switch registers
    • Clear forwarding table
    • Load custom values into forwarding table
  • This program does not need to be complicated. A simple command-line utility with a set of arguments is sufficient.
  • You should consider using this program as part of your test methodology. For instance, the program could compare actual switch state with predicted switch state after a specific sequence of packets is processed.
• Reset
  • Ensure that all state is set appropriately after a hard or soft reset.
• Run at 125MHz in order to receive full credit

Design and Style

• Good style simplifies coding, debugging, maintenance, and extension of your code. You should refer to the Hardware Style Guide for some pointers.

Deliverables

Project meetings

We will have regular project meetings throughout the semester. (Please consult the Schedule for the specific days). Over the course of this project, you group will be asked to informally discuss your design and implementation during these meetings.

Source code

You will submit your Verilog source code for the Ethernet Switch, which we will then build on ecs-network.serv.pacific.edu and test on our own NetFPGA board. For more details, see Project Submission.

Project Report

Your project report should effectively be a clear and concise design document. It should include at least the following:

• A clear, concise overview of how your switch functions. You should present packet flow for multiple scenarios (e.g. broadcast packets, packets from new hosts, etc.)
• A clear, concise description of how your forwarding table works and the implications of its design with regards to switch performance.
• A clear, concise description of how packet decoding and counting works
• A clear, concise description of how counter registers are accessed and updated by hardware and software.
• A clear, concise description of all the tests you performed to verify the correctness of your switch, including all tests in both the simulator and in hardware.
• A clear, concise description of your command-line register access program, including a list of arguments and examples of its syntax.

Grading

This project will be graded out of 100 points.

• Simulator checkpoint: 5 points
• Hardware Implementation / correctness: 65 points
• Software Implementation / correctness: 15 points
• Written report: 15 points

This guideline is not binding; we reserve the right to assign whatever grade we believe is fair.