The hard_temac v3.00.a and v.3.00.b are based on the v4.1 COREGen V4 Embedded Ethernet MAC wrapper files. When you select SGMII, the core includes the GT11. The hard_temac SGMII files target CES2/3 silicon. Please refer to the following Know Issues if CES4 silicon needs to be used. If you have further questions, please contact Xilinx Technical Support:
1. When using SGMII, the current hard_temac files target CES2/3 silicon and use a v1.2.1 calibration block. For CES4 silicon, there are updated MGT attributes that are needed and the v1.4.1 calibration block should be used. The v1.2.1 calibration block is not tested with CES4 and it is not supported by Xilinx to use CES4 and the 1.2.1 calibration block. For information on upgrading the calibration block, please see (Xilinx Answer 22477).
The latest GT11 attributes can be obtained from the ucf file generated by the latest GT11 Rocket IO Wizard in COREGEN. Adding these ucf constraints to the EDK project will override the attributes in the code for the core. Below is an example of the syntax of one constraint added to the ucf for an EDK project:
INST "hard_temac_0/hard_temac_0/*?I_EMAC_TOP/GT11_DUAL_1000X_inst/GT11_1000X_A" RXLOOPFILT = 1111;
2. The current core uses a 125Mhz reference clock. To reduce jitter for Virtex-4 FX GT11 a 2x 250 MHz reference clock can be used. For information on switching to a 250 MHz reference clock, see (Xilinx Answer 23612) and the Virtex-4 FX errata. If regenerating attributes with the Rocket IO Wizard as described above in #1, the Rocket IO wizard will allow you to set the reference clock frequency.
3. When SGMII is used at 10 Mb/s to connect two devices with 100 ppm clocks, there is potential for overflow or underflow in the RocketIO Elastic Buffer for both Virtex-II Pro and Virtex-4. To work around this issue, use 50 ppm clocks on both the Xilinx chip and the PHY chip. For more information, see (Xilinx Answer 23319).
4. Virtex-4 FX errata specifies that the MGT should always be active. In most scenarios with SGMII, the MGT should always be active because even if the cable is pulled the PHY will still be sending idles to the MGT as long as the PHY is powered up and running. If the MGT will be powered up but inactive, please see (Xilinx Answer 22477) and (Xilinx XAPP732): "Inactive Transceiver Behavior Work-Arounds for Virtex-4 RocketIO MGTs."
5. When generated for SGMII, the EMAC can fail to Auto-Negotiate and appears frozen or stuck in a loop. This problem is the result of an incorrect connection in the wrapper file. Currently, PHYEMAC#RXBUFSTATUS[1:0] is connected to the GT11 RXSTATUS[1:0]. To fix this, route RXBUFERR from the GT11 in question to the PHYEMAC#RXBUFSTATUS input port of the Virtex-4 EMAC. PHYEMAC#RXBUFSTATUS is unconnected in the EMAC and can be grounded.