Why RX part of C5GT XCVRs (Transceivers) do not work.

[TSS1]

Hi,

We are working with a board designed in-house.

It hosts a Cyclone 5 GT FPGA, of whose 6 XCVRs, we use 4:

3 RX @ 1485MbpS, and 1 RX&TX @4752MbpS.

In some of these boards, the XCVRs work fine, but in others, the XCVRs do not extract the,

lock on, or even calibrate on the ingress serial data.

We are puzzled how can a similar issue occur in two so different types of XCVRs.

We suspect this could be due to wrong termination (although I've verified OCT turned on in Quartus),

power-supply issues, power sequencing issues during power-up, or an unknown reason.

Furthermore, we suspect this could be a faulty device issue, or a counterfeit device issue.

Has anyone faced such problems? Your advice would be much welcome!

[CheePin_C_Intel]

Hi,

As I understand it, you observe some CV GT XCVR issue. If I understand you correctly, this happens in some of the boards while others are working fine. These boards are of the same design.

To ensure we are on the same page, just to check with you on the following:

1. Would you mind to further elaborate on your issue observations with the XCVR ie CDR lose lock, RX parallel output is incorrect?

2. Which XCVR channels ie duplex or RX only are having the issue?

3. What are the Native PHY status signals in Signaltap when issue occurs ie rx_ready, sync status, CDR lock status and etc

4. Are you performing loopback test? If yes, please help to share a high level block diagram on the test connection. 

Please let me know if there is any concern. Thank you.

Best regards,

Chee Pin

[TSS1]

Hi Chee,

Thank you for getting back to me.
You understand the problem correctly.
RX part of XCVRs cannot lock neither on bit-rate
nor on the data itself.
Enters/exits calibration processes all the time.
RX problems are on both RX-only and full-duplex XCVRs.
Signal-Tap signals indicate that input signals
are allegedly extremely weak to nonexistent,
as shown by the signals you've listed, as well as others.
We're not performing loopbak tests.
We could be wrong, but we suspect it's FPGAs either counterfeit
or from a faulty production batch.

Regards,
Itay

[CheePin_C_Intel]

Hi Itay,

sorry for the delay. I might have overlooked this. As I understand it, you observe RX CDR does not achieve lock. Would you mind to share with me the Native PHY status signals in Signaltap when issue occurs ie rx_ready, sync status, CDR lock status and etc to see if there is any potential anomaly.

To help isolating potential signal integrity issue, it is recommended for you to create a simple duplex Native PHY design, send fix data from TX and enable internal serial loopback to RX to see if the CDR can achieve lock.

Just would like to check with you if the mgmt_clk to the reconfiguration controller is directly sourced from a free-running and stable oscillator on-board with frequency 75-125 MHz? This is to ensure the RX offset cancellation can be performed successfully during power up so that the transceiver can function correctly.

Please let me know if there is any concern. Thank you.

Best regards,
Chee Pin

[TSS1]

Hi Chee,

I can share the Signal-Tap only after the boards return to our offices.

They are being debugged now,  on multiple other issues.

A loopback is possible only on the bidir XCVR (SFP) but not on the 3 RX-only XCVR,

as their TX counterparts are not routed in the PCB.

The mgmt_clk is 87.5MHz, but created from an FPGA-internal PLL.

The PLL itself is fed by a free-running and stable oscillator.

However, my design includes a mechanism supposed to keep the XCVR reset signal asserted,

as long as said PLL is not yet locked.

Thanks,

Itay

[CheePin_C_Intel]

Hi Itay,

Sorry for the delay. It seems like my response through email last week did not captured by the system.

Thanks for your update. For your information, you should also keep the reconfiguration controller in reset until the PLL output is stable. It is recommended for you to add some delay after the PLL achieve lock before releasing the reset to reconfiguration controller and Native PHY to ensure the PLL output is already stable.

Also, since the mgmt_clk is derived from IOPLL, you can also try to increase the frequency to 100MHz to see if there is any difference.

Please let me know if there is any concern. Thank you.

Best regards,

Chee Pin

[CheePin_C_Intel]

As I understand it, it has been some time since I last heard from you. This thread will be transitioned to community support. If you have a new question, feel free to open a new thread to get the support from Intel experts. Otherwise, the community users will continue to help you on this thread. Thank you.

[TSS1]

Hi Chee,

Thanks for helping us so far, it seems indeed it's an FPGA issue, 

but not necessarily as previously suspected (unsuccessful XCVR init.).

Rather - a problem  in the source who sold us the FPGAs.

In most FPGAs purchased from that source, problems occurred,

whereas in all FPGAs purchased from another source - no problems occurred.

We are waiting for test results from additional boards, to have better statistics,

to be sure this is indeed the case.

This is why on my side, I whish to keep this SR still open.

Thank you and best regards.

[CheePin_C_Intel]

Hi,

Thanks for the update and finding. It seems weird to have source dependency for the failure. Probably due to specific batch or variants. Please feel free to keep me posted on the finding. Thank you.

Best regards,

Chee Pin