Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
9 years ago

Huge numbers of recovery failures - even though reset is on Global Clock Net

Hi All

Ive raised a mysupport ticket on this - but I thought I might ask here also. I have a Stratix iV design that has 91% logic utilisation. We are in the process of cleaning up our reset strategy due to some issues with a new block.

1. All reset have been made asynchrous, active low.

2. All registers are reset

The global reset is routed through a CLKCTRL block because of the large fanout. But I still get huge number of failing registers (TNS ~156000 ns !!!)

I notice that the path from reset register to CLKCTRL is adding 4.1ns to the arrival path. Does this seem normal?

Any help or ideas on this appreciated.

6 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    The modern advice is "use reset only when required" but if already done then reduce fan out by pipelining reset assuming your design accepts it. Modules that wait for signals e.g. at end of chain can have pipelined reset unless they send hand shake signals. In fact if your design gets active well after reset release you can set false path all over.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    Global resetting everything was the design choice when the project started several years ago. Now w're on a global (rather than local) resets we picked out many cases where synchronous enables were infered from the reset. This is the design choice that was taken to must stick with it (I wouldnt do this now... but others might think differently..), as almost all of the code does this.

    I want to avoid false paths just in case something gets borked when coming out reset (its highly unlikely, but I want to avoid it unless necessary, though Im pretty sure it would be safe). At the moment, the reset is synchronised using a counter (16 bit) and a 2nd register when the counter rolls over. This should smooth out any bounces from the PLL locked signal thats used as one of the inputs. Other reset inputs are HWreset pin and sw reset. Theres no hand shaking.

    It was suggested we put a shift register as the output of the reset block. This, combined with possible reset pipelining options might be useful - ill give it a go (6 hr build - slow progress)
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    --- Quote Start ---

    Ok - Ive found this interesting page:

    http://quartushelp.altera.com/15.0/mergedprojects/logicops/logicops/def_physical_synthesis_asynchronous_signal_pipelining.htm

    Anyone know if I can determine if a signal is dertermined to be "critical"?

    The Pipeline asynchronous signal option is enabled in project settings - and it seems to fit with my problem exactly.

    --- Quote End ---

    I am no fan of using tool to do such job and I would rather do the pipeline myself as it is straightforward.

    Remember the modules distant in a chain can't get all released at reset in same clock period as front modules due to massive delay.

    Unlike clock and data which delay together through the chain. If your design units at rear of chain do not have feedback and will work well after reset release then it is safe to pipeline the reset. Otherwise you shouldn't pipeline and your design will fail timing.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    Physical synthesis, as you mention, may fix the problem, though it will greatly increase compile time. If you must use a global, you may want to see if you should be using a different clock control block. That insertion delay (the time to get to the clock control block) is pretty long (4.1 ns), so you should check to see if the Fitter selected the closest clock control block for getting the reset on the global clock.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    --- Quote Start ---

    Physical synthesis, as you mention, may fix the problem, though it will greatly increase compile time. If you must use a global, you may want to see if you should be using a different clock control block. That insertion delay (the time to get to the clock control block) is pretty long (4.1 ns), so you should check to see if the Fitter selected the closest clock control block for getting the reset on the global clock.

    --- Quote End ---

    It is as close as it can be. The theory is that the fitter is trying to compensate for hold on the reset for some of the registers (because 4.1ns is rather large when you're only going from the register adjacent to the CLKCTRL!) , so is inserting extra routing delay to fix it, and breaking the recovery for everything else. So Im adding a fitter only constraint to relax hold timing so that these will then fail hold or removal timing so I can isolate and fix them.