HDMI RX: GXB rx_coreclkin and rx_pma_clk showing 600 MHz instead of 300 MHz (and failing timing)

[NWein]

I have an two-port HDMI RX-only design, with all the RX code copied from the example design.  However, apparently there's something I didn't copy correctly because there is a 2x difference in the clock speeds shown in the Timequest report.  My design is failing timing because it's showing the generated clocks to be 600 MHz instead of 300 MHz in the example design.

The "hdmi_clock_speed" screenshot shows the clock listings from the Timequest report (I've edited out irrelevant clocks and reordered a bit for clarity).  In both designs, the HDMI RX clock is spec'ed at 300 MHz, but in my design the GXB rx_coreclkin and rx_pma_clk are generated at 600 MHz, whereas in the example design they show as 300 MHz.  This causes my design to fail timing with regard to those clocks, although in practice everything works fine because the problem seems to be with regard to the compiler incorrectly deriving the speed of those clocks, rather than the circuit itself being wrong.

The "clk_warnings" screenshot shows one warning I get during compilation.  Clearly, what the compiler is getting the wrong PLL settings somehow.

The "gxb_config" screenshot shows the first tab of the config of the GXB block in my design.  As far as I can tell, nothing is changed from the example design.  But obviously something, somewhere is different.  Any suggestions of what it might be, or where to look?

[Deshi_Intel]

HI,

1. May I know are you using Arria 10 or Cyclone 10 GX ?
2. Which Quartus version ?
3. Some possibility that I can think of that may affect clocking report are as below. You may want to cross check with example design again

• NativePHY IP setting
  • PLL setting
  • SDC constraint

Thanks.

Regards,

dlim

[NWein]

1) Cyclone 10GX

2) Quartus Prime Pro 20.2

3) a) Exactly where would I find the NativePHY PLL Setting?  I've looked but can't find anything that obviously connects to the multiply by/divide by problem shown above.
b) I will check again, but all the SDC constraints were copied directly from the example design, as was the entire source tree.  Although obviously *something* is different, somehow..

[Deshi_Intel]

Hi,

There are 2 different IP that I am referring here.

• NativePHY IP setting
  • I can see from your screenshot that you changed the default CDR reflclk from refclk 0 to refclk1 ?
  • What else did you changed ? You can slowly cross check back with HDMI example design
• PLL IP setting
  • In HDMI example design, there are multiple PLL used to provide clocking to HDMI Rx IP and also NativePHY IP. Some are IOPLL IP and some are fPLL
  • The one connected to NativePHY IP should be fPLL.
  • Anyway, I advise you to trace back the clocking design connection in HDMI example design and cross check with your own design again

Thanks.

Regards,

dlim

[Deshi_Intel]

HI,

It's been a while.

Just want to follow up is there any new update that you would like to share with me ?

Thanks.

Regards,

dlim

[NWein]

I apologize that shortly after I opened this issue I got buried in other work and haven't been able to spend much (any?) time on this.

Regarding "default CDR reflclk from refclk 0 to refclk1": this change was recommended by Intel support as a means to get an RX-only design to work.  That's the only change I made (at least, the only one I made intentionally).  The entire block of HDMI RX code was copied from the reference design.

The two subfolders in the reference design that seem relevant are gxb_rx, and pll_hdmi.  In both cases, I went in to look at the .xml files in my source tree, and compared them with a pristine copy of the reference design targeted at the dev board.  So that's rtl/gxb/gxb_rx/gxb_rx.xml and rtl/pll/pll_hdmi/pll_hdmi.xml.  In both cases, I found no significant differences other than the refclk changes mentioned above and various stuff related to changing the target device (we're using 10CX105YF672I5G vs. the dev board's 10CX220YF780E5G), and the different file locations.  Nothing about PLL multipliers or dividers has changed.

[Deshi_Intel]

hi,

Other thing that I can think of is the reconfiguration profile of PLL IP and NativePHY IP.

Make sure you copy everything and also review the sdc file.

These are some critical design files that I can think of that will affect TImequest Analysis.

Thanks.

Regards,

dlim

[NWein]

I will look through and try to figure out if I somehow omitted any files.  Could take a little while; will report back here.

[Deshi_Intel]

Alright