Xilinx 1000BASE-X Manuel D’Utilisation
Ethernet 1000BASE-X PCS/PMA or SGMII v9.1
229
UG155 March 24, 2008
Problems with a High Bit Error Rate
R
RocketIO Transceiver Specific
When using a RocketIO transceiver, perform these additional checks:
•
Ensure that the polarities of the TXN/TXP and RXN/RXP lines are not reversed. If they
are, this can be easily fixed by using the TXPOLARITY and RXPOLARITY ports of the
RocketIO.
are, this can be easily fixed by using the TXPOLARITY and RXPOLARITY ports of the
RocketIO.
•
For Virtex-II Pro, ensure that the REF_CLK_V_SEL attribute matches the REFCLK or
BREFCLK
BREFCLK
port that the clock source to which it is connected.
•
Check that the RocketIO is not being held in reset by monitoring the mgt_tx_reset
and mgt_rx_reset signals between the core and the RocketIO. If these are asserted
then:
and mgt_rx_reset signals between the core and the RocketIO. If these are asserted
then:
♦
In Virtex-II Pro, this indicates that the DCM has not obtained lock.
♦
In Virtex-4 and Virtex-5 this indicates that the PMA PLL circuitry in the RocketIO
has not obtained lock.
has not obtained lock.
•
Monitor the RXBUFSTATUS[1] signal (Virtex-II Pro) or the RXBUFERR signal (Virtex-4
and Virtex-5) when Auto-Negotiation is disabled. If this is being asserted, the Elastic
Buffer in the receiver path of the RocketIO is either under or overflowing. This
indicates a clock correction problem caused by differences between the transmitting
and receiving ends. Check all clock management circuitry and clock frequencies
applied to the core and to the RocketIO.
and Virtex-5) when Auto-Negotiation is disabled. If this is being asserted, the Elastic
Buffer in the receiver path of the RocketIO is either under or overflowing. This
indicates a clock correction problem caused by differences between the transmitting
and receiving ends. Check all clock management circuitry and clock frequencies
applied to the core and to the RocketIO.
Problems with a High Bit Error Rate
Symptoms
The severity of a high-bit error rate can vary and cause any of the following symptoms:
•
Failure to complete Auto-Negotiation when Auto-Negotiation is enabled.
•
Failure to obtain a link when Auto-Negotiation is disabled in both the core and the
link partner.
link partner.
•
High proportion of lost packets when passed between two connected devices that are
capable of obtaining a link through Auto-Negotiation or otherwise. This can usually
be accurately measured if the Ethernet MAC attached to the core contains statistic
counters.
capable of obtaining a link through Auto-Negotiation or otherwise. This can usually
be accurately measured if the Ethernet MAC attached to the core contains statistic
counters.
Note:
All bit errors detected by the 1000BASE-X PCS/PMA logic during frame reception will
show up as Frame Check Sequence Errors in an attached Ethernet MAC.
Debugging
•
Compare the problem across several devices or PCBs to ensure that the problem is not
a one-off case.
a one-off case.
•
Try using an alternative link partner or test equipment and then compare results.
•
Try putting the core into loopback (both by placing the core into internal loopback,
and by looping back the optical cable) and compare the behavior. The core should
always be capable of Auto-Negotiating with itself and looping back with itself from
transmitter to receiver so direct comparisons can be made. If the core exhibits correct
operation when placed into internal loopback, but not when loopback is performed
via an optical cable, this may indicate a faulty optical module or a PCB problem.
and by looping back the optical cable) and compare the behavior. The core should
always be capable of Auto-Negotiating with itself and looping back with itself from
transmitter to receiver so direct comparisons can be made. If the core exhibits correct
operation when placed into internal loopback, but not when loopback is performed
via an optical cable, this may indicate a faulty optical module or a PCB problem.
•
Try swapping the optical module on a misperforming device and repeat the tests.