IOPLL non-dedicated feedback option doesn't work correctly

[roeekalinsky]

In Stratix 10 and Agilex, the IOPLL supports an option for using a non-dedicated feedback path when using the normal compensation mode or source-synchronous compensation mode. However, the non-dedicated feedback option doesn't appear to work correctly.

With the non-dedicated feedback option selected, the IOPLL compensation anti-delay as reported in static timing analysis is insanely high, on the order of -30 ns, whereas it should be only a few ns for correct compensation. And consequently, this huge anti-delay causes huge clock skews of a similar magnitude, on the order of 30 ns, between the input clock and the clock generated by the IOPLL.

I'm providing a trivial design example that demonstrates this (see attached). It consists of little more than an IOPLL IP with normal mode and non-dedicated feedback option selected, and otherwise all defaults, plus a handful of registers at the top level to create timing paths to observe in STA. And note that the same design example produces reasonable compensation delays if the IOPLL is configured without the non-dedicated feedback option.

The design example provided is in the form of a Quartus Pro 24.1 project archive. But note that I've also tested older versions of Quartus Pro as far back as 21.3 -- same results.

Intel/Altera support folks, please have a look at the provided example and confirm that you can reproduce what I've reported.

And perhaps firstly can you even confirm, please: Is the non-dedicated feedback option known to work? Is it known to not work? Or am I missing something basic? Because it appears to be plainly broken.

[roeekalinsky]

Hello, Intel support, is somebody on this?  Can I get a response please?  Thank you.

-Roee

[AqidAyman_Intel]

Hi Roee,

Apologies for the delay reply.

I am looking into the resources and perhaps, this is to be expected when using non-dedicated path mode since it does not use a dedicated clock tree. Here’s the IP description:

Use Nondedicated Feedback Path: If this option is selected, the IOPLL will not use additional core clock resources in its feedback path.

Compensation modes that use nondedicated feedback conserve clock resources and have timing analysis benefits, but they create phase shift and frequency limitations. If compensation is not necessary, consider using direct mode.

Since when you turn this option off and the compensation timing look reasonable then that should rule out doing anything out of the ordinary with the PLL, such as cascading or using a non-dedicated clock pin to the PLL.

However, I will try to escalate this issue to the internal team for further investigation, but it may take some time if you are okay with that.

Regards,

Aqid

[roeekalinsky]

Hi Aqid,

Thank you for getting back to me.

Yes, please escalate it to the internal team for further investigation.

Per my understanding I don't believe that what I'm observing is expected, so I'll appreciate your support in getting to the bottom of it.

Thanks,

-Roee

[AqidAyman_Intel]

Hi Roee,

I have escalated this issue to get the attention from the internal team.

Currently, we are waiting for the response from them.

I will update you further once there is an update. I really appreciate your understanding.

Regards,

Aqid

[roeekalinsky]

Thanks for the update.  I'll look forward to hearing from you.

-Roee

[AqidAyman_Intel]

Hi Roee,

Apologies for long delay on the update. I tried to communicate this with the internal team and when we look back in your design, can we understand why you need to do compensation and not using direct mode for the IOPLL?

We view the design using the Technology Map Viewer and we noticed that the same input clock to the PLL is using as input clock to the data_shreg[2]. Then, the output of the register is connected to the input of the next register. This will cause clock domain crossing (CDC) and I think this can be the cause of this issue.

We suggested if you do not need compensation, you can use the direct mode or else, you can use the dedicated feedback path.

Regards,

Aqid

[roeekalinsky]

Hi @AqidAyman_Intel ,

Thank you for getting back to me, but this response fails to address the issue. It merely attempts in a number of ways to avoid addressing the actual issue.

The issue, again, is that this mode of the IOPLL appears to be grossly broken or not implemented correctly by Quartus.

My design requirements are irrelevant to this discussion, and suggestions to use other modes of the IOPLL are irrelevant. I'm not looking for help with my designs. I'm bringing to your attention the fact that something appears to be broken on the Altera side. That's the issue that needs to be addressed.

