STA interview questions, with worked answers and numericals

STA checks that every timing path in a synchronous design meets its requirements without input vectors. The tool breaks the design into paths, computes the latest and earliest arrival at each endpoint from library and parasitic data, compares them with the required times set by the clocks and constraints, and reports a slack for every check.

• Netlist: the gate-level Verilog.
• Libraries: Liberty (.lib) timing models for every cell, one set per PVT corner.
• Constraints: SDC with clocks, I/O delays, exceptions and design rules.
• Parasitics: SPEF after routing (or estimates before).

Outputs are timing reports, WNS/TNS summaries, design-rule violations, unconstrained-path reports, and optionally an SDF for gate-level simulation.

Setup time is the minimum time data must be stable before the active clock edge. Hold time is the minimum time it must stay stable after the edge. Together they define a window around the edge where the D input must not change.

Inside the flop, the master latch needs time to settle the new value before it closes (setup), and the old value must not be disturbed while the slave takes over (hold). If data changes inside the window, the flop can capture the wrong value or go metastable: its output hangs between 0 and 1 for an unpredictable time before resolving.

Setup (data must arrive before the next capture edge):

Arrival  = T_launch + T_clk→q(max) + T_comb(max)
Required = T + T_capture − T_setup − T_uncertainty
Setup slack = Required − Arrival

Hold (data must not arrive before the hold window of the same edge closes):

Arrival  = T_launch + T_clk→q(min) + T_comb(min)
Required = T_capture + T_hold + T_uncertainty(hold)
Hold slack = Arrival − Required

T_launch and T_capture are the clock latencies to the two flops. Positive slack passes; negative fails. Note that the period T appears only in setup.

Skew is the difference in clock arrival time between the capture and launch flops: skew = capture latency − launch latency.

• Positive skew (capture clock later): the capture edge moves out, so setup gets more time. The hold requirement also moves later, so hold gets worse by the same amount.
• Negative skew (capture clock earlier): setup loses time, hold gains margin.

That trade-off is exactly what useful skew exploits: delaying a capture clock to rescue a failing setup path, as long as the hold check on that flop pair and the setup of the next stage still pass.

The hold check compares data launched by a clock edge with the capture flop's hold window on that same edge. Both sides of the equation move together with the edge, so the period never appears in it. Slowing the clock gives setup more room but leaves hold slack exactly where it was.

That's why hold is treated as a functional failure: a chip with a hold violation fails at any frequency, while a setup failure can at least be recovered by running slower.

Hold is fixed by adding delay to the data path (buffers or delay cells, usually near the capture flop), using slower cells on that path, or reducing harmful positive skew.

1. Input to register: input port → flop D pin.
2. Register to register: flop clock pin → flop D pin.
3. Register to output: flop clock pin → output port.
4. Input to output: a purely combinational path through the block.

There are also clock paths, clock-gating check paths and asynchronous (reset) paths checked with recovery and removal.

Startpoints are clock pins of sequential cells and input ports. Endpoints are data pins of sequential cells (D, enable, async set/reset, scan enable), clock-gating enable pins and output ports.

A false path is one that never needs to be timed: it can't be sensitised functionally, or it crosses between clocks that are handled by synchronisers. STA stops checking it completely.

A multicycle path is real and must be timed, but the design guarantees it has more than one cycle, e.g. data that's only sampled every second cycle using an enable.

set_multicycle_path 2 -setup -from [get_cells src_reg*] -to [get_cells dst_reg*]
set_multicycle_path 1 -hold  -from [get_cells src_reg*] -to [get_cells dst_reg*]

The setup MCP moves the capture edge out to the 2nd edge. By default the hold check then moves to the edge just before it (one cycle after launch), which would demand that data stay stable for a whole cycle. The -hold 1 moves the hold check back to the launch edge, as in a normal single-cycle path.

Two identical cells on the same die don't have identical delays because of local process, voltage and temperature variation. OCV models this pessimistically within one corner:

• Setup: launch clock and data path get late derates (slower), the capture clock gets an early derate (faster).
• Hold: the reverse: launch and data early, capture late.

Flat OCV applies one derate everywhere, which is overly pessimistic for long paths. AOCV indexes the derate by logic depth and distance, since random variation partly cancels over many stages. POCV/SOCV models each cell's delay as a mean plus N·sigma (sigma usually from LVF tables in the Liberty) and combines them statistically along the path.

Launch and capture clock paths usually share a common segment from the clock source down to where the tree branches. With OCV, the tool derates that segment late on the launch side and early on the capture side, which is physically impossible: the same buffers can't be slow and fast at the same moment.

Clock path pessimism removal adds that difference back to the slack:

CPPR credit = late delay − early delay of the common clock segment

Example: a common segment of 0.84 ns late and 0.76 ns early gives 80 ps of credit, enough to turn a −50 ps path into +30 ps. Deeper branching points mean more shared buffers and more credit.

A divider, multiplier or clock-gating output creates a new clock whose waveform is derived from a master. create_generated_clock tells the tool that relationship:

create_clock -name CLK -period 1.0 [get_ports clk]
create_generated_clock -name CLK_DIV2 -source [get_ports clk] \
    -divide_by 2 [get_pins u_div/q_reg/Q]

