Simple Socket Server, No Response After Adding Logic

[Altera_Forum]

I realize that many questions have already been asked regarding the Simple Socket Server(RGMII). However, I cannot seem to locate a solution, mostly because I am unsure as to the problem. 

 The Scenario: I created a very bare bones project based on the TSE reference design, minus the external memories (replaced with on-chip memory). This design works perfectly; I can ping, telnet in, and control LEDs. I then added some additional PIOs so I could control signals other than the LEDs, and moved the system into a larger project.  The Problem: After moving the system, I am no longer able to connect to the board. (I.e I cannot telnet or ping.) The NIOS-II Console displays the same information as when it was working. I can still see the RX and TX LEDs flashing but there is no connection. I am using a static IP.  Any assistance or thoughts on how to approach troubleshooting are appreciated. Thank you.

[Altera_Forum]

What do you mean with " moved the system into a larger project" 

Did you port the same system into a larger fpga device or did you import the SSS hw/sw into a different design?

[Altera_Forum]

--- Quote Start ---  What do you mean with " moved the system into a larger project" Did you port the same system into a larger fpga device or did you import the SSS hw/sw into a different design?  --- Quote End ---    I moved the system hardware and software into a different design, on the same board. My QSYS system and its assosiated clock selection logic is in a different partition than the rest of my design which operates on a different clock ( They communicate through ports that have synchronizers + edge dectectors ).

[Altera_Forum]

Does your design meet the timing? Is it fully constrained?  

Adding a lot of logic into fpga can mess up critical timings. Focus on the mac section. Rx/Tx LEDs are not very significative, since usually they are directly driven by the phy IC and they will keep on working even if everything else crashes.

[Altera_Forum]

Auto-negotiation passes, so I would think something is working. Also, There are no failing paths in that module, there are some in another partition that existed from before adding the ethernet system. However, I may not have fully constrained the design after adding the qsys system. On Monday I'll make sure that it is fully constrained and report back. Thank you for the reminder.

[Altera_Forum]

What I pointed out in the previous post applies to Auto-negotiation, too. Auto-negotiation is a matter of the PHY and the MAC is not involved, apart for the MDIO interface which communicates with the PHY. But the MDIO is a serial interface somewhat separate from the actual MAC core. 

That's why your system can initialize the ethernet link and detect when negotiation has completed, even if mac is possibly not working.

[Altera_Forum]

Thank you for that information; the design is now fully constrained, and there are no failing paths in the partition containing the Ethernet Subsystem, however, I am still unable to connect to the server. 

 Edit: I have found that forcing the connection to run at 10Mbps, I am able to connect to the server. I think that there may be an issue with how I set up my clock multiplexer. I currently have 2 two-input multiplexers; one that chooses between 125 and 25, and a second that chooses between the former selection and 2.5. I will attempt to make a single 3-input clock mux and see if that makes a difference.  Update: Stratix IV does not allow 3 input clock muxes, thus I seem to be forced to use a PLL with 1/1 which leads to inconsistent PLL crosschecking. Any ideas on how to overcome this limitation?