Clock propagation delay between arrival and required path

Question

Hello,

I would like to understand why the clock propagation delay is different between data arrival and data required path with TimeQuest.

For example, with a simple synchronous path I was expecting that the clock propagation delay will be the same from clock pin to clock buffer. Then delay is obviously different from clock buffer to FF.

But, what I am seeing in TimeQuest report is that (bold lines) delay from pin to clock buffer is different. How can I explain this difference?

Data Arrival Path:

0.000 0.000 1 pin_j19 i_ref_clk_t

0.000 0.000 rr ic 1 ioibuf_x147_y107_n45 i_ref_clk_t~input|i

0.583 0.583 rr cell 3 ioibuf_x147_y107_n45 i_ref_clk_t~input|o

Data Required path:

5.000 5.000 latch edge time

9.867 4.867 clock path

5.000 0.000 source latency

5.000 0.000 1 pin_j19 i_ref_clk_t

5.000 0.000 rr ic 1 ioibuf_x147_y107_n45 i_ref_clk_t~input|i

5.583 0.583 rr cell 3 ioibuf_x147_y107_n45 i_ref_clk_t~input|o

9.533 0.331 RR CELL 1 FF_X23_Y103_N25 High Speed clipper_core_top:inst_clipper_core|core_top:acd_core_inst|bwp_mef10_3_top:\BWP_ENABLE:u_bwp_top|shaper_mef_10_3:\gen_inst_shaper:5:u_shaper_mef_10_3|remaining_available_bucket_space_step0[17]

Thanks,

altera_forum · Answer

The models have variation for best case and worst case process, voltage and temperature (PVT). To make TimeQuest run faster (by faster I mean wall clock time) at a specific PVT, TimeQuest looks at the specific case - for setup analysis, the launch clock comes as slow as possible and the latch clock comes as fast as possible and for hold time analysis, the launch clock comes as fast as possible and the latch clock comes as slow as possible. So even for the same path before it branches, you see different delays in the same path (I know this is strange). The amount of calculation and time required to resolve this to subtract the common path difference out. Some timing tools (like Primetime from Synopsys) subtract this out if you turn on the option, but the run time goes way up. The feature is called common clock pessimism and is rumored to be added to future versions of TimeQuest.

altera_forum · Answer

Common Clock Path Pessimism Removal (CCPPR) is not difficult to understand but it has intrigued me why it is there in the first place. Shouldn't the tool take care of it rather than pass it as an option to enable or not. It sounds like the tool is saying "CCPPR should be removed but I leave it to you).

My guess is that it slows down the tool and so it could be just a commercial ploy as many designs will have enough margin anyway. If timing fails then enable it and wait longer.

In ASICs there is yet another pessimism; common clock convergence (CCP I think), keep making life difficult !

altera_forum · Answer

This doc page 42 explains the theory behind this pretty well: https://www.altera.com/content/dam/altera-www/global/en_us/pdfs/literature/hb/qts/qts_qii5v3.pdf

Quartus documentation how to remove this pessimism:

http://quartushelp.altera.com/current/master.htm#mergedprojects/analyze/sta/sta_tqa_settings.htm

Forum Discussion

Clock propagation delay between arrival and required path

3 Replies

Recent Discussions

Timing analysis - long combinational path

QuartusPro 25.3 Crashed after using the Signal Tap Logic Analyzer

Duplicate_hierarchy_depth / duplicate_register

Automatically added negative node for TDS output doesn't work with Agilex 5

Quartus 20.1std compilation fails for Quartus map - Device 10AS057K2F40I1SG