Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)
Announcements
All support for Intel NUC 7 - 13 systems has transitioned to ASUS. Read latest update.
16512 Discussions

TimeQuest ALTPLL wrong setup relation

toczkows
Beginner
2,210 Views

Hi,

 

recently I found some strange behaviour of timequest STA regarding simple design with PLL on Quartus Prime Lite. If there is simple data transfer between clock (i_CLK) and clock that's output of PLL (sys_clk) (1:1 ratio "normal" mode) from same clock, then for STA setup and hold time relationshiops are dependant on waveform (phase shift) from main clock (i_CLK) that I create.

 

So for example in sdc:

create_clock -name {i_CLK} -period 10.000 -waveform { 0.000 5.000 } [get_ports {i_CLK}]

derive_pll_clocks

derive_clock_uncertainty

 

setup is 10 ns and hold is 0 ns as expected

 

but for constraints

create_clock -name {i_CLK} -period 10.000 -waveform { 8.000 13.000 } [get_ports {i_CLK}]

derive_pll_clocks

derive_clock_uncertainty

 

setup is 3.334 ns and hold -6.636 ns

 

From the clock tree perspective it looks like STA takes clock edges and apply it to nearest PLL VCO edge and apply that as output waveform phase shift and this leads to unrealistic timing (?) requirements that are dependand on arbitrary waveform generation in sdc, where it shouldn't be a case.

toczkows_0-1674027008655.png

How to handle this situation - override setup/hold with set_max/min_delay ?

Moreover in Quartus Prime Pro everythink works as exptected and relation stays always the same - ts 10.0 th 0.00

 

Regards

0 Kudos
27 Replies
sstrell
Honored Contributor III
2,011 Views

Setting a fall time outside the period of the clock in your .sdc doesn't make sense.  I'm surprised the tool let you do it.  What happens when you set the -waveform to {3.0 8.0}?

And where are you seeing these setup and hold time numbers?

0 Kudos
toczkows
Beginner
2,001 Views

 -waveform to {8.0 13.0} is absolutely classic way of creating shifted clock. Only rising edge must be defined within <0, clk_period) time. How otherwise one would defined clock with phase shift more then 180 degrees. See create_clock -help for details.

 

For -waveform {4.00 9.00}

toczkows_0-1674118033840.png

Ts is 6.667 ns

toczkows_1-1674118094263.png

 

As for -waveform {3.00 8.00} setup relation will be 10.00 ns , because rising edge time is less then VCO period <3.333>

 

 

 

0 Kudos
Nurina
Employee
1,976 Views

Hi,


Are you saying the PLL is launching/latching at the wrong edge? You can try set_multicycle_path for the PLL clock. https://www.intel.com/content/www/us/en/programmable/quartushelp/13.0/mergedProjects/tafs/tafs/tcl_pkg_sdc_ver_1.5_cmd_set_multicycle_path.htm


Regards,

Nurina


0 Kudos
toczkows
Beginner
1,966 Views

Thanks for your answer. MC can solve STA ts/th violations but doesn't anwser why STA ts/th in this example are dependant on arbitrary input clock phase shift (it can be any value), hance STA calculations looks wrong and completely unreliable. 

0 Kudos
Nurina
Employee
1,897 Views

Hi,


Shifting a clock will change the setup and hold relationship because then the launch and latch edge will be changing. By default, TimeQuest will choose the nearest latch edge and this results in a different setup & hold relationship. If the setup & hold relationship calculated by TimeQuest is not what you want, you should use set_multicycle_path.


Regards,

Nurina


0 Kudos
Nurina
Employee
1,879 Views

Hi,


May I know if you still need help with this thread?


Regards,

Nurina


0 Kudos
Nurina
Employee
1,863 Views

Hi,


We do not receive any response from you on the previous question/reply/answer provided. Please login to https://supporttickets.intel.com , 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.


p/s: If any answer from community or Intel support are helpful, please feel free to mark as solution, give Kudos and rate 4/5 survey


Regards,

Nurina


0 Kudos
toczkows
Beginner
1,846 Views

Hi,

 

@Nurina wrote:

Hi,

 

Shifting a clock will change the setup and hold relationship because then the launch and latch edge will be changing. By default, TimeQuest will choose the nearest latch edge and this results in a different setup & hold relationship. If the setup & hold relationship calculated by TimeQuest is not what you want, you should use set_multicycle_path.

 

