Forum Discussion
Occasional ContributorCannot get Cyclone 10 GX HDMI RX to lock
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 :
- 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")
- 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
Regular ContributorHi 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
NWeinHi 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.
