PLL Reconfiguration Fails when built using Quartus v13.1

[Altera_Forum]

Hi All, 

 I have a Stratix III design where I use PLL to drive LVDS transmitters. The PLL is reconfigurable using an instantiation of the ALTPLL_RECONFIG IP along with mif-initialized ROMs. For an LVDS application in Stratix III, certain PLL outputs (C0, C3, C5) must be used. The design has worked fine for quite some time using Quartus 12.0 and also earlier versions.  So here is strange part. I recently installed Quartus 13.1 and if I build it with that tool, the design no longer works. If I do my normal RTL simulations, all is fine. After creating a simplified and lower-speed project, I did a gate-level simulation and see that the reconfig function is loading the correct divider values into the wrong (unused) PLL counters and bypassing (= divide by 1) the PLL counters I am using. This agrees with my hardware measurements. Each of the outputs I use should be divided down from the VCO frequency but instead is running at the VCO frequency.  As a side note, evidently Quartus sometimes re-arranges counters on purpose but the documentation says this will not occur if the design includes reconfiguration. To be sure, I added the "Preserve PLL Counter Order" assignment but this changed nothing.  I have already submitted a service request but while waiting for that to get somewhere I thought I would put this out and see if anyone else has a similar experience? If I get a resolution from the service request, I'll post a follow-up here.

[Altera_Forum]

--- Quote Start ---  Hi All,  I have a Stratix III design where I use PLL to drive LVDS transmitters. The PLL is reconfigurable using an instantiation of the ALTPLL_RECONFIG IP along with mif-initialized ROMs. For an LVDS application in Stratix III, certain PLL outputs (C0, C3, C5) must be used. The design has worked fine for quite some time using Quartus 12.0 and also earlier versions.  So here is strange part. I recently installed Quartus 13.1 and if I build it with that tool, the design no longer works. If I do my normal RTL simulations, all is fine. After creating a simplified and lower-speed project, I did a gate-level simulation and see that the reconfig function is loading the correct divider values into the wrong (unused) PLL counters and bypassing (= divide by 1) the PLL counters I am using. This agrees with my hardware measurements. Each of the outputs I use should be divided down from the VCO frequency but instead is running at the VCO frequency.  As a side note, evidently Quartus sometimes re-arranges counters on purpose but the documentation says this will not occur if the design includes reconfiguration. To be sure, I added the "Preserve PLL Counter Order" assignment but this changed nothing.  I have already submitted a service request but while waiting for that to get somewhere I thought I would put this out and see if anyone else has a similar experience? If I get a resolution from the service request, I'll post a follow-up here.  --- Quote End ---    I am having a different issue with the ALTPLL_RECONFIG_IP which I was told was related to my Cyclone V silicon revision. I only have a single output of the PLL that I am reconfiguring. I am able to adjust the frequency as desired if I have 1 output, but the phase shift does not work correctly. It will phase shift in one direction by twice the amount than expected. Trying to shift in the reverse direction does not move the PLL output at all.  I did notice if I add a second output to my PLL, the frequency reconfiguration gets some strange results where the output frequency is off by a few MHz than what I tried to reconfigure it as. Since my service request was initially opened back in November 2013, I have a newer silicon revision that is experiencing the same exact problems (even though it should be fixed in this new silicon revision).  Just as an experiment, did you try disabling all your other PLL outputs and only use C0? I'm curious if you are able to reconfigure the frequency when only one output is enabled. I am using Quartus 13.1 update 3 on Windows 7.  Another side note - I just noticed that my Fractional PLL output drifts at about 1ns per minute with respect to the reference clock if the Dynamic reconfiguration mode is enabled. The drift is smother with the DSM set to 3rd order and jumpier if the DSM is set to 1st order. I have just submitted a service request. Have you seen a similar result? I attached a screenshot of my simplified test project:  https://www.alteraforum.com/forum/attachment.php?attachmentid=8637

[Altera_Forum]

Randolina, 

 It sounds like you may have a separate problem. I tried changing my project so the PLL uses only one output and did a gate-level simulation. (gate-level simulation simulates my problem, RTL level does not) My results were similar to before, the reconfiguration happens but the divider that I was using (c0) gets bypassed and the divider values intended for c0 get written to the unused c1 divider instead. In all cases, the PLL is running at exactly the correct frequency, there is no few MHz error.  The Stratix III PLL that I am using is an integer PLL, not fractional, so we are dealing with substantially different PLLs.  By the way, Altera has replicated my problem but does not yet have a solution.

[Altera_Forum]

