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...

NIOSII - Week 12

Now that I got the daughter card working, I am working on getting two ethernet port working together on the stratix board. This week I am was looking throught the code to figure out how to figure out which port is using each function, so I can give it the correct values. I was able to get some parts working, so far only the on board ethernet port is setup correctly. The daughter card doesn't get the correct values in the register. Have to edit every function to support both ethernet devices. I got everything set up and almost working. The only thing not working is the daughter card, it not doing the interrupt correctly. When interrupt is callled both ethernet ports get the on board chip interrupt value. I was able to get interrupt working for both ethernet ports, and I think they should be able to work. All I need to do now is test them.

Minor progress and address translation research

The past week has been spent mostly ironing whatever bugs we could find with two networks while also testing speed and optimization. Some bugs we had had to do with initial packets being lost along with packets not being formatted correctly.
After fixing this, I have moved on to starting to understand what I need to accomplish and do for address translation. What I will be trying to implement is similar to a full-cone NAT (or as Alex likes to call it, PAT). In full-cone NAT, each device on the interior network is given one port. This association is stored in a table. All packets being sent out to an exterior network will have it's headers edited. The source IP and port will be changed to match the aforementioned table when a packet is outgoing. When a packet is incoming, the router will change the destination IP and port along with then sending the packet to the right interface. If an incoming packet is not destined for a specific port defined in the table, then the packet will be dropped.
At the moment, I have not finished writing this so I have no testing done. I also fear that after implementing this, David's modifications to the packet buffer (along with his slight speed modifications) will break. I will need to dedicate some time to work with David to implement this and then merge back together and help him improve speeds.

[Hardware Router] Weekly Progress 4/30 - 5/06

Monday - Designed a simple Cyclic Redundancy Check module in verilog in order to modify the frame check sequence of Ethernet frames, as a first step in developing Ethernet for the DE4 board (in hardware). The frame check sequence is a portion of the Ethernet Frame Header that requires a CRC (Cyclic Redundancy Check) in order to determine whether or not the frame was transmitted properly. The CRC Module uses bitwise XOR with specific bits of data, and an enable bit, in order to generate the checksum. A so-called "magic number" of
32'hC704DD7B is used to determine whether or not an error has taken place. The "magic number" is calculated from a polynomial value. If there was an error, then the frame has tainted data, and must be discarded or corrected.

Tuesday - Designed simple FIFO to be used as a packet buffer and a Tristate Controller for use with the data pathways. The FIFO will hold the data from the Ethernet frames, as they come in, and release them after the headers are modified and the destination selected. The tristate controller will be used to output a hi-Z value onto the data line from one end so that the bus can be used by other locations. Went home early today due to sore throat.

Wednesday through Saturday - Home sick with influenza.

Sunday - Began work on initialization module. This module is used to initialize the PHY of the DE4 board. Each PHY should be reset for a period of time (several milliseconds?) in order for it to work properly when turned on. Use a simple counter and case statement to determine when to halt the reset.

NIOSII - Week 11

I was able to get the input from the daughter card working. I used ip_dump(pkt); to print out the info gotten from the packet, here is what it outputs when connected to the router. s91_rcvdata is the function for receving the data. I fixed it by combining two RD into one and put into the data.

IP packet header:
ver/hlen: 45, TOS: 00, len: 0155, id: 0009
flags/offs: 0000, TTL 96, protocol: 11, cksum: 71eb (ok)
src: 192.168.1.1  dest: 239.255.255.250
ip address 101a8c0

It printed the ARP info to check that it is getting the ARP correctly and it is working correctly.
Arp received
hardware address length: 6
protocol header length: 4
Source IP: 192.168.1.14 Dest IP: 192.168.1.234
Source MAC: 20:cf:30:2d:76:e2  Dest MAC: 00:07:ed:ff:75:4a

Now I have to change s91_senddata to get the data sending correctly. I got it working by splitting the 32bit data into two 16bit data and  then send them one at a time. I got it working and is able to ping into it.

One interior network, one exterior network

While David is working on trying to speed up the router, I have been working on getting two networks up successfully. We have both ran into a few problems but I will explain my part.
I have successfully gotten two networks to work while also changing my code a bit. The first thing I did was make iproute() return the right interface. Because of this, I got rid of setting the pkt->NET in send_via_arp() that I had done last week. Next I changed one interface's IP to a separate network. With this, the two networks could communicate with each other easily but I quickly ran into a problem when an ARP entry is not in the ARP table. If this happens, it will return the wrong interface and the packet will never be sent (and the route will be added wrongly). I haven't had a chance to try my fix out yet but at the moment it is just checking if there is a valid ARP entry. If not, it will broadcast an ARP request. Otherwise, if it is an IP address that is not in our interior network, it will automatically change the NET interface of the packet to the interface that is connected to the exterior network. I am still trying to make a more elegant fix. This problem only occurs when a Linux machine on the interior network is trying to be accessed through the network with no prior communication from the Linux client. It will not occur if two Windows machines are connected because when Windows sees a network connection, it immediately sends out ARP requests to it's gateway.
Once this is fixed (which it should by the end of tomorrow), I will work on two things: setting up the exterior network interface to act as a DHCP client and setting up some type of address translation for routing.

[Hardware Router] Layer 3 Perspective

The following is a design specification of the hardware router, from a layer 3 perspective:

