Forum Discussion
NWein
Occasional Contributor
5 years agoGXB stuck in calibration: some new issues
Last year I had an issue where my GXB block (included as part of HDMI RX IP) was stuck in calibration: https://community.intel.com/t5/FPGA-Intellectual-Property/Cyclone-10GX-transceiver-calibration-h...
- 5 years ago
HI,
Your Quartus design is complicated and I may need more time to slowly digest it.
Anyway, I have below 2 extra finding to share with you
- Your Quartus design "device and pin option" setting now set config clock source to internal oscillator instead of CLKUSR pin. This is not recommended as per below KDB guideline
- This 2nd finding here could explained why HDMI transceiver channel calibration stuck after you added in "ehive_dual_pd" platform designer that contains PCIe hard IP
- https://www.intel.com/content/altera-www/global/en_us/index/support/support-resources/knowledge-base/ip/2016/why-doesn-t-the-gen3-stratix-v-pcie-hip-start-flow-control-initi.html
- You can try remove PCIe IP design module and rerun testing to check if PCIe IP is the culprit ?
Thanks.
Regards,
dlim
Deshi_Intel
Regular Contributor
5 years agoHi,
Np and thanks for detail explanation.
Fundamentally 2 main factor that can corrupt transceiver (XCVR) power up calibration process should be either clock or reset
- For instance, XCVR channel reset control is toggling while XCVR calibration is running half way
- or the clk supply (reflkc or clkusr) is temp lost/disconnect or become noisy due to coupling noise while XCVR calibration is running half way
Question on signal_tap result :
- In ch[0] connected result, ch[0] PLL_locked asserted high is good but why HDMI 5V detect and HPD signal of ch[1] is asserted instead of ch[0] ?
- Same for ch[1] connected result, ch[1] PLL_locked asserted high is good but why HDMI 5V detect and HPD signal of ch[0] is asserted instead of ch[1] ?
- Is HDMI 5V detect and HPD signal connection so how inverted ? Any other HDMI signals that are inverted ?
Some additional debug input :
- You mentioned using 2 HDMI interface design works but after integrating into full system design (DDR, PCIe and QSYS design) failed.
- Can you gradually just add in one additional design interface at a time and rerun test to isolate which design interface added may be causing issue to HDMI Rx ?
- Once isolated which additional design interface/module is causing HDMI failure then you can further debug on the reset and clocking connection/control at your design top level file.
- Like any clk/PLL sharing between HDMI and the additional design interface/module ? Or potential noise coupling in FPGA internal clock network ? Are they near to each another in Quartus chip planner view ?
- Are they sharing same reset synchronizer/control design at top level design file ? Or separate reset control ? You can debug using separate reset control to see if it solved the issue ?
- Did you accidentally reprogram some clk generator chip on your board ?
- Can you add further delay in your higher application software design in your overall board reset control mechanism ?
Thanks.
Regards,
dlim