HDMI compliance issue

[JWang21]

Currently our design (using 10AX115) is suffering a HDMI compatibility issue with a certain video source. The HDMI Rx is Coretronix's in-house IP. The Tx is a specific video box.

We already know that this video box's TMDS clock exhibits larger jitter than other video sources. But this box works fine with other Rx (e.g. various kinds of monitors), except for ours.

(One thing to note is that Intel demo board with Bitec HDMI Rx IP also fails with this box.)

The video resolution is 1080p@60Hz and we use the TMDS clock as the reference clock to a fPLL.

We are wondering if Intel has any suggestions on how to further fine-tune the fPLL and/or xcvrs?

[Deshi_Intel]

HI,

May I know which revision of Bitec HDMI daughter card that you used ?

• The reason I asked is due to below Bitec latest daughter card rev11 has additional retimer chip that can help improve the signal integrity on board to confirm your debug finding whether the failure is due to bad signal quality issue or not
• https://bitec-dsp.com/product/fmc-hdmi-daughter-card-rev-11/

Alternatively, you can also refer to below transceiver link tuning guideline doc to learn more about the fine tune method

• https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/an/an871.pdf

Thanks.

Regards,

dlim

[JWang21]

Hi Dlim,

The only version info I can find on the board is:

PCB mark : MADE IN UK REV 6 (on the top-right corner of card)

In addition,could you please check with Bitec why they replaced Pericom re-drivers with TI re-driver and re-timer on its HDMI 2.0 daughter card?

Does the TI chips provide better noise/jitter resistance (or other benefits in terms of signal quality) than the Pericom counterparts? Or is it just some logistic consideration (e.g. cost)?

Thanks,

Jay

[Deshi_Intel]

Hi Jay,

So you are using Bitec daughter card rev 6 without the retimer chip that's only available in Bitec daughter card rev 11.

So, it's your call

• You can try perform link tuning to see if it helps
• Worst case is you can consider to purchase Bitec daughter card rev 11 to help improve the signal integrity

Thanks.

Regards,

dlim

[JWang21]

Hi Dlim,

Do you know why Bitec replaced Pericom re-drivers with TI re-driver and re-timer on its HDMI 2.0 daughter card?

Does the TI chips provide better noise/jitter resistance (or other benefits in terms of signal quality) than the Pericom counterparts? Or is it just some logistic consideration (e.g. cost)?

Thanks,

Jay

[Deshi_Intel]

HI Jay,

Sorry, I am not sure as well.

Perhaps it's better for you to consult Bitec directly since you are their customer as well :)

Thanks.

Regards,

dlim

[JWang21]

Hi Dlim,

Do you have any comment for these 2 condition,

1) When the video source has larger jitter, the fPLL can still lock to the incoming TMDS clock, though the data seems to be incorrectly decoded as the Rx fails to sync with Tx.

2) The fPLL is set to "CASCADE SOURCE" in FPLL MODE in Platform Designer. The fPLL's output is used as the XCVR's CDR reference clock. It does not connect to other fPLL or ATXPLL.

Thanks,

Jay

[Deshi_Intel]

HI Jay,

Pls see my comment below.

1. When the video source has larger jitter...

• This is a very subjective question and literally depend on your actual design implementation (timing constraint, fitter placement, which PLL location usage and etc)
  • Anyway, you can refer to A10 datasheet table 38 and table 39 for A10 fPLL and IOPLL spec guideline
    • https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/arria-10/a10_datasheet.pdf
    • Do take note of NOTE65 : A high input jitter directly affects the PLL output jitter. To have low PLL output clock jitter, you must provide a clean clock source with jitter < 120 ps.

1. The fPLL is set to "CASCADE SOURCE" in FPLL MODE in Platform Designer...

• I reviewed A10 HDMI reference design and I can see that it's using PLL cascade mode as well. The only difference is the reference design is using IOPLL instead of fPLL.
  • You can take a look of the reference design as well. checkout hdmi_rx_top.v design file in <project>\ip\hdmi_subsys\hdmi_subsys_alt_hdmi_example_design\alt_hdmi_example_design\rtl\hdmi_rx
  • https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/an/an776.pdf

Thanks.

Regards,

dlim

[JWang21]

Hi Dlim,

Thanks a lot for the prompt reply. We will look into those documents that Intel mentioned.

A note on the choice of fPLL instead of IOPLL for HDMI Rx is that the FPGA has much more fPLLs than IO PLLs and we ran out of IO PLLs to use.

Thanks,

Jay

[Deshi_Intel]

HI Jay,

Got it.

I am not saying IOPLL is definitely better than fPLL but it's just a suggestion for you to try out.

A suggestion here, it's easier to debug issue using simplify design rather than your full system design to help isolate the problem first

Thanks.

Regards,

dlim

[JWang21]

Hi Dlim,

We won't be able to do a simple design to isolate the problem since the CDR always shows that it is locked to data. It is only at the later TMDS decoder stage that we do find something wrong which causes the HDMI Rx to lose sync from time to time for the specific HDMI source that exhibits larger jitters.

As we employ dynamic re-configuration for the transceivers, it is required that we do re-calibration whenever we reconfigure the Rx when the Tx. So the potentially incorrect CDR calibration at power-up should not be the cause.

And I see no transceiver-related errors during compilation.

Currently we have scanned the xcvrs settings (VGA gain, CTLE DC/AC gains, DEF off/adaptive) and decided that the current settings are proper. We also tried medium and low bandwidth settings for the fPLL(High bandwidth is invalid). But all to no avail. 

We are doing more experiments to determine what is so special about this HDMI source ...

Thanks,

Jay

[Deshi_Intel]

HI Jay,

One thing to clarify is RX channel CDR locked doesn't mean that received data is correct.

It only tell the received data rate is correct but not that data content.

• For instance, like when using transceiver toolkit to perform link tuning time, we are relying on the PRBS data generator and PRBS data checker to tell pass or fail, not just relying on CDR lock signal

Thanks.

Regards,

dlim

[Deshi_Intel]

Hi Jay,

It's close to 2 months since I last heard from you.

Hopefully all our previous discussion did help to ungate your customer project development.

For now, I am setting this case to closure.

Thanks.

Regards,

dlim