ExpertQuestion 23 of 69

Walk through how trip points, slew, and the RC-011 extrapolation limit chain together into a single accuracy failure mode.

From PDVerse STA Mentor Guide, part of the pdVerse Mentor Guide

By Tabish Iqbal, who has 9+ years of VLSI Physical Design experience

Short Answer

Trip points (the waveform thresholds the library defines for measuring a signal's timing) set where slew gets measured. A wrong or unexpected trip point corrupts that slew value, which then indexes the driver's delay tables out of range — the tool has to extrapolate, PrimeTime's RC-011 warning, and extrapolation both loses accuracy and hands the next stage an inflated slew, feeding the same problem forward.

Cascading RC-011 extrapolation: a trip-point mismatch inflates measured slew past a 180 ps library index, triggering extrapolation whose output slew feeds the next stage's lookup — Technical Reference DiagramWalk through how trip points, slew, and the RC-011 extrapolation limit chain together into a single accuracy failure mode.

Technical Reference DiagramWalk through how trip points, slew, and the RC-011 extrapolation limit chain together into a single accuracy failure mode.

Technical Explanation

This is a chain, and each link makes the next one worse rather than just repeating the same error.

Trip points define the measurement, not just a display setting. PrimeTime measures slew and delay against thresholds set in the Liberty (LIB) library — pin-level thresholds first, then library-level thresholds, then the first library on the link path, falling back to 20/80 percent for slew and 50 percent for delay if none are defined. A mismatched threshold means the measured slew is wrong before delay calculation ever uses it.
That slew becomes a table index. Delay calculation looks up the driving cell's characterized delay and output-slew tables using the measured input slew and output load. A slightly-off slew can land outside the range the library was characterized over.
Out-of-range lookups trigger RC-011. PrimeTime's RC-011 message fires when a slew or load falls outside the library's minimum or maximum index — the tool clips and extrapolates, by default 10 percent above the maximum index and 80 percent below the minimum, or further with rc_ccs_extrapolation_range_compatibility (PT) set false, which trades fewer warnings for less accurate data.
Extrapolation degrades the very quantity that started the problem. Extrapolated delay is less accurate by construction, and it also produces an output slew carrying the same distortion.
That inflated slew feeds the next stage's lookup. The next gate receives this inaccurate slew as its own input, pushing its own lookup further out of range and producing another RC-011 on a later stage.
Why it is dangerous: the failure is invisible stage by stage — no single delay number looks obviously wrong, and the damage accumulates as the distorted slew propagates.
Breaking the chain: confirm the trip points in use with report_delay_calculation -thresholds (PT), then fix the underlying max_transition design rule violations that report_constraint (PT) reports, since the guide ties RC-011 directly to those unresolved DRCs rather than only widening the extrapolation range.

Common Mistake

The Trap: silencing RC-011 by setting rc_ccs_extrapolation_range_compatibility (PT) false and moving on, treating a wider extrapolation clip as a fix rather than a wider blind spot.

Widening the clip reduces the message count but does not restore characterized data — the delay is still extrapolated, just without the warning telling you so.
On a library that follows the guide's design-rule-constraint guidelines, the correct fix is closing the max_transition/max_capacitance violations report_constraint (PT) reports, not raising the extrapolation ceiling.

Follow-up Question & Model Response

"Two adjacent stages both show RC-011. Which one do you fix first, and why?"

Candidate Model Response: Fix the earlier stage in the path first. The chain runs forward — an out-of-range slew at stage one produces an inaccurate output slew that becomes stage two's input, so stage two's RC-011 may simply be an inherited symptom rather than an independent library gap. I would re-run report_delay_calculation (PT) after fixing stage one's max_transition violation and check whether stage two's warning disappears on its own before spending effort characterizing or re-buffering it separately.

Practical Example

A buffer on a 1.2 ns setup-critical path drives a load whose fanout was recently increased during an ECO. The library's inverter table for that cell is characterized up to a 180 ps input slew; the ECO pushes the measured input slew to 210 ps because an upstream trip-point mismatch already inflated it by 15 ps. report_delay_calculation -thresholds (PT) confirms the trip points are correct at the input, so the 210 ps is real — but it is still 30 ps beyond the table's maximum index, and PrimeTime issues RC-011 and extrapolates. The extrapolated delay comes in 6 ps higher than a re-characterized value would show, and the buffer's own output slew rises to 165 ps, which is what the next stage's driver sees. report_constraint -all_violators (PT) confirms the real fix: the ECO's added fanout is a max_transition violation on the buffer's output net, and inserting one repeater brings the input slew for the whole downstream chain back inside the characterized range.

Complete STA Handbook