Forum Discussion

plancheres's avatar
plancheres
Icon for New Contributor rankNew Contributor
1 year ago
Solved

Large uTh in timing analysis

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 congestio...
Fpga Devkit
  • RichardT_altera's avatar
    RichardT_altera
    1 year ago

    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


RichardT_altera's avatar
RichardT_altera
Icon for Super Contributor rankSuper Contributor
1 year ago

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's avatar
    plancheres
    Icon for New Contributor rankNew Contributor
    1 year ago

    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