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.