NIOSII board - Week 14

Now that I got all three ethernet port working, now I will make the board into a switch. I will have to modify arprcv so that when it gets a arp request it will send it out all the other port. I will have to modify the packet for each port that it will send out to. I also have to enable promiscuous mode, which allow arprcv to tell if packet is a request or a reply. I have to change IP route so the computer shows the it is receving a ping from the correct ip address. I am now able to ping correctly from the ports.

[Hardware Router] Development (5/20-5/21)

Attempting to set up routing services for the NetFPGA platform on the Altera DE4 board...

After finishing compilation with just the bare essentials of the platform, the FPGA Ethernet ports were set up using user scripts (written in TCL). The power LEDs of all relevant ports were activated when cables are connected to those ports. Furthermore, when an active Ethernet connection exists on the other side of the port, the Rx light blinks in time with packet transmission. However, the Tx light does not work, indicating that the board is still not sending any packets, neither in reply (such as ICMP Ping packets), nor in forwarding (as router should). Therefore, I have begun by attempting Layer 2 connectivity testing. A linux utility called Linkloop was installed on the linux laptop that David was using.

Attempts to install Linkloop on the secondary Linux PC proved... difficult... due to the fact that the Linux PC does not have a C compiler! As a result, the decision was made to utilize Cygwin on my personal laptop as the second end-point of the Linkloop testing structure. Linkloop was installed on both devices, and layer 2 connectivity test progressed.

Layer 2 connectivity unsuccessful. The problem appears to be in the PHY layer, and unrelated to MAC. However, further testing is required.

The Altera DE4 board uses a Marvell Fast Ethernet Transceiver for the PHY. The PHY is configured during initial runtime setup by means of a user script. The script sets each of the required PHY register values, including speed (they are capable of 10mbps, 100mbps, and 1gbps), auto-negotiation, and Duplex value (half or full duplex). The remainder of the procedure is still mysterious to me, but is laid out nicely in the configuration script. Further detailed analysis is required in order to fully understand the process by which the PHY control registers are configured, and to understand why connectivity is not properly established, in terms of outward data transmission.

Change for the better

This weekend, we have successfully gotten our router to a point where an excess of packets will not crash our router. The first thing I tried was first make the router a packet generator/ receiver to see if the problem was with the PHY. I wrote a simple C socket program to make a send client/ recieve server. I tested this with the router and as long as the router was receiving/ sending, nothign would crash. Next, under the advisement of Professor Pak Chan, I added a descriptor memory for each TSE. He figured that what was probably happening was that since they were all sharing one descriptor memory to begin with, some information was being overwritten when a lot of packets come in at one time. After adding these descriptor memories, our router would no longer crash. Now, through a brief benchmark test, we have seen an average speed of about 22MBit/s.

Professor Pak Chan also recommended we enable burst mode on the SGDMA but after an initial trial, it seemed to disable interrupts completely. After talking to David, it seems like by eneabling burst, I may have disabled a global interrupt value that I need to re-enable. We will test this tomorrow.

NIOSII board - Success / Week 13

Here is how I set the two ports.

Ethernet 0 (on board)
Your Ethernet MAC address is 00:07:ed:ff:75:4a
Static IP Address is 192.168.1.100

Ethernet 1 (daughter card)
Your Ethernet MAC address is 00:07:ed:24:8e:da
Static IP Address is 192.168.0.101

I tested both ethernet ports and I was able to get pings from both ethernet ports successfully.

Now I will add another daughter card to the board, so I will have three ethernet ports.
I added the daughter card to the SOPC builder so that both daughter cards share the same address and data pins. Then I have to set the pins for the upper daughter card and logic for irq also. In the code I change it so it will support 3 ethernet ports.

[Hardware Router] Development (5/15 - 5/16)

Today I received an email from Professor Tessier at the University of Massachusetts Amherst, who worked on a version of the NetFPGA platform compatible with Altera boards.