Without it, the tool doesn't see the flop output as a clock source. Flops clocked by it may be unclocked (unconstrained), the tool may time the clock net itself as data, and paths between the master and divided domains are timed with wrong or missing edge relationships. Source latency through the divider is also lost.

With both clocks defined, the tool finds the tightest edge pair, e.g. a 1 GHz master to a divide-by-2 clock gives a 1 ns setup relationship.

Input and output delays describe how much of the cycle is used outside your block, relative to a clock (often a virtual clock).

• Input max = external T_clk→q,max + board/external logic max. Used for setup.
• Input min = external T_clk→q,min + board/external logic min. Used for hold.
• Output max = board/external logic max + external setup.
• Output min = board/external logic min − external hold.

set_input_delay  -clock VCLK -max 2.0 [get_ports din*]
set_input_delay  -clock VCLK -min 0.8 [get_ports din*]
set_output_delay -clock VCLK -max 1.6 [get_ports dout*]
set_output_delay -clock VCLK -min -0.2 [get_ports dout*]

Multi-corner multi-mode analysis times the design in every combination that matters: modes (functional, scan shift, scan capture, low-power states), each with its own clocks and constraints, and corners (process, voltage, temperature and RC extraction corner). A mode + corner pair is a scenario.

• Setup is traditionally worst at slow process, low voltage, high temperature, with Cworst/RCworst parasitics.
• Hold is worst at fast process, high voltage, low temperature, with Cbest/RCbest parasitics.

At advanced nodes, temperature inversion means cells can be slower at low temperature at low voltage, so setup must also be checked at the cold slow corner.

1. Check the setup is valid: clocks propagated, pre-CTS uncertainty reduced to post-CTS values, CPPR enabled, correct hold scenario loaded.
2. Look at the distribution. Thousands of small violations (tens of ps) are normal and get fixed by hold optimisation. A cluster of violations close to one clock period points to a constraint bug, usually a setup MCP without its hold partner.
3. Group by clock pair and hierarchy. If they share a clock pair, check for skew between those branches or a missing clock group.
4. Check scan paths: shift paths between adjacent flops have almost no logic and are classic hold failures.
5. Fix structural causes first, then run hold optimisation, and re-check setup at the slow corners.

• Compare the same path in the passing and failing scenarios stage by stage. Which increments grew the most?
• If net delays grew, it's parasitics: the failing corner is probably an RC-worst corner and the path has long wires. Fix with buffering, layer promotion or placement.
• If cell delays grew unevenly, check for cells with strong voltage or temperature sensitivity (high-Vt cells at low voltage, temperature inversion at cold).
• If the clock changed, check skew in that corner; clock and data paths don't scale identically across corners.
• Also check it isn't a mode issue: different case analysis or constraints in that scenario.

Then fix with an MCMM-aware tool so the fix doesn't break hold in the fast corner.

First check the report is realistic: are the aggressors' timing windows actually overlapping with the victim, and are any aggressors on a clock that's asynchronous or mutually exclusive? Filtering infeasible aggressors can remove much of the delta.

If it's real, fix the coupling or the victim:

• Increase spacing or add shielding (a NDR on the victim).
• Reroute or change layers to cut the parallel run length with the main aggressor.
• Upsize the victim's driver so it holds its transition, or split the net with a buffer.
• Reduce the aggressor's slew (downsize it) if it has timing margin.

Opposite-direction switching slows the victim (setup); same-direction switching speeds it up (hold). Re-extract and rerun SI-aware STA after the fix.

No. Unconstrained endpoints aren't checked at all, so the clean report says nothing about them. Real violations can be hiding there.

1. Group the endpoints by cause. Typical ones: flops with no clock (missing create_clock or create_generated_clock), ports with no input or output delay, clocks blocked by set_case_analysis or a disabled arc, or a too-broad false path.
2. Decide for each group whether it's intentional (e.g. tie-off flops, a test-only port in functional mode) and document it, or a constraint gap.
3. Fix the SDC, rerun, and track the unconstrained count as a signoff metric.

The path has a narrow setup–hold window: delay cells add a little at the fast corner (where hold is checked) and a lot more at the slow corner (where setup is checked). Example: hold needs +120 ps at the fast corner, a delay cell adds 40 ps fast and 90 ps slow, setup has +200 ps. Three cells fix hold but cost 270 ps of setup, so setup fails by 70 ps.

• Attack the skew: large positive skew between the two flops makes hold hard; reducing it helps hold without adding data delay.
• Fix only the short branch: if the endpoint has fast and slow fan-in, put delay on the branch that's actually short, not the shared segment.
• Use delay elements with a smaller slow/fast ratio (wire-based delay, different Vt).
• Check that both checks are real: a missing hold MCP or an over-pessimistic uncertainty can create the conflict.

Graph-based analysis propagates the worst slew and worst derate seen at each pin, even if they come from different paths, so it's pessimistic. Path-based analysis recomputes the specific path with its own slews (and, with AOCV/POCV, its own depth), so it's more accurate and usually shows better slack.

If your signoff methodology accepts PBA for final checks, yes: a PBA pass on that path is a real pass. Two cautions:

• Make sure PBA was run on enough paths per endpoint (with an exhaustive or high -nworst setting); the worst GBA path isn't always the worst PBA path.
• Implementation tools optimise on GBA, so leaving many PBA-only passes costs runtime at signoff and can hide trends.