Clock Tree Synthesis
& Clock Skew

Why the Clock Needs a Tree

In RTL simulation, a clock signal arrives simultaneously at every flip-flop. In silicon, it does not. A single wire from the PLL output to a million flip-flops would have an enormous fanout — the driving cell would need to charge the combined input capacitance of every FF simultaneously. That drive current would be enormous, the wire resistance would cause huge RC delay, and the signal would arrive wildly late and with a degraded slew rate.

Clock Tree Synthesis solves this by inserting a balanced tree of buffers and inverters between the clock source and the flip-flops. Each buffer drives only a small number of downstream loads, the tree branches progressively, and the total delay from source to every leaf is made as equal as possible.

Clock Tree Topologies

Different designs use different physical structures for the clock tree, each with trade-offs in skew, power, and routability.

Clock Skew — Definition and Types

Clock skew is the difference in clock arrival time between the launch flip-flop and the capture flip-flop on a timing path. It arises from differences in buffer delays, wire lengths, and RC parasitics through the clock tree branches connecting source to each leaf.

Clock Insertion Delay (Clock Latency)

Clock insertion delay is the total propagation time from the clock source to a flip-flop's clock pin, measured through the PLL, clock network, and buffer tree. It has two components that STA treats separately.

# SDC: specify clock latency before CTS
set_clock_latency -source 0.5 [get_clocks CLK]   ;# source: PLL to port
set_clock_latency 1.2 [get_clocks CLK]            ;# network: estimated tree delay

# After CTS: use propagated clocks (actual network delay from extraction)
set_propagated_clocks [all_clocks]

CTS Goals, Constraints, and Flow

Before running CTS, the designer specifies a set of targets that the tool must meet. These are set as CTS constraints in the tool's configuration or in the SDC.

The CTS flow runs in these steps:

1. Clock tree specification
   └── Define: clock roots, exceptions (don't-touch cells, clock gating),
               skew targets, slew targets, buffer/inverter cell list

2. Virtual tree construction
   └── Tool builds a virtual balanced tree ignoring physical layout

3. Physical tree construction
   └── Cells are placed, wires are routed (in-CTS routing)
   └── Buffer sizes are chosen to match delays across branches

4. Clock tree optimization (CTO)
   └── Iterative fixing of skew hotspots, slew violations,
       max-fanout violations

5. Post-CTS timing analysis
   └── STA with propagated clocks (actual annotated delays)
   └── Fix remaining setup/hold violations from skew imbalance

6. Incremental CTS for ECO
   └── Fix specific skew issues without re-running full CTS

Clock Gating Cells in the Clock Tree

Clock gating is the most effective technique for reducing dynamic power in VLSI chips — by stopping the clock to idle registers, switching activity drops to near zero for those flip-flops. However, inserting clock gates into the clock tree has direct implications for CTS and timing.

// RTL clock gating — synthesized into ICG cell
always_ff @(posedge clk) begin
  if (en) data_reg <= data_in;   // synthesis tool infers ICG
end

// Or explicit ICG instantiation in RTL
ICGX1 u_icg (.CLK(clk), .EN(enable), .SE(scan_en), .GCLK(gated_clk));

// Downstream FFs use gated_clk — they stop switching when enable = 0

During scan test mode, the SE (Scan Enable) pin of the ICG forces the gate open so the scan clock can propagate to all FFs — critical for structural DFT test coverage.

Useful Skew — Intentional Timing Slack

Useful skew is the deliberate introduction of unequal clock arrival times to improve timing margins on specific critical paths. Instead of targeting zero skew everywhere, the CTS tool or timing engineer intentionally delays the capture clock on a setup-critical path — effectively giving data more time to travel through the combinational logic.

How Skew Appears in STA Reports

After CTS, every timing path report from tools like PrimeTime includes the clock arrival times for both the launch and capture flip-flops. The skew is visible as the difference between these two numbers.

  Timing Path Report — Setup Check
  ─────────────────────────────────────────────────────────
  Path:  FF_A/Q  →  [comb logic]  →  FF_B/D

  Data path:
    FF_A clock-to-Q               0.18 ns
    Combinational delay           0.62 ns
    FF_B setup time               0.05 ns
    ──────────────────────────────────────
    Data required arrival         0.85 ns

  Clock path:
    Clock source (PLL out)        0.00 ns
    Buffer BUF1                   0.15 ns
    Buffer BUF2 (launch, FF_A)    0.38 ns   ← launch latency
    Buffer BUF3 (capture, FF_B)   0.46 ns   ← capture latency

    Clock period                  1.00 ns
    Capture edge                  1.46 ns   (1.00 + 0.46)

    Skew = 0.46 − 0.38 = +0.08 ns (positive — helps setup)

  Setup slack = 1.46 − 0.85 = +0.61 ns  ✓ PASS

Common CTS Problems and Fixes

Frequently Asked Questions

Explore Further