Timing requirements/constraints related to a reset synchronizer

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:

1. R0/D (Data input pin) is tied to 1, hence, no timing requirement related to this.
2. Reset deassertion timing is required for R0/Q -> R1/D at the clock frequency at which reset deassertion is happening
3. Similarly, reset deassertion timing is required for R1/Q -> functional_flops/Rbar pins
4. 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
5. Timing at R1/Rbar pin is not required, since, when Rbar gets deasserted, R1/D and R1/Q are both at value "0".
6. 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

Min-pulse-width-check timing paths

All sequential elements require the clock pulse to have a pulse of at-least a certain width in order to function correctly. This is coded in their timing models in terms of a "minimum pulse width" requirement. And the timing path pertaining to check minimum pulse width of a signal is termed as "min-pulse-width-check" timing path. A min-pulse-width-check timing path essentially checks the arrival of one transition of the clock at the endpoint with respect to its fall transition. In other words, both constrained signal and reference signal are the same, just the opposite transitions.

For instance, min-pulse-width-check timing path for a high pulse will have fall transition as the reference signal and rise transition as constrained signal. The latest arrival of rise transition is checked against earliest arrival of fall transition Similarly, min-pulse-width-check timing path for a low pulse will have fall transition as constrained signal and rise transition as reference signal. The latest arrival of fall transition will be checked against earliest arrival of rise transition.

Constraining min-pulse-width-check timing paths: There are two kind of scenarios:

• Min-pulse-width requirement for the pin is picked from timing model

• User specifically specifies a "min-pulse-width" check at a specific pin using "set_min_pulse_width" command. This may be required in certain scenarios, such as a clock going out of the design through an output port, and we need to maintain a minimum duty cycle for the outgoing clock.

Regardless of this, we just need to define a clock of required period and we can report min-pulse-width-check timing path as desired.