Walk through how PrimeTime performs a full timing update internally, from reading data to computing slack.
From PDVerse STA Mentor Guide, part of the pdVerse Mentor Guide
Short Answer
It builds a timing graph after link_design, propagates the defined clocks to every register's clock pin, calculates each arc's delay with slew propagated stage to stage, propagates arrival times forward and required times backward while honoring exceptions, then subtracts the two to get slack at every point.
Technical Explanation
- Stage 1: build the design graph. After
link_design(PT) resolves the netlist into cells and nets, PrimeTime builds a timing graph on top of it - nodes are pins, edges are timing arcs: cell arcs from the library, net arcs from the parasitics. - Stage 2: propagate the clocks. The clocks defined with
create_clock(SDC), plus any generated clocks, are propagated through the clock network to every register's clock pin, establishing each register's clock edges and its latency (source plus network). Case analysis and clock gating prune this propagation where a branch is structurally disabled. - Stage 3: calculate delay, stage by stage. Every timing arc gets a delay - cell arcs from library tables interpolated on input slew and output load (load being parasitic capacitance plus pin capacitance), net arcs from the read parasitics or a wire-load model. Slew (the signal's rise/fall transition time) propagates forward, so each stage's output slew becomes the next stage's input slew; crosstalk delta delays are computed iteratively when signal-integrity (SI) analysis is enabled.
- Stage 4: propagate arrival times forward. Arrival times accumulate outward from every startpoint, keeping both the maximum (latest) and minimum (earliest) values, since setup and hold need opposite extremes.
- Stage 5: propagate required times backward. Required times propagate back from every endpoint, built on the capture clock's edges and the setup or hold requirement, honoring exceptions along the way - false paths pruned entirely, multicycle paths shifting which capture edge applies.
- Stage 6: compute slack, and report. At each pin, slack is required time minus arrival time for setup, or arrival time minus required time for hold. Path-based reports then trace the worst paths for a human-readable view.
Common Mistake
- Assuming a full update recomputes only the paths a script touches, when in fact a genuinely full update walks the whole graph - clocks, delay, arrival, and required time - regardless of what changed.
- Treating slew propagation as a per-arc detail with no wider consequence, when in fact an inaccurate slew at one stage compounds into every downstream stage's delay calculation.
- Cost: misjudging why a small SDC edit anywhere in the clock network triggers a full recomputation instead of a fast, localized one, leading to underestimated runtime planning.
Follow-up Question & Model Response
Why does changing a clock definition force PrimeTime to redo more of this pipeline than changing a single cell's drive strength does?
Candidate Model Response: A clock definition change invalidates stage 2, clock propagation, which every register's arrival and required time downstream depends on, so the tool has to redo clock propagation, delay calculation on any arc whose slew depends on the new clock edges, and both forward and backward propagation across the whole domain. A single cell's drive-strength change only affects the delay calculation of the arcs directly touching that cell and the slew it hands to its immediate fanout, so the recomputation stays local to that cell's neighborhood in the graph. The scope of what stage 2 feeds into is simply much larger than what one cell's stage 3 delay feeds into.
Practical Example
On a design with 40,000 registers across four clock domains, editing the period on one create_clock forces PrimeTime to re-propagate that domain's clock tree, recompute every arrival and required time downstream of it, and re-derive slack for roughly 9,000 endpoints - a full-domain update taking several minutes. Resizing a single buffer cell on one data path instead only recomputes that cell's own delay and the delay of its two or three immediate fanout arcs, updating perhaps a dozen downstream slack values in a fraction of a second, because nothing in stages 1 or 2 changed.
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