FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
6343 Discussions

HDMI compliance issue

JWang21
Beginner
828 Views

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?

fpll.png

0 Kudos
12 Replies
Deshi_Intel
Moderator
624 Views

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

 

Thanks.

 

Regards,

dlim

0 Kudos
JWang21
Beginner
624 Views

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

0 Kudos
Deshi_Intel
Moderator
624 Views

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

0 Kudos
JWang21
Beginner
624 Views

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

0 Kudos
Deshi_Intel
Moderator
624 Views

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

 

 

0 Kudos
JWang21
Beginner
624 Views

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

0 Kudos
Deshi_Intel
Moderator
624 Views

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)
  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.

 

Thanks.

 

Regards,

dlim

0 Kudos
JWang21
Beginner
624 Views

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

0 Kudos
Deshi_Intel
Moderator
624 Views

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

0 Kudos
JWang21
Beginner
624 Views

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

0 Kudos
Deshi_Intel
Moderator
624 Views

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

0 Kudos
Deshi_Intel
Moderator
624 Views

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

0 Kudos
Reply