In the post reset synchronizer, we discussed the functionality associated with a reset synchronizer. Here, we will discuss the timing associated with a reset synchronizer. Figure 1 below shows a reset synchronizer.
 |
| Figure 1: Reset synchronizer |
As we can see, a reset synchronizer is expected to have 3 pins other than a clock pin. We will discuss the timing requirements of each of these one-by-one:
- R0/D (Data input pin) is tied to 1, hence, no timing requirement related to this.
- Reset deassertion timing is required for R0/Q -> R1/D at the clock frequency at which reset deassertion is happening
- Similarly, reset deassertion timing is required for R1/Q -> functional_flops/Rbar pins
- Timing at R0/Rbar pin is not required, since, it is put there to absorb metastability and come out of metastability before next clock edge
- Timing at R1/Rbar pin is not required, since, when Rbar gets deasserted, R1/D and R1/Q are both at value "0".
- Both R0 & R1 need at least a certain pulse width at Rbar pin in order to detect the reset. This requirement is generally given in the timing model of flip-flop
Points 4 & 5 assume that there is not much skew between R0/Rbar and R1/Rbar, which is true since either there is a custom cell made as a reset synchronizer or both the flip-flops are placed very close to each other, leaving almost no scope for a large skew.
Points 2 & 3 require that reset synchronizer and its fanout flip-flops are clocked on a related clock.
Thus, there are following constraints related to a reset synchronizer:
- Reset synchronizer must be clocked on either same or related clock to its fanout flops
- set_false_path -to R0/Rbar
- set_false_path -to R1/Rbar
- Min-pulse-width requirement at Rbar pins modelled in timing models
But in this case, the recovery and removal timing are also violated because we are de-asserting the reset signal the same moment the clock edge arrives, thus the functional flip-flops will be brought out of reset at the clock edge too, or do I've got my facts wrong?
ReplyDeleteHi
DeleteI will recommend you to go through following, in case still you have queries, we can discuss
https://vlsiuniverse.blogspot.com/2016/09/reset-synchronizer.html
Thank you for the clear explanation.
ReplyDeleteI have two questions,
1. Suppose we have pll locked signal or other similar control signal like initialization done. We AND this signal with input async reset and connect to Rbar. What will be constraints for this path?
2. Can we use max_delay constraint instead of false path for Rbar? What will be the impact of these two types of constraints?
Hi
Delete1. In this case, you have two sources of asynchronous resets. One is the original async reset signal, and PLL_LOCK also acts as asynchronous reset signal in this case. So, all the constraints discussed here ill be valid for PLL_LOCK as well.
2. max_delay will constrain the signal to be arriving within a specific time, which is a sub-set of it being unconstrained (false path). So, there will not be any issue here.
“Reset deassertion timing is required for R0/Q -> R1/D at the clock frequency at which reset deassertion is happening”， Why is that “Reset deassertion timing is required” instead of that "setup/hold timing is required"? I think it is a normal data path.
ReplyDeleteHi
DeleteReset deassertion timing means timing of setup/hold for deassertion (going from active to inactive state) of reset signal. The reset signal needs to be timed only for deassertion, since assertion will not be related to clock. It travels combinationally from RD->Q
Are "set_false_path -to R0/Rbar" and set_false_path -to R1/Rbar command necessary? Thank you.
ReplyDeleteHi
DeleteNo, it is not necessary. There can be two cases:
1. Reset launches on an asynchronous clock. In this case, no impact of set_false_path.
2. Reset launches on synchronous clock. In this case, if you are ok to meet timing, then you may choose not to apply the set_false_path.
Excellent explaination
ReplyDeleteThanks for appreciation:-)
Delete