Forum Discussion

rtldeseng's avatar
rtldeseng
Icon for New Contributor rankNew Contributor
1 month ago

Stratix 10 fPLL is cascade source mode doesn't lock

Hello everyone.

I use fPLL cascading with Stratix 10 FPGA: fPLL in cascade source mode is connected to fPLL in transceiver mode.

In my design reference clock for fPLL in cascade source mode is not stable after power-up and I apply user recalibration to it. But after user recalibration when reference clock is stable, fPLL doesn't set lock signal.

After some investigation of the issue, I found that my design works fine with Quartus Pro 21.2 but doesn't work with newer versions like Quartus Pro 23.4/25.1/26.1.

Is there any known issue about fPLL is cascade source mode?

Any suggestions about how to overcome this issue are welcomed.

7 Replies

  • Ash_R_Altera's avatar
    Ash_R_Altera
    Icon for Regular Contributor rankRegular Contributor

    Hi,

    Can you please provide few details about your design?

    1) What is the input clock frequency and source of it?

    2) What is the output frequency that you are trying to achieve?

    3) Is the create_clock constraint applied for the input clock at the top level?

     

    Few design implementation checks would be:

    1) You must recalibrate the PLL when the reference clock is available.

    2) Clock on OSC_CLK_1 signal is used for calibration of the fPLL and it must be stable. Is it true for your case?

     

    It would be easier to debug if you can provide a reference design to reproduce the issue.

     

    Regards

  • Ash_R_Altera's avatar
    Ash_R_Altera
    Icon for Regular Contributor rankRegular Contributor

    Hi,

    Just checking if you can provide some more inputs as asked in my previous comment?

     

    Regards

  • rtldeseng's avatar
    rtldeseng
    Icon for New Contributor rankNew Contributor

    Hi, sorry for long reply.

    1. What is the input clock frequency and source of it?

    After power up it is 312.5MHz.

    The clock source is clock output of RX XCVR (the port that is called rx_clkout)

    2) What is the output frequency that you are trying to achieve?

    After power-up it is 312.5MHz. But when it is recalibrated the frequency is not much than 210MHz.

    In my project cascade source fPLL transfers input frequency to output. I would say it acts like clock buffer.

    For every changing of input frequency cascade source fPLL is reconfigured (dividers value are changed) and recalibrated.

    3) Is the create_clock constraint applied for the input clock at the top level? 

    It is in place.

    Few design implementation checks would be:

    1) You must recalibrate the PLL when the reference clock is available.

    2) Clock on OSC_CLK_1 signal is used for calibration of the fPLL and it must be stable. Is it true for your case?

    Because the source of clock is output of RX XCVR (the port that is called rx_clkout), when I am recalibrating cascade source fPLL I set RX XCVR to lock to ref. So, I can say that clock is stable.

    OSC_CLK_1 signal is stable

     

    I attached simplified project created with Quartus Pro 21.2. In this project RX XCVR generates 156.25MHz. And fPLL can be reconfigured using control from source and probes IP. Before recalibration (recalibration is triggered by positive edge of source bit[1]) it needs to set serial loopback (bit[3] of source IP) and check that we have lock to data by SignalTap. I tested this project with Quartus Pro 21.2 and 23.4. With Quartus 21.2 I see that after power-up calibration fPLL lock signal can be low or toggling, but after recalibration it is set to 1 and it is stable. With Quartus 23.4 lock signal is never asserted.

    This simplified project doesn't actually use clock from cascade source fPLL it just checks lock signal, but it shows connection of my real project after power up. In real project there is reconfiguration and clock switching of transceiver fPLL to use clock from cascade source fPLL.

    Overall, it seems that after compilation with Quartus Pro 23.4 or newer, clock from RX XCVR is not connected to cascade source fPLL

    • Ash_R_Altera's avatar
      Ash_R_Altera
      Icon for Regular Contributor rankRegular Contributor

      Hi,

      Thanks for sharing the design. I have made some observations and have few questions regarding your design.

      1) Why do you need a cascade clock to drive the transceivers? Though supported, cascading the PLL insert jitter. Why not use direct clock input pin for the reference clock?

      2) The downstream xcvr_tr_fpll, is configured for Transceiver mode and has 2 refclk sources. One 100MHz from clock pin and other from the upstream fPLL which provides 156.25MHz. As the frequencies vary you have to reconfigure the fPLL to adapt to the frequency settings. In the design the IP is set to 100MHz only. Are you doing this?

      Regards,

      Altera Support

      • rtldeseng's avatar
        rtldeseng
        Icon for New Contributor rankNew Contributor

        Hello.

        1. Why do you need a cascade clock to drive the transceivers? Though supported, cascading the PLL insert jitter. Why not use direct clock input pin for the reference clock?

        This is needed because of the requirements for my actual project. I can't share the details of why I really need it. Let's just accept it.

        2) The downstream xcvr_tr_fpll, is configured for Transceiver mode and has 2 refclk sources. One 100MHz from clock pin and other from the upstream fPLL which provides 156.25MHz. As the frequencies vary you have to reconfigure the fPLL to adapt to the frequency settings. In the design the IP is set to 100MHz only. Are you doing this?

        The shared design is simplified version of my real design that I cannot share. In real design transceiver fPLL is reconfigured and recalibrated after rate changing and clock switchover.