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

Cool ! So, everything is working fine in your design now ?

Do you still need to perform another round of dynamic reconfig user re-calibration or this clkusr workaround already resolved the issue ?

Thanks.

Regards,

dlim

Hi,

There is no special power control for fPLL.

By default fPLL is power on as long as user provide the FPGA power, PLL refclk source and fPLL is not in reset mode via "pll_powerdown" control from reset controller IP.

User can then check pll_locked signal and output clock frequency to ensure it's alive and behaving properly.

Thanks.

Regards,

dlim

HI,

Sorry, transceiver calibration is relying on clkusr as the clock source. We don't have alternate option to switch to FPGA internal clocking source.

I am afraid I need to request you to fix your board connection on clkusr pin connection.

Thanks.

Regards,

dlim

Hi,

Unfortunately clkusr is a must requirement. clkusr provided clock to transceiver channel to perform power on calibration during FPGA power up stage before FPGA enter user mode.

In your case, the transceiver channel may already gone wild and malfunction during power up stage due to missing clock before you can perform any transceiver operation (be it loopback test or anything) after FPGA enter user mode.

So, I don't think it will works and whatever test result on transceiver is not reliable as well.

Thanks.

Regards,

dlim

HI,

So, I presume you had fixed the clkusr issue ?

For transceiver calibration register access, you can refer to below PHY user guide doc chapter 7 to learn about transceiver calibration process.

For transceiver calibration enable control, refer to table 300, chapter 7.2.2 targeting offset address 0x100 (page 579)

• https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/arria-10/ug_arria10_xcvr_phy.pdf

Thanks

Regards,

dlim

HI,

The workaround should works as the power on calibration process and user triggered re-calibration process using dynamic reconfig is the same.

I presume you are not using PCIe. This workaround only works for none PCIe protocol.

You can refer to transceiver power-on calibration and user re-calibration guideline in below user guide doc (chapter 7.3, page 583)

• https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/arria-10/ug_arria10_xcvr_phy.pdf
• You needs to reset both PLL and transceiver channel again after re-calibration is done

Another thing to mention is maybe you can use IOPLL instead of fPLL to provide the 100MHz clock to clkusr pin.

• Pls try your best to take care of the clock signal quality that maybe impacted by your board rework.
• I hope this rework is just temporary workaround while waiting for your board design fix in future.

Thanks.

Regards,

dlim

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

Hi Deshi,

The whitepaper gave me hope. I was able to insert the CLKUSR successfully (I believe). I see the PLL and clock divider in the post-fit netlist. I left the GPIO oe and dout ports open, since the whitepaper seems to indicate this.

However, this has no effect on the calibration. There isn't any way to confirm that the NIOS receives the clock which it expects, so it's possible Quartus has not made the connection. (I'm using Quartus prime standard, 18.1.) Is there any way to confirm this?

I only have a single-channel transceiver (running a custom protocol unfortunately), and separate fPLLs, using the same transceiver reference clock. The PCS does have a reconfig interface enabled on it, but I'm not using it for anything. Is there any requirement to run the reconfig_clock off of the transceiver clock? I have been assuming it is only a fabric clock.

Do you have any reference designs which implement this workaround?

Here is how the logic is connected for your information:

    -- Backend method of inserting clkusr using GPIO and IOPLL.
    -- Generate 200M from xcvr refclk
    u_clkusr_pll : component clkusr_iopll
        port map (
            rst      => por_pll_rst     ,
            refclk   => clk_312p5_i     ,
            locked   => clkusr_locked_w ,
            outclk_0 => clkusr_200_w     
        );
 
    -- Divider 
    process (clkusr_200_w) begin
        if rising_edge (clkusr_200_w) then
            clkusr_w <= clkusr_locked_w and not clkusr_w;
        end if;
    end process; 
 
 
    u_clkusr_gpio : component gpio
        port map (
            din(0)      => clkusr_w         ,  --    din.export
            dout        => open             ,  --   dout.export
            oe          => open             ,  --     oe.export
            pad_io(0)   => clkusr_io           -- pad_io.export
        );
 

Ah, I have to correct myself. I interpreted the white paper incorrectly. When I enable the GPIO OE to '1', the CLKUSR does connect, and the PLLs and Transceiver does sync! This is fantastic news.

Thank you, Deshi. 😄

Hi Bryan,

yup, all GND pins should be connected together in GND plane on FPGA package layer.

Alright, I am setting this case to closure.

Thanks.

Regards,

dlim