[SOLVED] reset synchronization FF problem with clock tree

[digitalo]

Hi all!

I have an ASIC design where I want to implement the classical two-flip-flop reset synchronization. The clock is generated on chip, the reset is an external signal. The FFs have asynchronous set/reset inputs.

Of course, I put the synchronization flip-flops in the same clock domain as all other FFs. What this gives me is that the reset sync FFs are also connected at the bottom of the clock tree. Much of the clock period is eaten up by this, and the sync reset signal (the output of the FF) is only generated so late in the clock cycle that it doesn't arrive in time at its destinations (by more than 1 ns).

I'm using Verilog and Cadence velocity/encounter. I'm building a reset tree by using the bufferTreeSynthesis command.

I guess I should force encounter to place the clock inputs of the two sync FFs in parallel to the root of the main clock tree, but I don't know how to do this. Any ideas?

Dirk

---------- Post added at 20:08 ---------- Previous post was at 19:02 ----------

Forget that. It is obviously nonsense... Of course, the arrival time of the clock at the sync FF is effectively subtracted from the arrival time at the reset pin, when the "other end arrival time" is taken into account.
It seems I actually have a problem with bufferTreeSynthesis not taking sensible buffers. When I see a tree of close to minimum size inverters, I shouldn't wonder too much about a too large delay...

Dirk

 

[graphene]

if u have found d answer for yr problem.. pl share

 

[Riley103]

Thank you so much for the post.

__________________
**broken link removed**

 

[morris_mano]

I'm building a reset tree by using the bufferTreeSynthesis command.

How to decide whether it is necessary to build a reset tree or not? Is it related to the size of the chip? I would be interested in understanding why using reset synchronizer will not be enough? reset is different from clock as we do not care much when chip goes into reset, but only care about reset removal for asynchronous reset. To avoid metastability when reset is removed close to clock edge, wouldn't reset synchronizer (where you feed high signal to two cascaded flop whose reset is driven by asynchronous reset) be enough?

 

[digitalo]

How to decide whether it is necessary to build a reset tree or not? Is it related to the size of the chip? I would be interested in understanding why using reset synchronizer will not be enough? reset is different from clock as we do not care much when chip goes into reset, but only care about reset removal for asynchronous reset. To avoid metastability when reset is removed close to clock edge, wouldn't reset synchronizer (where you feed high signal to two cascaded flop whose reset is driven by asynchronous reset) be enough?

Synchronizing the reset removal to the clock doesn't help you, when you then distribute the synced signal so slowly that the delay approaches a full clock cycle.
Your tool will tell you when you get into this situation.

Dirk

---------- Post added at 08:53 ---------- Previous post was at 08:50 ----------

if u have found d answer for yr problem.. pl share

The solution was quite simple. I put the buffer tree generation with the cts flow. Before that I had a first call to optDesign -preCts. This call tried to improve the reset net, but failed. The result was that the reset net was already fragmented when I started to build the buffer tree. I think a buffer tree was only created for the small trunk of the net still named RESET.
I swapped the order of the two function calls and now it's working just fine.

Dirk