• Receive Packet
• Delimit data according to Ethernet Standard
• Store delimited data in 2D Array (memory)
• Analyze Packet
• Extract relevant header information
• Store information in temporary registers for ease of access\
• Decide what to do with packet
• Exception for own IP (must respond if valid packet)
• If unrecognized information, drop packet.
• Also drop if TTL = 0
• Associate outbound port with packet by modifying bits directly in the queue
• Modify Packet Data
• Change destination IP to destination associated with chosen outbound port
• Change source address to IP of outbound port
• Subtract from TTL
• Recalculate checksum and set it
• Checksum is the 16-bit one's complement of the one's complement sum of all 16-bit words in the header.
• Example checksum calculation, for IP Header: 4500003044224000800600008C7C19ACAE241E2B (20 byte header).
•  4500+0030+4422+4000+8006+0000+8C7C+19AC+AE24+1E2B = 2BBCF
• 2 + BBCF = BBD1 = 1011101111010001 -> 1's comp = 0100010000101110
• Checksum = 442E
• Send Packet
• Write to outbound port using Ethernet protocol
• Delete data for sent packet from memory and shift all other members of the array up (FIFO).

This is the top-level design. In order for it to work, we must first implement Ethernet protocol on the board.

Post describing Ethernet implementation will follow.

NIOSII - Week 10

This week I tried changing the address lines to see if that would solve the problems. I tried shifting the data where the address is assign in the verilog code, however that didn't work and made it worse. I tried changing how the SOPC address line is inputed into the lan91c111 address line, but that doesn't help either. I tried changing the verilog so that address line is size of 4 in the verilog and created the new symbol to match the address by how the NIOS ethernet guide say, address [4:2] goes into address [3:1] in the lan91c111. That also did not work. I tried changing the SOPC so that the lan91c111 is set as onboard ethernet port. For that design I used the ethernet address as told in the  NIOS ethernet guide, and the outcome was that the ethernet acts almost exactly like how I had it last week. The one change was that the MAC address was not able to be found in the flash and had to give it the board number to get its MAC address.

Packet forwarding with a working routing table on one network

So far, we have gotten a working router with one network per interface. This week, we have gotten all interfaces to work under one network. With a little guidance and a lot of research, we found a semi-efficient way to get all the interfaces on one network to communicate with each other.

So the first thing we changed from last week was the promiscuous mode. Last week, we tried to enable "'ENABLE_PHY_LOOPBACK" but that actually ended up causing us too many problems. From what we could figure out, when this option was enabled, the PHYs would setup differently (The usual start up code did not appear). None of our previous code would work with this setting (notably they would never reach the ARP forwarding we had programmed in). So with the advisement of Professor Pak Chan, we just enabled ALTERA_TSEMAC_CMD_PROMIS_EN_MSK. This would let the PHYs start up the right way and all our code was still intact. From here, we first had to make sure our promiscuous mode worked. We ran the same ARP tests as least week and we could see the ARP replies now.

Next, we started ironing out the details for ARP forwarding. The first thing we did was broadcast any ARP packet coming in that wasn't destined for the interface that the packet was received on. Since our ARP forwarding was already working, we just sent the packet to multiple interfaces except the interface that it was received on. Next we tried to get the ARP reply to forward correctly. The problem was that we didn't have a working ARP table yet so we could not reroute a packet easily. Because of this problem, we worked on getting the ARP table to setup correctly first. We would add an entry for each ARP request and reply (using make_arp_entry()) while also adding the MAC address into the table before each packet is sent back out. Once we could confirm this was working correctly, we finished forwarding the ARP reply part. To do this, we would call find_oldest_arp() (returns either an empty entry or finds the entry you are looking for) to find the ARP table entry that the packet is destined for and send the packet out that way.

Once ARP forwarding was all done, we moved onto working on the routing table. The problem here was that although the ARP packets were moving correctly through the router, any other packets would automatically be routed to interface 1 (eth0). After thinking about it for a while, we realized that because all our interfaces were on one network, we could use the ARP table to help route our packets. As we traced the way the packet would get the net interface, we found that it would often end up at the function send_via_arp() in et_arp.c. We saw that the only reason the packet wasn't actually being sent out the right interface was because the packet struct's NET value is never set to the right interface. So before the et_arp() (will send packet based on ARP information) function is called in send_via_arp(), we would change the interface to whatever interface was returned from an earlier call of find_oldest_arp(). After this slight change, all the packets forwarded to the right place but when investigating the routing table, all of our entries all pointed to the same network interface which is wrong. To fix this, we looked at where add_route is called. This function is mostly called from ip_route() so we looked into how ip_route() would add a route. It turns out it would look at the interface IP address and as long as it matched our destination IP address' subnet, it would add that to the routing table. To fix this, we have ip_route() calling find_oldest_arp() instead and using the ARP entry to add the right interface to the routing table.

After this, we are able to communicate through the network. We have tested using simple pings along with SSH to test TCP packets also. Next, we are going to split up for a bit to look into two parts. I am going to look into how I'm going to route into another network while David is going to look at optimizing packet buffers. After adding another network and routing correctly to it, I will probably have to look into implementing some sort of address translation.

NIOSII - Week 9

I figured out the problem with the daughter card was that it was not reading and writing to the correct registers. Everything in the register was written twice so the offset had to be shifted left to get the correct offset.

Here is the output when I fixed the offset.

Copyright 1996-2008 by InterNiche Technologies. All rights reserved.
Your Ethernet MAC address is 00:07:ed:ff:75:4a
prepped 1 interface, initializing...
Created "Inet main" task (Prio: 2)
Created "clock tick" task (Prio: 3)
smsc91c111 Auto-negotiation: 100 Mbps, Full Duplex
SMSC ethernet Rev: 0x3391, ram: 8192
mctest init called
IP address of et1 : 0.0.0.0

