STA Timing result much worse with Quartus v20 and later than v17.1

[Terry_fan]

Hi,

I have a design implemented in Arria10 device, I'm using Synplify_premier v2019 + Quartus v17.1 Standard edition. Now I want to upgrade the Quartus version to v20 later, e.g. v22.1.

The issue is that Timing Analyzer report much worse timing result with v22.1, e.g. I got slack -1.5ns with v17.1, but got -4ns with v22.1.  What could be the reason?

FYI RTL design is same, timing constraint is same, alt_clkctrl and memory IPs are upgraded to v22.1.

Any suggestion is appreciated.

Thanks.

[Nurina]

Hello,

First of all, migrating your project to a later version of Quartus does not guarantee better results as place & route and timing optimization is done differently. However, a large slack like that is quite alarming, it usually means that there is SDC constraint problem.

Can you share you .qar file for both v17.1 and v22.1? To generate this, go to Project>Archive Project.

Regards,

Nurina

[Terry_fan]

Hi,

Thanks for your reply, but I'm not sure I'm allowed to share the project file as it is a commercial project. 

one possible reason might be that the Synplify version does not support Quartus v22.1, but I haven't installed latest Synplify version. 

The reason I use Synplify is that it does good job on Gated clock conversion. Can you advise that, suppose I have a lot of gated clock in my design, how can I achieve good timing slack without using Synplify? is Quartus good enough to handle the gated clocks?

Thanks.

[Nurina]

Hello,

Are you using Quartus Pro or Standard? These documents tells you how you can perform Automatic Gated Clock Conversion on Quartus Pro and Standard:

• https://www.intel.com/content/www/us/en/docs/programmable/683236/22-1/automatic-gated-clock-conversion.html
• https://www.intel.com/content/www/us/en/docs/programmable/683283/18-1/auto-gated-clock-conversion.html

This should be sufficient to convert gated clocks. However from a timing perspective, I cannot confirm if this would improve the slack because I do not know the root cause of the timing violation in your design.

You can share your design through e-mail for privacy purposes. I'll drop an e-mail to you.

Regards,

Nurina

[Nurina]

Hello,

Case has been solved through email.

Solution:

I do agree that reusing Synplify netlist in from the v17.1 project could be an issue. Because the .vqm netlist should be optimized for the target Quartus software, ensuring better performance, and the place & route algorithm changes with each Quartus version: https://www.intel.com/content/www/us/en/docs/programmable/683122/18-1/using-synplify-premier-to-optimize-your.html

Plus it is better to provide timing constraints in the Synplify software: https://www.intel.com/content/www/us/en/docs/programmable/683122/18-1/simulation-and-formal-verification.html

Do you plan to continue without Synplify? 

I have looked into the timing reports and there are many violations at the RAM area.

I have also checked for Report Unconstrained Paths & Check Timing reports and there are many issues with the SDC constraint. Before you attempt to do any timing optimization you need to fix the Unconstrained Paths reported, or ensure that they can be ignored.

Regards,

Nurina