Examining the files sent by Professor Tessier, development was begun based on the NetFPGA platform. The NetFPGA was originally designed for use on Xilinx boards, but a modification of the system files should allow it to work on the Altera DE4 board.

Analyzing the system's implementation, it seems that the Ethernet controller is implemented largely in hardware. The port interfaces are instantiated in verilog by means of sequential always blocks causing the ports to advertise a "ready" signal unless synchronous reset signal is sent. Continuous assignments then set the ready signals. The rest of the assignments are also handled with continuous 'assign' statements. The NetFPGA core module is instantiated to provide error detection through the CRC checker. The core module also pipes data into the interfaces.

The NetFPGA Core module acts as the main top level design (with some exceptions). The SRAM and other storage structures (FIFOs) are instantiated here, and the logic in the core provides for the sending and acknowledgment portion of network connectivity. Frame errors are generated here, as well as other Ethernet sink errors, such as those dealing with malformed datagrams. Additionally, data path transmission is taken care of in this module, including timing and control signal handling.

Other portions of the design, such as various FIFOs used to hold Ethernet frame data, including payloads and header/tail fields, are self-explanatory.

Finally, the system relies on configuration scripts sent through the JTAG interface in order to configure the device. That is, instead of having the MAC addresses, IP addresses, routing tables, and ARP data hard-coded into the verilog (which would result in very tedious recompilation complications), user scripts are used to dynamically allocate all of the data during initial setup on runtime. After initial setup, the router is self-sufficient, but the JTAG connection may be maintained to maintain output of data relevant to debugging.

Next step is designing routing services for the device...

NAT delay

NAT was not as easy to implement as I thought it was and I did not finish this weekend. The main part I had problems with was setting up the NAT table itself. While editing the headers is not too hard, I overlooked what it took to implement the NAT table itself. What I realized is needed is a separate add, delete, and search function for the NAT table. One of these functions should also be capable of recycling entries which are not used (because the table itself is static). For now, here is what I propose for each function:

int add(IP, port): Adds entry to NAT table.
                          Returns the new port that is assigned to this IP and port combo.
void delete ( IP, port): Will delete an entry from the NAT table.
                              ***Not sure if this is needed if there is a recycle function built into add***
NATOBJECT lookup(IP, port): Will search through the table for the IP and port combo and return the entry.

I am going to try to model this after the existing routing and ARP tables except my implementation will be a lot more basic.

Troubleshooting the router crashing and more...

Over the past few weeks, I have been trying to find a way to optimize the speed of our router as well as finding a way such that the router does not crash when being sent a large number of packets at one time.  Once, we were able to get speeds of up to 20 Mbits/sec, but it crashed instantly after and it became frustrating from there.  A lot of it probably had to do with optimizing our code a bit as well as disabling the debug mode, but I figured the packet buffer might've been the cause of the crashing problem.  So I investigated how the buffer actually worked and ran some tests on the two buffers that were being used: one for small packets, specifically ping and ARP packets for example, and one for large packets, such as those from large file transfers in FTP or benchmark testing.  Along the way, I was able to make the buffers a lot bigger by modifying some values in ipport.h and enabled TCP window scaling to attempt to fix the router from crashing.  I had thought that by enabling TCP window scaling, packets would be able to go over the maximum window size (65,535) so the packets can handle large amounts of data at one time. However, I found out that the buffers do not actually fill up through testing and observation of the number of packets in each buffer compared to their maximum length defined within the Nichestack, so the case of buffer overflowing has been ruled out.  Matt has suggested creating a new project and make a controlled experiment to see if the router crashes with mostly original code (no changes to routing but two interfaces were enabled).  It turned out that the router still crashes with the original code. When it crashes, all the interfaces goes down, but one connection stays alive.  Matt and I suspected that another case is that somewhere in our code, the router is actually turning off the interfaces, so I am investigating that at the moment by going through the parts of the routing where the program may actually be forcing the interface off.  More to come...