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,
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
Occasional ContributorHi 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:
- 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.
- I confirmed that the the BITEC daughterboard rev specified in the code matches my hardware (rev 11)
- I copied the quartus.ini file from the PLL folder to the main project folder. It behaves the same either way.
- 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.
- 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
