Cyclone V issue with Fractional PLL and Reconfig IP Modules

[codecurious]

We are using a Cyclone V FPGA with an Altera PLL Reconfig and Fractional PLL IP modules via Quartus 22.1. Appnote AN-661 defines the connection and setup for the two IP blocks, along with the register definitions. Intel design example “pll-reconfig-mnc.qar” is another example file for implementing a Reconfig and fractional PLL, while showing a state machine to write to the Reconfig module. Pretty straight forward material, in which we have implemented nearly identical code to write to the Reconfig module. I have not simulated this, but instead used Signal Tap to show screenshots that match the AN-661(Figure 2) exactly. However I still do not see any change on the 64-bit output when we perform new writes with new PLL settings. I have tried resetting the module before and after the reconfig process per the below comment in the spec, but it made no difference. Also the Intel example did not issue any follow-on resets, but only shows a single programming cycle. 

“Altera recommends resynchronizing the fractional PLL using the areset signal if the phase relation‐ ship between output clocks is important. Always assert the areset signal after each mgmt_reset operation or after each fPLL reconfiguration process, to reinitiate the fPLL locking process.”

Here are more notes:

• 64Mhz input clock to the PLL
• “Enable dynamic reconfiguration of PLL” checked in the PLL Megawizard.
• I’m not using any .mif files or implementing this within Platform Designer, but purely in logic (like the Intel example, but with the ability to change the settings later, which we can see during the Signal Tap settings).
• Signal tap shows the Lock de-assert if I reset prior to the Reconfig writes. However regardless of data content with new write data, there is no change on the 64-bit output.
  • In this link, you can see the 64-bit output changing for example.
    • https://www.reddit.com/r/FPGA/s/OLgKNzXb5e
  • Here is a pic of the address, data, and write strobes with lost of setup/hold time and address\data write order the same as the Appnote and the example project. I even tried a delay for the last write to the Start register.

• Here is a pic zoomed out. You can Lock de-assert, but grouping for writes to the Reconfig module (blue demarcation), and then PLL re-assert. There is a change in the data structure of the reconfig_from_pll (63..0) vector just before it locks, but there is no big change in the data for a newly written PLL clock output setting.

• Below is a screen shot from the fit report

Any help is greatly appreciated, as we are stuck. Attached are the .vhd file from the Megawizard for the two IP modules. Please let me know what else I can provide to close this out quickly.

Thanks!

[EliasBarbudo]

from the first signal tap, it seems like reconfig ip is not sending any data to the PLL, could you double check if the reset of the reconfig ip is not active? the reconfig_to_pll bus should change each time you perform a write operation

[codecurious]

First, thanks so much for your help!! The same active high reset that is connected to the state machine that writes to the Reconfig module is also connected directly to the Reconfig module. I agree I expect to see data changing as in the example of the Reddit link I sent. The instantiation of the Reconfig and PLL IP is pretty straight forward, but unable to get any frequency update/change. Building of the IP and adding it to the project is also pretty straight forward, but I am missing something obviously. I reviewed the log files to see if there was any concerning warnings, but did not see anything (and the fit report shows the instantiation of the IP).

[EliasBarbudo]

lets try to see if we can get some data coming and going on the reconfig_to/from_pll buses. For this, could you disable mgmt_byteenable?  from the Reconfig IP GUI uncheck the add byteenable port

[codecurious]

Well I have some good news I hope. In parallel I was trying to create a simulation environment for the platform, since to date I had been using the Cyclone III simulation setup. This complete design was based on a fully functional Cyclone III design, and then ported to CycloneV. Part of the port was updating all PLLs and Reconfig IPs to CycloneV primitives. I could not get the tool to support simulating even the simplest of PLL primitives. In working with the FAE and support, it was discovered (and reproduced), that the Build 922 version of 22.1Std2 S/W has issues in creating the PLL simulation primitives. I was told to restart my efforts using version 917. I have just loaded the design and will verify my simulation capability here shortly. I am not sure if it is plausible that the 922 version has an issue in building a valid object file to support on H/W usage of the PLL and Reconfig modules. I am hoping that theory is plausible, since again following the appnote and instantiating the two IP modules is fairly straight forward and my timing matches the example identically. Let me know if you believe this makes sense, and I will keep you poste on the status here shortly. Thanks.

[EliasBarbudo]

Interesting, I am going to ask around to see if I can confirm that hypothesis, but seems to be right as even without the byteenable and asserting the reset of the reconfig ip, we should be seeing changes in the reconfig_to_pll bus. I created a simple design and tested a couple of things to see if I was able to replicate the issue and I saw that there is always some data going to the pll. But mine was started from scratch usign 22.1std.0 build 915

[codecurious]

A couple of notes: 1.) I am able to fully simulate the Reconfig PLL now and my code was functional. I did try to reproduce the Example #1 in the app note 661, but found one thing interesting. In using the exact same value as in the document, I get a frequency of 150.150Mhz vs the 151.11Mhz they mention in the document. I am not sure if you have (or can) verify what frequency you see when using there example project, but I am surprised for such a simple example the frequencies don't match. Let me know what you think.

2.) I am not sure if you found any issues with the build 915 version as mentioned before(?). Let me know if you have. Wednesday I will have access to the H/W and will try the new tool version with hopefully better results. I will keep you posted. Thanks!

[codecurious]

I need help to close this topic out please (it has been many days working this issue)! I tried the new tool version on the target H/W, and it is still not working. The simulations are working fine now. In Signal Tap I do not see any communication from the PLL. Please help to resolve this.

[AqidAyman_Intel]

I have been informed that this case was discussed internally. When changing the counter bit setting from polling mode to waitrequest mode, the issue was resolved.