How do you calibrate and correlate pre-CTS placement timing with signoff PrimeTime STA?

Short Answer

This is the classic "tool divergence" tapeout risk: your implementation tool (ICC2/Innovus) reports clean, comfortable slack pre-CTS, and then signoff PrimeTime — often run with different assumptions — reports massive negative slack on the same paths. Closing that gap is what correlation work is about. Align the SDC first, always. Both environments need identical clock definitions, generated clocks, multicycle paths, and case analysis — literally run check_timing in PrimeTime and confirm it matches what the implementation tool has active. A single missing generated-clock relationship or mismatched case-analysis setting can produce a huge, misleading divergence that has nothing to do with the physical implementation at all.

Technical Explanation

• This is the classic "tool divergence" tapeout risk: your implementation tool (ICC2/Innovus) reports clean, comfortable slack pre-CTS, and then signoff PrimeTime — often run with different assumptions — reports massive negative slack on the same paths. Closing that gap is what correlation work is about.
• Align the SDC first, always. Both environments need identical clock definitions, generated clocks, multicycle paths, and case analysis — literally run check_timing in PrimeTime and confirm it matches what the implementation tool has active. A single missing generated-clock relationship or mismatched case-analysis setting can produce a huge, misleading divergence that has nothing to do with the physical implementation at all.
• Match the RC extraction models. Pre-CTS, the implementation tool estimates interconnect with virtual Steiner-tree wire models pulled from TLUPlus/Quantus technology tables — but if those layer mappings don't match what signoff extraction (StarRC/Quantus) actually uses, you're comparing timing computed against two different physical assumptions about wire resistance/capacitance, and no amount of placement optimization will close that gap.
• Match the derating. If signoff PrimeTime applies Advanced OCV (AOCV) or POCV (LVF, typically ±3σ) derating, the implementation tool's sizing/optimization needs to be configured with the same POCV tables during place_opt — otherwise the placer is optimizing cell sizes against a different (usually more optimistic) margin than what signoff will actually check against.
• Get the clock uncertainty budget right — this one trips people up. Pre-CTS, set_clock_uncertainty needs to cover both clock jitter AND the skew you expect once a real clock tree exists (e.g., 50ps jitter + 100ps expected post-CTS skew = 150ps total pre-CTS uncertainty). Once CTS actually runs and clocks propagate, the skew component of that uncertainty gets removed, since real measured skew now exists — leaving it in post-CTS double-counts the same effect.
• Think of correlation work as closing four separate gaps at once (constraints, extraction, derating, uncertainty budgeting) — fixing only one of the four still leaves you exposed to a nasty pre-CTS-to-signoff surprise late in the flow.

Follow-up Question & Model Response

"What is the acceptable pre-CTS correlation delta between ICC2 and PrimeTime?"

Candidate Model Response: Path delay correlation should be within 3% to 5% on virtual Steiner routes, with zero endpoint classification divergence.