Forum Discussion
New ContributorLarge uTh in timing analysis
Based on engineering input, the hold times will vary depending on how the LAB is configured. Factors such as HS/LP (High Speed/Low Power), the amount of borrowing, and the settings for the Flip-Flop and LUT will all influence the reported uTh.
As you may already know, different timing models may also affect the uTh.
Without a design or project, it is difficult to determine what might be contributing to the high uTh at the moment.
Btw, I’m glad to know the timing issue is solved.
Regards,
Richard Tan
Super ContributorWithout looking at the design, it is hard to pinpoint why the uTH is large.
Do you still see hold timing violation with the OPTIMIZE_HOLD_TIMING set as ON ?
How is the design's utilization? As high device utilization or high routing congestion, in certain area, may complicates timing closure.
Regards,
Richard Tan
New ContributorHi Richard,
With OPTIMIZE_HOLD_TIMING = ON, the tool adds the necessary routing delays to eliminate all hold violations but this excessive routing translates into congestion that causes large setup violations in places that would otherwise easily pass timing. I compiled with OPTIMIZE_HOLD_TIMING = OFF so that I could study the root of the problem (by looking at the paths with the largest hold time violations). The logic utilization in this design was 92% ALMs, 83% registers, 40% M20Ks.
Update: I managed to reduced the resource usage in the highly congested areas (utilization is now 89% ALMs, 79% registers, 39% M20Ks) and all of the timing issue are now resolved. However, I would still like to understand the following:
Why does the uTh of a destination register depend on the path leading to that register? I thought hold time requirement was a register property and I expected it to be the same for every path leading to that register. Does anyone know how Quartus determines uTh during timing analysis?
Regards,
Phil
