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 Neil,

Attached is the test result screen shot from Intel HDMI validation team verifying the v20.2 HDMI example design that I shared with them.

This is expected test result for (deep colour mode = off) setting.

• 8bpc test result is passing while 10bpc and 12 bpc test result are failing

Why not let me share my HDMI example design sof file for you to try out on your C10 GX dev kit board.

Thanks.

Regards,

dlim

[NWein]

Thanks.  As I communicated to you via PM, the SOF file you provided me works correctly, confirming my dev board setup.

Given that the hardware is verified, that leaves my software setup or operator error.  I'm not sure what I could do differently at this point.  I generated the example design and compiled it in-place, with no modifications.

[NWein]

There is one difference between my SW setup and yours... I'm at the moment using the unlicensed HDMI core in evaluation mode.  As I understand, it should operate with full functionality while I'm tethered, but it is possible that that could be affecting operation somehow?

[Deshi_Intel]

Hi Neil,

Great. We are making good progress here. We solved the tough part and now marching towards more easier part I guess.

I am not too sure about the “unlicensed HDMI IP core in evaluation mode” either. I will try ask around to see if I can find out anything.

• Btw, how do you get the license in the first place ? Is there any Intel FPGA support FAE that you can consult to clarify further ?

Regarding software setup

• I am using Quartus Linux version. May I know are you using Quartus Linux or Quartus Windows version ?
• Another thing that I think can help you out is let me create step by step screenshot on how I generated HDMI example design. Then you can cross check to see are you following the same procedure here.

Thanks.

Regards,

dlim

[NWein]

1) We simply have not purchase the core yet, since we're still debugging a handful of units that are always running tethered.  Once we have a larger number of devices to distribute to more software developers and/or testers, we'll buy the core.  However, if we can determine that for some crazy reason the unlicensed mode *is* causing our problems, we can purchase the core (through Arrow).  But according to all available information it *shouldn't* be the problem.

2) I'm running QPP 20.2 under Windows 10

3) I've been told that, for now, this forum is to be my primary source of support.

Thanks,

Neil

[Deshi_Intel]

Attached is C10 GX HDMI design example generation guideline

[Deshi_Intel]

Hi Neil,

I have attached the HDMI design example generation guide for your reference. You can review it and compare with how you do it at your side.

Well, Arrow is right in the sense that Forum community is the platform to request for technical support but it doesn't stop customer for asking on licensing feature support that you will be getting when you do business with Arrow, right ?

• Sound to me like a fair request to clarify on feature support before you place order, right ?

Anyway, I have consulted internal team on the “unlicensed HDMI IP core in evaluation mode”.

• You are right. It shouldn't affect HDMI IP functionality
• just that for evaluation mode it will timeout(no display) after +- 1 hour.

Thanks.

Regards,

dlim

[NWein]

Hi,

The instructions you gave are basically the same as what I did before.  Nonetheless I tried them again, exactly as written (with one exception, see below), and got the same exact results, which is to say not working.

The one exception mentioned above is the dipswitch settings on the devboard.  As delivered, the board was set with different settings from your picture.  When I tried changing them things got worse, so I restored them to the previous.  Remember that the build you provided worked perfectly on my board with the dipswitch settings as-is, so I think they are fine.

The clocks are set correctly.

- Neil

[Deshi_Intel]

Hi Neil,

I generated HDMI example design using Quartus Pro v20.2 Win10 and test it out myself also encounter no video output failure.

Once I switch back to program the Linux generated HDMI example design then I get back the video output again.

I suspect there could be issue in generating HDMI example design from Win OS.

I have filed investigation report to Intel HDMI engineering team to look into issue.

Will keep you posted on the update.

Thanks.

Regards,

Deshi

[Deshi_Intel]

 

[Deshi_Intel · Accepted solution]

Hi Neil,

We suspect HDMI Rx failure encountered at your site is expected because you removed NIOS II design block which also function to perform CDR refclk switching from CDR refclk0 to CDR refclk1.

• Your modified HDMI Rx design is now stuck with wrong (CDR refclk0) instead of using correct TMDS clock (CDR refclk1).

In short, I believe you can follow below guideline that I drafted

Guideline for modification to HDMI Rx only design should be like below :

1. Option A : for customer that required quick XCVR power up calibration

• Remove everything else but keep (HDMI Rx top, NIOS II design and also the design code with comment "// Workaround for long power-up calibration issue")

1. Option B : for customer that doesn’t need “quick XCVR power up calibration” requirement

• Remove everything else including NIOS II design, just keep HDMI Rx top only
  • Modify gxb_rx NativePHY IP to change default CDR refclk to 1 (refer to attached pic)
  • regenerate gxb_rx IP and recompile HDMI design again

I am sorry Malaysia Cocid-19 situation is pretty bad where we are not allow to go back office until early Dec. I need to rely on you for now to help verify the HDMI design on hardware.

Thanks for your understanding.

Regards,

dlim

[NWein]

Thanks.  We do not require the quick power up calibration and definitely don't want the NIOS, so I will attempt option B.  I am hopeful.

COVID-19 situation is terrible here, but I have all this stuff in my house right now so I can keep going.

[NWein]

It looks like changing refclk to 1 was the secret sauce.  I now have full RX-only functionality on the dev board, across all resolutions.

The only slight issue I'm seeing is that the first time it connects, at 4K60, something is not quite stable.  If I change resolutions and resync, everything after that is solid.  This is something I'll be looking into but doesn't particularly worry me at the moment.

I am now in the process of trying to transfer everything onto my own hardware.  It is already working better than before, but not fully.  Translating all the constraints will take a bit of time.

Thanks for your persistence on this issue!

[Deshi_Intel]

Hi Neil,

Welcome and thanks for validating the design changes for us. I am glad we are achieving good debug milestone here and sorry for dragging this issue support for so long

Side update on earlier Win10 HDMI example design generation issue :

• Intel engineering team has confirmed it will HDMI Tx functional due to missing design files generation issue on the software folder
• The issue was root caused to below Win10 patch update. It may not be related to you anymore but it's good to alert you and the rest of forum user

1. Install Windows* Subsystem for Linux* (WSL)

• Step from microsoft: https://docs.microsoft.com/en-us/archive/blogs/canitpro/step-by-step-enabling-bash-on-windows-10
• Step from intel: https://www.intel.com/content/altera-www/global/en_us/index/support/support-resources/knowledge-base/tools/2019/how-do-i-install-the-windows--subsystem-for-linux---wsl--on-wind.html

2. Install patch to fix known issue on Windows 

• KDB: https://www.intel.com/content/altera-www/global/en_us/index/support/support-resources/knowledge-base/embedded/2020/nios2-elf-gcc-exe--error--createprocess--no-such-file-or-directo.html

Alright, good luck and I foresee it may take some time for your project development on your own board.

For now, I am setting this case to closure first. Feel free to file new forum post if you still have new enquiry in future on your project development.

Thanks and stay safe !

Regards,

dlim