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

[mattsqp]

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!

[Farabi]

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

[mattsqp]

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