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

[BHunt11]

I have an issue which looks like an xcvr_fpll_a10_0 may not be powered or is shut down. How can I confirm that all the PLLs are in fact powered on in Quartus?

[Deshi_Intel]

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

[BHunt11]

I found my issue. I don't have the CLKUSR pin connected to a clock source so the transceiver is not completing calibration.

Is there a way around using this external pin? Can I supply an internal clock source?

[Deshi_Intel]

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

[BHunt11]

Do the transceivers operate in any mode without the CLKUSR present? For example, can I put the PCS or PMA into loopback? That is, all RX receiver data is looped out the TX transmitter.

In this way, I could test the circuit in and out of the transceiver, before I fabricate new boards.

[BHunt11]

This is the looback mode I want to enable: Fig 236: Reverse Serial Loopback Path/Pre CDR, in UG-01143. May be called "diagnostic loopback".

[Deshi_Intel]

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

[BHunt11]

How do I force the transceiver to restart calibration? My PCS has the reconfiguration avalon interface attached to an avalon master.

[Deshi_Intel]

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

[BHunt11]

I'm trying a simple rework, where I drive 100MHz out of a pin into CLKUSR. (So this clock is not available for initial powerup calibration.) My intention is to now force the PMA and the PLLs to recalibrate using their dynamic-reconfiguration interfaces.

I have a JTAG Avalon master driving the reconfig interface of the fPLL. Then, I start the user recalibration process.

Can you confirm whether this would work? Am I required to assert or deassert the PLL reset while using the reconfig interface?

[Deshi_Intel]

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

[BHunt11]

Thanks Deshi. I'm trying to get a PLL (the 500Mhz TX fPLL) to recalibrate first, and having trouble. I'm still a little confused about a few things.

1) In what order do I reconfigure the PLLs and PMA? I have two fPLLs: 100M CDR ref clock, and 500M TX ref clock. Each of these has the pll_cal_busy asserted in signaltap, after I poweron. The avalon reconfig clock comes from an external 100MHz clock pin.

2) I don't see any reset signal explicitly on these PLLs. (Except for the avalon reset.) How do I reset each one? 

3) The transceiver PMA remains in reset until the fPLLs are up and running. I have not tried to take the transceiver out of reset.

4) I tried to use a JTAG Avalon master to control the reconfig interface on the 500M TX PLL. I see the waitrequest asserted when I inspect the avalon bus in signaltap, but I can't seem to arbitrate for access. I tried to do an 8bit write of 0x2 to address 0x0 (and 32b write), but in both cases the avalon bus hung forever.

5) I see the fPLL has an option "Enable Altera Debug Master" which is also called NPDME, but I have not found how to use it. I do not have this enabled in the fPLL. Is this required to drive the reconfig_* interface with a JTAG Avalon Master?

Thanks again,

BryanH

[Deshi_Intel]

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

[BHunt11]

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 );  

[BHunt11]

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. 😄

[Deshi_Intel]

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

[BHunt11]

Everything is working fine now. Thank you! Please close this case.

BTW regarding the GND ball. Are they all connected to a common GND plane?

[Deshi_Intel]

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