Ethernet 1000BASE-X PCS/PMA or SGMII v9.1
www.xilinx.com
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.
•
For Virtex-II Pro, ensure that the
REF_CLK_V_SEL
attribute matches the
REFCLK
or
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:
♦
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.
•
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.
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.
•
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.
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.
•
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.
•
Try swapping the optical module on a misperforming device and repeat the tests.
