Timequest and clock network delays

Question

I'm somewhat new to timequest and timing closure on FPGAs, and I'm finding some things with the use of timequest to be ... strange, in my opinion. This is somewhat related to http://alteraforum.com/forum/showthread.php?t=1745, but I have a different question.

In my timing reports, timequest kindly points out the clock network delay. My initial understanding of this is that this is the delay to the start point of the path. I expected to see a destination clock network delay as well, however, there is nothing there. The result is that, say I have a clock with period 8ns, clock network delay 4ns, the time allowed for data path propagation is only 4ns in the reports. I would expect it to be 8ns still (assuming the clock delay to start/endpoints are relatively the same). The path is not spread out over much of the chip; it is in a very small area, and I would find it difficult to believe there is a 4ns skew between the start and endpoints (see attached screenshot)

Here's a path illustrating what I'm seeing. Despite the 8ns period, the data path only has 3.9ns according to timequest. (As a side note, there was a set_max_delay constraint I put on this path which appears to have been 2.9, even though I specified 7.9. The same issue with the clock network delays was present before adding the constraint and recompiling).

Anyone able to help clear this up?

Thanks,

baver

Info: ===================================================================

Info: Max Delay Exception : 2.900

Info:

Info: Data Arrival Path:

Info:

Info: Total (ns) Incr (ns) Type Element

Info: ========== ========= == ==== ===================================

Info: 0.000 0.000 launch edge time

Info: 4.177 4.177 R clock network delay

Info:

Info: Data Required Path:

Info:

Info: Total (ns) Incr (ns) Type Element

Info: ========== ========= == ==== ===================================

Info: 2.900 2.900 latch edge time

Info: 7.135 4.235 R clock network delay

Info:

Info: Data Arrival Time : 8.035

Info: Data Required Time : 7.045

Info: Slack : -0.990 (VIOLATED)

Info: ===================================================================

Info:

altera_forum · Answer

It seems that 2.9ns set_max_delay is actually causing this (found where is was being set). And I found where the destination clock delay is reported (data required path section).

I think I answered all my questions.

altera_forum · Answer

To get more clock detail, modify your report_timing to "-detail full_path".  This breaks out your clock into more line items.  It's way too much informaiton when your clocks are right, but is very useful when identifying the clock paths and their delay sub-components.  Also, a common misunderstanding is to think set_max_delay is a requirement on the delay between registers.  In reality it just overrides your setup requirement(which is your clock period within a domain).  This way it still takes into account clock skews, which is good.

Forum Discussion

Timequest and clock network delays

2 Replies

Recent Discussions

Warning at Standard 25.1 by Arria 10

Perpetual license Quartus II doesn't allow to build Cyclone V devices anymore.

Quartus Eda_Writer keeps crashing

Failing IO buffer

Floating point operation on Cyclone 10 GX