DigiFlop

STA checks every timing path in a design against setup and hold requirements without simulating actual input vectors — it exhaustively analyzes all paths through the netlist for a given clock definition. Functional simulation only checks the specific vectors you run and can miss a rare-but-real timing violation that never got exercised; STA is exhaustive over paths, at the cost of not checking functional correctness at all.

Setup checks that data launched from one flop arrives and stabilizes at the next flop before the capturing clock edge, with margin — it bounds how slow a path can be. Hold checks that the newly launched data doesn't arrive so fast that it corrupts the value the capturing flop was supposed to hold from the previous cycle — it bounds how fast a path can be. Setup violations are usually fixed by speeding up logic; hold violations are usually fixed by adding delay.

Max delay/setup analysis checks that the longest (slowest) path from launch to capture doesn't exceed the available clock period — it answers 'is the data guaranteed to arrive in time?' and is checked at the slowest PVT corner, since that's when paths are at their worst-case slowest. Min delay/hold analysis checks that the shortest (fastest) path doesn't arrive so quickly it violates the hold requirement at the capture flop — it answers 'is the data guaranteed to still be stable when needed?' and is checked at the fastest PVT corner, since that's when paths are at their worst-case fastest (most likely to race ahead and violate hold).

Slack is the difference between the required arrival time of a signal at an endpoint and its actual arrival time. Positive slack means the signal arrived with margin to spare — the path meets timing with room left over. Negative slack means the signal arrived later than required (for a setup check) or too early relative to the next edge (for a hold check) — a timing violation that must be fixed before the design can be signed off, typically by re-synthesizing, resizing cells, adding buffers, or in the worst case, restructuring the RTL for that path.

A setup violation can usually be fixed post-silicon (or even in the field, in some designs) by simply reducing the operating clock frequency, trading performance for correctness — no fix required. A hold violation, however, is fundamentally about the relationship at the clock edge itself and is completely independent of clock frequency; no amount of slowing the clock down fixes a hold violation. If a hold violation is discovered after tapeout, the chip may be functionally broken with no software or frequency workaround, sometimes requiring a costly re-spin — which is exactly why hold timing closure gets extremely careful attention in the signoff flow before tapeout.

A false path is a path that exists structurally in the netlist — STA can trace a route from a launch flop to a capture flop through combinational logic — but which can never actually be sensitized during real operation, usually because of mutually exclusive control signals or because the two flops are in unrelated, intentionally-never-compared configuration registers. You tell the STA tool to exclude it entirely with an SDC constraint, `set_false_path -from <launch> -to <capture>`. Declaring false paths correctly matters because leaving them in can waste enormous synthesis/optimization effort chasing a timing violation that could never actually happen, or worse, mask real violations in the noise of hundreds of fake ones.

A timing exception is any SDC directive — false path, multicycle path, or a case-specific max/min delay override — that changes how STA treats a particular path relative to the default single-cycle assumption. Over-using false paths is dangerous because it's easy to mistakenly exclude a path that actually can be sensitized in real operation, silently hiding a genuine timing violation from signoff — the chip will look 'clean' in the STA report while actually having a real functional risk in silicon. Every false path declaration should be backed by a genuine structural/functional argument for why that path can never be exercised, not just used as a shortcut to clear a stubborn violation.

A multicycle path is a real, sensitizable path that the designer has deliberately allowed more than one clock cycle to complete, rather than requiring it to settle within a single cycle like a normal path. This is common for slow, wide operations — a multi-cycle multiplier, or a control path that's known to change only occasionally — where forcing single-cycle timing would mean over-designing (and burning power/area on) logic that doesn't need to be that fast. It's declared with `set_multicycle_path 2 -from ... -to ...`, telling STA that capture is legitimately allowed on the second clock edge rather than the first.

An SDC (Synopsys Design Constraints) file is the contract between the designer and the synthesis/STA tools describing what 'correct timing' means for a design — without it, a tool has no concept of clock frequency, I/O timing, or which paths matter. The most fundamental constraints are the clock definitions (`create_clock`, specifying period and waveform for every clock in the design), input/output delay constraints (`set_input_delay`/`set_output_delay`, describing the timing budget available at chip boundaries relative to those clocks), and any necessary exceptions (false paths, multicycle paths) that describe paths that don't follow standard single-cycle timing rules.

Clock skew is the spatial difference in arrival time of the same clock edge at two different flip-flops, caused by differences in the physical routing paths, buffer counts, and wire lengths in the clock tree reaching each flop. It's a static, physical-design-driven quantity, minimized by carefully balancing the clock tree (e.g. via an H-tree structure) during Clock Tree Synthesis. Clock jitter, by contrast, is the temporal, cycle-to-cycle variation in a clock edge's arrival time at a single point, caused by noise in the clock generation circuitry (PLL noise, supply noise) — it's a dynamic quantity that affects every flop the same clock reaches, not a difference between flops.

