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

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

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

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