--- Quote Start ---  Randolina,  It sounds like you may have a separate problem. I tried changing my project so the PLL uses only one output and did a gate-level simulation. (gate-level simulation simulates my problem, RTL level does not) My results were similar to before, the reconfiguration happens but the divider that I was using (c0) gets bypassed and the divider values intended for c0 get written to the unused c1 divider instead. In all cases, the PLL is running at exactly the correct frequency, there is no few MHz error.  The Stratix III PLL that I am using is an integer PLL, not fractional, so we are dealing with substantially different PLLs.  By the way, Altera has replicated my problem but does not yet have a solution.  --- Quote End ---    Glad to hear they could replicate it on their end too. I've only recently started using the PLL reconfiguration block and one mistake I made was clocking the altera_pll_reconfig too fast. I was trying to run it at my system clock which is 125MHz, but this caused issues where it would sometimes reconfigure the frequency. I did not see a timing spec for the altera_pll_reconfig block. I brought it down to 25MHz and can successfully reconfigure the frequency each time. I've tried as low as 10MHz to see if it would help the dynamic phase shift problem, but it still did not work. Even through it worked in a previous Quartus version, have you tried lowering the clock going into your reconfiguration block just as a test?  The Cyclone V looks like they combined the fractional PLL with the integer PLL by adding their Delta Sigma Modulator shown in the picture. The details under the hood between the Stratix III and Cyclone V fractional/integer PLL may be very different like your said though.  https://www.alteraforum.com/forum/attachment.php?attachmentid=8676

[Altera_Forum]

I have not tried changing the reconfiguration clock frequency but it is well within the specified range. For the Stratix III, the range is specified on the data sheet (under Switching Characteristics => Core Performance Specs => PLL => scanclk frequency) and is 100 MHz maximum with no minimum. This example project used 50 MHz, while my actual target design uses 80 MHz. Both work OK when built with Quartus 12.0. Thank you for the suggestion, that would have been an easy fix.

[Altera_Forum]

--- Quote Start ---  I have not tried changing the reconfiguration clock frequency but it is well within the specified range. For the Stratix III, the range is specified on the data sheet (under Switching Characteristics => Core Performance Specs => PLL => scanclk frequency) and is 100 MHz maximum with no minimum. This example project used 50 MHz, while my actual target design uses 80 MHz. Both work OK when built with Quartus 12.0. Thank you for the suggestion, that would have been an easy fix.  --- Quote End ---    No problem and thanks for pointing out the switching frequency spec which I must have overlooked! Reply back with what Altera finds. Also, in case you haven't seen it, there was an update 4 for Quartus recently, but I don't think there would be anything useful for this issue.

[Altera_Forum]

I'll certainly report back with Altera's findings.  

 I had not noticed that there is an update 4. I probably should try it - if they broke it by accident, maybe they will fix it by accident too.

[Altera_Forum]

I use dynamic phase shift ports directly on the PLL and I still see similar behavior. My target device is Arria V GX. The RTL simulations shows that the phase shift works but the realized design doesn't do anything on the board. I also use QII 13.1. I have 8 pll outputs with zero default phase shifts specified. QII 13.1 ignored the fact that I had dynamic phase shift ports connected and merged all the outputs to one output counter (C0).  

 FYI - I do not have the updates installed yet.

[Altera_Forum]

Altera has come back with a solution. They have instructed me to put a file named "quartus.ini" in the project folder. The contents of the file are simply "ftm_absorb_inverts_new=off". (without the quotes) When I do that and build with Quartus 13.1, RTL & gate level sims work normally, and the design works in actual hardware as well. They tell me the fix should be included in Quartus 14 so I can discontinue using the workaround at that point. 

 To "fpgabuilder", your problem might be similar to mine. My design uses dynamic phase shifting too but since the port counters were mixed up, the design crashes and burns before I can see if the dynamic phase shifting was working or not.

[Altera_Forum]

This change allowed me to dynamically phase shift two clocks from a PLL in a stripped down version of my design. But when I try this in my complete design, I can change only one of the two clocks. Additionally, which clock I can change depends on how I use those clocks in my design. Not completely obvious, but it seems the clock that drives more logic doesn't get the dps capability. 

 Something else that is weird, I do not see the quartus.ini in my project folder anymore? @mvanpelt, do you see the quartus.ini in your project folder. We use CVS so, I happen to close quartus and delete the project folder quite a bit.

[Altera_Forum]

Yes, I see quartus.ini in my project folder. If I were to build the project when I could not see it, I would assume that our problem would return. Sounds like you may have something more going on than just the problem Altera fixed for me. 

 On the CVS topic, I you have not committed the quartus.ini file into CVS, then it would make sense that it would be gone if you delete and then re-checkout your project folder. If you did commit it, I would think it would be there.

[Altera_Forum]

I believe the original problem (which mvanpelt was provided with a workaround for) can be fixed outright with the patch provided here: http://www.altera.com/support/kdb/solutions/rd05052014_157.html

[Altera_Forum]

Thank you, evangelosa, for pointing that out. It does look like that patch should fix the problem. I tried to install the patch to verify the fix but the patch installer complains that the patch is intended for Quartus version 13.1.0.162 (13.1 with no updates) whereas I have already applied updates that bring my version up to 13.1.4.182.  

 Hopefully the patch becomes part of the next update or service pack. I'll just wait for that rather than try to remove the updates from my installation.

[Altera_Forum]

Quartus version 14 is now out. I was hoping to see this problem fixed. However, instead it turns out that support for the Stratix III family has been dropped entirely. Looks like either the patch suggested by evangelosa or the quartus.ini workaround will have to be the permanent solution.