Why Hold Time Does Not Depend on Clock Frequency

Why hold time does not depend on clock frequency: the same-edge derivation, a waveform, worked numbers, and an OpenSTA run on SKY130 that proves it.

By BitForBytes Editorial & Hardware Research Team, Official BitForBytes Hardware Publication · 2026-10-07 · 11 min read

⚡ Quick Summary

Hold time is the minimum time a flip-flop's data input must stay stable after the active clock edge. The hold check compares data launched and captured by the same clock edge, so the clock period drops out: Tcq,min + Tcomb,min must be at least Thold + Tskew. Slowing the clock cannot fix a hold violation; adding data-path delay can.

1. Introduction & Core Motivation

A chip comes back from the fab and fails. If the cause is a setup violation, the team can still ship it: lower the clock frequency, sell it as a slower grade, and fix the path in the next revision. If the cause is a hold violation on a same-clock path, the chip fails at 1 GHz, at 1 MHz and at 1 Hz. No frequency setting rescues it. That asymmetry is why physical-design teams close hold timing at every corner before tapeout.

Most textbooks state the result in one line: "hold is independent of frequency". Students memorise it, then freeze when an interviewer asks why, or asks for the case where it stops being true. The naive mental model, "a slower clock gives everything more time", is right for setup and wrong for hold, because the two checks look at different pairs of clock edges.

This question appears in AKTU and GATE digital-electronics papers as a short derivation and is a standard first-round question for RTL and physical-design roles. After reading, you will be able to derive the hold inequality from the edges involved, compute hold slack with skew, and reproduce the proof yourself with OpenSTA on the SkyWater SKY130 library.

2. Detailed Technical Breakdown

Which Clock Edges Do the Setup and Hold Checks Compare?

The setup check compares a launch edge with the next capture edge, one period later; the hold check compares a launch edge with the capture flop's sampling of that same edge. Take two flip-flops, FF1 feeding FF2 through combinational logic, on one clock.

At edge 0, FF1 launches new data D1. At that same edge 0, FF2 is busy capturing the previous data D0, and needs D0 to stay stable at its D pin for the hold time after the edge. The danger is that D1 races through the logic and overwrites D0 before FF2 has finished capturing it. Both events, the launch of D1 and the capture of D0, are triggered by the same physical clock edge. The time between edge 0 and edge 1 is irrelevant to that race.

               edge 0                        edge 1
                 |<----------- Tclk ---------->|
 CLK      _______/------\______________________/------\____

 FF1.Q    == D0 ==X============ D1 =========================
                  ^ D1 appears Tcq after edge 0

 FF2.D    == D0 =====X========= D1 =========================
                     ^ D1 arrives Tcq + Tcomb after edge 0

 SETUP: D1 must arrive before (edge 1 - Tsetup)   -> uses Tclk
 HOLD : D1 must not arrive before (edge 0 + Thold) -> no Tclk
        because FF2 is still capturing D0 at edge 0

Stretching the clock moves edge 1 to the right. It gives D1 more time to arrive for setup. It does nothing to the gap between edge 0 and the arrival of D1 at FF2, which is the only gap the hold check measures.

How Is the Hold Inequality Derived?

The hold inequality comes from requiring the earliest new data to arrive after the capture flop's hold window closes. Measure every time from the launch clock edge at FF1.

The earliest arrival of new data at FF2's D pin is Tclk→q,min + Tcomb,min. The capture clock edge reaches FF2 at time Tskew, where Tskew = t_capture_clk - t_launch_clk (positive when the capture clock arrives later). FF2's hold window therefore ends at Tskew + Thold. The new data must not arrive before that:

Tclk→q,min + Tcomb,min  >=  Thold + Tskew

where Tclk→q,min is the minimum clock-to-Q delay of the launch flop, Tcomb,min is the shortest combinational path delay, Thold is the hold requirement of the capture flop, and Tskew is the clock skew, all in ns. Tclk does not appear. Compare the setup check for the same path:

Tclk  >=  Tclk→q,max + Tcomb,max + Tsetup - Tskew + Tjitter

