IntermediateQuestion 76 of 112Source: Synopsys PrimeTime User Guide: Clock Reconvergence Pessimism Removal

What is clock reconvergence pessimism, and why does removing it only affect the shared clock path?

From PDVerse STA Mentor Guide · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

Short Answer

Clock reconvergence pessimism is extra, unrealistic margin the tool adds when it assumes a launch clock path and a capture clock path vary in opposite directions, even over the portion of the clock tree they physically share. CRPR (clock reconvergence pessimism removal) corrects this only for the shared, common segment of the clock path, because that is the only part where both sides genuinely see the same physical variation at the same time.

Technical Reference DiagramWhat is clock reconvergence pessimism, and why does removing it only affect the shared clock path?
A clock tree trunk splitting into a launch branch and a capture branch, with the shared trunk segment labeled as the CRPR-corrected region and the two diverging branches labeled as still fully derated in opposite directions.

Technical Explanation

The pessimism exists because on-chip variation derating, by itself, does not know that two clock paths can share physical wires and cells.

  • Setup and hold derating assumes the launch and capture clock paths vary independently. Under on-chip variation mode, the tool applies late derating to one side and early derating to the other, as if they were two entirely separate clock trees.
  • But launch and capture paths often share a common trunk. From the clock source out to some branch point, both the launch flip-flop and the capture flip-flop are fed by the exact same buffers and wires, before the tree splits toward each flip-flop.
  • A shared segment cannot vary in two directions at once. The same physical buffer cannot be both 10% slower for the launch side's calculation and 10% faster for the capture side's calculation in real silicon — it is one piece of hardware with one actual delay.
  • CRPR removes exactly that contradiction, on the shared segment only. The tool identifies the common point where the launch and capture paths diverge, and removes the pessimism that came from derating the shared portion in two opposite directions.
  • Everything past the divergence point still gets full derating. Once the launch and capture paths take physically different routes, they genuinely can experience different variation, so no pessimism removal applies beyond the common point.
  • report_crpr (PT) shows exactly how much pessimism was removed for a given path, letting a designer see the common-path contribution separately from the diverging-path timing.

Common Mistake

The Trap: assuming CRPR removes all on-chip variation pessimism from a path's clock timing, rather than only the pessimism from the shared portion of the clock tree.

  • A designer sees CRPR recover slack on a path and assumes the clock-side margin is now fully accurate everywhere along both clock paths.
  • The diverging portions of the launch and capture clock paths still carry their full, legitimate derate margin, since those genuinely can vary independently — CRPR was never meant to touch that part.

Follow-up Question & Model Response

Two paths have the same total clock latency, but one shares 80% of its clock tree between launch and capture while the other shares only 20%. Would you expect CRPR to help them equally?

Candidate Model Response: No, I would expect CRPR to recover much more slack on the path with 80% shared clock tree, since CRPR only removes pessimism on the common segment, and there is simply more common segment to correct there. The path with only 20% shared tree has most of its clock path in the genuinely diverging section, where full derate pessimism still legitimately applies on both sides. Two paths with identical total clock latency can end up with very different effective margin after CRPR, purely because of how much of their clock delay comes from a shared trunk versus separate branches, so I would check report_crpr on each individually rather than assuming similar recovery.

Practical Example

Two setup paths in the same block both have 400ps of total clock latency. Path A shares 320ps of that latency on a common clock trunk before diverging to its launch and capture flip-flops; Path B shares only 80ps before diverging. report_crpr (PT) shows Path A recovering about 45ps of pessimism from its large shared segment, while Path B recovers only about 11ps, even though both paths started with identical total clock latency and the same derate factors applied on their diverging sections.

Complete STA Handbook

Get the complete 10-chapter STA handbook covering setup/hold margins, clock modeling, OCV/POCV, crosstalk noise, and PrimeTime closure.

Explore Complete STA Guide →
Static Timing Analysis (STA) Handbook — ten chaptersSTA HandbookTen chapters on setup, hold, OCV, and PrimeTime signoff. →

Continue practising

Related STA questions

ExpertWhat is the exact mechanism by which clock reconvergence pessimism removal (CRPR/CPPR) computes its credit?ExpertWalk through a full setup check including clock reconvergence pessimism (CRPR) — why does OCV derating create artificial pessimism on shared clock paths, and how is it removed?AdvancedExplain the interaction between POCV and clock reconvergence pessimism removal on a clock path - do they double-count?IntermediateWhy is on-chip variation derating only meaningful once clocks are propagated?