ExpertQuestion 54 of 69Source: Synopsys PrimeTime User Guide: CRPR Calculations for PLL Paths

Why does PrimeTime treat every output of a multi-output PLL as having the same phase when computing clock reconvergence pessimism removal, even though they don't share a physical common pin near the flops?

From PDVerse STA Mentor Guide · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

Short Answer

A PLL's multiple outputs are all locked to the same reference and, by construction, meant to stay in phase with each other, so PrimeTime models them as indistinguishable for CRPR purposes even though their last shared physical pin is deep inside the PLL, far from the launch and capture flops. Removing pessimism up to that reference point is essential, because treating the outputs as independently variable would invent skew between two clocks that the PLL's own design guarantees stay aligned.

PLL with two outputs OUTCLK1 and OUTCLK2 shown with report_crpr naming OUTCLK1 as the common pin (140ps removed) versus an unrelated clock pair sharing only a distant board-level buffer (12ps removed) — Technical Reference DiagramWhy does PrimeTime treat every output of a multi-output PLL as having the same phase when computing clock reconvergence pessimism removal, even though they don't share a physical common pin near the flops?

Technical Explanation

A PLL with more than one output — for example a primary clock output and a second, phase-related output for a different domain — is designed so all its outputs track the same internal reference and stay in a fixed phase relationship with each other.
For a path launched by one PLL output and captured by a different PLL output, the actual last common physical pin on the clock paths, if traced strictly by netlist connectivity, would be the PLL's own reference input pin — far upstream of either output.
PrimeTime instead treats the outputs as having the same phase for CRPR purposes, and removes clock reconvergence pessimism up to the PLL's outputs themselves, not just up to that distant reference pin.
This is necessary because the PLL's outputs are guaranteed in phase by the device itself; computing CRPR only up to the literal common pin would leave in a large amount of derate on the PLL's own internal delay difference between outputs — a value the PLL's phase-lock behavior makes physically meaningless to double-count.
report_crpr (PT) demonstrates this behavior directly: for a path between two different outputs of the same PLL, the report shows one of the PLL's own outputs, not the deep internal reference pin, as the common point used for the pessimism removal calculation.
This modeling choice only applies to outputs of the same PLL — outputs from two unrelated PLLs, or a PLL output paired with a directly-driven clock port, do not receive this treatment, because there is no guaranteed phase relationship to justify it.
What breaks: assuming this same-phase CRPR treatment applies to any two clocks that merely originate from a common ancestor, when in reality it is specific to a single PLL's own set of outputs — misapplying the assumption to unrelated clock sources would remove pessimism that is real and should be counted.

Common Mistake

The Trap: Assuming that any two clocks sharing an upstream ancestor somewhere in the clock tree automatically get the same generous CRPR treatment that PLL outputs receive from each other.

An engineer sees a comfortably-derated cross-domain path between two PLL outputs and generalizes the assumption to a different pair of clocks that merely share a distant, unrelated buffer stage upstream, expecting similarly generous CRPR credit.
That other pair of clocks gets ordinary CRPR treatment based on their real, literal common pin, which is often much closer to the flops and gives far less credit — the path is more pessimistic than the engineer assumed, and a real violation risk goes unchecked.

Follow-up Question & Model Response

"How do I confirm which common point PrimeTime actually used for a specific cross-PLL-output path, rather than assuming the phase-locked treatment applied?"

Candidate Model Response: Run report_crpr (PT) directly on the path in question, which names the exact common pin used and the pessimism value removed for that specific launch/capture pair. If the path is genuinely between two outputs of the same PLL, the report shows one of the PLL's outputs as the common point, confirming the phase-locked treatment is active. If instead the two clocks only share an unrelated upstream buffer, the report shows that buffer's actual output pin as the common point, with a correspondingly smaller pessimism-removal value — a difference worth checking explicitly rather than assuming from the clocks' names or origin.

Practical Example

A PLL with outputs OUTCLK1, feeding the core, and OUTCLK2, feeding a peripheral bus, drives a cross-domain synchronizer path. report_crpr on that path names OUTCLK1 itself as the common pin, even though the literal netlist path to a shared node runs back through the PLL's internal reference divider, and removes 140 ps of pessimism accordingly. A separate path between the core clock and an unrelated I/O clock sourced from a different oscillator, which merely shares a board-level reset buffer upstream, shows that buffer as its common pin with only 12 ps removed — the phase-locked PLL treatment does not extend to it.

Complete STA Handbook