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