Delays and slews all look slightly off across the whole design. Why might trip points be the culprit?
From PDVerse STA Mentor Guide, part of the pdVerse Mentor Guide
Short Answer
Trip points are the voltage thresholds where every delay and slew gets measured, so an unexpected threshold shifts every number in the design consistently. Confirm with report_delay_calculation -thresholds (PT) on a suspect arc, and report_lib (PT) to see which thresholds the library actually defines.
Technical Explanation
Trip points define where delay and slew are measured — the voltage thresholds marking the start and end of every timing arc and every signal transition.
- Why they behave like a global multiplier rather than a local bug: if the threshold in effect isn't the one you assumed, every delay and every slew in the design shifts, and it shifts consistently — exactly the symptom of everything looking slightly off, rather than one specific path looking wrong.
- Cause one, a library override: a library pin threshold can override the value the designer thought applied, because thresholds are resolved through a precedence order, and the winning source isn't always the one that was explicitly set.
- Cause two, an invalid threshold value: if the resolved threshold turns out invalid (0%/100%, say), the tool falls back to 5%/95% for slew, not the library's normal 20%/80% default, and if the designer was expecting the normal default, every slew in the design shifts accordingly.
- How to diagnose it directly rather than by guessing: run
report_delay_calculation -thresholds(PT) on one suspect arc — that shows the thresholds actually used for that specific delay computation, not the ones assumed from memory. - The follow-up check: run
report_lib(PT) on the library to see which thresholds it defines and where in the precedence order they sit, establishing both what's in effect and why before suspecting the parasitics or the library version instead. - The tell that points to trip points specifically: uniformity — a threshold problem moves every number in the design, so if only a handful of paths look wrong, the cause is somewhere else, not here.
Common Mistake
The Trap: chasing a parasitics or library-version explanation for a uniform, design-wide delay shift instead of checking thresholds first.
- A designer sees every reported delay creeping a few percent off from a prior run and starts re-checking the SPEF extraction or the library rev, assuming the cause is data quality.
- The real cause is a swapped-in library whose pin-level threshold definitions differ slightly from the previous one, something
report_delay_calculation -thresholdswould have surfaced in minutes, while the parasitics investigation burns hours chasing a correct dataset.
Follow-up Question & Model Response
If report_lib shows two different libraries in the design define different threshold pairs, which one wins on a given arc, and how would you tell?
Candidate Model Response: The threshold that applies is resolved per pin or per cell through the tool's precedence order, so a mixed-library design can genuinely have different thresholds in effect on different arcs, not just one global setting. Running report_delay_calculation -thresholds on a specific arc in each of the two library's cells directly shows the winning value for that instance, rather than assuming the whole design shares one number. In a design with mismatched threshold definitions across libraries, comparing delays between cells from each library without first confirming their thresholds match can lead to comparing numbers measured on different scales.
Practical Example
A block re-timed after a library update shows every reported delay about 6% higher than the previous run, uniformly across hundreds of paths. report_delay_calculation -thresholds -from reg1/CK -to reg1/D (PT) on one suspect arc reveals the active thresholds are now 10%/90% instead of the expected 20%/80%. report_lib on the new library confirms its cells define 10%/90% at the pin level, overriding the operating-condition-level 20%/80% the team had assumed still applied, explaining the uniform shift without touching a single parasitic value.
Complete STA Handbook
Master Signoff-Ready Static Timing Analysis
Get the complete 10-chapter STA handbook covering setup/hold margins, clock modeling, OCV/POCV, crosstalk noise, and PrimeTime closure.
Offline PDF Bundle
Want all 1109 questions offline?
Get the complete 4-book PDF bundle (PnR, STA, MMMC, Low Power) with a clickable table of contents - no ads, no internet needed.
Continue practising