Occasional Contributor
Regular ContributorHi,
Thanks for your help and update. Regarding your inquiry on the rx_cal_busy signal, for your information, the rx_analog_reset and rx_digital_reset are dependent on the rx_cal_busy. If you have the transceiver reconfiguration controller connected to the Native PHY, the controller will wait for the rx_cal_busy to de-assert before it start to release the rx_analog_reset. The rx_digital_reset will only be released after the CDR achieve lock-to-data mode which is indicate why assertion of rx_lockedtodata signal.
Since you are extracting a subset of code from the HDMI RX core, I am not sure how the subset of code works. Generally the rx_digital_reset will only be released after valid signal fed to RX pin and CDR achieve lock-to-data. But in your case, it seems like no incoming signal but the rx_digital_reset = 0.
To facilitate your debugging, I would recommend you to use the following simple Native PHY design to check if the transceiver can UP:
This is a duplex Native PHY design with transceiver toolkit enabled. You can customize the pinout, refclk frequency and data rate to your board. You can then bring up transceiver toolkit to check on the native PHY.
Please let me know if there is any concern. Thank you.
Best regards,
Chee Pin
Occasional ContributorI'll try the native phy design you linked next.
In the meantime, I tried putting a complete HDMI receiver into the design, and got interesting results.
Initial calibration seems fine. Signaltap shows that before I connect an HDMI input signal, everything is in a good state.
When I connect, things get weird. It tries to sync (I see a lot of activity on the reconfig management bus), but keep repeating it periodically. My assumption is that it is not successfully achieving sync. I do not yet know why. But at least it's trying!
- Neil
