3/28/2011: We will have a one time Wednesday meeting on 3/30 in Gates 459. See Piazzza for more info. Future weekly meeting time/place is TBD posted in “Teams” section.
4/2/2011: WordPress is up. Please use team WordPress page to post all your deliverables.
4/8/2011: On 4/13, teams will meet David Erickson instead of Nick (out of town), at Gates 459. Feel free to ask questions about your software designs.
5/9/2011: On 5/11, teams will meet David Erickson instead of Nick (out of town), at Gates 463a. Feel free to ask questions about your software designs. Meeting cancelled since David is sick today. Meeting with James as usual.
5/23/2011: Interoperability Test Today at class time! Final presentation 5/31 6pm @ Gates 104.
5/30/2011: Last milestone deadline extended to 6/2 (Thursday).

Time and Location

Spring 2010-2011
Monday/Wednesday 2:15PM – 3:30PM
Lecture Room: 380-380C


CS344 is a project-based class. The first class (of which attendance is required) is the only scheduled lecture. During the course teams of two or three students will work together to develop a fully functional IP router. The teams will consist of at least one student familiar with designing hardware in Verilog and one student who is comfortable working in large, system level network programs in C. Students will be paired by area on the first day of class. You do not need a partner before registering.

The hardware uses the NetFPGA boards which provide a programmable hardware platform for developing network equipment. Given the Verilog HDL code for a simple two port switch the hardware designer will extend/modify/discard this code to provide the functionality of a four-port IP router. A set of tools are provided to assist the student with design, verification and synthesis.

The software developer will create the code needed to control and manage the router. For control purposes, the software must participate in a dynamic routing protocol and respond to ARP and ICMP messages. For management purposes the software must export a telnet-like command-line interface such that a user can telnet to the software process and manage the actual hardware. The VNS (Virtual Network System) is used to allow the student’s software to run on any campus computer and yet communicate with the hardware directly.


This is a practical course involving the development and maintenance of a large code base. The course requirements are:

  • Students who are familiar with Verilog (or VHDL) and are comfortable with the general process of designing RTL-based logic and the verification process associated with that. The student must understand the difference between behavioral Verilog and RTL Verilog (a subset which can be synthesized into logic). The hardware course requirement is EE271.
  • Students who are competent software programmers, who have had significant exposure to system level programming in C. The students must be comfortable developing and debugging in a multithreaded environment, and should have experience working within a code-base of over 5,000 lines. The software course requirements are CS144/CS244a or CS140 and EE284.
  • All students should understand IP-level networking.

If you have questions on whether or not your level of skill or experience is sufficient please contact Prof. McKeown or one of the TAs directly.


The class will be broken down into teams of two or three students. Each team must have at least one member knowledgeable of the hardware aspect and one member with ample software expertice. We leave it up to the teams themselves to decide how to break up the workload between all members. At the end of the quarter, however, we do require that each team submit one document detailed the work done by each member. This document will weigh heavily when allocating points for team participation.


At the end of the quarter each group will give a 20 minute presentation on the design and implementation for their router. We are particularly interested in the novel aspects of your design, comments on how you worked together and with other teams, and what went wrong and what went right, as well as any general feedback for us on the project, flow, tools, difficulty, etc.

Weekly Meetings and Course Q&A

In order to keep track of your progress we are scheduling 10 minute, weekly meetings with each group to go over project status, issues etc. The exact times for these meetings will be announced after the groups have been decided.

The courseĀ Piazzza site will be our main Q&A place. Please sign up at Piazzza if you don’t already have an account. You may also send your questions to personal email addresses, but please expect longer reply time.

Class Router Interoperation

Routers by nature work cooperatively in large complex environments. In fact, much of the complexity in router design and implementation is inter-operating with routers developed by different teams based on varying assumptions of standard protocol specifications. Inter-operation is such a critical feature of network infrastructure development that it is one of the major focuses of this course. The last few weeks of the course are reserved for inter-operation and testing between all of the teams in the class. The students are responsible for initiating communication between groups, coming up with a cooperative integration plan and ensuring that your routers not only inter-operate with our supplied reference solutions, but all other routers in the class. It is our goal that by the end of the class, every finished router will be able to route traffic cooperatively on a large shared topology.

We have reserved a portion of the total class points to allocate based on participation during inter-operation. This means that we expect all the students to be pro-active from the start about planning and communicating a solid inter-operation strategy between teams during development. It is a good idea to collectively map out a strategy early on in the quarter and have incremental goals that can tested piece-wise. You may meet during designated course hours (since no lectures are held), use the class Piazzza site for communication, email or meet during class hours.

Documentation Deliverables

Design documentation is our window into the brilliance of your particular design and implementation. Through the course, each team will maintain two design documents, one for the hardware portion and the other for the software portion. Generally, when reading your design documents, we should be able to clearly understand your approach to the problem, the high level design and be convinced that you considered multiple options, choose the best one and are aware of the trade-offs. Both design documents should have the following high level structure.

Software/Hardware Design
Overarching design of the hardware or software (depending on the which design document). We expect sufficient detail to understand how your design fits together at a component level without a deluge of specifics.
Project Specific Documentation
For each project stage outlined in the class hardware schedule you will write a section of the design document detailing your design and implementation choices. Specific requirements for each section are listed in the section write-up. You will hand in these sections at the completion of each milestone.
Testing Strategy
You are responsible for coming up with a complete, integrated testing strategy which you will use to verify correctness throughout the development process. Remember that you are responsible for inter-operating with other routers so you must take this into account. You may choose to divide this section into four subsections, software testing, hardware testing, integrated unit testing and inter-operability testing.
Integrated Design
A full and comprehensive overview of your design. Be sure to describe in detail why you chose to design your router this way, the trade-offs involved and any problems with your design you hadn’t anticipated. You should take an integrated hardware/software approach to explaining your design. We are interested in knowing what is in hardware, what is in software, how they interact and what the interfaces between the two look like. You may choose to write this section last though much of the material can be taken from the portions of the document you will write during the design and implementation stages. This section may be the same in both documents.
Post Mortem and Lessons Learned
A summary of the your design and implementation experience. What went wrong? What went right? What would you do differently? Contrast your view of the project in retrospect to how it looked at first. In this section, we are primarily interested in what your learned during the project.

Stanford High-Performance Networking Group Stanford University