How to fix large number of hold violations for Cyclone V GX in Quartus II?

[AHorn4]

My Cyclone V GX design compiles with no setup or hold violations in the two slow models but contains a large number of very small (< 0.2ns) hold violations in the two fast models. After investigating further in TimeQuest, there are over 100 paths with these small hold violations.

Now I checked the amount of setup slack on these paths and they are all >3ns so there is definitely enough margin for Quartus II to fix these hold violations for me (I have Optimize Hold timing selected). The design is quite large (85% resources) and uses a PLL multiplied clock to drive the majority of the logic.

Is there an sdc command I can use to fix this problem? Or can I safely ignore these violations because they only occur in the two fast models and not the slow models.

Any help would be appreciated.

[Abe]

Have you tried changing the Analysis & Synthesis settings to Performance - Aggressive, as well as enabling the "Perform Clocking Topology Analysis During Routing" Option under the Advanced Fitter Settings menu in Quartus.

These options can help improve Hold timing at the cost of Runtime.

[KhaiChein_Y_Intel]

Hi,

Can you provide the timing report file?

Thanks

[AHorn4]

I have tried tried many advised methods including:

• Optimize Hold Timing (all paths)
• Perform Clocking Topology Analysis During Routing
• Aggressive Routing
• and on and on...

I have attached the timing report file.

Cheers

[KhaiChein_Y_Intel]

Can you report timing for PLL_1|pll_clk_manager_inst|altera_pll_i|general[0].gpll~PLL_OUTPUT_COUNTER|divclk   to see the failing paths?

[jrrguzman]

Have you checked clock skew in the failing paths? Hold violations are usually due to clocks skewing too much one from each other, so the launch clock arriving before the capture clock. If that difference is too high your data changes before the capture clock arrives and you'll get a hold violation.

[AHorn4]

PLL_1|pll_clk_manager_inst|altera_pll_i|general[0].gpll~PLL_OUTPUT_COUNTER|divclk is the main PLL derived clock that drives most of the logic in my design. I've attached 120 paths that contain hold violations - there are 375 in total.

In terms of clock skew, TimeQuest reports an average of 0.6ns of clock skew for all the failing paths but also reports 0.6ns of clock skew for paths that do not have hold violations.

[KhaiChein_Y_Intel]

You could try overconstraining by adding the following to your sdc.

if {$::quartus(nameofexecutable) != "quartus_sta"} { set_min_delay <value> -from -to  } 

Reference: https://fpgawiki.intel.com/wiki/Timing_Constraints#Overconstrain_path

Thanks