Delays and slews all look slightly off across the whole design. Why might trip points be the culprit?
From PDVerse PrimeTime STA Interview Guide · pdVerse Mentor Guide
Ten-second Interview Answer
Trip points are the measurement thresholds for every delay and slew, so an unexpected threshold shifts every number in the design consistently. Confirm with report_delay_calculation -thresholds on a suspect arc and report_lib to see which thresholds are actually in effect.
Complete Technical Explanation
Trip points are where delay and slew are measured - the voltage thresholds that define the start and end of every arc and every transition. That makes them a global multiplier on your results rather than a local effect. If the threshold in force is not the one you assumed, then every delay and every slew in the design moves, and it moves consistently, which is exactly the symptom of everything looking slightly off rather than one path looking wrong. Two common causes fit that pattern. A library pin threshold may be overriding the value you thought applied, since thresholds come from a precedence order and the winning source is not always the one you set. Or a threshold value may be invalid, which forces the fallback to 5/95 - and if you were expecting something else, all your slews shift. Diagnose it directly rather than by inference. Run report_delay_calculation -thresholds on a suspect arc: that shows you the thresholds actually used for that specific delay computation. Then run report_lib on the library to see which thresholds the library defines and where in the precedence order they come from. Between the two you can establish both what is in effect and why, which is the information you need before you start suspecting the parasitics or the library version. The tell for this class of problem is uniformity: a threshold problem moves everything, so if only a handful of paths look wrong, look elsewhere.
In Pd / Signoff
You reach for this when correlating PrimeTime against a golden signoff run or a SPICE spot-check and everything is off by a small consistent percentage. Run report_delay_calculation -thresholds on one arc in each tool setup and diff the thresholds before you diff anything else - it is a five-minute check that either explains the whole delta or rules out a whole class of causes.
Common Trap
Chasing a uniform delay or slew offset in the parasitics, library version or derating before checking thresholds. Trip points move every number in the design together, so a consistent global shift points at the measurement thresholds - and a library pin threshold overriding your assumption produces exactly that signature with no warning.
Expect Next
What threshold does PrimeTime fall back to when a specified trip-point value is invalid?
Topic And Primetime Commands
Delay Calculation / Slew & Transition. report_delay_calculation, report_lib
Keep building interview depth
Continue practising STA
Continue learning free
Get a practical low-power chapter
Receive the existing “Low Power and Multivoltage Fundamentals” PDF chapter and its download link by email.
Continue practising