Also irrelevant are the registers on the input clock and the resulting synchronous CDC in the example I provided. No, they do not affect the operation of the IOPLL. I put them in the design example merely as a convenient way to observe the problem with the IOPLL, but you can remove them from the design entirely and the problem with the IOPLL still exists just the same.

I'm providing another even simpler design example (attached) that doesn't have those registers on the input clock, so that there are no distractions or red herrings.

Please go back to your internal team for them to really investigate and address the actual problem with this IOPLL mode.

Thanks,

-Roee

[AqidAyman_Intel]

Hi Roee,

The internal team is looking into this, and it may take some time as there is no root cause for this issue. May I know if this issue is blocking you or not? Do you need a patch for this?

If yes, I will need to initiate an email to you asking for the detailed information to proceed with requesting a patch.

Regards,

Aqid

[roeekalinsky]

Hi @AqidAyman_Intel ,

Thank you for getting back to me.

No, it is not blocking me at this time.  And no, I'm not requesting a patch.

It will suffice if your internal team gets to the bottom of it and fixes the problem in an upcoming release.

Please keep me posted on their progress.

Thanks,

-Roee

[AqidAyman_Intel]

Hello Roee,

I am still awaiting updates from the internal team on this.

I will update you once I get any feedback.

Regards,

Aqid

[AqidAyman_Intel]

Hello Roee,

As far as I understand, I'm sorry to inform you that the internal team's plan for now is not to proceed with the fix unless we get a request for a patch which will also be going through evaluation before we can move forward.

I appreciate your input on this issue and report it to us.

What I can help for now is to issue an update for the documentation and see if we can get a documented clarification on this.

Regards,

Aqid

[roeekalinsky]

Hi @AqidAyman_Intel ,

I'd like to make sure that I clearly understood your response:

The internal team acknowledges that this mode doesn't actually work correctly, but they don't intend to fix it?  Is that correct?

Are they simply going to document the fact that it doesn't work?

Are they going to remove this non-working optional mode from the IP and Quartus tool chain as well as the documentation?

If I do "request a patch" to satisfy Intel's internal triage processes, will they then fix it just as a point-solution patch for me only?  Or will they then fold the fix into the subsequent mainline releases?

Please clarify.

Thanks,

-Roee

[AqidAyman_Intel]

Hi Roee,

As for the information I received so far, the current plan is to fix this in the upcoming Quartus release, and unfortunately only covers the latest devices which are Agilex 7-M and Agilex 5 devices.

[roeekalinsky]

Hi @AqidAyman_Intel ,

Which upcoming Quartus release would that be?  24.3?

[AqidAyman_Intel]

Hi Roee,

Yes, based on the information I got so far; the current plan is to fix this issue in the 24.3.1 Pro version.

Regards,

Aqid

[roeekalinsky]

Hi @AqidAyman_Intel ,

Please clarify about "24.3.1".  Normally, a Quartus Pro quarterly release like the upcoming 24.3 would be versioned as 24.3.0.  Is there a planned "update 1" for 24.3 sometime after the initial release of 24.3?  Is that what you mean?  Or what is 24.3.1 exactly and when can we expect it?

Thanks,

-Roee

[AqidAyman_Intel]

Hi Roee,

Based on my input from the internal team, 24.3.1 is the rebranded name for 24.4. However, I did not have the exact date on the release schedule, but it should expect to be released at the end of this year or early next year.

Regards,

Aqid

[roeekalinsky]

Thank you.

[AqidAyman_Intel]

I’m glad that your question has been addressed, I now transition this thread to community support. If you have a new question, Please login to ‘https://supporttickets.intel.com/s/?language=en_US’, view details of the desire request, and post a feed/response within the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support. The community users will be able to help you on your follow-up questions.

[roeekalinsky]

@AqidAyman_Intel,

The issue has not yet been addressed.  It has only been scheduled to be addressed.  I'd like to leave this thread open please until the issue has actually been addressed, which by your estimate would happen around 2024Q4 - 2025Q1.

Thanks,

-Roee