Of the setup and hold timing constraints which are to be met to get a stable output, which one is critical in estimating the maximum clock frequency of a circuit?


Setup time limits the fastest frequency (shortest period) for the clock. Hold time must be met to have proper operation, and any added buffers or delays to ensure hold time is met can slow the circuit below what you'd estimate from setup time. Beyond this simple rule of thumb, the upper frequency limit depends on the circuit details, and once you determine the critical path you might find ways to improve the design by changing the topology (e.g. put something in parallel, break up the combinational logic across more than one flop in the chain, as in pipelining if added latency is okay).

Another way to think about this: - Setup time relates to behavior from one clock edge to the next and data delay for a change launched on one edge settling before the next clock edge. If you have a setup time violation, you can reduce the clock rate and the circuit will function properly (assuming the clock tree is balanced reasonably well - see Tut's comment below). - Hold time can relate to behavior even on a single clock edge, in the case where a data change on one flop propagates to another flop quickly enough to violate the hold time at the next flop. When this happens the next flop latches the wrong data (the new data instead of the old). Slowing the clock rate will not help a hold time violation. To fix it you must add delay in the violating data path.

  • \$\begingroup\$ @Tut - Okay, I agree with that. If you have a bad clock tree all bets are off. The generalization works if you have a decent clock tree or the same leaf clock driving both flops. \$\endgroup\$ – mixed_signal Sep 30 '14 at 3:10
  • \$\begingroup\$ @Tut - Hang on. I'm not sure I agree with your example. What do you mean by "clock propagation delay" ? Are you referring to skew between the clock signals at the launching and capturing flops? The capturing flop latches data on the an edge one-half or one full clock cycle after the launching edge; increase the clock period and it has to work. However if the clock signal at the capture flop is too early then you'll have a hold problem, not a setup problem. But your general point might be that max speed is also limited by skew in the clock tree. \$\endgroup\$ – mixed_signal Sep 30 '14 at 3:22

The answer to that one is simple: both. If you violate either one you're in trouble. And just using these two will not allow a reliable estimate of maximum clock frequency. You also need, at a minimum, to factor in the propagation delay from clock edge to ouput change. Plus, and this is critical, you need to allow time for propagation of combinatorial delays. Since this is almost always greater than input hold time, you can generally ignore hold time, except in the odd case where you can't.

  • \$\begingroup\$ ... not forgetting clock jitter and clock skew, whereby one clock edge is late but another is early... \$\endgroup\$ – Brian Drummond Aug 5 '14 at 12:00
  • \$\begingroup\$ And metastability, let's not forget that. \$\endgroup\$ – WhatRoughBeast Aug 5 '14 at 12:03
  • \$\begingroup\$ Actually within the interior of a synchronous design you CAN pretty much forget about metastability : it can only be caused by a setup or hold violation in an earlier stage. At the inputs, you are of course correct. \$\endgroup\$ – Brian Drummond Aug 5 '14 at 12:08
  • \$\begingroup\$ Just a clarification: Clock to output time is a latency, not a limit on maximum frequency of operation. You could have a circuit that works fine at very high frequency but with substantial latency, such as a pipelined ADC. Depending on the system around the circuit the latency might or might not be relevant to maximum frequency of operation. From the original post's question, apparently total time to the output is relevant here, but it's not always the case. \$\endgroup\$ – mixed_signal Oct 20 '14 at 15:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.