Static Timing Analysis (STA) & PrimeTime Mentor Guide, 339 questions
Master Static Timing Analysis (STA) and PrimeTime interview reasoning through 339 source-grounded answers covering timing foundations, tool workflows, real debugging, and signoff closure.
Want all 1109 answers offline as 4 PDF books?
See the 4-book bundle · ₹349Complete STA HandbookComplete library25 TRICKY STA QUESTIONS
The advanced and expert questions most likely to trip up an otherwise well-prepared candidate, with full answers right on this page.
A DVFS scenario (one voltage/frequency operating point in a design that switches between several) can reach a command two ways: typed on the command as `-sms_scenarios` (PT), or inherited from a `push_sms_scenario` (PT) context around it. The explicit option always wins, and the pushed context is ignored for that command, not merged with it.
The command lists cells with no POCV (parametric on-chip variation, a statistical way of modeling how much a cell's delay can vary) coefficient or distance data - cells that quietly fall back to zero variation. Any path through one of them has under-modeled spread, so its reported corner is optimistic and can hide a real violation.
Annotated delays win by precedence, not by which one was applied last. `set_annotated_delay` (PT) sits at tier 1 and SPEF-derived parasitics sit at tier 3, so on any arc where both apply, PrimeTime uses the annotated value and ignores the SPEF-derived delay for that arc.
Correlation is a physical claim, not a convenience setting. A per-cell IR-drop annotation (a local voltage droop measured at one instance's supply pin) describes an independent local event, so PrimeTime compares the full worst-case voltage difference across it instead of assuming the driver and load move together.
Multi-input switching (MIS) is a delay adjustment applied when two or more inputs of a gate switch close together in time. On a 2-input NAND, both inputs falling together speeds up the rising output, which shortens the data path's minimum delay - the exact quantity a hold check uses - so MIS is scoped to hold, not setup.
PrimeTime propagates a defined clock waveform through the network to find each register's latency - source latency plus network latency - and derives skew from the differences. On top of that it adds clock uncertainty for jitter and margin, using ideal latency pre-CTS (clock tree synthesis) and real propagated latency post-CTS.
CCS (composite current source, a more detailed cell-timing model than the older NLDM tables) adds its own receiver-capacitance and driver tables. The safe max_capacitance limit is the lowest maximum load index across all of them, and the safe max_transition limit is the lowest maximum slew index across NLDM, CCS driver and CCS receiver_capacitance2 - set it from NLDM alone and DRC can pass while delay calculation quietly extrapolates.
StarRC run with SIMULTANEOUS_MULTI_CORNER: YES extracts several RC corners in one pass into a single multicorner GPD (Galaxy Parasitic Database) file. PrimeTime then selects one corner with `set_app_var parasitic_corner_name cworst_CCworst` (PT) and reads it - the payoff is that the expensive geometric extraction work happens once and is reused across every corner.
No - they correct different artifacts. CRPR (clock reconvergence pessimism removal) removes the double-counted delay on the clock segment shared by launch and capture; POCV's graph-merging pessimism removal separately removes the stochastic-max inflation that occurs where several fan-in distributions converge. A clock path needs both active.
Because SMVA (statistical multi-voltage analysis) is a full signoff feature covering noise across voltage combinations, and voltage-dependent noise response - crosstalk bumps and immunity - is captured only in a library's CCS noise models, not its CCS timing tables. A scaling group missing noise data on even one member library breaks the interpolation.
Trace voltage in the same order PrimeTime resolves it: `report_power_switch` (PT) for the switch's On State condition, `report_power_network` (PT) for the topology it feeds, `report_supply_net` (PT) for the output net's voltage, then `report_timing -voltage` (PT) or the pg_pin_info attribute on the cells. The most common root cause is a missing set_voltage on the switch's output net.
Refuse it. An ideal clock uses estimated or zero network latency, not the real skew of the clock tree that clock tree synthesis (CTS) just built, so it silently mis-times every path in the domain - hold checks worst of all, since hold is dominated by skew. Solve runtime with parallelism and prioritization instead, not by falsifying the clock model.
A generated clock's source latency is inherited from its master, not specified independently - it is the master clock's insertion delay from its origin down to the generated clock's source pin. PrimeTime computes it automatically when the master is propagated, and tracks it separately per edge because a clock network's rise and fall delays are not always equal.
A setup check compares when data arrives at a flip-flop against the latest time it is allowed to arrive. On-chip variation (OCV, the assumption that identical cells on the same chip can still run at slightly different speeds) forces the tool to derate the launch clock path late and the capture clock path early, even though both paths often share the same physical wires up to some branch point. That double-counts variation on the shared segment. Clock reconvergence pessimism removal (CRPR) finds that shared segment and credits back the extra margin.
Cell delay normally shortens as temperature drops, because carrier mobility improves — this is why designers default to the coldest corner for hold analysis. At low supply voltage, though, delay can start increasing as temperature drops instead, because the threshold voltage's own temperature dependence takes over from mobility. This reversal is called temperature inversion, and it means the coldest corner is not automatically the fastest, or the worst, corner for hold.
A frequency-divided relationship between two clocks — say a 2:1 crossing where one domain runs at half the frequency of another — is modeled with a generated clock: a clock definition that derives its edges from a source clock using a stated divide ratio, instead of an independent `create_clock` on the same physical clock pin. That lets the tool compute the exact synchronous relationship between every edge of both clocks, rather than treating the crossing as an unrelated, asynchronous boundary.
A compound generated clock — one that is first divided down from a faster source clock and then gated off (stopped and started) by an enable signal — has to encode both operations correctly in its SDC. Get either one wrong, and the tool computes the wrong period, the wrong edges, or fails to recognize the derived clock's relationship to the rest of the design, since it can only reason about the exact waveform the designer describes to it.
The tool walks the clock tree from its root toward the launch and capture flops and finds the last pin both paths still share — the common point. It then computes the derated delay to that pin twice: once using the derate factor the launch side would apply, once using the derate factor the capture side would apply. The difference between those two derated values is added back into the path's slack as the CRPR credit, because the shared silicon cannot actually run at two different speeds at once.
Flat OCV applies one multiplier to every cell and net delay on a path, regardless of how many stages the path has or how far it spans. Advanced on-chip variation (AOCV) instead looks up a smaller derate factor for paths with more logic stages or a shorter physical span, because random gate-to-gate variation partially cancels out over many stages, while systematic variation grows with distance. The result is a path-specific factor that is usually less pessimistic than one flat number applied everywhere.
Parametric on-chip variation (POCV) gives each timing arc its own nominal delay and a standard deviation, or sigma, taken from the library's variation data — rather than one derate factor applied uniformly. Along a path, independent per-arc sigmas combine statistically, so total path variation grows with roughly the square root of the number of stages, not linearly with stage count the way flat derating effectively does. That makes flat derating increasingly over-conservative on long paths.
`set_timing_derate` (SDC) is the command that applies OCV derate factors. Its qualifiers scope exactly what gets multiplied: `-early` or `-late` chooses shortest-path or longest-path delays, `-cell_delay`/`-net_delay`/`-cell_check` chooses which kind of delay component, and `-clock`/`-data` chooses which side of the path. Omitting a scoping qualifier applies the factor to everything in that early/late direction across the whole design.
Crosstalk delay happens when the victim net is already switching, and a neighboring aggressor net's coupling current speeds up or slows down that transition — this shifts when the victim crosses its switching threshold, changing timing. Crosstalk noise happens when the victim is quiet, and coupling current alone produces a spurious glitch bump. The Miller effect is why an aggressor switching in the opposite direction from the victim roughly doubles the effective coupling capacitance compared to a quiet aggressor, since the voltage across the coupling capacitor changes by twice as much.
Naively adding every aggressor's individually worst-case contribution assumes all of them can switch at exactly the moment needed to maximally disturb the victim, in the worst-case direction, all at once. Two things actually constrain this: each aggressor's own timing window (the real range of times its edge can occur, given its own paths and clocks) may not even overlap the victim's transition window, and the probability that every small aggressor aligns simultaneously in the same direction drops fast as the aggressor count grows — which is why the tool can use a statistical composite-aggressor model instead of a flat worst-case sum for the smaller contributors.
PrimeTime does not include a command that creates or schedules useful skew (deliberately unbalancing clock arrival times at different flops to borrow slack from one path and give it to another). That scheduling happens upstream, during clock tree synthesis in the implementation tool. PrimeTime's role is downstream: it analyzes and reports whatever skew already exists in the clock tree, using commands like set_clock_uncertainty and report_clock_timing, rather than commands that build the skew into the tree in the first place.
set_false_path and set_max_delay are point-to-point exceptions: they remove or replace the timing requirement on specific paths but the tool still computes and can report the path's delay. set_disable_timing instead removes the arcs through a pin, cell, or port from the timing graph entirely, so no path can be traced through that point at all — more efficient when every path through a point is genuinely false. When exceptions conflict on the same path, PrimeTime resolves it per path using a fixed priority: set_false_path beats set_max_delay/set_min_delay, which beats set_multicycle_path, and a more specific -from/-to/-through specification beats a more general one.
Static timing analysis (STA) checks every timing path in a chip design without simulating any data. It walks each path once, adds up the worst-case delays, and compares that total against the clock period. The tool does this for every path at once, so it can prove the whole chip meets its setup and hold requirements instead of just sampling a few cases.
Circuit simulation only tests the exact input sequences a testbench happens to apply. A modern chip has far too many possible internal states for any testbench to trigger the one combination that produces the slowest, worst-case path. Static timing analysis avoids this problem entirely by checking delay algebraically instead of by simulating data.
A timing path is the route a signal takes from one fixed point to another: a startpoint where data is launched, through combinational logic, to an endpoint where data is captured. Every delay and slack number the tool reports is calculated for one specific timing path.
A startpoint is where the tool considers data to be launched — a flip-flop's clock pin or a primary input port. An endpoint is where the tool checks that data arrived correctly — a flip-flop's data pin or a primary output port. These are the only object types the tool will accept as path boundaries.
Every timing path in a design falls into one of four shapes, named for its startpoint and endpoint: register-to-register (reg2reg), input-to-register (in2reg), register-to-output (reg2out), and input-to-output (in2out). Each shape is constrained by a different SDC command, because each one crosses the chip boundary differently.
`create_clock` (SDC) is the command that tells the tool a clock exists: its period, where it enters the design, and the shape of its waveform. Without it, the tool has no reference edge to launch or capture data against, so no synchronous timing check can happen at all.
Data arrival time is the total time the tool calculates from the launch clock edge (time zero) until the data signal actually reaches and switches at the capturing flip-flop's data pin. It's the sum of every delay along the path — clock tree, the launching flop itself, and the logic in between.
Data required time is the deadline the tool computes for a path: the latest moment data may arrive (for a setup check) or the earliest moment data may safely change (for a hold check) at the capturing flip-flop. It comes from the clock period, the capturing clock's own delay, and the cell's own setup or hold requirement.
A setup check confirms that data launched on one clock edge arrives and settles at the capturing flip-flop's data pin before that flop's next active clock edge, with enough margin to spare. Setup time is that margin — the minimum stretch of time the data must sit stable right before the clock edge for the flop to capture it reliably.
A hold check confirms that data launched on a clock edge stays stable at the capturing flip-flop's data pin for a minimum stretch of time after that same clock edge. Hold time is that minimum stretch — the flop needs the data to hold still just long enough for its internal capture circuit to fully latch the value before anything new arrives.
Slack is the tool's margin number for a path: how much room there was between when data was required and when it actually arrived. For setup, slack is required time minus arrival time. For hold, it's the other way around — arrival time minus required time.
Positive slack means a path met its timing requirement with margin left over — the design is safe on that check. Negative slack means the path missed its requirement, which is a real timing violation that will cause incorrect behavior in silicon unless it gets fixed before tapeout.
The launch flip-flop is the one whose clock edge sends new data into the path being timed. The capture flip-flop is the one whose clock edge samples and stores whatever arrives. Every register-to-register path the tool reports has exactly one launch flop and one capture flop, even though a single flop often plays both roles for different paths.
`set_input_delay` (SDC) tells the tool how much of the clock period was already used up before a signal reached one of the chip's input ports — time spent on the board, in the driving chip's own delay, and in wire flight time. It doesn't add any actual delay inside the chip; it's purely information the tool uses to compute correct arrival times for paths starting at that port.
`set_output_delay` (SDC) tells the tool how much time must be left over, after a signal leaves the chip's output port, for the board and the receiving device's own setup or hold needs. Like `set_input_delay`, it's a timing assertion the tool uses for its math, not a delay it physically inserts.
Clock uncertainty is a margin the tool builds into every setup and hold check to cover clock jitter, skew the model can't fully predict, and other small clock imperfections. It's subtracted from the setup deadline (making it stricter) and added to the hold deadline (also making it stricter) through `set_clock_uncertainty` (SDC).
Clock latency is the total time it takes the clock signal to travel from its true origin to a specific flip-flop's clock pin. The tool splits that total into two pieces: source latency, the delay before the clock even reaches the design's defined clock point, and network latency, the delay from that point through the on-chip clock tree to the flop.
Clock skew is the difference in arrival time between the clock edge reaching the capture flip-flop and the clock edge reaching the launch flip-flop, on the same path. It shifts how much time the data path effectively has — positive skew gives setup more room but takes room away from hold, and negative skew does the reverse.
Combinational logic delay is the total time added by ordinary logic gates — AND, OR, XOR, multiplexers, inverters — sitting between the launch flop's output and the capture flop's input on a timing path. It's usually the single largest, and most controllable, piece of a path's total delay.
Cell delay is the time it takes a single standard cell's output to switch after its input switches, measured between the same reference points (typically each pin's 50% voltage crossing). The tool looks this number up in the cell's own Liberty library data rather than calculating it from first principles.
Net delay (also called interconnect delay) is the time a signal takes to travel along the metal wiring between two pins, once it leaves the driving cell. It comes from the wire's own resistance and capacitance (RC), not from any transistor switching.
A `report_timing` (PT) report has four parts read top to bottom: a header naming the start and end of the path, a data-arrival section tracing the signal's delay pin by pin, a data-required section computing the deadline, and a slack line at the bottom showing whether the path passed.
An SDC (Synopsys Design Constraints) file is a plain-text script that tells the tool what timing the design is supposed to meet — its clocks, its I/O timing, and any exceptions — before synthesis, place-and-route, or STA can check anything against it.
A setup violation means data arrived at a flip-flop's input too close to the clock edge — later than the setup time the flop needs to latch it reliably. It signals that the design is too slow for the clock period being tested, not that the chip is necessarily broken.
A hold violation means new data raced through the logic and reached a flip-flop's input before the flop had finished safely latching the previous value, corrupting that stored bit. Unlike a setup violation, a hold violation cannot be fixed by running the clock slower.
Slew, also called transition time, is how long a signal takes to swing from a low logic level to a high one, or back again. A slower slew adds extra delay to every gate downstream, wastes power, and makes a wire more vulnerable to noise from its neighbors.
A Liberty (.lib) library is a text file that describes exactly how every standard cell in a technology behaves — its delay, its output slew, its input pin capacitance, and its power draw — measured across the range of input slews and output loads the cell might see.
NLDM (Non-Linear Delay Model) is the classic way a Liberty library stores cell delay — a two-dimensional lookup table indexed by input slew and output load, with the tool interpolating between the table's measured points for any value in between.
PVT corners are combinations of Process, Voltage, and Temperature that real chips will actually experience across manufacturing spread and normal operating conditions. Timing shifts noticeably across them because the physical speed of a transistor depends on all three.
An ideal clock reaches every register at the same instant, with no physical clock tree modeled yet. A propagated clock is traced through the design's real clock buffers and wires, so it carries the true insertion delay and skew that physical clock tree synthesis actually produced.
Worst Negative Slack (WNS) is the most negative slack value found across every endpoint in a design or path group. It tells you the single most timing-critical path in the design, and how far the design is from meeting its target clock frequency.
Total Negative Slack (TNS) is the sum of every violating endpoint's slack across the design, added together as negative numbers. It measures how widespread timing failure is, in a way that a single worst-path number like WNS cannot.
A generated clock is a clock produced inside the design itself — by a divider, a multiplexer, or a clock-gating cell — rather than arriving from an external pin. It is declared with `create_generated_clock` (SDC) so the tool keeps it tied to the timing of the master clock it comes from.
A false path is a timing exception, declared with `set_false_path` (SDC), that tells the tool to stop checking both setup and hold on a path because that path can never actually be exercised in real functional operation.
A multicycle path is a timing exception, declared with `set_multicycle_path` (SDC), that tells the tool a path is deliberately allowed more than one clock cycle to complete, instead of the default single-cycle deadline every path is checked against.
The `check_timing` (PT) command audits the loaded design and constraints for setup problems that would make slack reports meaningless — unclocked registers, unconstrained ports, and combinational loops — before you rely on any slack number it produces.
Parasitics are the resistance and capacitance a routed wire has simply by existing as metal near other metal and near the substrate. SPEF (Standard Parasitic Exchange Format) is the file format used to carry those extracted values from the layout tool into the STA tool.
Pre-layout STA runs on the synthesized netlist with ideal clocks and estimated wire delay, before physical placement exists. Post-layout STA runs on the actual routed design with propagated clocks and real extracted wire parasitics, and is the version that counts for signoff.
STA needs four files to run: a gate-level netlist describing what is connected to what, Liberty timing libraries describing how each cell behaves, an SDC file stating the timing intent, and — for post-layout accuracy — a SPEF file with extracted wire parasitics.
Timing signoff is the final checkpoint where a design must show zero setup and hold violations, clean design-rule checks, and full path coverage across every required corner, before the layout is released for manufacturing.
The critical path is the path with the least slack in the whole design, whether that slack is positive or negative. It is not automatically a timing violation — a design with a healthy, all-positive-slack timing report still has a critical path, it is just the one closest to failing.
A timing arc is the delay from one specific input transition on a cell to one specific output transition — for example, input rising to output falling. A single gate has several arcs, and the tool tracks each one separately because the delay is not the same for every combination.
A setup or hold check compares two clock-relative times on a path and produces slack — a value that can be positive or negative. A design rule check (DRC) like max transition compares a single measured value against a fixed library or user limit, with no clock relationship involved at all.
An unconstrained path is one the tool can trace electrically but has no timing requirement attached to — no clock relationship or `set_input_delay`/`set_output_delay` (SDC) tells it what "on time" means. The tool will not report a slack number for it at all, good or bad.
A flip-flop's data input is usually fed by several different upstream logic paths that converge through a mux or a gate, so more than one path can share the same endpoint. The tool reports the one with the worst slack for that endpoint, not every path that reaches it.
A virtual clock is a clock the designer defines with `create_clock` (SDC) but never attaches to any real port or pin in the design. It exists only so the tool has a timing reference for signals that talk to an off-chip device on a clock the chip itself does not generate.
By default, `create_clock -period` (SDC) assumes a perfectly even 50% duty cycle clock. To model a clock that is high or low for a different fraction of its period, add the `-waveform` option and list the exact rise and fall edge times yourself.
Without a `create_clock` (SDC) statement, the tool has no reason to treat that port as a clock at all — it times signals through it as ordinary combinational logic, and every flip-flop it should be clocking shows up as having no clock.
A clock domain is the group of flip-flops and logic that all get their clock from the same defined clock, directly or through a generated clock derived from it. Most chips have several domains because different parts of the design genuinely need to run at different speeds.
An SDC file can define as many clocks as the design has clock sources or generated-clock points — there is no fixed limit. Each clock gets its own independent period, waveform, and name, so none of them are required to match any other clock's period.
`set_clock_transition` (SDC) tells the tool how slow the clock edge itself is — its rise or fall time — when the clock network is still ideal and has no real buffers to measure that from. `set_clock_uncertainty` (SDC) is a completely different number: extra margin subtracted from the setup or hold check to cover skew and jitter.
Clock sense describes which edge direction of a clock signal a flip-flop actually reacts to — rising-edge-triggered or falling-edge-triggered. Most designs use rising-edge flops, but a design can deliberately use falling-edge flops, often to build a double-data-rate interface or to relax a tight setup path.
`set_clock_groups -asynchronous` (SDC) tells the tool that the listed groups of clocks have no fixed timing relationship to each other at all, so it should not build a setup or hold check across any path between them. Paths within each group are still checked normally.
SDC commands take plain numbers with no unit attached, and the tool interprets every one of them in whatever time unit the design's own technology library or `set_units` (SDC) statement declares — nanoseconds is the most common default. Every number in the file only means anything relative to that one setting.
The period is what lets the tool compute a required time at all — every setup check measures arrival time against one clock cycle length, so `create_clock` (SDC) cannot build a usable clock without it. Picking a period looser than the real target hides real violations; picking one tighter wastes design effort chasing margin nobody needed.
`set_case_analysis` (SDC) tells the tool to treat a pin as permanently stuck at a fixed logic value — 0 or 1 — for the whole analysis, instead of a signal that can still switch. Designers use it for pins that really are fixed in the mode being analyzed, such as a tied-off test or configuration input.
Leaving a path unconstrained means the tool never checks it at all and cannot tell an intentionally irrelevant path from a genuine constraint gap. Marking it a false path with `set_false_path` (SDC) is a deliberate, documented statement that the path was checked and judged not to need timing at all.
A half-cycle path is one where the launching and capturing flip-flops are triggered by opposite edges of the same clock, so data only has half a clock period, not a full one, to get there. It is not automatically a violation — it just needs to be measured against the correct, shorter required time.
`set_disable_timing` (SDC) removes one specific timing arc — a delay from one pin to another inside a cell or between two points — from analysis entirely, as if that internal connection did not exist. It is used when a real electrical path exists but is never functionally active in the mode being timed.
`set_max_delay` and `set_min_delay` (SDC) give a path an explicit time budget in nanoseconds directly, instead of deriving one from a clock relationship. `set_false_path` (SDC) removes a path from checking entirely; these two commands keep the path checked, just against a number the designer states outright.
`set_false_path` (SDC) tells the tool to stop checking a path's delay completely — it does not stop the real hardware from switching. If that path genuinely does carry a changing signal during functional operation, its real delay is never verified, and a slow path can fail silently in silicon while every report stays clean.
`-from` and `-to` name a path's startpoint and endpoint directly — a clock, a register, or a port. `-through` instead names one or more intermediate points the path must pass through on its way there, letting the designer target one specific route among several that share the same start and end.
Derating is the practice of scaling a calculated delay up or down by a fixed factor to account for the fact that two identical-looking gates on the same chip do not switch at exactly the same speed. PrimeTime applies a derate factor with `set_timing_derate` (SDC) so setup and hold checks assume a small, safe amount of extra variation instead of trusting one single delay number for every instance. It is the tool's way of modeling on-chip variation without having to know the exact speed of every gate up front.
A late derate scales a delay up, making a path look slower than the "typical" number calculated it to be, and PrimeTime applies it wherever running late is the dangerous direction. An early derate scales a delay down, making a path look faster, and the tool applies it wherever running early is the dangerous direction. Which paths get which derate flips depending on whether the tool is checking setup or hold.
Cell delay comes from a transistor's switching speed, which depends on process parameters like threshold voltage that vary meaningfully from one physical location on the die to another. Net delay comes mostly from wire resistance and capacitance, set by the metal stack's geometry, which varies far less across a die than transistor speed does. Because the two delay types come from different physical sources with different amounts of variation, PrimeTime lets you set separate derate factors for each with `-cell_delay` and `-net_delay` (SDC) instead of forcing one number to cover both.
A flat OCV derate applies the same percentage margin to every cell and every net in the design, regardless of how many logic stages a path crosses or how far apart the launch and capture clock paths are. It is simple to set up with one `set_timing_derate` (SDC) command, but it treats a two-stage path and a forty-stage path as equally risky, which is not how real variation behaves. As designs grow, that flat number either wastes margin on short paths or under-covers long ones.
Parametric on-chip variation, POCV, models each cell's delay as a range described by a mean value and a standard deviation, or sigma, instead of one worst-case number scaled by a fixed percentage. PrimeTime reads this mean-and-sigma data from the Liberty library's variation tables, sometimes called LVF data, and combines it statistically across a path rather than assuming every stage varies by the exact same fixed amount. That gives a derate that automatically adapts to how many stages a path has and how much each individual arc actually varies, instead of relying on one guessed percentage for the whole design.
Clock reconvergence happens when the launch and capture paths of a timing check share part of the same physical clock tree before splitting off to different flip-flops. Because that shared portion is the exact same silicon for both paths, on-chip variation applied to it should cancel out instead of being counted twice, once as an increase on one side and a decrease on the other. PrimeTime's clock reconvergence pessimism removal, CRPR, finds that shared portion and removes the extra, unrealistic pessimism it would otherwise add, which matters most for hold checks because hold margins are already small.
Hold checks care about the smallest possible delay difference between a launch path and a capture path, and shrinking transistor and wire geometry increases the percentage of random, uncontrollable variation in that smallest delay. A smaller node also means less absolute delay margin to begin with, because gates and short wires are faster, so the same picoseconds of variation eat up a much larger share of the available window. The result is that hold violations become more common and harder to fix even though the design intent has not changed.
Signal integrity, often shortened to SI, covers what happens when a wire's voltage is disturbed by something other than its own driver, most commonly capacitive coupling from a switching neighbor. A wire that is not supposed to change at all, a quiet or static net, can still see a temporary voltage bump purely because a neighbor switched and coupled some of its energy across. PrimeTime's SI analysis checks for this alongside ordinary delay calculation, because the coupling can either slow a signal down or create a glitch large enough to be misread as a real logic transition.
A victim net is the wire PrimeTime is currently checking for a crosstalk effect, either a delay change or a noise glitch. An aggressor net is any neighboring wire, close enough to share meaningful coupling capacitance with the victim, whose own switching can push charge onto the victim and disturb it. The same physical wire can be a victim in one check and an aggressor in another, since the roles describe which net is being analyzed, not a fixed property of the wire itself.
Coupling capacitance is the capacitance that exists between two nets that run near each other on the chip, not between a net and the ground plane. Because that capacitance links the two wires electrically, a voltage change on one wire pushes some current through it onto the other, changing how quickly the second wire's own driver can charge or discharge its load. That is why a neighboring wire's switching can measurably speed up or slow down a signal's delay, an effect PrimeTime reports separately as crosstalk delay.
A wire load model estimates a wire's resistance and capacitance from statistics, an average length for a given fanout, before the design has real placement or routing. Annotated parasitics come from actually extracting the resistance and capacitance of the wires the tool physically routed, captured in a SPEF file, so they reflect the real length, shape, and neighbors of every specific wire. Once real layout exists, using annotated parasitics instead of a statistical estimate is what lets STA correlate with how the chip will actually behave.
An extraction corner describes an assumption about how wide, thick, and closely spaced the manufactured metal wires actually turn out to be, since real fabrication varies within a controlled range around its target geometry. RCmax models the resistance-and-capacitance combination that makes wires act slowest for a given check, and RCmin models the combination that makes them act fastest, and signoff checks both because a wire varying toward one extreme is not guaranteed to vary the same way as one varying toward the other. This is separate from a PVT timing corner, which covers process, voltage, and temperature variation in transistors, not wires.
NLDM, non-linear delay model, describes a cell's delay and output transition as a lookup table indexed by input transition time and output load capacitance, giving a single number for each combination. CCS, composite current source, instead describes the cell's actual output current over time, letting the tool calculate delay more accurately when the load is not a simple capacitor, such as when crosstalk or a resistive interconnect is involved. Both come from the same Liberty library file format, but CCS carries more detailed information at the cost of a larger library and more calculation.
A timing mode describes one functional operating condition of the chip, such as normal function, test/scan mode, or a low-power state, each of which can activate different clocks, different enabled paths, and different constraints. The same physical chip needs to meet timing in every mode it can actually be placed into, not just the one a design team thinks of as "normal," because a path that is safely disabled in one mode might be fully active in another. Multi-mode analysis runs the design through each mode's own SDC constraints to check timing holds up in every one of them.
A timing corner describes a set of physical operating conditions the silicon might actually see, such as process variation, supply voltage, and temperature, often shortened to PVT. A timing mode, by contrast, describes a functional operating state the design's logic is in, such as scan test or a low-power state, and is about which paths and constraints are active rather than how fast the silicon physically runs. A full signoff scenario needs both: which mode the logic is in, and which corner's physical conditions apply for that check.
A scenario is one specific combination of a timing mode and a timing corner, analyzed together as a single, self-contained timing run with its own constraints and its own PVT or RC assumptions. Signoff needs many scenarios because a chip has to work correctly in every mode it can be placed into, under every corner condition the silicon might experience, and a violation hiding in just one untested combination is still a real silicon risk. Running many scenarios is how a design team gets confidence that no single mode-corner combination was left unchecked.
Different timing checks are stressed by opposite physical conditions: setup checks get worse when the silicon runs slow, and hold checks get worse when it runs fast, so no single PVT corner is the worst case for both at once. A chip also has to work across its full specified range of voltage, temperature, and manufacturing outcome, not just one assumed condition, so checking only one corner leaves the rest of that range completely unverified. This is why signoff always runs multiple corners rather than trying to find one corner that represents every risk.
Hierarchical timing analysis breaks a large design into smaller blocks and times each one somewhat independently, using a simplified model for how each block connects to the rest of the chip instead of loading the entire flat netlist in one run. Analyzing a block on its own lets a team get fast timing feedback and sign it off before the whole chip's netlist even exists in one piece, and it keeps the top-level run from becoming too large to manage. This matters most on large SoCs where a single flat run across the whole design would be too slow or too large to iterate on.
An extracted timing model, ETM, is a simplified stand-in for a block's timing behavior, built by summarizing how each input pin affects each output pin, without keeping any of the internal gates that produced that behavior. It captures the delays and internal setup/hold checks the top-level design needs at the block's boundary, in a much smaller file than the block's full netlist and library data would require. Using an ETM instead of the full block lets a top-level run treat a large, complex block like a single, fast-to-load timing element.
Timing budgeting takes the total time available for a path crossing multiple blocks, one clock period, and divides it into smaller allowances for each block and each piece of interconnect the path passes through. Each block gets its own slack target because block teams typically work somewhat independently and in parallel, and giving each one a clear number to hit lets them close timing without needing the full top-level netlist available yet. Without budgeting, a multi-block path has no way to tell an individual block team whether their piece is the one using too much of the shared time.
`report_timing` (PT) prints one path in full detail — every pin, every incremental delay, down to a single slack number. `report_constraint` (PT) instead scans the whole design and prints a summary: how many endpoints pass, how many fail, and by how much, for every check type at once. You reach for `report_timing` once you already know which path you care about, and for `report_constraint` when you still need to find out what is broken.
MET and VIOLATED are the pass/fail labels `report_constraint` (PT) prints next to every checked endpoint. MET means the slack at that endpoint is zero or positive — the check passed with no margin problem. VIOLATED means the slack is negative, so the endpoint is failing that check and needs a fix or a legitimate exception.
`report_analysis_coverage` (PT) reports what fraction of the design's paths and endpoints were actually included in the timing run, broken down by exception type and clock group. A design can show a completely clean `report_constraint` (PT) result and still hide real risk if large parts of it were excluded, disabled, or never constrained in the first place.
`report_bottleneck` (PT) ranks the individual cells and nets that show up most often across every failing path in the design, instead of listing the failing paths themselves. A single slow buffer or an overloaded net can sit on hundreds of different failing paths at once, and fixing that one cell clears all of them together.
`report_timing` (PT) shows you the final delay number for each pin along a path. `report_delay_calculation` (PT) shows the underlying math behind one specific delay: the drive strength, the load it is driving, the slew it produces, and which library model or SPEF entry the tool used to compute it. You reach for it when a single delay number looks wrong and you need to see what produced it, not just that it exists.
The incremental delay column shows how much time one single stage — one cell or one net — adds by itself. The cumulative delay column, printed right next to it, is the running total of every incremental delay so far, from the path's startpoint up to that pin. The final cumulative value at the endpoint is the arrival time used in the slack calculation.
`get_timing_paths` (PT) returns a Tcl collection of path objects that a script can loop over, filter, or measure, instead of printing a formatted report to the screen. `report_timing` (PT) is built for a person to read; `get_timing_paths` is built for a script to process, which matters once you need to check hundreds of paths automatically rather than read them one at a time.
An ECO — engineering change order — is a small, targeted set of netlist changes made late in the flow to fix specific violations, instead of rerunning the full place-and-route flow. A designer reaches for PrimeTime's ECO commands when only a handful of cells need resizing or a few buffers need inserting, because a full re-implementation would cost far more schedule time than the violations are worth.
A DRC (design rule constraint) violation happens when a signal's own physical limit is broken — its transition time is too slow, or its driven capacitance too high — regardless of any clock relationship. A setup or hold violation is always about a signal arriving too late or too early against a specific clock edge. A path can pass every setup and hold check and still fail a DRC limit, and vice versa.
`write_changes` (PT) takes every edit an ECO command like `fix_eco_timing` (PT) made inside PrimeTime's model and writes it out as a script of concrete netlist edits — cell resizes, buffer insertions, connections — that another tool can apply. Without this step, the ECO exists only inside PrimeTime's own view of the design and never reaches the real netlist or the physical layout.
A setup fix has to make a path faster, so `fix_eco_timing -type setup` (PT) uses cell sizing alone to shrink data-path delay. A hold fix has to make a path slower, so `fix_eco_timing -type hold` (PT) uses both sizing and buffer insertion to add delay back in. The two violations need opposite changes to the same path, which is why the tool treats them as separate fixing types, not one generic "fix timing" command.
`fix_eco_timing` (PT) reports the violations it believes it fixed based on PrimeTime's own timing model at the moment it ran, but that model can go stale the instant the physical tool actually places, routes, and legalizes the new cells. A full STA re-run, with freshly extracted parasitics, is the only way to confirm the fix holds in the design as it will actually be built, not as PrimeTime estimated it.
A timing ECO only changes non-functional properties of the netlist — cell sizes, buffer insertion, wire routing — to fix a timing or design-rule violation without changing what the chip logically does. A functional ECO changes the logic itself: a gate is added, removed, or rewired to fix a real behavioral bug. The two are handled very differently late in a project, because a functional change can ripple through verification in ways a timing-only change cannot.
Level 2: Construction & Debugging
A setup check compares the latest possible data arrival at the capture flop's D pin against the earliest possible required time. Arrival is the launch clock delay plus the launch flop's clock-to-Q delay plus the slowest data path; required is one clock period plus the fastest capture clock delay, minus the flop's setup time and the clock uncertainty margin. The path passes when arrival is less than or equal to required.
A hold check verifies that data launched by a clock edge does not race through the logic and corrupt the value that same edge is supposed to capture from the previous cycle. Unlike setup, no clock period is added: the tool compares the fastest data arrival against the latest capture edge, so skew and short paths decide the outcome, not the clock frequency.
Before layout, STA typically assumes an ideal clock: it arrives at every flop at exactly the same time, with zero skew. `set_propagated_clock` (SDC) switches the tool to use the clock's real insertion delay through the actual clock tree built during clock tree synthesis (CTS) — the step that builds the physical wiring that distributes the clock.
Clock jitter is the clock edge itself wobbling from cycle to cycle at its source — a physical property of the clock generator (a PLL, for example) that the tool cannot derive on its own. Clock uncertainty is a margin the designer explicitly tells the tool to subtract from the setup or hold budget, using `set_clock_uncertainty` (SDC), to account for jitter plus other unmodeled effects like residual skew.
Source latency is the delay from the clock's true origin — an off-chip pin, or a PLL — to the point in the design where the clock is defined. Network latency is the estimated on-chip delay through the clock tree itself, from that definition point to each register. Both are set with `set_clock_latency` (SDC) as stand-in numbers before clock tree synthesis has built a real tree to measure.
A DDR (double data rate) interface launches or captures data on both the rising and falling clock edges, so one input delay referencing only the rising edge covers half the data. The `-clock_fall` option on `set_input_delay`/`set_output_delay` (SDC) tells the constraint to reference the falling edge instead, and the rising and falling constraints must be applied together, not one overwriting the other.
A false path is a path the tool can trace through the netlist, but which the engineer asserts can never actually be exercised in real functional operation — for example, a path only active in a test mode that never coexists with the capturing clock. `set_false_path` (SDC) tells the tool to stop timing that path entirely, so if the assumption behind it is wrong, the path ships with zero timing verification and no warning.
`set_clock_groups` (SDC) classifies how two clock domains relate for timing purposes. `-asynchronous` marks clocks with no fixed phase relationship, so paths between them are not meaningfully timed. `-logically_exclusive` marks clocks that never operate at the same time functionally, though they may still coexist physically on the die. `-physically_exclusive` goes further, asserting the clocks also cannot electrically interfere with each other.
A generated clock is one derived on-chip from a master clock — by a divider, a clock gate, a multiplexer, or an inverter. It must be defined with `create_generated_clock` (SDC), not `create_clock` (SDC), so the tool understands and preserves the exact phase relationship between the generated clock and the master clock it comes from.
Recovery and removal are the asynchronous-control equivalents of setup and hold, but applied to a register's set or clear pin rather than its data pin. Recovery is setup-like — the control signal must be de-asserted early enough before the clock edge. Removal is hold-like — the signal must stay asserted long enough after the edge before releasing.
`max_transition` is a design-rule ceiling, defined in the standard cell library, on the largest transition time — how long a signal takes to swing between logic levels — that a cell's input or output pin is allowed to see. A violation is a hard design rule check (DRC) failure, verified against a fixed library limit, independent of whether the path around it has positive timing slack.
`max_capacitance` (LIB) is a design-rule ceiling, specified per pin in the standard cell library, on the largest output load — the total capacitance of the wire plus whatever it drives — a cell is allowed to drive. Like `max_transition`, exceeding it is a hard DRC failure regardless of the path's timing slack. `max_fanout` (LIB) is a related but separate library attribute limiting the number of pins driven, not the electrical load directly.
When more than one timing exception could apply to the same path, the tool resolves the conflict by precedence rather than combining them — and `set_false_path` (SDC) takes precedence over `set_multicycle_path` (SDC). A broad false path declaration can therefore completely exclude a path an engineer meant only to relax with a multicycle exception, with no warning that the multicycle command was ever overridden.
GBA keeps a single worst-case slew value at each node of the timing graph and reuses that same value for every path passing through it — fast, but pessimistic, since it can penalize a fast path with a slow, unrelated path's slew. PBA re-times each path individually using its own actual slews all the way along, which is more accurate but too computationally expensive to run on every path in the design.
`report_timing` (PT) prints a Point/Incr/Path table that walks down the path arc by arc, showing each cell or net arc's own incremental delay alongside the running cumulative total. To find the dominant delay contributor, scan the Incr column for the single largest jump — not the final cumulative Path value, which only tells you the total, not where it came from.
`check_timing` (PT) scans the design for constraint problems that would make timing analysis incomplete or simply wrong — flops with no clock defined, ports with no input or output delay, generated clocks whose source pin cannot be found, and combinational feedback loops. Under-constraint is silent: a design missing constraints can still produce a fully green, all-passing `report_timing` (PT) that means nothing.
`group_path` (PT) organizes timing paths into named groups — by clock, by endpoint type, or by a custom set the designer defines — so reporting and optimization tools can treat different classes of paths distinctly instead of lumping every path into one undifferentiated list. Common groupings by startpoint/endpoint type include reg2reg, in2reg, reg2out, and in2out.
Start by reading `report_timing`'s (PT) Incr column arc by arc to find where delay accumulates unexpectedly. At each large increment, decide whether it belongs to a net arc (a wire) or a cell arc (a gate): a large net increment usually calls for a physical fix like rerouting or buffering, while a large cell increment calls for checking the cell's driving input transition and load before resizing or fixing it.
Model PLL jitter as the dynamic part of clock source latency, using the `-dynamic` option of `set_clock_latency` (SDC), rather than folding it only into `set_clock_uncertainty` (SDC). Unlike uncertainty, dynamic latency affects the tool's crosstalk arrival-window calculation and is handled correctly by CRPR (clock reconvergence pessimism removal).
Mark the source objects ideal with `set_ideal_network` (PT); the ideal property then spreads forward through combinational logic and stops at the first sequential cell. Add `-no_propagate` when only the immediate net, not its whole downstream fanout, should stay ideal.
Use `set_clock_uncertainty` (SDC) with `-from` and `-to`, for example `set_clock_uncertainty 2 -from [get_clocks CLKB] -to [get_clocks CLKA]`. It's needed on clock-domain-crossing paths, where the launch register and the capture register sit on different clocks.
Under POCV (parametric on-chip variation), a slack or arrival value isn't one number, it's a statistical distribution, so there is no single scalar the bare attribute could return. `.mean` gives the average of that distribution and `.std_dev` gives its sigma, the spread.
PrimeTime expands the cell into pins: `-from` a cell becomes each of the cell's clock input pins, `-to` a cell becomes each of its data input pins. You can see the expanded, pin-level exceptions with `report_exceptions` (PT) or `write_sdc` (PT).
An increment adds to the existing derate factor rather than replacing it, so the final late derate is 1.082 + 0.03 = 1.112 and the final early derate is 0.924 + (-0.03) = 0.894. If a sum landed below 0.0, the tool would clamp it to 0.0.
Give separate values with `set_clock_uncertainty -setup` and `-hold` (SDC), for example `-setup 0.25` and `-hold 0.10` on the same clock. Setup uncertainty is subtracted from the required time, hold uncertainty is added, and each should cover only the skew and margin relevant to its own check.
It's the fixed tie-breaker order the tool uses when several mechanisms could each set the voltage on the same object — from a named-port override at the top down to the library's default voltage map at the bottom. A more specific, explicitly targeted setting always wins over a broad default.
CCS (composite current source) is the recommended Liberty model for scaling library groups: it represents the cell driver as a current source and captures nonlinear voltage dependence, whereas NLDM's (nonlinear delay model) delay and slew tables carry no real voltage dependence and drift from SPICE across a wide voltage sweep.
The special form — a startpoint or endpoint given as `-through` while a clock object is supplied to `-from`/`-to` — supports every valid start and end type, but it costs more to evaluate, especially on a large design. Plain `-from`/`-to` (SDC) is cheaper and should be used whenever it says what you mean.
Setting a constant with `set_case_analysis` (SDC) constrains only what's downstream of that pin — the tool never infers which upstream values would be logically necessary to produce it. So the constant has to be placed where its value can propagate forward to reach the logic it's meant to simplify.
Give both `-max` and `-min` input and output delays on every boundary port with `set_input_delay`/`set_output_delay` (SDC). Setup analysis uses the maximum, late external delays; hold uses the minimum, early ones — constraining only one leaves the other check with no external budget at all.
Specify each clock's delay on the port with `-add_delay` (SDC). Without it, a new `set_input_delay`/`set_output_delay` on a port removes the port's existing delay data and replaces it, so a second command without the flag would silently wipe out the first clock's budget instead of adding to it.
A `set_multicycle_path 2 -from {A B C} -to D` (SDC) was only partly applied. The `f` code means one startpoint, C, was invalid and got dropped; the `o` code means another path, A-to-D, was overridden by a higher-priority exception. Only B-to-D actually carries the multicycle value of 2.
OCV (on-chip variation) works by derating clock latencies, giving the launch and capture clock paths different, scaled delays. With an ideal clock, there are no real propagated clock delays to derate, so before that point the equivalent margin is approximated by inflating `set_clock_uncertainty` (SDC) instead.
A level shifter spans two power domains, so its timing depends on two independent rail voltages plus temperature. Covering all three dimensions on-grid needs 2 x 2 x 2 = 8 corner combinations, against 2 x 2 = 4 for an ordinary single-rail cell that only depends on one voltage and temperature.
Both equations subtract the capture clock's delay term because that delay always shifts the capture edge later in time — a single fact about the circuit. For setup, a later capture edge helps by relaxing the deadline; for hold, it hurts by widening the race window. Same term, same sign, opposite effect on margin.
An SDF (standard delay format) file carries pre-computed cell and net delays that PrimeTime reads with `read_sdf` (PT) and applies directly. A SPEF (standard parasitic exchange format) file carries extracted parasitic RC data instead, read with `read_parasitics` (PT), from which PrimeTime computes the delays itself.
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.
Zero slack means a path meets its timing requirement with no margin left over — it is a pass, not a warning by itself. Whether zero slack is actually safe depends on what margin is already folded into the check, since a report showing exactly 0ps can hide very different amounts of real safety margin.
Worst negative slack (WNS) is the single most negative slack value anywhere in the design — one number that tells you how bad the worst violation is. Total negative slack (TNS) is the sum of every negative slack value across all failing paths, so it tells you how widespread the problem is, not just how deep.
Before clock tree synthesis (CTS) — the step that builds the real buffered network delivering the clock to every flip-flop — the tool has no real clock wiring to measure, so it assumes an ideal clock with zero or estimated delay. After CTS, the clock has real buffers, wires, and skew, so the same path is timed against a completely different — usually less generous — set of clock arrival times.
A hold check compares how fast new data can race through the logic against how much extra time the clock gives the capturing flip-flop before its next edge. If the capturing flop's clock edge arrives earlier than the launching flop's edge — negative skew from the capture side's point of view — that time budget can go negative even when there is almost no logic delay to eat into it at all.
An intra-clock path starts and ends on flip-flops driven by the same clock, so the launch and capture edges come from one predictable waveform. An inter-clock path crosses from one clock to a different clock, so the tool has to reason about the relationship — or lack of one — between two separate waveforms before it can even define what a valid launch-to-capture edge pair looks like.
Setup and hold are two separate checks on the same path, comparing different arrival times against different requirements — one checks whether data arrives in time for the next clock edge, the other checks whether it stays stable long enough after the current edge. A path can easily pass one check with room to spare while failing the other, because nothing forces the two results to move together.
Source latency is the travel time from a clock's true origin — often an off-chip PLL — to the point in the design where you defined it with create_clock, and the tool cannot see that part of the path on its own. The set_clock_latency -source command with -early and -late lets you enter that travel time as a range, so setup and hold checks can each use whichever end of the range is worse for that specific check.
A gated clock — the master clock passed through an AND or OR gate for power savings — is not dividing or multiplying edges the way a flip-flop-based divider does, so it needs its own generated-clock option. The -combinational flag on create_generated_clock tells the tool to treat the output as a direct, gated copy of the master clock rather than trying to count edges.
A divide-by-2 clock comes from a flip-flop that toggles once every master-clock edge, and you define it with create_generated_clock -divide_by 2 -source, pointing -source at the pin where the master clock feeds the dividing flip-flop. Because the divider toggles symmetrically on every master edge, the tool assumes a clean 50% duty cycle by default, without needing a separate waveform.
Clock uncertainty is margin the tool subtracts before deciding a check passes, and setup and hold do not always need the same amount of it. The -setup and -hold options on set_clock_uncertainty let you assign each check its own value, instead of one flat number applying equally to both.
A virtual clock is a create_clock definition with no real source pin — it never propagates anywhere in the design, but it still gives set_input_delay and set_output_delay a -clock reference to compute setup and hold windows against. This is the standard way to constrain an interface to an external chip whose own clock never physically reaches your design.
Without that declaration, the tool still tries to time every path it can trace between the two clocks, assuming some worst-case edge alignment even if the clocks are driven by separate, unsynchronized oscillators. That worst-case alignment is often physically impossible, so the design sees a false violation with no real data-path fix, since the actual problem is a missing synchronizer, not a timing constraint.
An external driver's arrival time at an input port is not always symmetric, so set_input_delay accepts separate -max and -min values instead of one flat number. The -max value feeds the setup check, since setup cares about the slowest realistic arrival, and -min feeds the hold check, since hold cares about the fastest realistic arrival.
set_output_delay reserves part of the clock period for an external device's own setup and hold requirements after your output port changes, so the internal logic only gets the remaining part of the period to produce that signal. A larger output delay value leaves less time for internal logic, since more of the period is set aside for the receiving device.
create_generated_clock normally figures out the master clock on its own, by finding whichever clock reaches the named -source pin. When more than one clock can reach that pin — a multiplexed clock source feeding a shared divider, for example — that inference becomes ambiguous, and -master_clock has to name the intended clock explicitly.
Clock latency tells the tool where a clock edge arrives — a position in time, set with set_clock_latency or computed from a real propagated network. Clock uncertainty is a margin subtracted around that position to cover jitter and other variation the tool cannot exactly compute, set with set_clock_uncertainty — both are needed because one answers where the edge is and the other answers how much to distrust that answer.
By default, a second create_clock definition on a port that already has one replaces the first. The -add option keeps both instead, which models a port reached by more than one clock through an upstream mux — but only the clock active in a given mode should actually be used, so the mux selection also needs a case analysis or a mode-specific scenario to avoid two live clocks conflicting on one node.
The tool normally traces a clock signal's polarity automatically as it passes through the clock network, following each cell's known logic function. When a cell's function is not resolvable that way — a black-boxed cell or a non-unate function like XOR — set_sense -type clock -positive or -negative explicitly tells the tool whether the output tracks or inverts the reference clock's polarity at that point.
An ideal clock, before it is propagated through real buffers, defaults to zero transition time — an instant edge — since the tool has no real clock network to measure slew from yet. set_clock_transition assigns a realistic nonzero rise or fall time to that ideal clock, so early setup and hold checks reflect a more realistic edge shape instead of an idealized, optimistic instant one.
By default the tool keeps treating a signal as a clock through every downstream pin it can trace it to. When a clock-like signal legitimately feeds both real clock destinations and ordinary data logic — a test clock reused as a data mux input in some modes, for example — set_sense -type clock -stop_propagation tells the tool to stop treating it as a clock past that specific pin, so the rest of the fanout is analyzed as ordinary data.
`set_case_analysis` (SDC) fixes a pin or port to a constant logic value for the whole analysis run, so the tool treats that input as never toggling in any mode it checks. A false path instead leaves the pin free to toggle and only removes one specific launch-to-capture pair from setup and hold checking. Because case analysis changes what the tool believes the hardware does, it can remove entire branches of logic from analysis; a false path removes only the paths you name.
A half-cycle path launches on one clock edge and is captured on the very next edge of the same clock, including the opposite polarity edge, so by default the tool gives it only half a clock period instead of a full one. If the design actually only needs a new result once per full cycle, that default half-cycle check is unnecessarily strict, and a multicycle exception tells the tool to check the path over a full cycle instead.
Naming clocks with `-from [get_clocks A] -to [get_clocks B]` in `set_false_path` (SDC) declares every path between those two clocks false, in both register-to-register directions the clocks touch. To keep only one specific crossing false while other paths between the same two clocks stay checked, you name the actual startpoint and endpoint cells or pins instead of the clock objects.
A false path removes a path from timing checking entirely, which is only correct if the path's timing genuinely never matters. A multicycle path instead tells the tool the real number of clock cycles available, so a slow signal that does need to meet a timing budget — just a looser one than one cycle — stays checked, with a deadline that matches how the hardware actually behaves.
The plain `-from`/`-to` options in `set_false_path` (SDC) apply to a path regardless of which clock edge launches or captures it. Adding `-rise_from`, `-fall_from`, `-rise_to`, or `-fall_to` narrows the exception to only the paths that launch or are captured on that specific edge, leaving the opposite-edge paths through the same registers fully checked.
The tool accepts a `set_false_path` (SDC) command even if the objects you named do not resolve to any real path in the design, and it will not warn you by default. Running `report_exceptions` (PT) or `report_timing` with the exception in place is how you confirm the command actually removed something, rather than silently doing nothing.
The tool applies a fixed priority order whenever two case analysis settings conflict on the same object: a value set directly on a pin or port always overrides a value that merely propagates to it from an upstream driver. This lets a designer override a general upstream setting for one specific downstream pin without having to change the upstream setting itself.
Adding `-setup` to a `set_false_path` (SDC) command restricts the exception to the setup check only, so the hold check on that same path keeps running normally. Without the `-setup` or `-hold` qualifier, a false path removes the path from both checks at once, which is often more than the design actually needs.
`set_multicycle_path -setup 3 -from ... -to ...` (SDC) grants the path three clock cycles for its setup check instead of the default one. Because that also shifts the hold check by default, you pair it with `set_multicycle_path -hold 2 -from ... -to ...` on the same path to move the hold check back to right after the launch edge.
`set_case_analysis static` (SDC) fixes a pin at a constant value without committing to whether that value is logic 0 or logic 1, which matters specifically for signal integrity analysis. A net driven by a `static` pin is treated as never switching, so it cannot act as a crosstalk aggressor or be pushed around as a crosstalk victim, the same protection a plain 0 or 1 gives for timing but stated in a way that also covers noise analysis correctly.
AOCV (advanced on-chip variation) adjusts the derate factor from a lookup table based on how many logic stages or how much distance a path covers, using fixed numbers set once for the whole library. POCV (parametric on-chip variation) instead derates each individual timing arc from a statistical spread — a mean and a sigma value — read directly from the library, so the margin can differ arc by arc instead of by table lookup alone.
A derate factor is a multiplier the tool applies to a calculated delay to model manufacturing and environmental variation the delay calculation alone cannot see. `set_timing_derate -early` (SDC) scales delays down to model a faster-than-nominal path, and `-late` scales them up to model a slower-than-nominal path, and a single setup check actually uses both at once on opposite sides of the same path.
By default, `set_timing_derate -early`/`-late` (SDC) scales both the cell delays and the net delays on a path by the same factor. Adding `-cell_delay` or `-net_delay` restricts the derate to just one of the two, which matters because cell delay and net delay come from different physical sources of variation and do not need the same margin.
A flat derate applies the same percentage margin to a one-stage path and a fifty-stage path alike, even though random manufacturing variation tends to partly cancel out over many stages, not stack up in full. AOCV tables give a smaller derate to longer paths and a larger derate to shorter ones, recovering slack on long paths that a flat number was over-penalizing without actually giving up real coverage.
Sigma is the standard deviation of a cell delay's expected spread around its mean value if you could measure that same cell many times across normal manufacturing variation. A larger sigma means the real delay is more likely to land far from the mean; the tool combines each arc's sigma with its neighbors statistically instead of assuming every arc's delay lands at its absolute worst value at once.
`set_aocvm_table_group core_tables [get_cells H1]` (PT) assigns a specific, named AOCV derate table to the cells inside one hierarchical block, instead of the whole design sharing one default table. This lets a block built in a different library corner, or characterized separately, use derate data that actually matches its own construction.
Clock reconvergence pessimism is extra, unrealistic margin the tool adds when it assumes a launch clock path and a capture clock path vary in opposite directions, even over the portion of the clock tree they physically share. CRPR (clock reconvergence pessimism removal) corrects this only for the shared, common segment of the clock path, because that is the only part where both sides genuinely see the same physical variation at the same time.
A basic POCV model gives each timing arc one fixed sigma value, used no matter what input transition or output load that arc actually sees in the design. Liberty Variation Format (LVF) instead stores sigma as a small table indexed by input slew and output load, the same way nominal delay is already indexed, so the derate the tool applies can change arc-by-instance based on real operating conditions.
A PVT corner models variation between chips or across a whole die — one chip running slightly hot and slow, another cool and fast — using one fixed set of conditions for the entire design in that run. On-chip variation (OCV) margin instead models variation between two points inside the very same chip in the very same run, which a corner, by definition, holds constant.
Crosstalk delay is a timing effect: a neighboring wire switching at the same time pushes out or pulls in your signal's arrival time, changing when it gets there. Crosstalk noise is a voltage effect: a neighbor's switch bumps a quiet, steady wire enough that a downstream gate can briefly misread it, even though nothing on that wire was supposed to switch at all.
Turning on signal integrity (SI) analysis usually makes total negative slack (TNS) worse, because the tool now adds a delta delay for every net whose neighbors can switch at a similar time, instead of assuming clean, unaffected wires. Some paths can also improve slightly, since a neighbor switching the opposite direction can pull a signal in early instead of pushing it out.
A timing window is the range of time during which a signal could plausibly switch, given the earliest and latest arrival times the tool has already computed for it. Crosstalk analysis needs timing windows because two nets only affect each other if their windows actually overlap — a neighbor that always switches hours before or after your signal is not a real aggressor, no matter how much capacitance couples them.
A switching aggressor net pushes out or pulls in a victim through the coupling capacitance between them: current flowing through that shared capacitance either fights against the victim's own edge or helps it along, depending on whether the two nets switch in the same direction or opposite directions at close to the same time. The result is a real change in the victim's arrival time, not just a voltage bump.
Setting the si_enable_analysis variable to true tells PrimeTime to compute crosstalk delta delay for every net during timing analysis, using the coupling capacitance in the annotated parasitics, instead of timing each net as if it had no neighbors. It is a global switch: once set, it applies to the whole analysis, not to one net or one path at a time.
The `report_si_bottleneck` (PT) command ranks nets by how much crosstalk delay or noise they contribute across every scenario, then prunes duplicates so you get one unique, sorted list of the worst offenders instead of scrolling through a separate report per scenario. You read it top to bottom, fixing the highest-cost net first, since it usually touches the most violating paths per unit of repair effort.
Coupling capacitance between two wires grows as they run closer together and for a longer parallel distance, and shrinks quickly as the spacing between them increases. A shield — a grounded or fixed-value wire placed between a signal and its neighbor — gives the coupling current somewhere to go that is not the victim net, so both wider spacing and shielding cut crosstalk by directly reducing the capacitance the aggressor can act through.
Capacitive coupling percentage is the share of a net's total capacitance that comes from coupling to neighboring nets, rather than from ground or fixed-reference capacitance. A net with a high coupling percentage is dominated by its neighbors' switching behavior, so its delay is far more sensitive to what nearby aggressors do than a net whose capacitance is mostly grounded.
PrimeTime starts from every net that has coupling capacitance to at least one neighbor and an overlapping timing window with that neighbor, then narrows the list using explicit include and exclude commands the designer supplies for cases the tool cannot infer on its own, such as two nets that are physically close but logically guaranteed never to switch together. Without SI enabled at all, the tool skips crosstalk analysis entirely and times every net as an isolated wire.
A scenario is one complete, self-contained timing setup: a single combination of an operating mode (its own SDC constraints, like functional or test mode) and a single PVT corner (its own library, operating condition, and parasitics). PrimeTime analyzes each scenario as if it were a fully separate design, then merges the results, because a design's real behavior depends on which mode and which corner it is actually running under at any given moment.
The `current_scenario` (PT) command changes which scenario subsequent commands apply to, whether that is one specific scenario, a chosen subset, or every scenario at once with the `-all` option. This matters because most PrimeTime reporting and analysis commands act on whatever scenario currently has command focus, not on the whole design by default.
Running every mode against every corner is the safest possible coverage, but it is also the most expensive: each additional scenario costs real machine time and license usage to analyze, and many mode-corner combinations are physically impossible or already known to be dominated by a different combination. Teams prune the full cross product down to the combinations that can actually happen and that actually stress a check, rather than paying for scenarios that provide no new information.
HyperScale is a PrimeTime capability for analyzing a very large design as a set of smaller blocks with lightweight timing models standing in for each block's internals, distributed across multiple machines, instead of loading the entire flattened netlist into one process. It exists because a full-chip flat run on a large SoC can outgrow the memory and runtime budget of a single machine long before it outgrows the design itself.
An extracted timing model (ETM) hides everything happening inside a block — its gates, its internal nets, its internal paths — and keeps only the input-to-output timing arcs a neighboring block actually needs: how long a signal takes to cross the block, and what capacitance or drive strength it presents at each boundary pin. It is built so a top-level run can time paths that pass through the block correctly, without ever loading the block's real netlist.
Beyond the PVT corner's library and the clock's SDC definition, a complete scenario also needs its own operating condition (the exact voltage and temperature point within the corner), its own set of annotated parasitics matching that corner's extraction, and its own mode-specific constraints such as case analysis settings and exceptions. Leaving any one of these tied to a different scenario's data, instead of the scenario's own, produces a result that looks complete but times the design under a mismatched, inconsistent set of assumptions.
The `report_global_timing` (PT) command summarizes worst-case timing across every active scenario in one view, instead of requiring a separate report per scenario that a designer would have to compare by hand. It gathers each path's result from whichever scenario stresses it hardest and presents a single, ranked summary of the design's actual worst-case timing status.
A flat timing run loads a design's entire netlist into one analysis, with every gate and wire visible to the tool at once, regardless of which block it belongs to. A hierarchical run instead analyzes some blocks using compact stand-in models — an extracted timing model or a HyperScale boundary model — instead of their full netlists, trading a small amount of representational detail for a large reduction in memory and runtime.
Before a block has real gates and wires, its portion of a top-level path's available time is estimated from the block's expected size, pin count, and role in the path, then written as a placeholder budget — an artificial input or output delay constraint on the block's boundary — so the block team can start implementation against a concrete target instead of waiting for the rest of the chip to be built first.
Graph-based analysis (GBA) times every stage of every path using the single worst-case delay for that stage, so it never actually walks one real path start to finish. That worst case might come from a completely different path than the one being reported, which stacks extra pessimism onto the number PrimeTime prints. Path-based analysis (PBA) re-times the specific path in question using its own real delays, so signoff only trusts a report once the paths that look like they fail under GBA have been re-checked with PBA.
Clock skew is the difference in arrival time of the same clock edge at two different flip-flops, and it can help or hurt a setup or hold check depending on its sign. `report_clock_timing -type skew` (PT) lists, for a chosen clock, the launch and capture arrival times at the worst pair of registers and the skew between them, so you can see whether the clock network itself is adding or removing margin on a path.
A single-clock skew report only compares arrival times of the same clock at different flops, but many real paths launch from one clock and capture on a different one. `report_clock_timing -type interclock_skew` (PT) reports the timing relationship between two distinct clock edges at the point a path actually crosses between them, which is the number the setup and hold checks on that crossing actually use.
By default `report_timing` (PT) reports the setup (max delay) check for the worst path, so a designer chasing a hold problem can stare at the wrong check without realizing it. Adding `-delay_type min` (PT) tells the command to report the minimum-delay, hold-side check instead, which uses a different required time and often a different worst path entirely.
By default `report_timing` (PT) prints only the single worst path for the endpoints it is scoped to, which hides every other path that is also close to failing. `-nworst N` (PT) reports the N worst paths per endpoint instead of one, so a designer can see whether a violation is an isolated path or the tip of a cluster of similar failures.
Writing `set_false_path` or `set_multicycle_path` (SDC) with a typo in a pin, instance, or clock name does not raise an error, PrimeTime simply applies the exception to zero paths and stays silent. `report_exceptions -ignored` (PT) lists every exception in the design that matched nothing, which is the only reliable way to catch this before it hides a real violation.
PrimeTime normally re-times only the parts of the design that changed since the last update, which is fast but relies on the tool correctly tracking every dependency. `update_timing -full` (PT) throws away that incremental state and recomputes timing for the entire design from scratch, which is the safer choice after a change the incremental engine might not fully track, such as a library swap or certain low-level scripted edits.
Reading in a large netlist, linking libraries, applying SDC, and running the first `update_timing` (PT) can take a long time on a real design, and repeating all of it just to check one more report wastes that time every session. `save_session` (PT) writes the fully loaded and timed design state to disk, and `restore_session` (PT) brings it back almost immediately, so a designer can pick up exactly where the last session left off.
A single-core PrimeTime run processes the design's timing update one operation at a time, which becomes the bottleneck on a design with millions of instances and many scenarios. `set_host_options -max_cores N` (PT) lets PrimeTime split timing updates and parasitic reads across N cores on the same machine, so the same update finishes in a fraction of the time.
Reading one `report_timing` (PT) result at a time tells you about a single path, but it says nothing about whether the design as a whole is converging toward closure or drifting further from it. `report_global_timing` (PT) summarizes the overall timing closure state across the design, how many endpoints are met, how many are violating, and by how much in aggregate, giving a single closure snapshot instead of a path-by-path picture.
Tapeout signoff is not one number, it is a checklist that every setup and hold check passes across every signoff corner and mode, every design-rule check like max transition and max capacitance is clean, and every endpoint in the design is actually constrained. Missing any one item on that list, even while the main slack number looks clean, means the design is not ready to tape out.
When a path fails setup because one cell along it is too slow, replacing that cell with a stronger drive-strength version of the same function is often the cheapest fix, since it changes delay without touching placement or routing. `size_cell` (PT) does exactly this inside an ECO session, swapping a named instance to a different library cell while PrimeTime checks the new cell fits the same footprint and pin function.
Resizing an existing cell only helps when a stronger version of the same function exists in the library and fits the same footprint, which is not always true, especially for a hold fix that needs a small, precise amount of extra delay. `insert_buffer` (PT) adds a brand-new buffer cell at a driver pin during an ECO, which is the standard way to add delay a resize cannot provide, or to fix a net with excessive load a single cell swap cannot absorb.
There is no `report_eco` command in PrimeTime, so this question has a false premise. Before fixing, `report_eco_options` (PT) confirms the settings the fixer is allowed to use, and `report_eco_library_cells` (PT) lists the candidate cells it can swap in. After fixing, the actual log of what changed comes from `write_changes -format text` (PT), which prints every size_cell and insert_buffer edit applied in the session as a readable change list.
Static timing analysis confirms the design meets timing inside PrimeTime, but other tools in the flow, gate-level simulation, other STA tools used for cross-checking, or a customer's own verification, need the same delay information in a portable, standard format. `write_sdf` (PT) exports PrimeTime's computed cell and net delays as a Standard Delay Format file, which is the accepted handoff format for carrying signed-off timing outside PrimeTime itself.
A single corner combines one process, one voltage, and one temperature assumption, and different corners can make different checks the worst one, a fast, low-voltage corner tends to be worst for hold while a slow, high-voltage corner tends to be worst for setup. A design that only reports clean at the typical corner has simply never been checked against the corner where its real worst violation would show up.
A SPEF file records the resistance and capacitance PrimeTime uses to compute net delay, and it describes one specific physical layout. Once an ECO adds a buffer, resizes a cell, or reroutes a net, the physical layout has changed, so the old SPEF no longer describes the real chip, and any timing report built from it is describing a design that no longer exists.
A hold fix, whether a resized cell or an inserted buffer, adds delay onto a net that other logic may also depend on, and that added delay can push a neighboring path that used to have a little hold margin into a violation of its own. Fixing one endpoint in isolation, without checking what else shares that net or driver, can trade one violation for another instead of clearing it.
Level 3: PrimeTime Analysis & Debugging
A DVFS scenario (one voltage/frequency operating point in a design that switches between several) can reach a command two ways: typed on the command as `-sms_scenarios` (PT), or inherited from a `push_sms_scenario` (PT) context around it. The explicit option always wins, and the pushed context is ignored for that command, not merged with it.
The command lists cells with no POCV (parametric on-chip variation, a statistical way of modeling how much a cell's delay can vary) coefficient or distance data - cells that quietly fall back to zero variation. Any path through one of them has under-modeled spread, so its reported corner is optimistic and can hide a real violation.
Annotated delays win by precedence, not by which one was applied last. `set_annotated_delay` (PT) sits at tier 1 and SPEF-derived parasitics sit at tier 3, so on any arc where both apply, PrimeTime uses the annotated value and ignores the SPEF-derived delay for that arc.
Correlation is a physical claim, not a convenience setting. A per-cell IR-drop annotation (a local voltage droop measured at one instance's supply pin) describes an independent local event, so PrimeTime compares the full worst-case voltage difference across it instead of assuming the driver and load move together.
Multi-input switching (MIS) is a delay adjustment applied when two or more inputs of a gate switch close together in time. On a 2-input NAND, both inputs falling together speeds up the rising output, which shortens the data path's minimum delay - the exact quantity a hold check uses - so MIS is scoped to hold, not setup.
PrimeTime propagates a defined clock waveform through the network to find each register's latency - source latency plus network latency - and derives skew from the differences. On top of that it adds clock uncertainty for jitter and margin, using ideal latency pre-CTS (clock tree synthesis) and real propagated latency post-CTS.
CCS (composite current source, a more detailed cell-timing model than the older NLDM tables) adds its own receiver-capacitance and driver tables. The safe max_capacitance limit is the lowest maximum load index across all of them, and the safe max_transition limit is the lowest maximum slew index across NLDM, CCS driver and CCS receiver_capacitance2 - set it from NLDM alone and DRC can pass while delay calculation quietly extrapolates.
StarRC run with SIMULTANEOUS_MULTI_CORNER: YES extracts several RC corners in one pass into a single multicorner GPD (Galaxy Parasitic Database) file. PrimeTime then selects one corner with `set_app_var parasitic_corner_name cworst_CCworst` (PT) and reads it - the payoff is that the expensive geometric extraction work happens once and is reused across every corner.
No - they correct different artifacts. CRPR (clock reconvergence pessimism removal) removes the double-counted delay on the clock segment shared by launch and capture; POCV's graph-merging pessimism removal separately removes the stochastic-max inflation that occurs where several fan-in distributions converge. A clock path needs both active.
Because SMVA (statistical multi-voltage analysis) is a full signoff feature covering noise across voltage combinations, and voltage-dependent noise response - crosstalk bumps and immunity - is captured only in a library's CCS noise models, not its CCS timing tables. A scaling group missing noise data on even one member library breaks the interpolation.
Trace voltage in the same order PrimeTime resolves it: `report_power_switch` (PT) for the switch's On State condition, `report_power_network` (PT) for the topology it feeds, `report_supply_net` (PT) for the output net's voltage, then `report_timing -voltage` (PT) or the pg_pin_info attribute on the cells. The most common root cause is a missing set_voltage on the switch's output net.
Refuse it. An ideal clock uses estimated or zero network latency, not the real skew of the clock tree that clock tree synthesis (CTS) just built, so it silently mis-times every path in the domain - hold checks worst of all, since hold is dominated by skew. Solve runtime with parallelism and prioritization instead, not by falsifying the clock model.
A generated clock's source latency is inherited from its master, not specified independently - it is the master clock's insertion delay from its origin down to the generated clock's source pin. PrimeTime computes it automatically when the master is propagated, and tracks it separately per edge because a clock network's rise and fall delays are not always equal.
Case analysis sets a fixed value and structurally kills every arc that value controls; set_disable_timing removes one specific arc or object entirely; set_false_path removes exactly the point-to-point paths named. There is an efficiency ladder favoring them in that order.
The SDF (standard delay format) standard defines INTERCONNECT delays only for nets internal to the design. A net connected directly to a primary input or output port describes the environment outside the design, and that is modeled instead with set_input_delay and set_output_delay - so non-annotation there is correct behavior, not a coverage gap.
Because a hold check's reference edge is derived from the same-cycle setup relationship, not defined independently. Moving the setup capture edge out by one cycle drags the implied hold edge forward with it, demanding data stay stable for a full extra cycle the real hardware never needs.
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.
Set `set_case_analysis 0 [get_ports SCAN_MODE]` (SDC) without enabling sequential case-analysis propagation on the scan flops, and the constant stops at their TE pins. It never crosses the flop, so the CP-to-TI scan arcs stay enabled and the scan chain keeps being timed - with no warning that anything is wrong.
Reason default describes the selection mechanism, not the mode - it means nothing actively chose or excluded that mode, so it fell back to the group's default state. That is the tell that your intended set_case_analysis never actually reached, or never satisfied, the mode's controlling condition.
Set `sdc_save_source_file_information` (PT) to true - its default is false - and PrimeTime records the file and line of every exception command going forward. The hard restriction is that it can only be changed before any exception has been read in; once one has, an attempt to change it errors out and the setting stays unchanged.
Derating factors (multipliers applied to a cell's delay to model variation) are an input to delay calculation itself, so changing which tables apply alters delays on a broad set of arcs at once. Because arrival times propagate transitively across the whole graph, the tool can't patch just a few endpoints - it forces a full recomputation. Set all variation data before the first update.
Default to `set_driving_cell` (SDC) whenever a real library cell can represent the external driver, since it uses that cell's actual load-dependent delay model. Fall back to `set_drive` (SDC) for a driver that has no library-cell equivalent, and use `set_input_transition` (SDC) when the port's slew is genuinely load-independent, or to match another tool that only supports a fixed transition.
OCV derates parts of a path differently to build a deliberately pessimistic worst case: for setup, the data path and launch clock are treated as slow while the capture clock is treated as fast; for hold, the assignment reverses. CRPR then credits back the pessimism double-counted on the clock segment both paths share.
Static timing analysis (STA) only checks that data arrives inside the setup and hold windows implied by the constraints you gave it - it cannot tell you whether those constraints describe the real hardware. A report with zero setup and hold violations can still ship a broken chip if a false path hid a real one, a clock-domain crossing was never checked for metastability, or a whole cone of logic was left unconstrained and silently dropped from the count.
Beyond the setup and hold check, PrimeTime also verifies recovery and removal times on asynchronous set/reset pins, minimum pulse width and minimum period on clocks, and design-rule limits like maximum transition and maximum capacitance. Any one of these can be skipped entirely if the object it applies to was never constrained, so a clean setup/hold report does not by itself mean every check actually ran.
Before place-and-route, PrimeTime estimates wire delay from a wire-load model or a rough placement guess; after routing, it uses real extracted parasitics from the actual metal geometry. Because interconnect delay - not gate delay - usually dominates at advanced nodes, a path that looked fastest on paper can become the slowest once real wire lengths and coupling are known, and a different path takes over as the critical one.
A flip-flop that toggles on every rising edge of an input clock divides that clock's frequency by two, and PrimeTime needs a `create_generated_clock` (SDC) statement at its Q output so the tool knows the new clock's period and phase instead of treating that pin as an ordinary data output. For a clock derived from the rising edge of its master, `-divide_by` is enough; for one derived from the falling edge, or with an uneven duty cycle, `-edges` gives the control `-divide_by` cannot.
When one generated clock feeds another - for example a divide-by-2 clock that is itself divided again to make a divide-by-4 clock - each stage's `create_generated_clock` (SDC) should name the immediately preceding generated clock as its `-master_clock` (SDC) and `-source`, not the original master, so PrimeTime can trace the chain edge by edge instead of guessing. Chaining the definitions this way keeps each stage's source-latency calculation limited to the logic between that stage and the one before it.
A phase-locked loop (PLL) needs its output clock declared as a generated clock with `-pll_feedback` and `-pll_output` (SDC) so PrimeTime can compute the phase correction the PLL applies between its reference and feedback pins. If a flip-flop sits on the feedback path - dividing the PLL's output frequency back down to match the reference - that flip-flop's output also needs its own generated-clock definition, because the PLL's phase correction only works once the tool can trace the entire loop, sequential elements included.
The `set_clock_jitter` (SDC) command, applied to a master clock, sets the same jitter properties on every clock generated from it, so you do not have to repeat the jitter values on each generated clock individually. `report_clock_jitter` (PT) then shows the cycle jitter, duty-cycle jitter, and which master clock's jitter each generated clock inherited, so you can confirm the propagation actually took effect.
Simple clock uncertainty describes the skew of one clock against its own ideal edges; interclock uncertainty describes the skew specifically between two named clock domains, and it is the more specific description of the two. When a path qualifies for both because its launch and capture clocks are different, PrimeTime uses the interclock value and ignores the simple one, on the assumption that a value written specifically for that pair of clocks is more accurate than a general per-clock value.
Setting `set_clock_uncertainty` (SDC) on a port or pin applies it only to the capturing registers downstream of that specific object; if multiple uncertainty values reach the same clock multiplexer from different ports, PrimeTime applies the worst of them to the mux's entire fanout, even to registers clocked by an input the mux is not currently selecting. Setting the uncertainty on the clock object itself avoids that ambiguity, because the value follows the clock definition rather than one physical point in its network.
A pulse generator that keeps the incoming clock's frequency but reshapes it into a narrow pulse can be described with the `pulse_clock` attribute instead of a full generated-clock definition, using one of four senses - `rise_triggered_high_pulse`, `rise_triggered_low_pulse`, `fall_triggered_high_pulse`, or `fall_triggered_low_pulse` - to say which master edge triggers which polarity of pulse. The actual pulse width is then set with `set_clock_latency` (SDC) rather than a waveform, because an ideal pulse-clock sense starts life with zero width by definition.
Because every valid hold relationship is defined relative to the setup relationship, changing the setup relationship with `set_multicycle_path -setup` (SDC) automatically moves the hold check's capture edge along with it - usually to a point that does not match what the design actually needs. The standard fix is to pair it with a second command, `set_multicycle_path (N-1) -hold ...` (SDC), that moves the hold capture edge back to where it belongs.
`report_exceptions` (PT) lists every exception-setting command and flags each one with a letter code when part or all of it was ignored - `f` for an invalid startpoint, `t` for an invalid endpoint, `p` for a non-existent path, and `o` for a path overridden by a higher-priority exception. A command that is fully ignored does not show up in the default report at all; `report_exceptions -ignored` (PT) is what surfaces those completely silent failures.
`report_timing -exceptions dominant` (PT) reports the single exception that actually governs a specific path, and `report_timing -exceptions overridden` (PT) shows any others that were considered but lost, when more than one exception-setting command touches the same points. As a general precedence rule, `set_max_delay` (SDC) outranks `set_multicycle_path` (SDC) on the same path, so an explicit maximum-delay override wins even if a multicycle exception was written for the same through-point.
When a `set_false_path` (SDC) or similar exception command names a sequential cell in its `-from` or `-to` option, PrimeTime automatically expands that command to every clock or data pin of the cell and applies the exception pin by pin. Some other tools, including IC Compiler II, keep the exception at the cell level instead of expanding it, so the same SDC line can end up resolving overlapping or conflicting exceptions differently depending on which tool reads it.
`reset_path` (SDC) removes a previously-set `set_false_path`, `set_max_delay`, `set_min_delay`, or `set_multicycle_path` (SDC) exception, but only if its `-from`/`-to`/`-through` object exactly matches the object used when the exception was originally set - a near match, like a different pin on the same net, silently does nothing. Any exception-setting command also accepts a `-reset_path` (SDC) option, which clears every existing exception on the matched paths first and then applies the new one, letting you replace an exception cleanly instead of stacking a new one on top of an old one.
A POCV Liberty variation table, such as an `ocv_sigma_cell_rise` (LIB) group, stores the standard deviation of a cell's delay as a function of input transition and output load, exactly the way a normal delay table stores the nominal delay itself, with a separate `sigma_type` of `early` or `late` for each direction of variation. PrimeTime looks up the sigma value for the arc's actual transition and load, then scales it by a corner multiplier - the K sigma value, 3 by default - to get the derate actually applied at each timing corner.
POCV analysis turns on with a single application variable, `set_app_var timing_pocvm_enable_analysis true` (PT), after which PrimeTime performs graph-based POCV timing updates automatically as part of every `update_timing` (PT) run; a POCV side file, if one is used instead of or alongside library-based data, is loaded separately with `read_ocvm` (PT). A cell with no variation data anywhere - no Liberty sigma tables and no side-file entry - simply gets no statistical derate on that arc, which is exactly what the diagnostic `report_ocvm -list_not_annotated` (PT) command is built to surface.
Single-parameter POCV models each cell's own random variation independently, as a statistical distribution built from that cell's own sigma data. Distance-based POCV instead models systematic variation across a timing path as a function of the physical distance the path spans on the die, computing one scalar derate factor from a lookup table and applying it to shift the mean of the path's timing - never the standard deviation - and the two can be combined in the same analysis, since PrimeTime computes and applies each contribution independently.
Ordinary, symmetric POCV models variation as a normal distribution, where the nominal delay and the statistical mean are the same number. Moment-based POCV instead allows an asymmetric distribution - a longer tail in one direction than the other - and once a distribution is skewed, its average value is no longer the same as the no-variation nominal value, so the library separately reports a mean shift describing exactly how far the mean has moved away from nominal.
Via variation models the manufacturing spread in vias - the connections between metal layers - as an independent, Gaussian random variable per via, contributing both delay and slew variation because a via carries both resistive and capacitive components. It specifically needs slew variation data from LVF libraries because a via's resistance affects how much the signal's slew degrades as it travels along the net, and that slew-degradation effect has to be computed and propagated accurately, not just its delay contribution.
A timing corner sets the process-voltage-temperature (PVT) condition a Liberty (.lib) library was characterized at; a SPEF corner sets the resistance and capacitance values a parasitic extraction tool computed for the same layout under a stated extraction condition. Signoff needs both because delay depends on two things that vary independently: how fast a transistor switches, and how much resistance and capacitance the surrounding wire adds. Pairing them wrong -- say, a slow-process library with a best-case, low-R low-C SPEF corner -- hides real violations instead of finding them.
A CCS timing model in the Liberty (LIB) library describes how a cell's output current drives its load, so PrimeTime can compute delay and slew accurately even when interconnect resistance rivals the driver's own resistance. A CCS noise model, a separate table in the same Liberty file, describes how well a cell resists or amplifies a glitch injected by a switching neighbor. Signoff loads both because a design can pass every delay check and still fail because a quiet net glitches past its receiver's noise-immunity threshold.
Crosstalk delay analysis checks two opposite effects on the same victim net: an aggressor switching the same direction can push the victim's edge later (delay push-out), while an aggressor switching the opposite direction can pull it earlier (delay pull-in). A setup check needs the worst push-out delay and a hold check needs the worst pull-in delay, and no single crosstalk-adjusted delay number captures both, so PrimeTime (PT) computes an early-mode and a late-mode delay for the same arc.
A setup check wants the parasitic corner that maximizes total delay, so it pairs with the extraction corner with the highest resistance and coupling capacitance (often labeled a worst, or RCmax, corner). A hold check wants the corner that minimizes delay and margin, so it pairs with the lowest-resistance, lowest-capacitance corner (often labeled a best, or RCmin, corner). The two checks use opposite ends of the same extraction spread because each is trying to catch the situation where timing is least forgiving for that particular check.
An extracted timing model (ETM) is a compact, black-box description of a block's input-to-output timing -- arrival times, required times, and internal delay arcs -- built once from the block's full netlist so the top-level analysis never has to re-read that netlist directly. Hierarchical designs use an ETM because loading every block's full gate-level detail at the top level makes a full-chip run too slow and too memory-heavy to iterate on, while an ETM keeps just enough timing information for the top level to check the block's boundary correctly.
A quick timing model (QTM) is a boundary timing model a designer builds by hand, from a spec or an early floorplan estimate, before a block's real netlist even exists. An extracted timing model (ETM) is instead generated automatically from a block's actual, already-implemented netlist. Teams use a QTM early in the flow, often just to hold a placeholder for top-level planning, and replace it with a real ETM once the block is designed and its true timing is known.
Two MCMM scenarios can be merged into one report only when they share the same constraints on every path the report will show, which usually means the same mode and enough corner similarity that neither scenario's worst path is masked by the other's. Scenarios get kept separate whenever a designer needs to trace a violation back to a specific mode or corner, since a merged view can only show the worst number across whatever it combined, not which scenario produced it.
An extracted timing model (ETM) keeps only enough information at each boundary pin -- arrival time, required time, and the constraints tied to it -- to reproduce the block's external timing behavior, and deliberately drops the internal gates and nets that produced those numbers. That compression is exactly what makes the model small and fast, but it also means the top level cannot see or verify any assumption baked into the block at extraction time, so a mismatch between what the block assumed and what the top level actually presents can go undetected.
A clock entering a block from the top level has to be defined consistently on both sides of the boundary -- same period, same source latency assumption, same propagation state -- or the block's internal timing and the top level's view of that same clock will silently disagree. Hierarchical flows handle this by generating the block's own clock definition from the top-level clock tree information available when the block is built, then re-verifying that definition once the real top-level clock tree exists.
A full `report_timing` (PT) path report has four readable sections in order: a header naming the startpoint, endpoint, and which check it reports; an arrival-time section that adds up every delay from launch to the endpoint; a required-time section that works out the latest, or earliest, legal arrival from the capture clock; and a slack line, simply required time minus arrival time. Reading it section by section, instead of jumping straight to the slack number, is what lets a designer find which specific arc is actually eating the margin.
`report_clock_timing` (PT) shows how a single clock propagates through its entire network -- every buffer and inverter from source to every endpoint -- separately from any one data path, which is what lets a designer isolate whether an odd number in a `report_timing` (PT) path report comes from the data logic or from the clock tree itself. Where `report_timing` shows one path's clock arrival as a single number buried inside a larger report, `report_clock_timing` shows the whole clock's latency and skew profile across all its endpoints at once.
A clock reconvergence pessimism removal (CRPR, sometimes shown as CPPR) line in a timing report is a correction the tool applies when the launch and capture clock paths share a common segment near the clock source -- it subtracts out the derating or variation margin double-counted on that shared portion, since the same physical wire cannot really run both faster and slower at once. It only removes pessimism from the common path; any divergent portion downstream of where the paths split still carries its own full derate on each side.
`report_exceptions` (PT) lists every timing exception currently set, including which ones a later, higher-priority exception overrode or which were ignored entirely because a more specific exception already covered that path. Reading that report -- rather than trusting that a `set_false_path` or `set_multicycle_path` (SDC) command you wrote was applied -- is the only reliable way to confirm which exception actually reached a given path when several could plausibly match it.
Comparing two PrimeTime runs on the same path means comparing them section by section the way a single report is read -- same startpoint and endpoint, same check type, then the clock path, the data path, and the required-time computation one arc at a time -- until the first point where the two runs diverge. That divergence point, not the final slack difference, tells the designer whether the change came from the library, the parasitics, the constraints, or an actual netlist edit.
A PrimeTime ECO fixes a hold violation by inserting a delay buffer or upsizing a cell on the failing path using commands like `insert_buffer` or `size_cell` (PT), choosing cells from a list of pre-placed spare cells or small legal gaps so the physical implementation tool doesn't need to re-place or re-route the design. Because hold is fixed by adding delay to the data path rather than by making anything faster, and delay-adding cells are small and local, this kind of fix can usually stay confined to the immediate site of the violation instead of disturbing the surrounding layout.
A PrimeTime setup ECO reduces delay along the failing path, usually by upsizing an undersized cell to drive its load faster or by inserting a buffer to split a long, slow net into two shorter, faster-driven segments -- both changes that `fix_eco_timing -type setup` (PT) can select automatically. This works without re-placement whenever a larger cell or an extra buffer fits into the existing site or a small nearby gap; when it doesn't fit, the ECO has to fall back to a fix that does require moving something, which is why setup fixes are less reliably placement-free than hold fixes.
A placement-only ECO moves existing cells to new legal locations without changing what those cells are or how they're connected -- used for physical fixes like DRC cleanup or small routing congestion relief. A full ECO changes the netlist itself -- swapping a cell's size or type, inserting a new buffer, or rewiring a connection -- which is what a timing fix from `fix_eco_timing` (PT) actually does, and which then requires the physical tool to place and connect whatever new or changed cell the edit introduced.
A PrimeTime ECO fix is verified against the single scenario it was computed in, using estimated parasitics for anything not yet physically routed, so it only proves the fix works under that one corner and that one estimate. Signoff needs every scenario in the full MCMM matrix re-checked with the real, post-implementation parasitics, because a fix that clears the violation it targeted can create a new one elsewhere, or fail to hold once the actual routed layout -- rather than the ECO tool's estimate -- is used.
A spare cell is an unconnected, pre-placed standard cell -- often a simple gate or buffer -- dropped into the layout during initial placement specifically so a later ECO can wire it into the netlist without adding anything new to the physical layout. A freeze-silicon ECO flow, used when the mask set can no longer change, depends on spare cells because every fix in that flow has to reuse existing silicon rather than requiring new cells to be placed and routed from scratch.
A violation is a good candidate for an ECO when it's small in magnitude, localized to a few paths, and fixable by resizing, buffering, or reconnecting a handful of cells without exceeding what spare capacity or small layout gaps can absorb. A violation calls for a full place-and-route re-run instead when it's large, widespread across many paths sharing a systemic cause -- a congested region, a poor floorplan decision, an under-resourced clock tree -- because an ECO can only patch individual paths one at a time and cannot fix the systemic condition creating many of them at once.
Level 4: Signoff Reasoning
A setup check compares when data arrives at a flip-flop against the latest time it is allowed to arrive. On-chip variation (OCV, the assumption that identical cells on the same chip can still run at slightly different speeds) forces the tool to derate the launch clock path late and the capture clock path early, even though both paths often share the same physical wires up to some branch point. That double-counts variation on the shared segment. Clock reconvergence pessimism removal (CRPR) finds that shared segment and credits back the extra margin.
Cell delay normally shortens as temperature drops, because carrier mobility improves — this is why designers default to the coldest corner for hold analysis. At low supply voltage, though, delay can start increasing as temperature drops instead, because the threshold voltage's own temperature dependence takes over from mobility. This reversal is called temperature inversion, and it means the coldest corner is not automatically the fastest, or the worst, corner for hold.
A frequency-divided relationship between two clocks — say a 2:1 crossing where one domain runs at half the frequency of another — is modeled with a generated clock: a clock definition that derives its edges from a source clock using a stated divide ratio, instead of an independent `create_clock` on the same physical clock pin. That lets the tool compute the exact synchronous relationship between every edge of both clocks, rather than treating the crossing as an unrelated, asynchronous boundary.
A compound generated clock — one that is first divided down from a faster source clock and then gated off (stopped and started) by an enable signal — has to encode both operations correctly in its SDC. Get either one wrong, and the tool computes the wrong period, the wrong edges, or fails to recognize the derived clock's relationship to the rest of the design, since it can only reason about the exact waveform the designer describes to it.
The tool walks the clock tree from its root toward the launch and capture flops and finds the last pin both paths still share — the common point. It then computes the derated delay to that pin twice: once using the derate factor the launch side would apply, once using the derate factor the capture side would apply. The difference between those two derated values is added back into the path's slack as the CRPR credit, because the shared silicon cannot actually run at two different speeds at once.
Flat OCV applies one multiplier to every cell and net delay on a path, regardless of how many stages the path has or how far it spans. Advanced on-chip variation (AOCV) instead looks up a smaller derate factor for paths with more logic stages or a shorter physical span, because random gate-to-gate variation partially cancels out over many stages, while systematic variation grows with distance. The result is a path-specific factor that is usually less pessimistic than one flat number applied everywhere.
Parametric on-chip variation (POCV) gives each timing arc its own nominal delay and a standard deviation, or sigma, taken from the library's variation data — rather than one derate factor applied uniformly. Along a path, independent per-arc sigmas combine statistically, so total path variation grows with roughly the square root of the number of stages, not linearly with stage count the way flat derating effectively does. That makes flat derating increasingly over-conservative on long paths.
`set_timing_derate` (SDC) is the command that applies OCV derate factors. Its qualifiers scope exactly what gets multiplied: `-early` or `-late` chooses shortest-path or longest-path delays, `-cell_delay`/`-net_delay`/`-cell_check` chooses which kind of delay component, and `-clock`/`-data` chooses which side of the path. Omitting a scoping qualifier applies the factor to everything in that early/late direction across the whole design.
Crosstalk delay happens when the victim net is already switching, and a neighboring aggressor net's coupling current speeds up or slows down that transition — this shifts when the victim crosses its switching threshold, changing timing. Crosstalk noise happens when the victim is quiet, and coupling current alone produces a spurious glitch bump. The Miller effect is why an aggressor switching in the opposite direction from the victim roughly doubles the effective coupling capacitance compared to a quiet aggressor, since the voltage across the coupling capacitor changes by twice as much.
Naively adding every aggressor's individually worst-case contribution assumes all of them can switch at exactly the moment needed to maximally disturb the victim, in the worst-case direction, all at once. Two things actually constrain this: each aggressor's own timing window (the real range of times its edge can occur, given its own paths and clocks) may not even overlap the victim's transition window, and the probability that every small aggressor aligns simultaneously in the same direction drops fast as the aggressor count grows — which is why the tool can use a statistical composite-aggressor model instead of a flat worst-case sum for the smaller contributors.
PrimeTime does not include a command that creates or schedules useful skew (deliberately unbalancing clock arrival times at different flops to borrow slack from one path and give it to another). That scheduling happens upstream, during clock tree synthesis in the implementation tool. PrimeTime's role is downstream: it analyzes and reports whatever skew already exists in the clock tree, using commands like set_clock_uncertainty and report_clock_timing, rather than commands that build the skew into the tree in the first place.
set_false_path and set_max_delay are point-to-point exceptions: they remove or replace the timing requirement on specific paths but the tool still computes and can report the path's delay. set_disable_timing instead removes the arcs through a pin, cell, or port from the timing graph entirely, so no path can be traced through that point at all — more efficient when every path through a point is genuinely false. When exceptions conflict on the same path, PrimeTime resolves it per path using a fixed priority: set_false_path beats set_max_delay/set_min_delay, which beats set_multicycle_path, and a more specific -from/-to/-through specification beats a more general one.
report_timing offers point-based filtering with -from, -to, and multiple -through arguments (order matters — each -through is matched in sequence), count-based filtering with -nworst and -max_paths, and slack-based filtering with -slack_lesser_than. Path tagging is a separate feature: it marks a set of already-analyzed paths with a name, so a later exhaustive path-based analysis (PBA) run can skip re-analyzing paths already covered by an earlier, cheaper analysis mode, saving runtime on a technique that is otherwise expensive to run broadly.
Total negative slack (TNS) sums up how much every violating endpoint is behind schedule. In union mode (the default), each endpoint contributes only its single worst negative slack value to the total, even if it belongs to more than one path group or scenario. In every-group mode, an endpoint contributes separately for every path group it is negative in, so the same physical flop can be counted more than once. The tool selects the mode with the timing_report_union_tns variable, and the choice changes the reported TNS magnitude significantly once distributed multi-scenario analysis (DMSA) combines several scenarios together.
fix_eco_timing fixes setup violations by default using cell sizing alone, reducing data path delay without adding buffers, while it fixes hold violations using both cell sizing and buffer insertion, adding delay where a path is too fast. Setup is fixed first because it is the harder violation to repair and is allowed to introduce new hold violations along the way; hold is fixed second, and it deliberately avoids reintroducing setup or design-rule violations, since fixing hold after setup means the setup picture is already considered final.
MCMM (multi-mode multi-corner) is the requirement to verify and optimize timing across every combination of a design's functional modes and its process/voltage/temperature corners, since a chip must work correctly in every mode it will actually run and at every corner silicon can land on. DMSA (distributed multiscenario analysis) is the execution architecture that makes checking all those combinations tractable: a manager process coordinates a scenario for each mode-corner combination, running each on its own worker process, then merges the results back into one signoff view.
RC corners model the extremes of interconnect variation caused by manufacturing spread in wire width and spacing. Cmax pairs wider wires and tighter spacing (lower resistance, higher capacitance); Cmin pairs narrower wires and wider spacing (higher resistance, lower capacitance); RCmax and RCmin describe the analogous extremes when resistance, not capacitance, dominates delay. A short net's delay is driven mostly by capacitive loading, so Cmax tends to be its setup-worst corner; a long net's delay is driven mostly by resistive RC delay, so RCmax tends to be its setup-worst corner instead — the same physical wire extremes stress different nets differently depending on which effect actually dominates their delay.
A zero-violation summary only proves that whatever paths, corners, and checks the tool actually looked at came back clean — it says nothing about paths that were never constrained, corners that were never run, or exceptions that silently swallowed real risk. A rigorous signoff declaration means working through a full checklist — every mode-corner scenario, OCV/derating settings, crosstalk analysis, exception review, and unconstrained-endpoint checks — and confirming each one was genuinely covered, not just that the final number happened to read zero.
Observing that a handful of measured parts consistently beat signoff timing can be a legitimate signal of recoverable over-conservatism, worth investigating carefully. But treating it as proof that margins should simply be relaxed is dangerous, because the parts an engineer typically gets to measure are the ones already close to typical process — not the worst-case-corner parts signoff margins exist specifically to protect. A design that never violates on the parts you measured says little about the parts you didn't.
Three layers stack on top of each other. Base CRPR removes the ordinary OCV double-count on the shared clock segment when the tool computes final slack. A second layer removes the coupling-delay pessimism CRPR would otherwise miss on that same shared segment, but only for zero-cycle checks, where the identical clock edge launches and captures. A third layer, enabled by pba_enable_xtalk_delay_ocv_pessimism_reduction, extends CRPR into the arrival-window computation itself during path-based analysis (PBA), since those windows do not get CRPR by default.
Both effects change the same number — min delay, which is the value the hold check compares against the clock's arrival. Multi-input switching (MIS, a faster delay the library allows when several gate inputs switch together) shortens the data side, so data arrives earlier. Clock reconvergence pessimism removal (CRPR) adjusts the shared portion of the launch and capture clock paths. The hold check then compares the MIS-shortened arrival against the CRPR-adjusted capture time — and the two effects do not push the same way, so both need to be modeled correctly to get the true margin.
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.
The SDC commands and checks are the same on both. What changes is how much proof you must produce that every constraint is correct: a safety-critical design demands justified I/O timing budgets, zero-tolerance completeness checks, individually reviewed exceptions, and an auditable record of which constraint version signed off which tapeout. A consumer design runs the same methodology with lighter formal review, because the cost of a mistake is quality risk rather than a safety hazard.
Every setup and hold check in the whole signoff is measured against the clock model, so a clock mistake corrupts many paths at once and produces no distinct error message — it just looks like ordinary timing data until it fails silicon. The methodology cost is small and reused on every run; the exposure it prevents is measured in respins and schedule, so the return is heavily asymmetric.
A max-delay corner is the worst-case setup condition — the slowest the design can legally run. Lower supply voltage gives a transistor less drive current, so switching is slower and delay is larger. That is why the positional (max-delay) value in set_voltage is the lower voltage in the pair, and the -min value — the min-delay, hold-checking voltage — is the higher one.
Treat it as an investigation, not a slack-closing shortcut. Confirm the path is real and see what already constrains it, get the real number of allowed cycles from the RTL designer, apply set_multicycle_path -setup N with the matching -hold (N-1), then re-check with report_timing -exceptions all that the exception is dominant and covers exactly this path and nothing else.
A forgotten set_resistance override on one net outranks a later, accurate SPEF read for that same net, because PrimeTime's back-annotation precedence puts lumped resistance and capacitance commands above detailed parasitics. report_annotated_parasitics -check still passes, because the net does have a complete RC network — it just is not the one everyone assumes.
Parametric on-chip variation (POCV) models delay variation on cell and net arcs by default, but not automatically the variation of the setup and hold requirements themselves. That needs a separate enable, timing_enable_constraint_variation, plus library data in Liberty variation format (LVF). Forget it and the tool compares a distribution of arrival times against a fixed, zero-variation requirement — an inconsistent and optimistic model.
Standardize whatever must be identical everywhere it appears to compose correctly across the chip — the primary clock definitions, the clock-group relationships, the ideal-versus-propagated and uncertainty conventions, and the verification gates. Delegate whatever is genuinely internal to one block, like a local generated clock or a block-specific uncertainty refinement, as long as it follows the standardized conventions.
report_timing is the signoff number, and the gap almost certainly comes from a merging step that only report_timing performs: it merges adjacent common-clock-path points whose reconvergence pessimism differs by less than a threshold, 5 picoseconds by default, which slightly under-credits pessimism removal. report_crpr reports the unmerged, more granular value, so hand-adding its numbers on top of a separately-run report_timing double-counts or misaligns the credit.
A transparent latch endpoint gets two separate reconvergence pessimism values, one for the opening edge and one for the closing edge, because the two edges sit on opposite clock polarities. Opening-edge pessimism reduces how much time is available to borrow; closing-edge pessimism increases the maximum borrowing allowed. The two effects push in opposite directions and do not cancel out.
Both designs use the same clock commands and modeling; what changes is how exhaustively completeness is verified, how conservatively margins are chosen and justified, and how traceable the clock spec is back to the fabricated design. Safety-critical work treats a clock error as a potential undetected hazard and adds evidenced gates and independent review; consumer work applies the same methodology with proportionate, lighter review.
Applying the full multi-input switching (MIS) speed-up factor unconditionally, with the arrival-window overlap check disabled, is the optimistic extreme for hold — MIS shortens min delay, so removing the check that limits when the speed-up applies can make data arrive earlier than the model shows and hide a real hold violation. It trades accuracy for runtime, and the accuracy it gives up is on the unsafe side.
Support reduction only where it is provably safe — merging modes whose constraints are genuinely compatible, or distributing the existing scenario set to run in parallel — never by silently dropping a corner. Each mode-and-corner scenario represents a real operating condition; blindly removing one means whatever path is worst-case there is simply never checked, with no signoff warning that anything was skipped.
Possibly. Crosstalk-induced delay change on the shared segment of the launch and capture clock paths is only pessimistic — and only removable by CRPR — for a zero-cycle check, where the same clock edge launches and captures. The discriminator is whether this specific check is zero-cycle; if it is not, the crosstalk effect on launch and capture cannot be assumed identical, and CRPR correctly leaves it alone.
Standardize whatever must be consistent, correct, and comparable across the organization — the flow structure, the mandatory validation gates, reproducibility controls, sign-off criteria, and result format. Delegate genuinely project-specific configuration — the mode-and-corner matrix, library versions, design-specific exceptions, and debugging approach — inside that standardized framework.
Push the library team toward accurate, correctly-versioned characterization with the node's real models; the synthesis team toward a clean, linkable netlist and a shared constraint source; the RTL team toward clean, documented clocking; and establish shared naming and versioning conventions plus a fast feedback loop so a defect is reported and fixed at its source, not patched downstream on every run.
For a capture edge at time t, the tool pairs it with the nearest launch edge strictly before t — never the edge at exactly t itself — because data launched at the same instant it is captured would need zero propagation delay through real logic, which is physically impossible. Reaching back to the previous edge gives a smaller available window and therefore the more restrictive, correct setup requirement.
Both features exist because a clock mesh or spine has huge numbers of nearly identical nets, but they solve different problems. The PORT construct, enabled with sdf_enable_port_construct, shrinks SDF file size by collapsing near-identical INTERCONNECT delays into one PORT statement. Multidrive alignment, enabled with sdf_align_multi_drive_cell_arcs, forces one worst-case delay onto parallel driver cell arcs so a downstream simulator does not fail on ambiguous multidriven timing — and unlike the PORT construct, it is deliberately pessimistic.
The tool ranks slack separately inside each path group, so the single worst number it prints is the worst slack in whichever group you are looking at, not necessarily the tightest path in the whole design. A path with a false path or multicycle exception removed from consideration, or one sitting in a different, less-scrutinized group, can be the real limiter on maximum frequency while the reported "critical path" belongs to a group with an easier bar. Trusting one worst-slack number without checking group membership and coverage across every group can hide the actual bottleneck.
Without `set_propagated_clock` (SDC), the tool times every clock path as an ideal network with only the latency and uncertainty values a designer supplied, so it never sees the real, branch-by-branch skew that clock tree synthesis introduces. A path that looks comfortably positive under the ideal-clock assumption can flip to a violation the moment real, propagated clock latency is applied, because the ideal model was silently optimistic about how well-aligned the launch and capture clock edges really are.
A normal `set_clock_latency` (SDC) value replaces the clock's computed source latency outright, but the `-pll_shift` option adds its value on top of whatever base latency the tool already derived for a PLL-generated clock. That distinction lets a designer layer a PLL's drift and jitter numbers onto the real, feedback-computed latency instead of overwriting it, which is the only way to keep a PLL feedback loop's timing internally consistent.
A pulse clock — a signal that produces a narrow high or low pulse from each edge of a source clock — is defined with `create_generated_clock -edges {n1 n2 n3}` (SDC), where the three numbers name which edges of the source clock trigger the pulse's rise, its peak, and its fall. Repeating one of those edge numbers is what tells the tool "this is a pulse," and which edge number is repeated, and where in the list it repeats, determines whether the pulse is active-high or active-low and whether it is triggered from the source's rising or falling edge.
Each stage of a divider chain — divide-by-2, then divide-by-4, and so on — needs its `-master_clock` (SDC) reference to be the generated clock immediately upstream of it, not the original source clock, because the tool derives a generated clock's waveform by tracing the real logic between it and its named master. Naming the original clock as master for every stage asks the tool to trace through logic already assigned to a different clock domain, which it cannot do, and the result is an unexpanded generated clock that PrimeTime cannot time correctly.
`report_clock_timing -type latency` (PT) prints, per clock pin, the transition, source latency, network latency, and total latency the tool actually computed, which is the direct way to confirm a generated clock expanded correctly instead of just trusting that the SDC no longer throws an error. A generated clock that traces properly shows a real, non-zero source latency inherited from its master and a network latency consistent with its position in the clock tree; one that still has a tracing problem shows a zero, missing, or clearly wrong latency value even when the SDC itself no longer reports an error.
Every `-through` point inside a single `set_false_path` (SDC) command must be crossed, in the order given, for that command to match a path — it behaves like an AND across the list. Two separate `set_false_path` commands, each with its own `-through` point, instead act like an OR: a path is false if it matches either command's full requirement, not only if it satisfies both commands' through-points together.
PrimeTime applies exception precedence independently to each path, not each command, and among conflicting exception types the fixed order is `set_false_path` first, then `set_max_delay`/`set_min_delay`, then `set_multicycle_path` last. When two or more of these types genuinely conflict on the same path, only the highest-ranked one takes effect and the others are silently ignored for that path.
Path specification priority in PrimeTime is based entirely on how specific the object types named in `-from`/`-to`/`-through` are, not on the order the commands appear in the SDC file. A command naming exact pins ranks above one naming a clock, so the pin-level command wins on any path both commands touch, regardless of which line was written earlier.
`report_exceptions -ignored` (PT) lists every exception command the tool computed but did not apply, because a higher-priority exception — by type or by specificity — already governed that path. Running it across the whole design after every exception file is loaded is the only systematic way to catch an exception that was accepted by the SDC parser but never actually took effect on any path.
A logic constant set with `set_case_analysis` (SDC) propagates automatically through combinational gates, but the tool stops it at a flip-flop's output by default, because a sequential cell's output value depends on its stored state and clock behavior, not purely on its input value the way a combinational gate's output does. Overriding that default — for the whole design with a variable, or for specific cells with `set_case_sequential_propagation` (PT) — is a deliberate, narrow decision, not something to switch on globally without checking each cell it affects.
CRPR only gives back derate on the portion of the clock tree that the launch and capture paths genuinely share in common — it never touches derate applied to the parts of the tree that diverge. On a path where the divergent branch is where the real timing risk sits, removing pessimism from the shared trunk does nothing to help that risk, while the tool still fully derates the divergent branch in the pessimistic direction, so the net effect on hold slack can be negative rather than positive.
A PLL's multiple outputs are all locked to the same reference and, by construction, meant to stay in phase with each other, so PrimeTime models them as indistinguishable for CRPR purposes even though their last shared physical pin is deep inside the PLL, far from the launch and capture flops. Removing pessimism up to that reference point is essential, because treating the outputs as independently variable would invent skew between two clocks that the PLL's own design guarantees stay aligned.
LVF lets a cell's own Liberty timing arcs carry distance-based derating factors directly in the library, alongside the ordinary POCV sigma tables, so the tool can look up a derate that depends on how far apart two timing points are in the clock network without loading a separate AOCV side file at all. Because the data lives in the library and can vary with slew and load like any other LVF table, it is functionally equivalent to a side file's distance-based table, but automatically tied to the cell characterization it came from.
By default, `set_timing_derate` (PT) affects only ordinary, flat cell and net delays — it does not touch the separate statistical models AOCV and POCV use, because those models already carry their own, more detailed variation data and blending in a flat percentage on top would double up two different representations of the same physical variation. The `-aocvm_guardband`, `-pocvm_guardband`, and `-pocvm_coefficient_scale_factor` options exist specifically to adjust the AOCV or POCV models themselves, separately from the ordinary derate command's default scope.
A hold failure that only shows up after routing, and not before, usually means crosstalk delay is pulling in (speeding up) the data path or the clock path once real coupling capacitance exists between physical wires. The debug approach is to re-run with signal integrity analysis on, find which net actually moved the arrival time, and confirm the aggressor and victim really switch inside the same timing window. The fix targets the coupling itself, not the derate margin.
Turning on signal integrity (SI) analysis adds a crosstalk delay margin to every net PrimeTime believes could be an aggressor or victim, and graph-based analysis (GBA) applies that margin using a bounded worst-case switching window rather than a path's real timing. That extra, pessimistic margin can push previously comfortable paths close enough to zero slack that they now need a path-based (PBA) re-check to confirm whether the violation is real.
A single RC extraction corner cannot represent worst-case crosstalk on both sides of the same coupling event, because the aggressor needs a fast edge while the victim needs to look slow and easily disturbed. Signoff handles this by extracting the same physical nets under different assumptions for the aggressor and the victim inside one crosstalk check, rather than picking one corner for the whole design.
A crosstalk glitch on a quiet net is only a real problem if the receiving gate is weak enough to be fooled by it, and Liberty's CCS noise (composite current source noise, a table format capturing how a cell's output responds to a disturbance) tables define exactly how much glitch height and width a given receiver can absorb before it forwards a wrong value. PrimeTime compares the actual glitch it calculates on the victim net against that receiver-specific immunity curve, not against one flat voltage threshold.
Budgeting means splitting a top-level path's available time among the blocks it passes through, before every block has its own final implementation, so each block team knows its own setup and hold targets. Because the total time on a path is fixed, giving one block extra margin necessarily takes margin away from another block on the same path, so budgeting is a negotiation over a shared, limited resource, not just a per-block guess.
HyperScale, a hierarchical timing method that analyzes a block using a compact model instead of its full netlist, relies on a block context: boundary loads, arrival times, and derating assumptions taken from the top-level environment when the block model was built. If the top level changes after that snapshot, for example the floorplan shifts or a neighboring block's clock tree changes, the block context goes stale, and signoff run against it can pass on paper while the real chip does not.
A block closed bottom-up against budgeted constraints, assumed boundary timing rather than real top-level values, needs to be checked against a flat, full-chip run once the top level exists, because the budget was always an estimate. Reconciliation compares the block's assumed boundary arrival and required times to what the flat run actually computes at those same pins, and treats any gap as a signal that the budget, the block, or both need another pass.
A block's standalone signoff only checks timing against the boundary assumptions used to build its extracted timing model (ETM, a compact stand-in for the block's internal timing used at the top level), not against the real conditions the top level ends up creating. If the top level's actual clock arrival, skew, or loading at the block's boundary differs from what the standalone run assumed, the same block that passed on its own can produce a failing path once its ETM is stitched into the full-chip analysis.
An unconstrained endpoint is a register, port, or latch input with no required time defined for it, so PrimeTime cannot check setup or hold there at all; it is not a passing path, it is simply not being checked. Finding it means turning on unconstrained-path reporting with the `timing_report_unconstrained_paths` variable (PT) and running `check_timing` (PT) or `report_timing -exceptions all` (PT), which lists the endpoint and states why it has no required time.
When two timing exceptions apply to overlapping parts of the same path, PrimeTime enforces only one of them, the dominant one, based on a fixed priority order, not the order they were written in the SDC. `report_timing -exceptions dominant` (PT) shows which exception actually won, which can be a `set_max_delay` (SDC) or `set_false_path` (SDC) command instead of the `set_multicycle_path` (SDC) you may have written for that same path, if a higher-priority exception also touches it.
`report_timing` (PT) prints a fixed, human-readable report of one or a few paths at a time, which does not scale to triaging hundreds of near-critical paths after a big netlist change. `get_timing_paths` (PT) instead returns a collection of path objects that a script can filter, sort, and summarize programmatically, which is the tool built for large-scale triage rather than one path at a time.
`report_analysis_coverage` (PT) reports how many endpoints were actually tested for each check type, setup, hold, and design rule checks, against how many exist in the design, which is the direct way to prove a signoff run covered everything rather than inferring it from a clean slack summary. In a multi-scenario run, several mode and corner combinations analyzed together, the merged version of this report rolls that same coverage question up across every scenario at once.
With that little time, the priority is grouping violations by root cause before fixing anything, because 3,000 individual violations are rarely 3,000 independent problems; most trace back to a handful of systematic causes like one under-sized clock buffer stage or one derate setting. Fix the highest-leverage systematic cause first, re-run incrementally to see how many violations that single fix clears, then triage what remains, rather than working the list top to bottom.
A cell swap that fits in the same physical footprint and existing routing can often be verified with PrimeTime's incremental timing update alone. But a swap that changes the cell's size, pin locations, or drive strength enough to need new placement legality or different routing invalidates the parasitics PrimeTime is using, so timing needs to be re-extracted, and sometimes re-routed, before signoff can trust the result.