Occasional Contributor
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.
