Cannot get Cyclone 10 GX HDMI RX to lock

[NWein]

I'm using the Intel HDMI 2.0 RX IP on a Cyclone 10 GX, Quartus Prime Pro 20.2.  I cannot get it to lock at any frequency.  My video source is a Teledyne-Lecroy HDMI analyzer, so I feel comfortable that the video input is valid.

Different input resolutions behave differently, and I'm seeing a number of different failure modes.  Three common ones are shown in the attached STP files, which include the reconfig management state machine as well as all the relevant signals I could figure.

Common to all cases: PLL is always locked, vidlock is never asserted.

1) gxb0_waitlock.stp: hdmi lock is never achieved (state machine times out in the WAITLOCK state).  rx_freqlocked and rx_datalock are asserted on all channels.

2) gxb_lose_freqlock.stp: hdmi lock is achieved, but eventually one or more channels lose rx_freqlocked before vidlock is ever achieved.

3) gxb_lose_hdmilock.stp: hdmi lock is achieved, but is lost before vidlock is ever achieved.

We just got a new dev kit and I will try out my code (which is really just the RX from the example design) on it to see if it works there, but that won't be until next week.

[Deshi_Intel]

HI,

Based on your update, looks like you will be getting Intel C10 GX dev kit to validate the HDMI example design ?

Yup, this is good move. Pls bring up HDMI example design on Intel C10 GX dev kit board to validate your hardware setup first before switching to your own design.

Below is the HDMI design user guide doc for your reference

• https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug-dex-hdmi-c10gx.pdf

Thanks.

Regards,

dlim

[NWein]

Regrettably, I am having trouble compiling my design for the dev board.  I'm seeing an error I've seen before; last time I went through a very long and involved tech support case and although it was eventually fixed we never really got a clear explanation of the problem, so now I once again have no clue how to address it.

I am seeing this error, for each of the three transceiver channels:

Error(11192): Input port "REF_IQCLK[0]" of "HSSI_PMA_CDR_REFCLK_SELECT_MUX" cannot connect to PLD port "O[0]" of "IO_INPUT_BUFFER" for node "c10_refclk2_p~input".

I have tried using other clock inputs instead of refclk2 and there's no change.  Until I can get past this I can't do anything.

Here's all the extra info that comes with the error:
Extra Info(13133): Output port's "O[0]" node name is "c10_refclk2_p~input".
Extra Info(13134): Input port's "REF_IQCLK[0]" node name is "ehive_hdmi_only|hdmi0|hdmi_rx_top|u_gxb_rx|gxb_rx|g_xcvr_native_insts[0].twentynm_xcvr_native_inst|twentynm_xcvr_native_inst|inst_twentynm_pma|gen_twentynm_hssi_pma_cdr_refclk_select_mux.inst_twentynm_hssi_pma_cdr_refclk_select_mux".
Extra Info(12877): Output port "O[0]" of "IO_INPUT_BUFFER" can connect to:
Extra Info(12878): Port "INCLK[0]" of "CLKBUFBLOCK".
Extra Info(12878): Port "INCLK[0]" of "CLKSELBLOCK".
Extra Info(12878): Port "INCLK[1]" of "CLKSELBLOCK".
Extra Info(12878): Port "INCLK[2]" of "CLKSELBLOCK".
Extra Info(12878): Port "INCLK[3]" of "CLKSELBLOCK".
Extra Info(12878): Port "DATAIN[0]" of "DELAY_CHAIN".
Extra Info(12878): Port "I_INCLK[0]" of "CLKBURSTBLOCK".
Extra Info(12878): Port "I_RXN[0]" of "HSSI_PMA_RX_BUF".
Extra Info(12878): Port "I_RXP[0]" of "HSSI_PMA_RX_BUF".
Extra Info(12878): Port "I_RX_N_BIDIR_IN[0]" of "HSSI_PMA_TX_BUF".
Extra Info(12878): Port "I_RX_P_BIDIR_IN[0]" of "HSSI_PMA_TX_BUF".
Extra Info(12878): Port "I_REFCLK_INN[0]" of "HSSI_REFCLK_DIVIDER".
Extra Info(12878): Port "I_REFCLK_INP[0]" of "HSSI_REFCLK_DIVIDER".
Extra Info(12878): Port "I_RXP[0]" of "HSSI_PMA_CDR_PLL".
Extra Info(12878): Port "I_PIN_PERST_N[0]" of "HSSI_GEN3_X8_PCIE_HIP".
Extra Info(12879): Input port "REF_IQCLK[0]" of "HSSI_PMA_CDR_REFCLK_SELECT_MUX" can connect to:
Extra Info(12880): Port "O_REFCLK_A[0]" of "HSSI_REFCLK_DIVIDER".

[Deshi_Intel]

Hi,

Looks like there is some refclk connection issue which caused design compilation failure. I need to review your design to understand the failure better.

• Can you share with me your Quartus design top level file and Quartus project qsf file ?

Alternatively, can you try out HDMI example design on your custom board ?

Thanks.

Regards,

dlim

[Deshi_Intel]

HI ,

I just drop you private message as well.

