Forum Discussion
New ContributorTimeQuest ALTPLL wrong setup relation
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.
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
27 Replies
NurinaRegular Contributor
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
sstrellSuper Contributor
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?
toczkows-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}
Ts is 6.667 ns
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>
- Nurina
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
- toczkows
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.
- Nurina
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
- Nurina
Hi,
May I know if you still need help with this thread?
Regards,
Nurina
- Nurina
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
- toczkows
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
- Nurina
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
- toczkows
Hi
I'll prepare .qar tomorrow.
- Nurina
Thanks.
To generate this, go to Project>Archive Project.
Regards,
Nurina
- toczkows
simple example in attachment.
I had only access to old quartus version, but can be updated to newest one if needed.
- Nurina
Hi,
Please see page 47 of this document on the setup and hold relationships.
Regards,
Nurina
