Project - Integration
From Comp519
Contents |
Overview
In this portion of the project you will be integrating the software and hardware portions of your router. Your software router will configure the hardware and send/receive packets using a simple protocol for reading and writing registers. You will be responsible for modifying your router to communicate through the hardware registers and adding the necessary user interface support for accessing registers.
An example router bitfile has been provided in /exports/provided/reference-router/. Although the integration process is entirely up to your group, you might consider first integrating your software against this reference router (so that you can fix any of your software problems without worrying about the hardware), and then switching the bitfile to use your hardware router (so that you can fix any of your hardware problems in isolation). The reference router has routing/ARP tables of size 32, but otherwise implements the standard Register Map specifications.
Getting Started
For this part of the project you will abandon the VNS framework. Your router server software will run on the machine physically connected to the NetFPGA board and communicate with the board using a driver. In order to make your router run in CPU mode, you will have to recompile it using the -D_CPUMODE_ flag (currently commented out in the Makefile). On startup, a router in CPU mode will expect a hardware information file, cpuhw, in the current directory. This file provides the interface information for the router, instead of receiving it from VNS. The provided base code reads cpuhw and calls your sr_integ_add_interface(...) for every interface it finds. An entry in this file should list the interface name, IP address, mask and MAC. The interface name must be of the format eth0-eth3. The Network Topology page specifies which network each physical interface on the router is connected to.
eth0 10.143.206.1 255.255.255.192 00:ba:d0:ca:fe:01
There should be one entry for each active interface. You will also want to supply a static routing table file (details below). A connection to the board may look something like:
rixner@netfpga06:~$ nfsudo scone -r my_rtable
Once connected, you should be able to access the hardware registers and if implemented correctly, send and receive packets as before. In a nutshell, the hardware supports eight packet channels. Four channels for the Ethernet ports (e-ports) and four matching CPU channels (c-ports). An incoming packet on an e-port will be routed to any one of the eight channels, according to the entries in the routing table and the destination IP address table (listing the IP addresses that need to be forwarded to the software). If it is routed to a c-port, the software will be able to read it in. To send a packet out from software, write it to the appropriate c-port and it will automatically be forwarded to the matching e-port and sent out.
An rtable for this assignment will look something like:
rixner@netfpga06:~$ cat my_rtable 10.143.206.0 0.0.0.0 255.255.255.192 eth0 10.143.206.64 0.0.0.0 255.255.255.192 eth1 10.143.206.128 0.0.0.0 255.255.255.192 eth2 10.143.206.192 0.0.0.0 255.255.255.192 eth3 0.0.0.0 10.143.206.194 0.0.0.0 eth3
The first four entries tell the hardware to forward packets for the directly attached subnets to the appropriate Ethernet port. The final entry tells the hardware to forward all other packets to the Internet. Refer to the Network Topology page in order to properly construct your routing table.
Note that your hardware should not make any assumptions about what will be in the routing table, which should start out empty. The software will have to write the interface information and routing entries to the hardware before it can start processing packets correctly.
Because you have been using your dedicated NetFPGA machine the entire semester, it is likely that packets have accidentally been sent to the CPU queues by mistake. You may wish to reboot your system and clear the PCI controller before beginning integration, to remove any stale packets or old (invalid) control data.
nfsudo cpci_reprogram.pl nfsudo reboot
Accessing NetFPGA
Sending/Receiving Packets
Instead of sending and receiving packets through VNS, you will be responsible for sending them and receiving them over raw packet sockets connected to the CPU queues on NetFPGA. This requires you to implement the functions sr_cpu_input and sr_cpu_output (found in sr_cpu_extension_nf2.c) using raw packet sockets.
The Raw Packet Sockets page gives a tutorial on how to use raw packet sockets with NetFPGA. Note that root access is required to use raw sockets. We have extended the nfsudo utility to provide this access to you. To function, you must be inside your scone directory and call your binary "scone". Then, use the command:
nfsudo scone <<optional arguments>>
Accessing Registers
You also need to use the readReg and writeReg functions to access the hardware in order to initialize/modify/read the routing table and other hardware router structures. The register specification is provided in the Register Map and is also available as /exports/provided/NF2/lib/C/common/reg_defines.h.
You should extend your user interface to be able to read and write the hardware registers. This will be invaluable for debugging, as it enables you to determine the status of all registers at run-time. You should extend your functions for displaying internal software router state (routing table, ARP table, interfaces) to also display internal hardware router state, so that you can determine if they are consistent.
Interoperability
You will be provided with a hardware bitfile that correctly implements the hardware router specification. Your software must operate correctly with the reference router to ensure conformance to the specifications and interoperability with our (and other groups') hardware routers.
Performance
Once your integrated router is functional, we encourage you to evaluate its performance. A small part of the project grade will be related to the relative performance of your router in several scenarios.
However, you should NOT worry about performance unless/until you have completed everything else related to this project!
Requirements
Your software must be able to operate with this reference hardware (for interoperability) and with your group's hardware.
You hardware should perform all of the functions that were previously required of it. All other functions should be performed in software. Your integrated router must continue to support all of the functions that were previously required of the software (which may require some changes to the hardware). Note that the software must now correctly control the hardware, so you will need to extend your software implementation to be able to configure the hardware tables to mirror the software data structures which can be considered the "master copies". Note that the size of the hardware and software tables will be different, so you will need to make some decisions about what will be "cached" in the hardware. Your integrated router should allow for larger routing tables and ARP tables in software compared to in hardware. If the number of table entries is less than the hardware capacity, then all entries should be in hardware. (i.e. you should not rely on the software to perform all routing)
Deliverables
You will turn in the software (C, ...) and hardware (Verilog) for your integrated router implementation. There will be no written report for the integration project. Rather, this project will be described in the final written report submitted later.
Grading
This project will be graded out of 100 points.
- Correctness with reference hardware: 40 points
- Correctness with your hardware: 50 points
- Performance: 10 points
This guideline is not binding; we reserve the right to assign whatever grade we believe is fair.