Kindly checkout the detail in private message.

Thanks.

Regards,

dlim

[Deshi_Intel]

 

[Deshi_Intel]

Hi Neil,

The forum private message attachment feature is broken but this forum post attachment feature is working. So, I have attached the pic explaining the fitter error to you.

In short,

• your hdmi_rx_devboard_restored project assigned transceiver rx_cdr_refclk0 pin to a IO_clk (pin_F23) which caused Quartus fitter error
• while your hdmi_rx_prototype_restored project assigned rx_cdr_refclk0 pin to a transceiver dedicated refclk (pin_R24) which is good and correct

Just wonder do you aware you can actually generated HDMI example design that target C10 GX dev kit board directly from HDMI IP ?

• I can see that HDMI example design assigned rx_cdr_refclk0 (usb_refclk_p) to transceiver dedicated refclk (pin_U24)
• You can follow similar pin setting

Thanks.

Regards,

dlim

[NWein]

I did not use R24 on the devboard because it is routed to the PCIe connector, and that will not be connected to anything.  U24 should be OK, I will give that a try.

I am aware that it's possible in theory to target the design to the devboard, but for whatever reason that is not working correctly on my Quartus install right now.  When I go to select a board to target, the pull-down shows no options at all.  Therefore, I had to manually assign everything.

I will report back with the results of my compilation and test with the new clock pin assignment.

[Deshi_Intel]

HI Neil,

Sure, go ahead to try out the HDMI example design.

Another observation that I have is I noticed you didn't enabled "deep colour mode" in HDMI IP which limit your video data bit per colour (bpc) to < 10 bpc

May I know is there a reason why you disable deep colour mode in HDMI IP ?

• to save FPGA logic resource consumption ?
• Else this could be one of the factor affecting your video traffic as well

Thanks.

Regards,

dlim

[NWein]

Our HDMI receiver feeds an encoder that only supports 8 bit video data.

[Deshi_Intel]

I see. Got it.

Just need to make sure your video source Teledyne-Lecroy HDMI

analyzer configure to 8bpc setting only for your HDMI testing

Thanks.

Regards,

dlim

[NWein]

No worries there, the analyzer (like any HDMI source) obeys the EDID.

It looks like the project behaves just about the same on the dev board as on our own hardware.  The STP files attached to the first message represent it well.  As before, behavior is different at different resolutions.  Most resolutions achieve HDMI sync but it flits in and out.  Video sync is never achieved.  At some resolutions (e.g., 1024x768x60) HDMI sync is never achieved.

