7.6 Hold Time: Why Data Must Stay Stable After the Clock Edge

Define hold time, evaluate hold-time violations, and explain why (unlike setup violations) hold violations cannot be fixed by slowing the clock.

Setup time (Topic 7.5) protects the moment just before the clock edge; hold time protects the moment just after it. Both exist for the same underlying physical reason — the flip-flop's internal sampling circuitry needs a clean, stable snapshot of the input around the edge — but they behave very differently as design constraints, and mixing up how to fix a violation of each is one of the most common conceptual errors students (and even working engineers) make early on.

Core Concept: The Stability Window After the Edge

Hold time (T_hold) is the minimum time that data must remain stable at a flip-flop's input after the active clock edge has occurred. Even though the clock edge is the instant the flip-flop "decides" what value to capture, the internal sampling circuitry needs a brief additional window afterward during which the input must not change, or the capture that is already in progress can be corrupted.

Formally: data must hold its value for at least T_hold after the active edge — t_stable_after_edge ≥ T_hold. If new data arrives at the input too soon after the edge (faster than T_hold allows), the flip-flop may end up capturing the new value instead of the intended old one, or land in an in-between metastable state exactly as with a setup violation.

• Hold time = minimum required stable window AFTER the active clock edge. • Constraint: t_stable_after ≥ T_hold. • Hold violations are most common on very short, fast paths — especially flip-flop-to-flip-flop with little or no combinational logic in between (for example, adjacent stages of a shift register).

Step-by-Step and Tricky Concept: Why Slowing the Clock Does NOT Fix a Hold Violation

This is the single most important distinguishing fact about hold time, and it is a favorite interview trap: a setup violation can always be fixed by lengthening the clock period (giving the combinational path more time to settle before the next edge), but a hold violation cannot be fixed that way at all. Hold time is checked relative to the same clock edge on both the sending and receiving flip-flop — it depends entirely on the relative path delay between them, not on the clock period. Slowing the clock down gives more room before the NEXT edge, but it does nothing to change how quickly new data can race through a very short combinational path right after the CURRENT edge.

Because of this, hold violations are fixed by a completely different technique: inserting deliberate delay (extra buffers, or otherwise lengthening the physical path) on the offending fast path so that new data cannot possibly arrive at the receiving flip-flop before T_hold has elapsed. This is a routine step performed automatically by place-and-route tools during physical design, specifically targeting paths that are dangerously short — most often direct flip-flop-to-flip-flop connections with no logic in between, such as adjacent bits of a shift register or bypass/pass-through paths.

Hold time notation and constraint

T_hold                                    // minimum required stable time AFTER the edge

Constraint: t_next_data_change >= t_edge + T_hold
Violated when new data arrives sooner than T_hold after the edge

Code Examples

The flip-flop requires D to remain stable for at least T_hold = 1 ns after the edge. Here, D changed only 0.3 ns after the edge — well short of the required 1 ns hold window. Because 0.3 ns < 1 ns, the hold requirement is violated: new data arrived too soon after the edge, before the previous capture was safely completed internally. Expected result: Hold requirement: NOT satisfied (violated by 0.7 ns)

Compare the post-edge stability duration (0.3 ns) against T_hold (1 ns): 0.3 ns < 1 ns → hold VIOLATED.

Given:
  T_hold = 1 ns
  D changes 0.3 ns AFTER the active clock edge

Question: Is the hold requirement satisfied?

Hold window after the active clock edge

Data must remain unchanged for at least T_hold after the active edge. Changing inside that window risks corrupting the capture already in progress.

clk    ______|‾|______________________
             ^ active edge
             |<-- T_hold -->|
D (OK)   ____|______stable_________|__ new value
                              ^ changes AFTER hold window -> SAFE

D (violation) ____|__X________________
                      ^ changes DURING hold window -> VIOLATION

Important Rules

Hold time is measured forward from the active clock edge: data must stay stable for at least T_hold after it.

Constraint: next data change time ≥ clock edge time + T_hold.

Unlike setup violations, hold violations CANNOT be fixed by slowing the clock — they depend on relative path delay, not clock period.

Hold violations are fixed by inserting extra delay (buffers) on the offending fast path, most often on very short flip-flop-to-flip-flop connections.

Hold-fixing buffers in place-and-route

During physical design (place-and-route), automated tools routinely insert small delay buffer cells onto paths flagged with hold violations — a very common and expected step, especially on short register-to-register connections like shift-register stages, bypass muxes, or clock-gating enable paths, where there is essentially zero combinational logic to naturally slow the signal down.

Trying to fix a reported hold-time violation by lowering the clock frequency (lengthening the clock period).

Fix hold violations by adding delay on the fast path itself (extra buffers, rerouting) — the clock period has no effect on hold margin because hold time is checked relative to the same edge on both ends of the path.

Setup checks compare a path's delay against the NEXT clock edge, so a longer period genuinely helps. Hold checks compare a path's delay against the SAME clock edge that launched the data, so changing the period between edges changes nothing about that relationship — the only fix is changing the path delay itself.

A design reports a hold-time violation on a very short flip-flop-to-flip-flop path. Which fix actually resolves it? A. Increase the clock period (slow down the clock) B. Add deliberate delay (buffers) onto that specific short path so new data can't arrive too soon after the edge C. Decrease the clock period (speed up the clock) D. Change the flip-flop's reset polarity

B. Add deliberate delay (buffers) onto that specific short path so new data can't arrive too soon after the edge — Hold time is checked relative to the same clock edge on both the sending and receiving flip-flop, so the clock period (which only affects the gap to the NEXT edge) is irrelevant to hold margin. The only real fix is adding delay directly on the fast path so new data cannot outrun the hold window.

Why are hold violations especially common on shift-register-style connections (adjacent flip-flops with no combinational logic between them)? A. Because shift registers always run at very high clock frequencies B. Because the path delay between the two flip-flops is extremely short, so new data can arrive at the receiving flip-flop almost immediately after the launching edge — too fast to satisfy T_hold C. Because shift registers don't use a clock at all D. Because flip-flops in shift registers have no setup time requirement

B. Because the path delay between the two flip-flops is extremely short, so new data can arrive at the receiving flip-flop almost immediately after the launching edge — too fast to satisfy T_hold — With no combinational logic to slow the signal down, data can propagate from one flip-flop's output to the very next flip-flop's input almost instantly — which is exactly the scenario hold time is meant to guard against, since the new value can arrive well inside the receiving flip-flop's required post-edge stability window.

A shift register has adjacent flip-flops connected directly, with only a tiny buffer delay of 0.2 ns between them. If the receiving flip-flop's T_hold is 0.5 ns, is the hold constraint satisfied? If not, roughly how much extra delay must be added to fix it?

0.2 ns < 0.5 ns, so the hold constraint is violated by 0.3 ns. At least 0.3 ns of additional delay must be inserted on that path (e.g., extra buffer cells) so the new data cannot arrive at the receiving flip-flop before the 0.5 ns hold window has elapsed.

Compare the actual path delay (0.2 ns) to T_hold (0.5 ns) directly — clock period is irrelevant to this check.