Cyclone 10GX transceiver calibration hung

[NWein]

I have a design using the HDMI RX IP.  I am finding that the native PHY (gxb_rx) seems to be stuck in calibration forever.

With Signaltap, I can see that rx_cal_busy is asserted forever.  Also rx_analogreset and rx_digitalreset are asserted, but I'm not entirely sure how they're supposed to behave.

I've verified that CLKUSR is fine, as is my other reference clock.  Where should I look next to figure out what's going on?

[CheePin_C_Intel]

Hi,

As I understand it, you are observing the Native PHY RX seems to be stuck in calibration. To further narrow down the issue, it is recommended to create a simple test design with only duplex Native PHY + TX PLL + reset controller. Then place on the same pinout to see if can replicate similar observation. This would be helpful to narrow down to Native PHY and facilitate debugging. Just would like to check with you the specific Quartus version that you are using? It is recommended for you to try with the latest Quartus version to see if there is difference to narrow down Quartus version dependent issue.

Generally the calibration would auto take place after device power up with the condition:

1. CLKUSR directly sourced from a free-running clock source ie on-board oscillator and stable before power up

2. Frequency for CLKSUR should be from 100 MHz to 125 MHz.

3. All the refclks that drive Native PHY and TX PLL need to be free-running and stable as well prior to power up

Please help to verify the above conditions to see if can spot any anomaly.

Also, please help to look into if there is any anomaly with the XCVR related power supplies.

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

Best regards,

Chee Pin

[NWein]

Thanks for the reply.  Here are answers to your questions:

1) I am using Quartus 19.3, not the latest but still pretty recent.  I'm willing to try upgrading, but I feel pretty certain the HDMI IP has been used successfully with this version (or older).

2) I will try a design with just the gxb_rx and see if it will calibrate.  I'll report back with results.

3) We have verified that CLKUSR is a working, 100 MHz free-running clock. The HDMI IP has two refclks specified, one (fr_clk) is a free-running clock that we also have connected to an external 100 MHz clock input.  I will verify that the clocks are all stable before device power-up is complete.

[CheePin_C_Intel]

Hi,

thanks for your update. Prior to upgrading to newer Quartus version, I think we can focus on the Native PHY simple design test. You can try with simple Native PHY RX only design. If it is not working, then you can try with duplex Native PHY to see if there is any different. Thank you.

[NWein]

I created a copy of my project, and only the gxb_rx, gxb_rx_reset module from my design.  Omitted management block (maybe a mistake) because calibration should happen independently of the management stuff.

Quartus crashes at the beginning of the fitter stage, just after "successfully loaded synthesized database".  No further explanation.

Sadly, a Quartus crash is an all-too-common occurrence me these days, and for the moment I am at a standstill.

[NWein]

I tried updating Quartus from 19.3 to 20.2, and it still crashes when compiling the test design.

[NWein]

OK, I started from scratch with a brand new test design.

I extracted a subset of the code from the HDMI RX core (hdmi_rx_top), including the gxb_rx, gxb_rx_reset, mr_reconfig_mgmt modules, and a couple of other minor things.  *Lots* of signals are stubbed off, and I can only guess whether I've done this all in a reasonable way.

Signaltap shows that rx_cal_busy is *unasserted* now, which presumably means that calibration was successful.  Rx_digitalreset and rx_analogreset are both unasserted; those are driven by the mr_reconfig_mgmt, and since there is no incoming signal maybe that makes sense.  Also, I note that the reconfig_waitrequest signals are now also unasserted, which is a good sign (I think).

Are the rx_cal_busy signals dependent on the any of the other inputs to gxb_rx (like the analog or digital reset), or does the fact that busy signals are unasserted absolutely mean that the transceivers have calibrated successfully?  If the latter, then I need to figure out what in the rest of the design that I removed could be stopping them from calibrating.

[CheePin_C_Intel]

Hi,

Thanks for your help and update. Regarding your inquiry on the rx_cal_busy signal, for your information, the rx_analog_reset and rx_digital_reset are dependent on the rx_cal_busy. If you have the transceiver reconfiguration controller connected to the Native PHY, the controller will wait for the rx_cal_busy to de-assert before it start to release the rx_analog_reset. The rx_digital_reset will only be released after the CDR achieve lock-to-data mode which is indicate why assertion of rx_lockedtodata signal.

Since you are extracting a subset of code from the HDMI RX core, I am not sure how the subset of code works. Generally the rx_digital_reset will only be released after valid signal fed to RX pin and CDR achieve lock-to-data. But in your case, it seems like no incoming signal but the rx_digital_reset = 0. 

To facilitate your debugging, I would recommend you to use the following simple Native PHY design to check if the transceiver can UP:

https://fpgacloud.intel.com/devstore/platform/17.1.1/Pro/cyclone-10-gx-xcvr-toolkit-reference-design/

This is a duplex Native PHY design with transceiver toolkit enabled. You can customize the pinout, refclk frequency and data rate to your board. You can then bring up transceiver toolkit to check on the native PHY.

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

Best regards,

Chee Pin

[NWein]

I'll try the native phy design you linked next.

In the meantime, I tried putting a complete HDMI receiver into the design, and got interesting results.

Initial calibration seems fine.  Signaltap shows that before I connect an HDMI input signal, everything is in a good state.

When I connect, things get weird.  It tries to sync (I see a lot of activity on the reconfig management bus), but keep repeating it periodically.  My assumption is that it is not successfully achieving sync.  I do not yet know why.  But at least it's trying!   That's a bit of progress.

- Neil

[CheePin_C_Intel]

Hi Neil,

Sorry for the delay. Thanks for your update that HDMI IP seems to be working prior to feeding input signal. Currently you are working on the issue with the IP when input signal is fed to the RX. Please feel free to let me know if you would like to further engage our HDMI IP expert to further assist. Since I could not duplicate a case from here, you may open a new Forum case specific to HDMI IP RX and let me know the case so that I could help to expedite the routing. Thank you.

[NWein]

Thanks.

I'm still uncertain why the transceivers wouldn't calibrate in the full design, but it seems more useful at the moment to pursue getting a signal lock on the HDMI receiver-only design, and deal with the complete design issues only after that is resolved.

I'll post here once I open a new case.

[CheePin_C_Intel]

OK. Please keep me posted on the progress. Thank you.

[CheePin_C_Intel]

Hi,

Just would like to follow up with you on this. Thank you.

[CheePin_C_Intel]

Hi,

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.

[NWein]

Hi,

I have made no progress on this issue, but have been diverted to other issues.  I will be returning to this in a week or so to dig in.  I will file a new question when I have new information.

Thanks,

Neil

[CheePin_C_Intel]

Hi Neil,

Thanks for your update. This thread will be transitioned to community support. Please feel free to open a new thread when you have new information. Thank you.