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.
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.
Why not let me share my HDMI example design sof file for you to try out on your C10 GX dev kit board.
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.
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?
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.
Regarding software setup
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.
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 ?
Anyway, I have consulted internal team on the “unlicensed HDMI IP core in evaluation mode”.
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.
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.
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.
In short, I believe you can follow below guideline that I drafted
Guideline for modification to HDMI Rx only design should be like below :
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.
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.
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!
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 :
1. Install Windows* Subsystem for Linux* (WSL)
2. Install patch to fix known issue on Windows
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 !