Hold slack is arrival minus required: (Tclk→q,min + Tcomb,min) - (Thold + Tskew).

Worked example. Let Tclk→q,min = 0.20 ns, Tcomb,min = 0.10 ns, Thold = 0.15 ns and Tskew = +0.25 ns. Arrival is 0.20 + 0.10 = 0.30 ns. Required is 0.15 + 0.25 = 0.40 ns. Hold slack is 0.30 - 0.40 = -0.10 ns, a violation. Run the same numbers at 100 MHz or at 1 kHz and the slack is still -0.10 ns, because the period was never used. Inserting a delay buffer of at least 0.10 ns on the data path brings the slack to zero.

Can You Prove It With a Real Tool?

Yes: synthesise two back-to-back flip-flops and run OpenSTA at two clock periods; the hold slack does not move. The RTL below is the worst case for hold, a bare wire between two flops.

`default_nettype none
// shift2: two flip-flops back to back, no logic between them.
// Reset: none (kept minimal so the Q-to-D path is a bare wire).
// Latency: 2 clock cycles.
module shift2 (
    input  wire clk,
    input  wire d_in,
    output wire d_out
);
    reg ff1_q;
    reg ff2_q;

    always @(posedge clk) begin
        ff1_q <= d_in;    // launch flop
        ff2_q <= ff1_q;   // capture flop: shortest possible data path
    end

    assign d_out = ff2_q;
endmodule
`default_nettype wire

This infers exactly two D flip-flops and no combinational logic; Yosys 0.33 maps both to sky130_fd_sc_hd__dfxtp_1. There is no latch because both registers are assigned on every clock edge.

Map it to SKY130 and time it. The Liberty file sky130hd_tt.lib ships in the OpenSTA repository's examples folder.

yosys -p "read_verilog shift2.v; synth -top shift2; \
  dfflibmap -liberty sky130hd_tt.lib; \
  abc -liberty sky130hd_tt.lib; opt_clean -purge; \
  write_verilog -noattr shift2_netlist.v"
sta -no_init -exit hold_demo.tcl

# hold_demo.tcl - run once with -period 10.0 and once with 1.0
read_liberty sky130hd_tt.lib
read_verilog shift2_netlist.v
link_design shift2
create_clock -name clk -period 10.0 [get_ports clk]

# Optional: make the capture clock 0.40 ns late (positive skew).
# _1_ is the capture flop's instance name in the Yosys netlist.
# set_clock_latency 0.40 [get_pins _1_/CLK]

report_worst_slack -max   ;# setup
report_worst_slack -min   ;# hold

Results from OpenSTA 3.1.0, typical corner:

Setup slack drops by exactly 9.00 ns when the period drops by 9.00 ns. Hold slack is identical in both rows of each pair. Adding 0.40 ns of positive skew improves setup by 0.40 ns and pushes hold into violation at both frequencies. The hold report for the skewed case shows why:

   0.00    0.00   clock clk (rise edge)
   0.00    0.00   clock network delay (ideal)
   0.00    0.00 ^ _0_/CLK (sky130_fd_sc_hd__dfxtp_1)
   0.27    0.27 ^ _0_/Q (sky130_fd_sc_hd__dfxtp_1)
   0.00    0.27 ^ _1_/D (sky130_fd_sc_hd__dfxtp_1)
           0.27   data arrival time

   0.00    0.00   clock clk (rise edge)
   0.40    0.40   clock network delay (ideal)
   0.00    0.40   clock reconvergence pessimism
           0.40 ^ _1_/CLK (sky130_fd_sc_hd__dfxtp_1)
  -0.03    0.37   library hold time
           0.37   data required time
---------------------------------------------------------
           0.37   data required time
          -0.27   data arrival time
---------------------------------------------------------
          -0.09   slack (VIOLATED)

Both the launch line and the capture line start at "clock clk (rise edge)" time 0.00. The tool is comparing the same edge with itself, which is the whole argument in one report. The printed -0.09 is rounding: each line is rounded from the tool's internal values, and 0.27 - 0.37 is -0.10 on paper.