However the DHCP doesn't work, so there are still some problems. I found out the offset only fixed the 16DIRECT RD/WR function, but the 8DIRECT RD/WR function is not RD/WR correctly.
I checked by read the mac address which uses 8DIRECT RD/WR.
Here is what I found.

MAC     Offset     Register Data Written to
0x00      4             8,9
0x07      5             8,9
0xed      6             12,13
0xff       7             12,13
0x75      8             16,17
0x4a      9             16,17

Stratix Router Development (4/17)

4/17 - The PHY error was fixed, but still DHCP was unable to be sent/received. The LED light on the board was lit, however. This may not seem like a big issue, since DHCP is low priority for the board's overall function as a router, but the DHCP packets failing to send are a symptom of the issue that the board is still unable to send/receive packets. After investigating the method for packet sending, I added a print statement for debugging purposes. The board sends by setting up a send-queue and by running through it and sending packets as it goes along; it is this that I sought to debug. Printing out the contents of the send queue each time it was added gave us two pieces of information:

• The contents of the send queue were identical each time something was added into it.
• The timing of the sends was apparent. Data was added to the send queue (and the print statement was therefore triggered) every few seconds after the board detects an Ethernet link (and the LED therefore turns on).

Wireshark (a packet monitoring software) determined that no data was being actually sent out of the port, not even garbage data. I used an oscilloscope to probe the live pins to confirm this. There is no signal on any of the Tx or Rx pins of the Ethernet cable, even though the LED is lit and the print statement is being triggered, informing us that the send queue is being used. It is still unclear how to solve the problem of packet sending/receiving, but we have learned more about the situation.

Stratix Router Development (4/8 - 4/16)

At the start of the week, I came to the decision that it would be better to focus on moving forward with other parts of the project rather than working on the Stratix board, since it was complicated to arrange a suitable working arrangement for two people using one board. Matthew Luu sent me the routing algorithms and code that he and David had worked on so that I could look at the verilog files and their program and begin to adapt it for use on the Stratix board while Simon was working on setting up Ethernet on the daughter card.

It quickly became apparent that this was a lower priority and should be set aside until the daughter card Ethernet access was up and running. The problems with the daughter card were more severe than I initially anticipated. On Tuesday, April 10th, I began collaborating with Simon again on bringing up the Ethernet card on the Stratix board.

On April 11th, I ran through the pin layout of the daughter card in Altera Quartus Pin Planner and found that the assignments were properly set. I attempted to use an oscilloscope to probe each pin and determine whether correct signals were visible on each of the daughter card's pins. The data was inconclusive. Although many of the signals were properly set, such as both of the clock pins, the pins responsible for data flow were completely blank.

On April 12th, I continued to approach the problem from a physical mindset while Simon worked used SignalTap to trace the signal paths and determine whether accurate results were present. No breakthroughs happened on this day.

On April 14th, Simon received an email from Professor Pak Chan indicating that a register offset of 14 was part of the reason for the problem. After adding the correct values, it appeared that the card's interface initialized properly, but still no data was being sent out. An error was being thrown, saying "s91: No PHY found". After examining the code, I realized that the program was using a simple check to make sure that data pulled from the registers was being compared to the ALTERA_AVALON_LAN91C111_PHY_COMPANY_ID and ..._MFCT_ID registers to determine whether the PHY is functioning. After adding a statement to print the id1 and id2 variables (which should contain the ..._COMPANY_ID and ..._MFCT_ID, it was apparent that no data at all was transmitted, i.e. both IDs had a value of x0.

On April 16th, Simon determined that the reason the PHY was not visible was another register issue. The file altera_avalon_lan91c111_regs.h needed to be modified to produce a correct offset. After this, the issue with the PHY was resolved, but a new error occurred indicating that DHCP was failing.

Modifying the Lookup Method of the Routing Table and More!

Recently, Matthew and I found out (with the help of Professor Pak) that Altera's built-in programmable promiscuous mode had to be enabled in order for our ARP forwarding to work for interfaces that are linked to the same sub-network.  In networking, promiscuous mode basically means that any packets that go through a certain interface/port will be read through and will not be omitted. In other words, this will help us because once this is enabled, our Altera board will not be able to omit and drop packets with MAC destination addresses that are not destined for the same interface/port.  To enable this mode, I basically looked up where promiscuous mode is set in the C library headers and found that there is a option ('ENABLE_PHY_LOOPBACK') defined to enable two masks ('ALTERA_TSEMAC_CMD_PROMIS_EN_MSK' and 'ALTERA_TSEMAC_CMD_LOOPBACK_MSK'), which overall enables the programmable promiscuous mode.  I haven't been able to test out to see if this mode works since Matthew still needs to revise his application code for ARP forwarding, but conceptually it seems like it should fix most of our problems we're facing at the moment.

Unfortunately, we encountered another problem pertaining to performance of the router board.  When using the evaluation version of PassMark, a benchmark testing software that allows us to test the speed of our router, we were getting very low numbers (average was around 1000kbps, which is far below our expectations for our project.)  Matthew and I figured that the problem might have to do with the initialization of the MAC and the drivers before Simple Socket Server ran.  In particular, I noticed that the initialization routine (tse_mac_init) for the Triple-Speed Ethernet MACs contained a variable 'speed', which may determine how fast the interfaces can be.  For now, I set the variable to be fixed as 1000Mbps for all the interfaces (this routine is called once for each interface), but I have not tested it yet.  This way, I would think that all the interfaces will be able to handle speeds of up to 1000 Mbps.

