How do I report powered-down transceivers and PLLs in Quartus Prime Standard?

Hi Bryan,

I dig further and found out about workaround to use FPGA IOPLL to provide clock to clkusr pin directly via some Quartus hacking method. (refer to attached doc). This should help to save your board rework effort.

• I didn't face your issue so it's hard to predict the FPGA behaviour here. Can you help to confirm following ?
• Before apply IOPLL workaround, when FPGA enter user_mode, I expect both transceiver channel and PLL *_cal_busy signals should still stuck high forever as it's still waiting for clkusr input to trigger calibration.
• After applied IOPLL workaround, when FPGA enter user_mode, I expect both transceiver channel and PLL *_cal_busy signals should eventually de-asserted once clkusr received clock from IOPLL and trigger calibration. If it works fine then you don't really need to perform another round of user re-calibration anymore.

But to be safe, you are always encouraged to perform re-calibration again

1. Regarding fPLL reset control

• Ideally if you are using Intel FPGA reset controller IP then you shouldn't need to worry about reset control for transceiver channel and transceiver PLL anymore as shown in user guide doc 4.2. Transceiver PHY Implementation -> Figure 201. Typical Transceiver PHY Implementation
  • To answer your question, fPLL reset is control by pll_powerdown signal but I found out there is a bug. Pls refer to below KDB link for the fix
  • https://www.intel.com/content/altera-www/global/en_us/index/support/support-resources/knowledge-base/hsio/2020/why-is-the-assertion-of-pllpowerdown-input-unable-to-reset-the-i.html

1. Regarding NPDME

• You can refer to user guide doc -> chapter 6.15.1. Native PHY Debug Master Endpoint for more info about this interface
  • It basically provide access connection for user to control reconfig interface via system console through JTAG master
  • You don't need NPDME if you are using other method to access reconfig bus like direct RTL design access or through NIOS CPU access

1. Regarding reconfig interface wait_request stuck high issue

• Byright it should work. Can you try to access reconfig bug again after *cal_busy signal de-asserted with successful IOPLL workaround implementation ?
  • Are you sharing multiple reconfig interface that may create some issue here ? Can you try to split the reconfig interface to see if it helps ?

Thanks.

Regards,

dlim