Setup and Hold Judgement on a 200 MHz Synchronous Path
A 200 MHz synchronous block (T = 5.00 ns) contains a launch flop and a capture flop on the same clock, but the capture clock arrives 0.30 ns later than the launch clock. For the suspect path, the flop clk-to-Q delay is 0.40 ns maximum and 0.15 ns minimum, the combinational network is 4.80 ns maximum and 0.35 ns minimum, setup time is 0.20 ns, and hold time is 0.10 ns. At 200 MHz the block produces intermittent errors; at 150 MHz it passes. A junior engineer proposes adding a 0.25 ns buffer in the data path to fix setup. The block has no scan chain, so the failing path is identified only by functional test. The team must decide whether the path has a setup violation, a hold violation, or both, and whether the proposed buffer is safe.
1. Compute the setup slack and decide whether the 200 MHz failure is consistent with a setup violation.
Read the worked answer
With capture clock arriving later by 0.30 ns, setup slack is
T + skew − (tcq_max + tcomb_max + tsu) = 5.00 + 0.30 − (0.40 + 4.80 + 0.20) = 5.30 − 5.40 = −0.10 ns.
So the path has a setup violation of 0.10 ns at 200 MHz. At 150 MHz, T = 6.67 ns, giving setup slack 6.67 + 0.30 − 5.40 = +1.57 ns, which explains why the block passes at the lower frequency. The intermittent functional errors at 200 MHz are therefore consistent with a setup failure, though that alone does not prove it is the only issue.
2. Compute the hold slack and evaluate whether the proposed 0.25 ns data-path buffer is safe.
Read the worked answer
Hold slack is
tcq_min + tcomb_min − skew − th = 0.15 + 0.35 − 0.30 − 0.10 = +0.10 ns.
So there is no hold violation at present, but the margin is only 0.10 ns. Adding a 0.25 ns buffer increases both tcomb_min and tcomb_max. Setup slack becomes −0.10 − 0.25 = −0.35 ns, which is worse. Hold slack becomes 0.15 + (0.35 + 0.25) − 0.30 − 0.10 = +0.35 ns, so hold improves. The buffer therefore does not fix setup and is the wrong direction for the actual failing check. It also consumes area and power and may create a new critical path.
3. Recommend a fix that addresses the real violation without creating a hold failure.
Read the worked answer
The real problem is setup, so the maximum combinational delay must be reduced by at least 0.10 ns, for example by logic restructuring, retiming, or moving part of the function to the next pipeline stage. Increasing the capture-clock delay to 0.40 ns would also give setup slack 5.00 + 0.40 − 5.40 = 0.00 ns, but hold slack then becomes 0.15 + 0.35 − 0.40 − 0.10 = 0.00 ns, leaving no margin; a slightly larger skew would violate hold. The safer design is to reduce tcomb_max while preserving tcomb_min, then recheck both corners. Do not add delay in the data path: at 200 MHz it makes setup worse, and near the present hold margin it could create a hold violation.