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?
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.
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?
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.
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.
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.
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)
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?
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)
Another thing to mention is maybe you can use IOPLL instead of fPLL to provide the 100MHz clock to clkusr pin.
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?
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.
But to be safe, you are always encouraged to perform re-calibration again
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. 😄
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 ?