TimeQuest ALTPLL wrong setup relation

[toczkows]

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

[sstrell]

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.

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

Regards,

Nurina

[toczkows]

yes, and exactly how does that anwser my question ?

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

[Nurina]

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]

Thanks,

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

[Nurina]

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

[Nurina]

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:

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

Setup Report Timing

Hold Report Timing

Can you try this solution?

Regards,

Nurina

[Nurina]

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

[toczkows]

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.