Forum Discussion

mattsqp's avatar
mattsqp
Icon for New Contributor rankNew Contributor
4 months ago

Cyclone 10 GX Dev Kit: IOPLL not locking when using CvP mode

Hi everyone,

I'm working with a simple CvP-based design on the Cyclone 10 GX Development Kit. My design is based on the official CvP example design, with a small modification: I've added an IOPLL that generates 150 MHz and 125 MHz clocks from a 50MHz input clock.

Here's the issue I'm seeing:

  • After power-up, I program the *.core.rbf file using quartus_cvp.exe, and everything works as expected – the IOPLL locks reliably.

  • However, if I program the exact same *.core.rbf file again (without powering off), the IOPLL no longer locks.

Has anyone encountered similar behavior or have any idea what might be causing this?
Is there something specific I need to reset or reinitialize in the PLL or CvP flow when reprogramming?

For clarification I've added my top-level HDL design.

Thanks in advance for any help or insights!

Pcie

4 Replies

  • mattsqp's avatar
    mattsqp
    Icon for New Contributor rankNew Contributor
    1 month ago

    Hi Farabi,

    Thank you for your answer. I can ensure that both the .periph.jic and .core.rbf are generated from the same Quartus project. However, I've noticed that even minor changes, like changing a blinky counter in the FPGA logic (with no changes to the periphery or PCIe configuration), result in a slightly different periphery image. I think this behavior is expected as Quartus embeds some metadata in the bitstream or the place and route algorithm is not fully deterministic.

    This would mean that we need to keep the specific periphery image (that is flashed at the customer site) under strict revision control, and all subsequent core images would have to be built against the exact same periphery image. Is that the recommended workflow?

    Thank you and best regards,
    Matthias

  • Farabi's avatar
    Farabi
    Icon for Regular Contributor rankRegular Contributor
    3 months ago

    Hello,


    best practice:

    Always generate the *.periph.jic and *.core.rbf from the same Quartus project or from projects with identical settings.

    Then use revision control to track changes and ensure compatibility.


    regards,

    Farabi


  • mattsqp's avatar
    mattsqp
    Icon for New Contributor rankNew Contributor
    4 months ago

    Hi Farabi,

    Thanks for your help. I believe I’ve identified the root of the problem. I noticed that the Cyclone 10 GX FPGA series only supports CvP initialization mode (one-time configuration via PCIe after power-up), but not the CvP Update mode (reconfiguration during runtime).

    This limitation seems to be a plausible explanation for the system behavior I’ve been observing. I found this information mentioned here:
    https://community.intel.com/t5/FPGA-SoC-And-CPLD-Boards-And/Cyclone-10-GX-CvP/m-p/1326978#M21253

    What do you think?

    Also, I’ve been wondering how to verify that a peripheral image *.periph.jic and a core image *.core.rbf are compatible with each other.

    Is there a tool in Quartus Prime that can help with this?
    As far as I can tell, a simple binary comparison of the peripheral images from two different FPGA builds doesn’t seem sufficient to check compatibility.

    Thank you in advanced

  • Farabi's avatar
    Farabi
    Icon for Regular Contributor rankRegular Contributor
    4 months ago

    Hello,


    From your statement :

    1- After power up, programming the *.core.rbf works fine- meaning IOPLL locks.

    2- Reprogramming the same *.core.rbf without power cycle- IOPLL wont lock.


    In your design- your state machine pll_ctrl_state_r controlling the syspll_rst based on lock status and timeout counters. PLL is reset (syspll_rst = 1) when state machine enter pll_reset.


    After power up, state machine wait for PLL to lock. If it doesnt lock- SYSPLL_TIMEOUT_C asserts a reset. However, after programming, PLL might not received proper reset signal because pcie_perstn remains high.


    You may need to add an explicit PLL reset after CvP re-programming.

    1- Try to add logic to assert syspll_rst for few cycles after CvP reprogamming completed.

    2- Use a signal to detect CvP completion and trigger short reset pulse.


    regards,

    Farabi