Regards,

Nurina



Question here was transfer between register A cloecked by "clock" and register B clocked by  "clock" after PLL in normal mode. According to documentation 

4.2.8.4. Normal Compensation Mode (intel.com) this clock is internally (inside FPGA) phase aligned to input clock - and thats not what TimeQuest is reporting - as you can see in previews screens. When using Quartus Pro or Vivado in this mode clock is always reported as phase alligned ( so setup is equal to period and hold to 0) but not in Quartus Prime for only some input phase cases. And my question is why ? Is it a bug in documentation for cycone V or in timequest or something different

0 Kudos
Nurina
Employee
1,799 Views

Hello,


As mentioned above, when you create a phase shift this will affect the setup and hold relationships.

Can you share the .qar file of your design? From there I might be able to understand your question better.


Regards,

Nurina


0 Kudos
toczkows
Beginner
1,779 Views

Hi

I'll prepare .qar tomorrow.

 

0 Kudos
Nurina
Employee
1,770 Views

Thanks.

To generate this, go to Project>Archive Project.


Regards,

Nurina


0 Kudos
toczkows
Beginner
1,757 Views

simple example in attachment.

I had only access to old quartus version, but can be updated to newest one if needed.

0 Kudos
Nurina
Employee
1,680 Views

Hi,


Please see page 47 of this document on the setup and hold relationships.

https://www.intel.com/content/dam/support/us/en/programmable/support-resources/fpga-wiki/asset02/timequest-user-guide.pdf#page=47


Regards,

Nurina


0 Kudos
toczkows
Beginner
1,654 Views

yes, and exactly how does that anwser my question ?

 also see 4.2.8.4. Normal Compensation Mode (intel.com) page 92...

0 Kudos
Nurina
Employee
1,589 Views

Hello,


I see your problem now. I've tested on Pro as well and it works. Seems like this is a bug on Standard, I am reporting this problem to engineering team.


Regards,

Nurina


toczkows
Beginner
1,567 Views

Thanks,

 

Do you think for now relation can be 'fixed' by setting set_max_delay set_min_delay between those clocks ?

 

 

0 Kudos
Nurina
Employee
1,541 Views

Hello,


I don't think so. Wouldn't it ignore the first phase shift that you have set?

Please refer to this documentation:

https://www.intel.com/content/dam/support/us/en/programmable/support-resources/fpga-wiki/asset02/timequest-user-guide.pdf#page=59


Regards,

Nurina


0 Kudos
Nurina
Employee
1,492 Views

Hi,

 

Engineering is still investigating the problem here.

I've tried experimenting by adding phase shift in the PLL.

 

With below SDC constraints,

create_clock -name {i_clk} -period 10.000 -waveform { 4.000 9.000 } [get_ports {i_clk}]

derive_pll_clocks

derive_clock_uncertainty

 

Added below changes to the PLL:

Nurina_7-1677557139813.png

 

The setup & hold relationship is 10ns & 0ns respectively:

Setup Report Timing

Nurina_8-1677557145263.png

 

Hold Report Timing

Nurina_9-1677557150065.png

 

 

Can you try this solution?

 

Regards,

Nurina

 

0 Kudos
Nurina
Employee
1,469 Views

Hello,


Have you tried the solution I have provided?


By the way, engineering has responded. Can you let me know why you are setting an offset to the base clock? What's the use case?


Regards,

Nurina


0 Kudos
toczkows
Beginner
1,446 Views

Hi,

 

so solution in principle works if I apply this values postpriori to pll settings - still there is question if actually router know what its doing in term of route path optimizations.

 

regarding the question about why clock offset is done - it was just simple example - in actual project clock edges are in 0 ns offeset -period 10.000 -waveform { 0.000 5.000 } [get_ports {i_CLK}]  -> this clock describes incoming clk from ADC lvds interface that has 0 degrees clock to data edge offset. It is  ALTLVDS_RX ipcore that produces phase shifted versions by x ns described above. For signal processing purpose as well as for resource sharing we need this clock exact copy that runs with same and 2 times faster frequency and thats when we find this abnormal behaviour if we connect ALTLVDS_RX ipcore output clock to ALTPLL ipcore.

 

0 Kudos
Reply