Walk through how PrimeTime performs a full timing update internally, from reading data to computing slack.
From PDVerse PrimeTime STA Interview Guide · pdVerse Mentor Guide
Ten-second Interview Answer
It builds the timing graph after link_design, propagates the defined clocks to every register clock pin, calculates arc delays with slew propagation, propagates arrivals forward and required times backward while honoring exceptions, then subtracts them to get slack.
Complete Technical Explanation
A full timing update runs as a sequence of conceptual stages. First the design graph: after link_design the linked netlist becomes a graph of cells and nets, from which PrimeTime builds a timing graph whose nodes are pins and whose edges are timing arcs -cell arcs from the library, net arcs from the parasitics. Second, clock propagation: the defined clocks from create_clock and the generated clocks are propagated through the clock network to every register clock pin, establishing each register's clock, its edges and its latency, source plus network; case analysis and clock gating prune that propagation. Third, delay calculation: each timing arc gets a delay -cell arcs from library tables interpolated on input slew and output load, where load is parasitic plus pin capacitance, net arcs from the parasitics or the wire-load model - with slew propagated so each stage's output slew feeds the next stage's input slew, and with crosstalk delta delays computed iteratively when SI is enabled. Fourth, forward propagation: arrival times accumulate from all startpoints, keeping both max, latest, and min, earliest. Fifth, backward propagation: required times propagate back from all endpoints, built on capture clock edges and setup or hold requirements, honoring exceptions - false paths pruned, multicycle paths shifting the capture edge. Sixth, slack at each pin: required minus arrival for setup, arrival minus required for hold. Finally reporting, where path-based reports trace the worst paths.
In Pd / Signoff
Knowing the order explains runtime and error behaviour that otherwise looks arbitrary: constraints that arrive after the clocks are propagated, or parasitics read after delay calculation, force stages to be redone, and an SI-enabled run costs more because delta delays iterate. It also tells you which stage a complaint comes from - a missing clock is a propagation-stage problem, not a reporting one.
Common Trap
Assuming the order of the stages is cosmetic and constraints can be applied in any sequence. Clock propagation has to precede arrival propagation, because launch edge time and latency anchor the arrival computation and capture edge and latency anchor the required time - without it the tool has nothing to compute from.
Expect Next
Why must clocks be propagated before arrival times are computed?
Topic And Primetime Commands
STA Fundamentals / Slack & Arrival. link_design, create_clockKeep 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