Arria10 IOPLL odd phase shift behavior

[GBeck]

Seeing some strange behavior when performing a simulation of an IOPLL.  The IOPLL is configured within a QSYS sub-system.  The IOPLL utilizes a 125MHz ref clock.  Multiple output clocks are required.

40MHz 0 degree phase shift, 45 degrees phase shift, 90 degree phase shift and 135 degree phase shift

We've been able to produce the necessary clocks using the attached file (system_altera_iopll_181_ves6lbi.vo.txt).  Clock outputs 1-4 are used by the logic that requires the (4) 40Mhz clock with 45 degree phase difference.  Clock outputs set to 0 and 180 degree phase shift do not produce expected results.  

Not sure if these results are real or a simulation library issue.  Has anyone experienced this before?

Regards, Gary

[EngWei_O_Intel]

Thanks Gary for your inquiry. Allow me some times to take a look on your design before getting back to you.

Eng Wei

[EngWei_O_Intel]

Hi Gary

From your attachment, we are seeing the setting as below:

.phase_shift0("3125 ps"),
.phase_shift1("3125 ps"),
.phase_shift2("6250 ps"),
.phase_shift3("9375 ps"),
.phase_shift4("21500 ps"),
.phase_shift5("0 ps"),
.phase_shift6("0 ps"),
.phase_shift7("0 ps"),
.phase_shift8("0 ps"),

which are 45degree shifted for outclock2,3,4, which are showing up in the waveform you have attached. Can you further describe the issue you are seeing?

Thanks.

Eng Wei

[GBeck]

If phase_shift0 is changed to 0 ps there a phase shift present

Also if phase_shift0 is changed to 12500 ps the resulting shift is not 180 degrees.

.phase_shift0("3125 ps"),
.phase_shift1("3125 ps"),
.phase_shift2("6250 ps"),
.phase_shift3("9375 ps"),
.phase_shift4("21500 ps"),   // 309.6 degrees
.phase_shift5("0 ps"),
.phase_shift6("0 ps"),
.phase_shift7("0 ps"),
.phase_shift8("0 ps"),

[GBeck]

Adding modelsim capture with the following PLL settings

.phase_shift0("0 ps"),
.phase_shift1("3125 ps"),
.phase_shift2("6250 ps"),
.phase_shift3("9375 ps"),
.phase_shift4("12500 ps"),
.phase_shift5("0 ps"),
.phase_shift6("0 ps"),
.phase_shift7("0 ps"),
.phase_shift8("0 ps"),

Notice outclk_0 and outclk_4 phase shift is not as expected

[GBeck]

Eng Wei,

Curious if there have been any developments... Have you been able to re-produce the issue?  

Let me know if you have any questions.

Thanks, Gary

[EngWei_O_Intel]

Hi Gary

I am seeing it in my simulation as well. I am getting engineering help to check if the usage is correct or if the Modelsim setup is correct. I will keep you posted for any update.

Thanks.

Eng Wei

[EngWei_O_Intel]

Hi Gary

Just found this piece of information from the link below,  where Intel Arria® 10 and Intel Cyclone® 10 GX devices might have simulation issue with IOPLL phase shift:

https://www.intel.com/content/altera-www/global/en_us/index/support/support-resources/knowledge-base/component/2019/why-do-output-clocks-of-the-iopll-intel-fpga-ip-have-incorrect-p.html

For those affected devices, it is recommended to perform hardware verification when checking phase shifts of output clocks of the IOPLL. 

Thanks.

Eng Wei

[GBeck]

Eng Wei,

Find it interesting the modify date on the KDB article is the same date as my original post of the issue.  Is there a planned fix for the simulation model?  Need to be able to simulate prior to obtaining hardware.

By the way we are using Quartus 18.1.

Regards, Gary

[EngWei_O_Intel]

Hi Gary

This behavior was filed a while back by other users and the issue is published in knowledge base just recently. I was using version 20.1 and still seeing similar behavior. The feedback I have is that there is no plan for this fix at the moment. 

Thanks. 

Eng Wei

[EngWei_O_Intel]

Hi Gary

since this is a known Modelsim simulation issue, can we have a test bench workaround that creates necessary clocks and force them to the IOPLL output nodes? 

Thanks.

Eng Wei

[GBeck]

Eng Wei,

This is a simulation model issue not a ModelSim issue.  For the workaround we created aliases for the PLL clock outputs and forced the clocks with the correct phase shift.

Obviously this is not ideal but does keep up moving forward.  Is there any estimate on a corrected model?

Regards, Gary

[EngWei_O_Intel]

Hi Gary

At the moment, we don't have any estimation time for this to be an updated fix. 

Thanks.

Eng Wei

[EngWei_O_Intel]

Hi Gary

I will transition this case to community support. If you have a new question, feel free to open a new thread to get the support from Intel experts. Otherwise, the community users will continue to help you on this thread. Thank you.

Eng Wei