Large uTh in timing analysis

[plancheres]

Hello,

I'm working with Arria 10 and I'm trying to optimize timing in a design which appears to be congested due to excessive routing delays added by the compiler to meet hold timing. (The congestion is causing IC delays of up to 7.5ns between adjacent cells.) In order to reveal where all the routing delays are being applied, I recompiled the design with "Optimize Hold Timing" disabled. In the timing analysis (see attached picture), I noticed that some registers have a very large uTh (1.1 ns) and this is causing the tool to add significant routing delays. The strange part is that the same register has a small uTh (0.1 ns) when driven from a different launch register, that is:

From A to C, C has uTh = 1.1 ns.

From B to C, C has uTh = 0.1 ns.

In both cases above:

- registers A, B, and C are in the same clock domain

- the Data Arrival times for A->C and B->C are very similar

- the clock paths for A and B are the same

- the clock paths for C are the same

- the timing analysis is performed in the same corner.

The only major difference between the two paths is the uTh value in the Data Required time.

My questions are:

1) What causes uTh to be so large and what can be done, if anything, to reduce it?

2) Why does the same destination register have two different values of uTh in two different data paths? I thought the hold time requirement was just a property of the destination register.

Regards,

Phil

[RichardTanSY_Intel]

Without 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

[plancheres]

Hi 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

[RichardTanSY_Intel · Accepted solution]

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

[plancheres]

So the congestion may have led to some LABs being borrowed that weren't optimally configured, leading to larger uTh.

Thanks Richard.

[RichardTanSY_Intel]

Thank you for acknowledging the solution provided.

Now, I will transitioning this thread to community support. If you have any further questions or concerns, please don't hesitate to reach out. Please login to ‘https://supporttickets.intel.com', view details of the desire request, and post a feed/response within the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support.
The community users will be able to help you on your follow-up questions.

Thank you and have a great day!

Best Regards,

Richard Tan