Can jitter in clock effect setup and hold violations?

First of all, we need to understand what is meant by jitter. In most simplistic language, jitter is the uncertainty of a clock source in production of clock edges. For example, if we say that there is a 100 MHz clock source. Ideally, it should produce a clock edge at 0 ns, 10 ns, 20 ns... So, if we say that there was a clock edge at time t = 30 ns, we should get the next clock edge at t = 40 ns. But this is hardly so; due to the uncertainty of getting a clock edge, we might get the next edge between 39.9 ns to 40.1 ns. So, we say that 0.1 ns is the jitter in the period of the clock. In reality, the definition of jitter is more complex. But, for our scope, this understanding is sufficient.

Let us consider a simple timing path from a positive edge-triggered flip-flop to a positive edge-triggered flip-flop.

Now, let us come to our discussion. First, let us discuss the effect of clock jitter on setup slack.

Effect of clock jitter on setup slack for single cycle paths: From our knowledge of STA basics, setup check formed, in this case, will be from edge 1 -> edge 3. Now, if we know that edge 1 arrived at 20 ns, then edge 3 may arrive at any time (20 ns + CLOCK_PERIOD + jitter) and (20 ns + CLOCK_PERIOD - jitter). So, to cover worst case timing scenario, we need to time as per (20 ns + CLOCK_PERIOD - jitter). So, effectively, we will get (CLOCK_PERIOD - jitter) as effective clock period.

In other words, jitter in clock period makes the setup timing more tight. Or it decreases setup slack for single cycle timing paths.


Effect of clock jitter on hold slack for single cycle paths: Going on the same grounds as setup slack, hold check will be from edge 1 -> edge 1 only. And we know with certainty that edge 1 will leave the source at 20 ns only. So, hold slack should not get bothered by the amount of jitter present at the clock source for single cycle timing paths.

Now, you understand the basics of  how jitter affects setup and hold slacks. We can state as below:

If the check being formed involves two different edges of same polarity (for instance, different rising edges), then, jitter in clock period will affect setup slack. Otherwise, it will not.

Now, can you guess the effect of jitter on setup and hold slacks for zero cycle timing paths?

Also, what will be the amount of pessimism needed to be taken into account for setup and hold slacks' calculations if the timing path is a multi-cycle path taking 2 cycles for setup and zero cycle for hold?

Also read:

• Interview questions related to clock jitter and duty cycle variations

Recovery and removal checks

Recovery and removal checks are associated with deassertion of asynchronous reset. The assertion of reset causes the output to get reset and deassertion transfers the control of output to clock signal; i.e., deassertion of reset does not change the output as we discussed in post synchronous and asynchronous resets. However, to ensure that the design comes out of reset in deterministic cycle and to avoid metastability, there must be a region around arrival of clock edge within which reset must not be deasserted. This is similar to setup and hold timing checks, the difference being that:

Setup and hold checks are associated with synchronous data signals for a flop and are applied to both rise and fall transitions of data. Recovery and removal checks, on the other hand, are for asynchronous reset transitioning from active state to inactive state only (deassertion of reset).

To properly understand what recovery and removal checks are, we need to understand what asynchronous reset assertion and deassertion does.

Asynchronous reset assertion: In a flip-flop, assertion of reset causes the output to go to its reset value (which is normally "0"). The assertion of reset is an asynchronous event and is not impacted by the state of clock. Figure 1 below depicts the assertion of reset. As it can be seen, Output asynchronously goes to "0" as an effect of reset going to its active state "1".

Asynchronous reset deassertion: The deassertion of asynchronous reset causes the output to get out of the impact of reset and behave like a normal flip-flop. When the reset gets deasserted, its output remains to be "0" until the clock edge. When the clock edge arrives, the value at the input of the flop propagates to the output. Figure 2 below depicts the same. However, the position of reset deassertion with respect to clock edge matters here as is the case with setup and hold checks. If the reset toggles in the vicinity of clock edge, the flip-flop may go metastable. This is avoided by defining recovery and removal checks for reset deassertion. For the sake of simplicity, we can say that recovery and removal checks are setup and hold checks for reset deassertion.

Reset recovery check: Recovery check ensures that the deasserted reset signal allows the clock signal to take control of the output at the desired clock edge. For this, reset signal must be stable at least "recovery time" before the active clock edge. Recovery time is the minimum time required between the deassertion of reset signal and arrival of clock edge. This can be modelled similarly as a setup check with the difference of it being a single sided synchronous check only.

Reset removal check: Removal check ensures that the deasserted reset signal does not get captured on the clock edge at which it is launched by reset synchronizer. For this, reset signal must be stable at lease "removal time" after the active clock edge. Removal time is the minimum time required after the arrival of clock edge for which reset must not be deasserted at the flop's reset pin. This can be modelled similarly as a hold check with the difference of it being a single sisded synchronous check only.

Figure below shows reset de-assertion as a complete picture and summarises what we have discussed in this post.

Next read: Reset basics

Also read:

• Interview questions related to reset design and reset timing