At this moment, I am currently looking up rt_lookup and finding a way to modify the subnet masking algorithm inside it (which tries to match routing table entries with the packet it's trying to forward/route) such that it can work not only on different sub-networks as we tested before, but all through one same sub-network for all the interfaces.  As Matthew explained on his previous post, the forwarding of packets from one interface to another does not work when all the interfaces are on the same subnet.  Right now, it should only use the interface with the best matching IP address based on the masking, which would be the very first interface. I will give further updates about the lookup method over the weekend.

NIOSII - Week 8

For the Stratix board I had a problem with the IOR signal, when IORD_ALTERA_AVALON_LAN91C111_BSR(smsc->regbase) was called in a loop I would get
IOR signal always high which was not correct. So I rebuilt the project and got the IOR signal to alternating which is the correct signal.

Here is output of SSS.

InterNiche Portable TCP/IP, v3.1
Copyright 1996-2008 by InterNiche Technologies. All rights reserved.
Your Ethernet MAC address is 00:07:ed:ff:75:4a
dtrap - needs breakpoint
prepped 1 interface, initializing...
mctest init called
IP address of  : 0.0.0.0
dtrap - needs breakpoint
dtrap - needs breakpoint
Error sending DHCP packet on iface 0.
ip_exit: calling func 0x311cce4
ip_exit: calling func 0x3124874

dtrap - needs breakpoint is outputed because when reading for regbase the value is not 0x3300
when it is  AND with 0xFF00. I was able to get past this error by using a for loop and adding 1 to the regbase untill I get the correct value. Found that if you add 14 to thereg base you get the value you need. So I change the regoffset to 14 and I didn't get the dtrap - needs breakpoint error. Now I get a new error.

Here is output of SSS.

InterNiche Portable TCP/IP, v3.1
Copyright 1996-2008 by InterNiche Technologies. All rights reserved.
Your Ethernet MAC address is 00:07:ed:ff:75:4a
prepped 1 interface, initializing...
s91: No PHY found
SMSC ethernet Rev: 0x1f, ram: 0
mctest init called
IP address of et1 : 0.0.0.0
Created "Inet main" task (Prio: 2)
Created "clock tick" task (Prio: 3)

s91: No PHY found is outputed if the PHY ID in the register doesn't match the PHY ID for lan91c111and is unable to validate a presence of the PHY.

Figured out what the problem is, it is read at the wrong address.

Putting everything on one network on DE4

Our next task is to put all the ports on one network. We had initially tried this before but decided to test out how the packets were routed first but we ran into problems. We are encountering the same problems but now understand what is happening a bit deeper now.

The first problem has to deal with ARP forwarding. There is really just one big problem here and it is that ARP forwarding doesn't seem like a reality for this project. That's not to say I'm giving up, but the basic ARP forwarding does not seem possible because the interface does not recognize a packet that is not destined for it. To test this, I forwarded the ARP request that would be sent from one client to another. To do this, a few values had to be changed (most importantly the interface to send out of had to be changed). When the other client replied with an ARP reply, it would try to send it to the destination of the original client. Because of this, the packet is never received by the DE4 board (which I find to be strange). To test this out, I made the code print out something every time the SGDMA receive callback function is called. It would never print out that it acquired any sort of ARP reply. Another test I did was to change the original ARP request packet to have the source destination MAC address as other things and no packet would be seen by the DE4 board unless it was destined for the right MAC address (or it was broadcast). I tried to compare using my own D-Link router but the router is able to see packets not destined for the right MAC address. So instead of ARP forwarding, I am going to try to go with setting up something like an ARP proxy. So instead of forwarding ARP requests, I will just use the ARP table for the DE4 board. If an ARP request comes in for an IP that is already in the ARP table, the DE4 board will reply with it's own MAC address and handle the packets as they come in. Otherwise, the DE4 board will broadcast a request and try to build an updated ARP table.

The second problem has to deal with the behavior of rt_lookup() (route lookup) when used with interfaces that are all on the same network. As David has pointed out before, most packets that come in will cause the board to call rt_lookup() before it routes the packet through. Unfortunately, when all the interfaces are all on the same network, rt_lookup() will just return the first interface it is looking at. An example would be that if a client is pinging the board's eth2, all the ping replies will still be sent out eth0. At the moment, David is looking into this while I work on the ARP proxy.

Implementation and Research of the Routing Table Function Calls

Over the past week, I have been working on mainly setting up the rest of the interfaces and getting them to work correctly on the board as well as researching and 'implementing' the routing table with Matthew.  In fact, while researching through the Nichestack functions for anything related to routing tables, most of the functions used to manipulate the routing table are already provided for us by the Nichestack/Simple Socket Server library.

To get the other two interfaces on the board to work with the previous two interfaces that we set up last quarter, I basically revised the SOPC design by adding in two extra Triple-Speed Ethernet MACs (for the PHY layer of the interfaces) as well as two extra sets of SGDMAs (two transmit SGDMAs and recieve SGDMAs) and  that can be used by the MACs to assist on forwarding packets and reducing overhead for the processor on the DE4 board.  The design is then implemented in Verilog code by adding and changing the code that was similarly used to implement the first two interfaces of the board.  Doing this allowed the board to recognize the two new interfaces and different MAC addresses were successfully given to all four ports.  Afterwards, Matthew and I tested the two new interfaces by pinging packets to the different subnetworks created by the four ports.  The ping packets were successfully forwarded to their respective destinations (i.e. 192.168.1.55 was able to ping to 192.168.0.52 by going through the board's two ports with IP addresses 192.168.1.51 and 192.168.0.51)

With forwarding functionality finally implemented on our board, Matthew and I then proceeded to the next agenda in our Gantt Chart: manipulation of the routing table.  Again, pretty much everything essential for a static routing table has been given to us by the Nichestack/Simple Socket Server library, so most of the time, we did research on how each routing table function works as well as where these functions are subsequently called and how they are being used.  The three main routing functions are rt_lookup, which basically looks up for a specific entry in the static routing table, add_route, which adds entries to the routing table, and del_route, which deletes entries in the routing table.

There are two methods in the Altera board support package that call rt_lookup: 'add_share_route' which is located in the file 'ipnet.c', and 'iproute' which is located in the file 'ip.c'.  'add_share_route' basically creates an entry in the routing table such that packets that use the source address of this entry will be forced out the same interface that it came from.  rt_lookup is used in this method to check if the entry is already in the routing table; if the entry is already there, its gets updated. If the entry does not exist yet, 'add_share_route' adds an entry that uses either the gateway address of the interface, the IP address of the interface, or the IP address of the original sender of the packet.  'iproute' is used to correctly route a packet  the correct interface on the board. uses 'rt_lookup' to find the IP address of the next hop/destination link on an entry in the routing table.  The static routing table also uses a single entry cache to determine if the most recently used entry of the routing table is the desired entry.

'add_route' is also called in 'iproute', as well as methods 'icmprcv', 'pcn_init', 'mn_add_route', and 'dhc_reclaim'. 'iproute calls 'add_route' when 'rt_lookup' fails to find a valid entry in the routing table. 'icmprcv' is a callback function that handles incoming received ICMP packets by determining what should be done to them depending on the type of ICMP message (i.e. prints a simple message or forwards it to a particular interface, etc.).  'icmprcv' calls 'add_route' whenever the ICMP packet is of message type 'REDIR' (redirect), which is used to inform a host to update its routing informaion in order to send its packets on an alternative route.  'pcn_init' is also a callback function that keeps track of the time it takes (cycles) to create the net interfaces.  'pcn_init' calls 'add_route' to add a route entry to match the interfaces that were created. I am not exactly sure of what 'mn_add_route' does, but I think it provides a menu interface for the user that allows the user to manually add a routing entry to the routing table.  'add_route' here is obviously called to make 'mn_add_route' functionable.  'dhc_reclaim' is used to work like DHCP Discover, but instead it is specifically used for machines that had a DHCP address before, but wants to reclaim the address back from the server.

The only method that 'del_route' is called in is at 'ni_set_state', which allows a network interface to be turned on or off based on the opcode parameter given to the function itself.  'ni_set_state' uses 'del_route' to flush all the routing table and ARP entries that are assigned to the interface specified by the parameter 'ifp' in 'ni_set_state'.

As of now, Matthew and I are currently trying to figure out on how to get ARP packets to forward correctly when all the interfaces on the router board are all assigned on the same sub-network.  This might be done by bridging the interfaces together, but we're not sure if the static routing table would work afterwards.

Small update on Stratix board

Software wise, the way the Stratix board starts up its interfaces is a bit different than the way the DE4 starts up its interfaces. For the Stratix board, there is no need for the add_sys() function. Instead, all interfaces start from netmain() through the function call TK_NEWTASK(). This starts up each INSTANCE defined in alt_sys_init.c. This means that each interface should already start up by itself. This also means that we can't define MAC addresses the same we defined them on our DE4 board because a prep function runs once per instance (whereas on the DE4 board, it only runs once overall). So instead, we used a static integer to implement the different MAC addresses.

Right now, it seems the software recognizes that the daughter board is there. I can only assume this because the program will crash if the daughter board isn't there. I can assume the daughter board is recognized because the program is also actively waiting for a packet to come in the second interface. Unfortunately, there still seems to be no power to the daughter board's Ethernet. A computer will not recognize a cable is plugged in if we connect it to the daughter board. Since it is not even recognized, Wireshark does not see any packets. For the DE4 board, even if the interfaces shared MAC addresses, there would still be packets being sent from each interface. In this case, packets are still not being sent.

Routing Table progress

This week, we looked into the routing table. The whole routing table was pretty much built into the niche stack so we just did research to find exactly how it worked. In this entry, I will talk about the main functions of the routing table while David will talk about how they are called in his own blog entry.

First of all, all the routing table functions are in bsp/iniche/src/ip/iproute.c. What these functions do is manipulate (or search) through a routing table variable called rt_mib with the struct type RTMIB. These are the list of essential functions:

rt_lookup(ip_addr host): This function runs through the whole routing table through a for loop. It is looking for a match between the host ip address and an ip address in the routing table. It does a bit by bit comparison and it will have a pointer to the closest match. If an exact match is found, it will stop the for loop and return the pointer to the exact match. Otherwise, it will return either the closest match (closest subnet) or NULL.

add_route(ip_addr dest, ip_addr mask, ip_addr nexthop, int iface, int prot) : This function is supposed to add a route (or update an existing route) directing dest to nexthop. It will return a pointer to the table entry or NULL if there is an error. To work, this function first points to the interface and checks for errors. It will then loop through the whole table using a for loop (similar to rt_lookup). Inside this for loop, if the entry is found, it will update the entry and return the pointer to that entry (ending the function). If the entry is not found (and no empty slot has been previously discovered), it will check if the current spot is empty. If it is, it will make a pointer newrt point to the current entry. If the current slot is not empty, it will check if the priority of prot (from the function argument) is more than the priority of the protocol of the current table entry. If it is, it will point newrt to the entry and then check the priority of newrt against the table entry. It will then mark the entry depending on which pointer to the routing table is more prioritized by pointing newrt to the entry. It will then modify the entry, timestamp it, and return the modified entry.

del_route(ip_addr dest, ip_addr mask, int iface): This function will delete a routing table entry. First it will point ifp to the iface. Next it will go through the routing table using a for loop (like the other two functions) and try to find something with matching credentials to our function arguments.If there is a match, clear the struct (using memset) and clear the cache.

A side note to all of this is that the number of entries in the table (since it is static right now) is 16. This id defined in ipport.h under the varialbe RT_TABS

NIOSII-Week7

Built Nios Stratix schematic and eth 1 works.
Trying to implement ethernet 2 on daughter card.
Address for ethernet 2 have to be hard wired.
Address [11:10] ,[7:4] ,[0] for daughter card are conneted to gnd.
Address [9:8] for daughter card are conneted to vcc.
Address[3:1] for daughter card are conneted to SOPC.
SBHE_n and AEn are conneted to gnd.
IOR, IOW for daughter card are conneted to SOPC
INT for daughter card is is etherenet 2 IRQ.

Used scope to check pin are right.
Used Signal Tap to check components.
Looked though the SSS code to find what problem is.

Figured out that the ethernet driver is for 32 bit and
the daughter card is 16 bit. So we have to change driver
to support 16 bit for daughter card. Ethernet driver
supports only one device, so we have to change it to support two.

Ethetnet 2 currently not working.

Spring Break Progress

We first found out why there was a strange header offset before. The problem we were having was that we put both interfaces on the same network. At first, we tried to go through the ARP functions (et_arp.c) and just forward requests through but upon more research, we found that this was very unsafe. What we didn't know was that when clients try to ping each other on the same network, they send an ARP request packet. The ARP packets have different headers than IP packets which is why we were seeing the offset.So we immediately discarded all of our changes to the et_arp.c file we edited earlier.
The next thing we did to get the packets to start forwarding was to make the interfaces static (whereas before, they were DHCP clients). We set each of our two interfaces on their own network by giving them the IP addresses of 192.168.0.51 and 192.168.1.51. To do this, we had to comment out #define DHCP_CLIENT in our bsp/system.h file but then add #define DHCP_CLIENT 0 to bsp/iniche/src/h/niosii/ipport.h. We then gave each interface it's own IP address.
Now that our two interfaces were up on different networks, we ran into a problem. Our previous algorithm for doing simple packet forwarding seemed to block ARP replies. This was strange because the ARP check would check the packet before sending it to our packet forwarding algorithm anyways. So to bypass this, we removed our simple algorithm, enabled IP_ROUTING, and let the iniche stack do it's own forwarding. So instead of using our own algorithm, we took advantage of the function   ipdemux.c:ip_rcv_phase2 to do the general packet forwarding.

One step forward, two steps back

So this past week was spent mostly investigating and understanding how exactly a packet arrives at the DE4. We did spend a good time writing a simple algorithm to route packets but unfortunately, we probably won't end up using this as this was more to learn how the routing process works. In doing this, we found a major flaw in our program.

First, we started by tracing how a packet arrives. First we found that it seems to all start in the TK_ENTRY() function defined in netmain() in netmain.c. Here it polls for a change in the queue (rcvdq.q_len) to see if it changed. If the length changed, it will call the function pktdemux() which should then call the ip_rcv function to demux and then ip_rcv_phase2() which will attempt to route the packet.
Next we looked into how the queue is changed. First, there is an interrupt function called from tse_sgdmaRx_isr inside ins_tse_mac.c. Inside thsi function, it checks if there is room inside rcvdq and looks at the SGDMA status. If allowed, it will then go into the tse_mac_rcv(). Inside this function, the bits are adjusted to form a correct frame length and then puts the packet into the queue.

After we understood how the packet arrives, we wanted to write a simple packet sniffer such that every packet coming in is printed out. Instead, we just ran ipdump() at the ip_recv function. Next we wanted to use this information and try to rewrite headers and send out the modified packet using raw_send() from the PACKET struct. At the same time, we haven't been able to thoroughly test this since a packet not destined for the device does not get to the ip_recv function because of a problem.
It was here we saw problems sprout. The first problem we saw was that raw_send() didn't seem to send out the type of packet we wanted to. The next problem was that we finally realized that with our previous configuration, all packets were sent out only through one interface.
The final, more immediately important, problem was that we found that any packet with the destination that wasn't the interface it was sent to would have a different offset in the IP header. An example would be if we send a ping from 192.168.0.104 to 192.168.0.102 (eth1 on the DE4 board), the board would read this correctly .If we send a ping from 192.168.0.104 to 192.168.0.137, the board would not read this correctly and the packet header would show that the source was 118.226.192.168 and the destination was 0.4.0.0. This is the important issue right now because any packet coming in that isn't destined for the devices on the board will not be read in correctly and will not be analyzed by the ip_rcv function.

NIOSII-Week6

This week I am working on getting the SSS working for the board.
I was able to run Hello World on SRAM, so the sram works.
I was able to get SSS loaded on the board, but DHCP was get the IP address.
DHCP times out and goes back to static. I was not able to telnet or ping it.
Not sure what the problems is I checked the pins, SOPC builder and  SSS C code.
I was able to get SSS working with DHCP and was able to telnet it and make it
change the LED lights. Now I am trying to get the second ethernet port on the daughter card.
I was able to figure out the pins for the ethernet daughter card. I was not able to get the second
ethernet port to work.

Stratix Subproject progress (Week 5)

This week was largely spent on attempting to change the pin layouts from the older version to the newer one. The problem was that pins were set to the locations based on the old names in the previous project's version. In the new version, different names were used. Thus, it was necessary to intuitively shift the pin locations to the newer names. This PDF file from Altera's website (especially page 20) served as a guide in determining pin purpose and locations. The Pin Planner in quartus was used to effect the actual changes.

Simon discovered that some of the shared signals were unnecessary, and after the appropriate changes were made in SOPC builder (and after the system was regenerated) the pins were correctly set.

Now, work continues on the software portion of the project, on the C program files.

More on multiple ethernet ports

Here is a blog post just detailing David's explanation and perhaps going a little bit more in depth in the steps we took to get where we were at.

The first thing we tried to do was make sure we had our Verilog and sopc files correct. In SOPC, a new TSE_MAC device was added along with two SGDMAs for receiving and transferring. In Verilog, we just made sure both of our ethernet devices were being defined correctly with "arrays".

Next, we started with the Simple Socket Server template given to us from Eclipse. The first problem we encountered was that from just the template, a MAC address was not being assigned. Instead, it would ask for a serial number and when anything was typed in, it would just assign the MAC address to FF:FF:FF:FF:FF:FF. Because of this, we looked into exactly where the ethernet device was initialized at first. We traced it down to the bsp/alt_sys_init.c file and saw that the TSE_MAC device was initialized in the function alt_sys_init(). This wasn't much help at first so we backtracked a bit to look at the all the functions which actually modified the MAC address. We found these in sss/network_utilities.c. The first thing we modified here was to get rid of any calls to a serial number but this didn't really solve anything. The MAC address would still be the same. We didn't want to define the MAC address exactly because we knew that there was at least one MAC address in flash. We spent a while trying to open in flash and ended up giving up for a while on that and instead just assigned a random MAC address to our ethernet port. This meant we just modified one of the function calls inside sss/network_utilities.c such that a random serial number would be generated and a random MAC address would be assigned based off of this random serial number. Once we got this MAC address up, the SSS was working exactly how we wanted it to.

We moved on to starting to work on getting two ethernet devices up. We had already enabled it all in our Verilog code and SOPC builder so we focused on looking through where in our program we should initialize the devices. We studied through where any device was called and ended up at the bsp/alt_sys_init.c file. The way we got here was we traced how alt_inich_init() was called in our main Simple Socket Server task (in sss/iniche_init.c). In the previously mentioned alt_sys_init() function, all the ethernet devices were being initialized. At first, we couldn't exactly figure out why both devices weren't coming up so we looked into how these devices were setup in the iniche drivers. Through Professor Pak Chan's hint, we started using the function alt_tse_system_add_sys(). To use this, we also had to make sure we initiated each device needed to go into the argument fields of this function. This has been previously discussed in depth by David so I will not get into it. At first, we put all of these statements into SSSInitialTask() in the iniche_init.c file because this is where our SSS would start. When we started testing it, we saw your devices would come up, but our DE4 board seemed to no longer function as a DHCP client. With further investigation, we found that our devices were still sending out DHCP discover packets (found through using Wireshark to trace the packets) but would not accept any packets. I have talked about our troubles with this in a previous post so to make a long story short, we figured out we were not accepting packets because we closed the OpenCore Plus IP dialog box when programming. We next just moved the alt_tse_system_add_sys() calls to bsp/alt_sys_init.c, where the rest of the devices were being setup. After a few tests and some fine tuning to the way we acquire a MAC address, we finally got our SSS server with two ethernet ports up.

While it did take us a long time, all our debugging led us to understand more clearly how an ethernet device is setup, how DHCP works in regards to the ethernet device, and how the MAC address is acquired/assigned. Our next task is to investigate into the way MicroCOS looks and interacts with packets. We will be looking at functions that interact with packets, packet headers, and sending. With our two ethernet devices setup, we will be trying to make a simple forwarding router soon. More updates will come as more progress is made.

NIOSII-Week5

This week I worked on SOPC builder and setting the pins for the components.
Components in the SOPC are
CPU
Tristate Bridge
LAN
RAM/ROM
Timer
Timer 2
JTAG
UART
System ID
FLASH
SRAM
SDRAM
PIO

Added all verilog files from SOPC to project. FPGA pins from SOPC builder are all set.
There was problem when compiling with data0 and tri_state_bus_data being in the same pin.
I looked at the qsf file of the standard layout and found how to fix the problem. I had to add
set_global_assignment -name RESERVE_DATA0_AFTER_CONFIGURATION "USE AS REGULAR IO" to my qsf file to make it work. I was able to compile. When I try to run hello world
I get error where ELF proccess failed. So that means there is something wrong with the pins/mem/design that maked ELF unable to load.

Fixed ELF proccess failed, reason was the there was no clk. Had to create 50mhz clock in timing analyzer. Was able to run Hello World on onchip mem.

Modified Simple Socket Server (Interfaces)

During the past few weeks I have been continuing on trying to get the second interface to work on the modified simple socket server example.    The verilog file has been changed once again to force enable the opening of the second interface (eth1).  Most of the work trying to get the second interface to work involved manipulating/hacking some files within the Altera BSP plugin in Eclipse.  The main files that I have been looking at were particularly ones inside the driver folder of the board support package provided by Altera, particularly on ins_tse_mac.c, altera_avaolon_tse_system_info.c, altera_avalon_tse.c and their respective C Header files in the 'inc' folder.   ins_tse_mac.c contains the methods used to configure the TSE MACs and the public API for the TSE driver. 


The most important method in that file to enable the use of multiple interfaces is  alt_tse_system_add_sys, which defines and adds a TSE system/interface onto an array that will be read to tell the board that a second interface is available to use.  For now, I am assuming that this method will be used twice; one for the first interface and one for the second interface.  The reason I am using it twice is because the simple socket server's default assignment only allows the use of one interface (eth0), so it must be overridden to make use of more than one interface. The file in which I used the add_sys function is in alt_sys_init.c, which is the HAL initialization source file.  Before add_sys can be called though, the objects used to pass into as parameters for add_sys had to be instantiated, such as 'sys_mac_0 = {TSE_SYSTEM_MAC(TSE_MAC_0)};' with type 'alt_tse_system_mac'.  The name TSE_MAC_0 inside TSE_SYSTEM_MAC comes from the names given by system.h, which is created by the the configuration given by the SOPC builder. In other words, the names used to create these objects for add_sys must be exactly named as configured by the system.h file/SOPC builder.


After adding the functions mentioned above, Matt and I tried testing out the program on the DE4 board and the board can then detect and prepare two interfaces.  Based on the debug messages from the program, each TSE MAC has their own physical address in memory as it should (and exactly the ones configured in SOPC builder) and links for the PHYs for both interface can be established.  The first time we tested this out though, our DHCP was not working and we got unreasonable IP addresses (not part of the subnet of the router's IP address) that we couldn't even ping/telnet to.  Unfortunately, we found out the reason for all this trouble is because of a dialog box that must not be closed in the JTAG programmer program, which enables the forwarding of packets to the board (OpenCore Plus IP).  Once we realized that, we tested the program out again and DHCP works again.

As of now, the NicheStack has to be modified so messages can be received and queued asynchronously using both interfaces and then processed synchronously by the server.  I am particularly looking at the os_q.c file contained in the UCOSII folder, which contains the queue management functions for the RTOS.  A DHCP server must also be implemented for the board at the moment.

DE4: Ethernet accepting packets!

At first (the last week or so), we were having a problem with our DE4 ethernet devices not accept packets. We spent days pouring through each function and trying to find a reason for this. We used Wireshark to make sure it was sending the DHCP requests and to make sure our routers were replying to DHCP requests. After some guidance from Professor Pak Chan, we found ourselves stuck in the same location (except now our MAC addresses were being read from the flash correctly).
We ended up starting over and for some reason, still couldn't receive any packets on our board. So after another few hours of testing, we found that there was no problem with the code or anything. In fact, the problem was that we pressed "Cancel" on the OpenCore Plus IP dialog box after programming onto the board.  As upsetting as this was (we could have finished last week), we at least walk away from this experience knowing more about each function that is being used and an experience of how MicroCOS works.

Now that we know that, we have setup the simple socket server on two interfaces. Right now, we only have two problems that don't exactly meet what we want. The first one is that we need to find the place to read in the MAC address for eth1. As it is now, all we did was move a pointer up based on which number eth device is being initialized. The second problem is that right now, we only have one SSS task running. Ideally, I believe we are supposed to have a task for each device. I'm not exactly sure how to declare a device per task and right now, it seems that it can run SSS at a time (meaning it works on both ports as long as the telnet session is not happening concurrently). We will iron this out soon. A separate write up is on it's way once we iron out all the details.

NIOSII-Week4

2/29/12
Error for NIOS IDE was due to Quartus 5 not work for Window 7. So I have to use Quartus 11.1 to build the SOPC file and C files.

3/2/12
For SSS project need to change variables to match variables in system.h
Got SSS to complie on eclipse.
Since old pin layout pin names are diffrenent have to add pins that have different name than old pin layout.

Packet Generator 3/2/12

Packet Generator

First and foremost, I apologize for taking so long to develop a packet generator.

For this part, the first thing I wanted to do was investigate the pcap library which tcpdump uses. This library allows the program to investigate the IP and link layer packets coming in. This may or may not be necessary but I wanted the program to, in the future, be able to investigate all the packets coming through similar to tcpdump. There is a similar library for Windows called WinPcap which also provides a send function. At first, I thought the Pcap library had it's own specified send function so that it could read in packets. Unfortunately, I was wrong and eventually realized that only a simple send command was necessary. The packet generator is split into two parts, a host and a client:

Host: This host will first be called with the port number and the choice between TCP or UDP packets to send out. (Host <port number> <TCP/UDP>). It will wait for a connection. When it receives a connection, it will spawn a thread and the thread will send a defined set of bits to the client.

Client: The client file will be called with an IP address, port number, and choice between TCP or UDP packets (Client <IP> <port> <TCP/UDP>). It will first establish a connection with the router (depending on TCP or UDP) and then prepare to receive packets. The first packet received will be marked with a time. The client should know how much is being sent over so that the last packet received will also be marked with a time. It will then calculate how many bits it has received and the time passed to calculate speed.


Note: This post will be edited upon completion. At this moment, the calculation of the speed is not working correctly and the way the host and the client interact may need to be changed. Also, as much as I researched the libpcap library, it is not being utilized yet. I plan on perhaps saving all traces to a file. Otherwise, I plan on sending an endless stream of packets from the host to the client to get a constant reading on speed from the interfaces.

NIOS II

Week3

2/24/12
For the NIOS II on the SOPC builder I replaced the cpu with a NIOS II cpu and made the connection.
I removed the ext_flash and ext_ram. I gave IRQ to the components that need it. Generated files from SOPC builder. Started hello world example on eclipse. Had 3 errors. Fixed one error by finding install file and moving to correct location.

Current Errors:
*** [system_description/../obj/system.h-t] Error 1
*** [system_project] Error 2

2/26/12
Can't create SSS on eclipse TCP/IP error