Again, this is essentially the HDMI receiver from the example design, unaltered, with my own code to loop the reconfig management bus output from the RX back to the input (that's in reconfigLoopback file in archive I sent).  I'm pretty sure that code is OK but it bears checking.

It is unclear to me where to look for the problem.

[Deshi_Intel]

 

[Deshi_Intel]

Hi Neil,

In short, basically your HDMI design video is not working despite all different video resolution that you try out.

• It's hard to tell whether is it due to hardware setup issue or HDMI Quartus design issue
• Can we rule out potential hardware setup issue by using Quartus Pro v20.2 HDMI example design as golden reference, first ?
• make sure you configure the right Bitec daughter card revision parameter in example design top level file (c10_hdmi2_demo.v)

I know this is HDMI Rx to Tx retransmit design while your application is just using RX only. But for the sake of debug, let's stick to this golden example design for now

• I suggest we stick with it for debug purpose while refer to the HDMI example design user guide doc to aid in debug
• https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug-dex-hdmi-c10gx.pdf

Another thing that you should take note is HDMI design doesn't work by using default IOPLL setting. IOPLL needs to reconfigured to match with incoming HDMI video resolution before it can work properly.

• What it imply is HDMI operation may failed if somehow this important IOPLL loose lock or the IOPLL reconfiguration doesn't happen correctly
• I am not sure whether have you monitor "iopll_locked" as I don't see this signal in your signal_tap file ?
• I also don't see quartus.ini file in your HDMI project PLL folder. By right it should be generated together with the v20.2 HDMI example design. This quartus.ini helps to prevent IOPLL from loose lock.
• Just wonder are you using HDMI example design code generated from Quartus Pro v20.2 HDMI IP ?

Thanks.

Regards,

dlim

[NWein]

Hi again,

I have the quartus.ini in my file hierarchy.  Maybe the archiver didn't pick it up?  Based on past experience, I don't trust the archiver, so it wouldn't surprise me.  I had previously checked and did see the warning when opening the PLL reconfig IP.  The instructions on that .ini file aren't really clear; they say to put it in the project directory, but in the example design it's in the PLL folder.  Just to be 100% sure, I tried copying it to the top project directory as well, and it made no difference.

Iopll lock was in the Signaltap files, except I had included the sync version (pll_locked_sync).  As far as I can tell, iopll is locking correctly at all resolutions.

The code I am using is indeed from 20.2 example design.

I will try to fire up the full example design next.

[Deshi_Intel]

Hi Neil,

The correct way to apply the quartus.ini file is to place the quartus.ini file in same folder as the Quartus project file *.qpf. In your case will be

• \hdmi_rx_devboard\quartus_projects\ehive_hdmi_devboard2
• I am not sure why HDMI IP developer placed the quartus.ini file in the IOPLL folder or is there special background processing in it
• My recommendation is you can copy the quartus.ini file and placed it in Quartus project file *.qpf folder and recompile the whole HDMI example design again for hardware testing

Regarding IOPLL_locked signal_tap check

• To be safe, just wonder have you set signal_tap "falling edge" trigger on pll_locked_sync signal to ensure it never loose lock ?

Below are some factor that I think will caused HDMI failure but we should be able to ruled out some of these failure using golden HDMI Rx to Tx example design

• board issue (dev kit board should be golden unless it's faulty)
• HDMI cable issue (use different cable vendor and also test out different cable length. Make sure there is no other adjacent HDMI cable that may caused interference)
• HDMI video source (you are using Lecroy tester which should be good, alternate option is to test with other HDMI source like HDMI graphic card)
• Quartus design issue (can be ruled out using golden HDMI reference design)
• Quartus design HDMI pin setting issue (can be ruled out using golden HDMI reference design)
• Ensure correct on board FPGA power, HDMI design input clock frequency, and proper HDMI reset control
• Potential HDMI software and RTL design corruption issue due to file copy, Quartus version upgrade and etc (regenerate new fresh HDMI example design is the way to go here)

Thanks.

Regards,

dlim

[NWein]

Hi again,

Executive summary: I tried the HDMI example design, unmodified, on my brand-new dev board.  It behaves approximately the same as my previous attempts: will not lock onto the input.  No video output was received.

Notes:

1. I tried multiple video sources (HDMI analyzer and my Dell Laptop), two different cables including one that came with the analyzer, and assorted input resolutions.
2. I confirmed that the the BITEC daughterboard rev specified in the code matches my hardware (rev 11)
3. I copied the quartus.ini file from the PLL folder to the main project folder.  It behaves the same either way.
4. I did not yet set up a signal tap for the example design, but it outputs sync status to the LEDs and they blinked just like on my design.
5. While compiling I get this warning: "Warning(125092): Tcl Script file ../software/tx_control/mem_init/meminit.qip not found."  I am unclear about the implications of this (if any), but I did double-check and the instructions for the design say nothing about needing to compile the SW or do anything special with it in order to run the design.

In another effort, I went through the QSF file on my own design and compared it to the golden reference design.  I found a few small discrepancies, then fixed them and tried my design again (and once again I will note that "my design" is basically the receiver half of the golden reference design).  No change of behavior was observed.  During compilation, I did get warnings about the XCVR_RECONFIG_GROUP settings, despite the fact that mine are now identical to the golden reference design.  Example:

Critical Warning(11947): Only one XCVR_RECONFIG_GROUP "0" .qsf setting for interface instance "fmc_dp_m2c_p(0)~pad". Check .qsf setting's validity.

I continue to be at a loss here, and await further suggestions.

Thanks,

Neil

[Deshi_Intel]

 

[Deshi_Intel]

 

[Deshi_Intel]

Hi Neil,

I have consulted Intel HDMI engineering team.

• The is special case where the IOPLL reconfig quartus.ini needs to be placed in IOPLL folder for it to take effect. So, no need to move to main Quartus project folder
• So far, HDMI validation team doesn't perform hardware testing with deep colour mode = off setting.
  • I have generated the v20.2 HDMI example design sof file with deep colour mode = off for the HDMI validation team to test out. Will keep you posted on the test result update.
• The latest hardware test configuration from Intel validation team is as below
  • Quartus Pro : v20.3
  • HDMI source : Quantum Data 980B
  • HDMI sink : Sharp TV
  • Bitec HDMI daughter card : rev11
  • Video format : RGB, YCbr444, YCbr422, YCbr420
  • Video resolution : 4kp60, 4kp30, 1080p60, 720p60, 576p50, 480p60, 1080i30, 1080i25
• May I know what video format that you tested so far ?
  • Can you try out above validated configuration ?
  • Also can you screen shot your Teledyne-Lecroy HDMI analyzer setting for me ?

I am not so sure about all the warning message that you saw BUT as long as you are generating new HDMI example design from fresh then recompile design to generate sof file for testing then should be fine.

• Just avoid copy paste from old project folder or perform auto upgrade from old project folder will do

For C10 GX dev kit setup side, what matter is per attached pic screen shot

• Ensure you are providing the correct clock frequency (100MHz and 125MHz) to HDMI IP. Pls double check with dev kit clock controller GUI software
• Also, make sure you configure the switch setting correctly as per attached pic

Additional debug suggestion

• You can try out with deep colour mode = enabled setting while Intel validate deep colour mode = disable from our side
• you can also use Quartus v20.3 to generate new HDMI example design for testing to match with Intel validation result
• Lastly, is there a way for you to validate your C10 GX dev kit and Bitec HDMI daughter card to ensure they are in good condition else we will be wasting effort to debug potential faulty board issue here ?

Thanks.

Regards,

dlim

[Deshi_Intel]