Skew directly adds to or subtracts from the margin at every flop pair. If the capture flop's clock edge arrives later than the launch flop's edge ('positive skew' in the direction of data flow), that effectively gives the data path more time to settle — helping setup margin, but simultaneously making the hold check harder, since the capturing edge stays open longer and can accidentally capture the next cycle's data too early. Deliberately introducing controlled skew (useful skew) is sometimes used as a physical design optimization technique to help a specific critical setup path, but it must be applied carefully because it always trades against hold margin on the same path.

Useful skew deliberately biases the clock tree so that the capturing flop's clock edge arrives slightly later than the launching flop's edge along a specific critical setup path, effectively 'borrowing' extra time for that path from the next pipeline stage. It can rescue an otherwise-failing critical path without touching the logic itself. The risk is that the same skew that helps setup on one path simultaneously tightens the hold margin on that same path (and potentially worsens skew relationships to other flops sharing that clock branch), so it has to be applied surgically and re-verified across the whole design, not just the target path.

PVT stands for Process, Voltage, and Temperature — the three main sources of variation between how a chip behaves in simulation/characterization versus how any particular manufactured unit behaves in the field. Process corners (like SS/TT/FF) capture manufacturing variation in transistor speed; voltage corners capture supply variation; temperature corners capture operating environment. Because no single 'typical' corner represents every chip in every condition it will ever see, STA is run across a grid of corners — commonly the slowest corner (SS, low voltage, high temperature) for setup checks, and the fastest corner (FF, high voltage, low temperature) for hold checks — and the design must meet timing at every corner in the signoff set, not just the nominal one.

MCMM means running timing analysis across every combination of process/voltage/temperature corner (worst-case slow, worst-case fast, typical, etc.) and every functional/power mode (full performance, low-power, various DVFS states) the chip supports. A phone SoC has to work correctly whether it's a fast die at high voltage in a cold room or a slow die at low voltage overheating in a pocket, across dozens of DVFS operating points — each of those is a separate corner/mode pair that must pass timing independently.

OCV models the fact that transistors across one die don't all behave identically due to manufacturing and local voltage/temperature variation — the launch path and the capture path can each run faster or slower than nominal, independently. For setup (max) analysis, tools slow down (late-derate) the data/launch path and speed up (early-derate) the capture clock path — the pessimistic combination for setup. For hold (min) analysis, the derates flip: launch is sped up, capture clock is slowed down.

Flat OCV applies the same derate percentage regardless of how many logic stages a path has, which over-penalizes long paths (variation partially averages out over many stages) and under-penalizes short ones. AOCV (advanced/stage-based OCV) varies the derate by path depth and distance; POCV (parametric OCV) models variation statistically per-cell rather than as a flat multiplier. Both reduce needless pessimism versus flat OCV, which matters a lot once a design is timing-closure-constrained.

If the launch and capture clock paths share a common segment (the same buffers near the clock source) before diverging, applying a late-derate to that shared segment on the launch side and an early-derate to the same physical segment on the capture side is a contradiction — the same buffers can't be both slow and fast at once. CRPR identifies the shared portion of the clock tree and removes the artificial pessimism the derates introduced on that common segment, giving a more realistic (less pessimistic) timing margin.

GBA computes worst-case arrival/required times at each node independently and propagates them through the timing graph — fast, but pessimistic, because it can combine worst-case conditions from paths that could never physically coexist. PBA re-derives timing along one specific path with its own consistent set of conditions, removing that false pessimism. Designers typically run GBA across the whole chip for speed, then re-check the handful of paths that fail in GBA with PBA before spending effort on a real fix, since some GBA failures turn out to be PBA-clean.

The clock gating cell (an AND/latch-based ICG) adds delay and can shift the arrival time of the gated clock edge relative to the ungated reference used elsewhere, which can eat into hold margin on paths that cross the boundary of the gated region. It's typically fixed by adding explicit timing constraints around the gating cell during CTS so the tool balances the gated and ungated clock trees, or by inserting deliberate hold buffers on the affected data paths.

Timing closure is the iterative process of getting every path in the design to meet its required timing constraints (setup and hold, across all signed-off corners) simultaneously. It typically involves running Static Timing Analysis after each stage of the physical design flow (synthesis, placement, clock tree synthesis, routing), identifying violating paths, and applying fixes — resizing or swapping cells for faster/slower variants, adding buffers, restructuring logic, adjusting placement, or in some cases feeding timing-critical information back into RTL or synthesis constraints — then re-running STA to confirm the fix worked and didn't break something else. It's inherently iterative because fixing one path can shift congestion or introduce a new violation elsewhere.