Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
20644 Discussions

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

Altera_Forum
Honored Contributor II
1,630 Views

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.
0 Kudos
6 Replies
Altera_Forum
Honored Contributor II
646 Views

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.

0 Kudos
Altera_Forum
Honored Contributor II
646 Views

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)
0 Kudos
Altera_Forum
Honored Contributor II
646 Views

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.
0 Kudos
Altera_Forum
Honored Contributor II
646 Views

 

--- 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.
0 Kudos
Altera_Forum
Honored Contributor II
646 Views

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.

0 Kudos
Altera_Forum
Honored Contributor II
646 Views

 

--- 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.
0 Kudos
Reply