HDMI compliance issue

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

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

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

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

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

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

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

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

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

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