Setup vs Hold: What Is the Difference?

Setup is a maximum-delay check against the next clock edge, and hold is a minimum-delay check against the same edge.

How Do You Fix a Hold Violation?

You fix a hold violation by increasing the minimum data-path delay or by reducing the skew, never by touching the clock period. Place-and-route tools such as OpenROAD, Cadence Innovus and Synopsys IC Compiler II do this automatically after clock tree synthesis by inserting delay cells or buffers on the short path.

Hold fixing happens after clock tree synthesis for a reason: before the tree exists, clocks are ideal and the real skew is unknown. Each inserted buffer adds area and power, and it also adds delay to any setup path that shares those cells, so tools fix setup first and then pad only the paths with positive setup slack to spare.

3. Practical Takeaways for Students

• Exam angle: Write both inequalities side by side, underline that Tclk is absent from the hold check, and draw the two-flop waveform with edge 0 marked for both launch and capture. A numerical with skew, like the worked example above, is the usual 5-mark follow-up.
• Interview angle: "A fabricated chip has a hold violation. Will it work at a lower frequency?" No, for a same-edge path. "Which do you fix first, setup or hold?" Setup, because hold fixes add delay that can break setup, and hold is only meaningful after clock tree synthesis.
• Common mistake: Using maximum delays in the hold equation. Hold uses the shortest path and the fastest corner. A path with 20 levels of logic can still fail hold if one branch of it is a direct wire.
• Try it yourself: Reproduce the table above with Yosys and OpenSTA, then change the latency from 0.40 to 0.30 and predict the slack before you run it. Check the shift2 RTL in the BitForBytes Verilog Judge first.

4. Frequently Asked Questions

Can a hold violation be fixed by reducing the clock frequency?

No, not for a path launched and captured on the same clock edge. The hold inequality contains clock-to-Q delay, minimum logic delay, hold time and skew, but not the clock period, so changing frequency changes nothing. The fix is more delay on the data path or less skew between the two clock pins.

This is why hold is treated as a functional failure and setup as a performance limit. A setup-limited chip can be sold at a lower speed grade; a hold-failing chip cannot be recovered in the field.

Is hold time ever dependent on the clock period?

Yes, in two special cases. On a half-cycle path, where data is launched on a rising edge and captured on a falling edge, the hold check is made against the capture edge half a period earlier, so half the period appears as extra hold margin. Multicycle path constraints also move the hold edge by whole periods.

For the ordinary single-clock, same-edge path that interviewers mean, the statement holds without exception. Mentioning the half-cycle case after giving the standard answer shows you understand where the rule comes from.

Why is the library hold time negative in some timing reports?

A negative hold time means the flip-flop tolerates its data input changing slightly before the clock edge. Inside the cell, the clock passes through internal buffers before it reaches the latching element, so the real sampling instant is later than the edge at the CLK pin, while data has its own internal delay.

In the SKY130 run above, the typical-corner hold time of dfxtp_1 was reported as -0.03 ns. A negative value makes the hold check easier to meet; it does not remove the check.

Which is more dangerous, a setup violation or a hold violation?

A hold violation is more dangerous in silicon because it cannot be removed by slowing the clock, so the affected chip is dead at every frequency. A setup violation limits the maximum operating frequency but leaves the chip functional below that limit.

During design, both must reach non-negative slack at every sign-off corner. Setup is usually harder to close, since it needs logic restructuring, while hold is usually easier to close but costlier to miss.

5. References & Further Reading

• J. Bhasker and R. Chadha, "Static Timing Analysis for Nanometer Designs: A Practical Approach", Springer, 2009.
• N. H. E. Weste and D. M. Harris, "CMOS VLSI Design: A Circuits and Systems Perspective", 4th edition, chapter on sequential circuit design.
• OpenSTA, Parallax Software, github.com/parallaxsw/OpenSTA (source, documentation and the examples/sky130hd_tt.lib.gz Liberty file).
• SkyWater SKY130 open-source PDK, sky130_fd_sc_hd standard-cell library.