Occasional Contributor
Regular ContributorHi,
thanks for your update. Prior to upgrading to newer Quartus version, I think we can focus on the Native PHY simple design test. You can try with simple Native PHY RX only design. If it is not working, then you can try with duplex Native PHY to see if there is any different. Thank you.
Occasional ContributorI created a copy of my project, and only the gxb_rx, gxb_rx_reset module from my design. Omitted management block (maybe a mistake) because calibration should happen independently of the management stuff.
Quartus crashes at the beginning of the fitter stage, just after "successfully loaded synthesized database". No further explanation.
Sadly, a Quartus crash is an all-too-common occurrence me these days, and for the moment I am at a standstill.
Occasional ContributorI tried updating Quartus from 19.3 to 20.2, and it still crashes when compiling the test design.
Occasional ContributorOK, I started from scratch with a brand new test design.
I extracted a subset of the code from the HDMI RX core (hdmi_rx_top), including the gxb_rx, gxb_rx_reset, mr_reconfig_mgmt modules, and a couple of other minor things. *Lots* of signals are stubbed off, and I can only guess whether I've done this all in a reasonable way.
Signaltap shows that rx_cal_busy is *unasserted* now, which presumably means that calibration was successful. Rx_digitalreset and rx_analogreset are both unasserted; those are driven by the mr_reconfig_mgmt, and since there is no incoming signal maybe that makes sense. Also, I note that the reconfig_waitrequest signals are now also unasserted, which is a good sign (I think).
Are the rx_cal_busy signals dependent on the any of the other inputs to gxb_rx (like the analog or digital reset), or does the fact that busy signals are unasserted absolutely mean that the transceivers have calibrated successfully? If the latter, then I need to figure out what in the rest of the design that I removed could be stopping them from calibrating.
