VLSI / Static Timing Analysis
VLSI · Stage 10 · Timing Signoff

Static Timing Analysis

Static timing analysis (STA) checks every timing path in a design against its clock requirements without simulating a single input vector. Instead of driving stimulus through the netlist and watching waveforms settle, STA walks every possible startpoint-to-endpoint path through the design's timing graph and asks a simpler question at each one: is the data guaranteed to arrive in time, and is it guaranteed not to arrive too early? Because it's exhaustive and vector-free, STA scales to designs with billions of transistors in a way dynamic simulation never could — and it's the final gate every chip passes through before tapeout.

Foundation

What STA Checks

STA breaks a design into a graph of timing arcs: every register clock pin and every primary input is a possible startpoint; every register data pin and every primary output is a possible endpoint. Between any startpoint and endpoint there's a combinational path, and STA computes two numbers for each: the arrival time (how long the signal actually takes to get there, worst-case) and the required time (the deadline imposed by the clock and the next register's setup/hold requirements). The difference is slack — positive slack means the path meets timing with margin to spare, negative slack means a violation that has to be fixed before signoff.

Why static, not simulation

Dynamic simulation only tells you about the specific input vectors you happened to apply. STA analyzes every structural path in the design simultaneously, guaranteeing no timing path is missed — at the cost of being pessimistic about paths that can never actually be exercised by real functional behavior (see Timing Exceptions).

Path-based vs. graph-based

Most signoff STA is graph-based (GBA) for speed — propagating worst-case arrival times through the timing graph node by node. Path-based analysis (PBA) re-derives a specific reported path's true delay exactly, recovering pessimism GBA introduces when different paths share partial logic; used selectively on the worst-reported violations.

Where it sits in the flow

STA runs continuously from synthesis onward — as an optimization guide inside place-and-route — and one final time at signoff, alongside the DRC/LVS/IR-EM checks covered on Tapeout / GDSII, using post-route parasitics for the most accurate delay numbers available before the design is committed to a mask.

Path Classification

Timing Path Types

Every path STA analyzes falls into one of four categories, based on what's at each end.

The four timing path types reg2reg FF FF register → register ↓ setup/hold mechanics in2reg PI FF input port → register → Physical Design reg2out FF PO register → output port → Physical Design in2out PI PO input port → output port → Physical Design reg2reg paths dominate a typical design (the vast majority of paths) and are timed purely against the on-chip clock. in2reg / reg2out / in2out paths need I/O timing budgets from outside the chip — see Physical Design → Interface Paths & Virtual Clocks (set_input_delay / set_output_delay against a virtual clock, since the driving/receiving chip is off-die)

Click a path type to jump to more detail. reg2reg, in2reg, reg2out, and in2out are the four structural path categories STA classifies every path into. Each has different sources for its required-time deadline.

Cross-link: in2reg/reg2out/in2out timing budgets (virtual clocks, set_input_delay/set_output_delay) are covered in full with real SDC examples on Physical Design → Interface Paths. This page focuses on the reg2reg setup/hold mechanics that apply to every path type.
Core Mechanics

Setup & Hold Analysis

Every flip-flop has two timing requirements around its clock edge: data must be stable for a setup time (Tsu) before the edge, and remain stable for a hold time (Thd) after it. STA checks both, but against opposite path speeds — setup checks the slowest path can still make it in time; hold checks the fastest path doesn't arrive too early and corrupt the value the setup check was protecting.

⤢ Click to zoom Data-valid window around the capture clock edge capture clock edge Tₛ₡ setup window Tₕₑ hold window data must arrive before setup window opens data must stay stable until hold window closes Setup is fixed by slowing the launch-side path down (or the clock period up); hold is fixed by making the launch-side path slower too — the two checks pull in opposite directions on the same path.

The setup window sits just before the clock edge, the hold window just after — together they define the narrow slice of time around the edge where the data input must not be changing.

The setup check

Setup asks: does the slowest possible arrival at the capture flop's data pin still land before the setup window opens? The launch edge starts the clock-to-Q delay of the launching flop, then the combinational logic's worst-case (max) delay; the capture edge, one clock period later, minus the setup time and the clock's uncertainty budget, sets the deadline.

Setup slack Slacksetup = (Tclk + Skewuseful) − (Tcq + Tcomb,max + Tsu + Uncertainty)

A positive result means the path meets setup with margin; negative means a violation. Uncertainty bundles clock jitter and (pre-CTS) an estimated skew margin — see Physical Design → SDC Clock Uncertainty for how that number is derived and how it shrinks once a real clock tree exists.

The hold check

Hold asks the opposite question at the opposite edge: does the fastest possible arrival stay away from the same clock edge for long enough afterward? Here the launching path's minimum delay is compared against the hold-time deadline at the very next clock edge, not one period later — which is why hold violations, unlike setup violations, can't be fixed by simply running the clock slower.

Hold slack Slackhold = (Tcq + Tcomb,min) − (Thd + Skewuseful,hold)

Hold violations are typically fixed by inserting delay buffers into the offending path (slowing it down just enough), since neither clock period nor voltage/temperature changes help — a hold violation exists at every operating point.

Why hold violations are scarier in silicon: a setup violation just means the chip runs slower than intended at some operating point — often recoverable by binning to a lower frequency. A hold violation is a functional failure at every frequency, including DC, because it's a race condition intrinsic to the path, not a speed limit.

What setup and hold actually protect

The path-level formulas above treat Tsu and Thd as fixed numbers pulled from a library, but they come from something physical: every flip-flop is (almost always) built from two back-to-back latches — a master latch that's transparent while the clock is low and a slave latch that's transparent while the clock is high. Data only actually gets "captured" at one specific instant: the moment the master latch closes and stops being transparent, which happens some number of gate-delays after the clock signal crosses the flop's external clock pin. Setup and hold aren't really about the external pin edge at all — they're about guaranteeing the data is stable at that internal closing instant, referenced back out to the external pins design engineers actually see in SDC and timing reports.

⤢ Click to zoom Inside a master-slave flip-flop D pin Master latch transparent while CP is low internal node X real capture instant happens here Slave latch transparent while CP is high Q pin CP pin external clock edge clock buffer / inverter chain generates true & complement CP internally The external CP pin edge and the real internal capture instant are two different moments in time, separated by whatever the clock buffer chain's delay happens to be — setup/hold are defined to hide this from the designer.

Setup and hold time are specified relative to the external CP pin purely for convenience — the actual physics happens at internal node X, once the master latch's transmission gate closes.

How setup and hold are actually measured

Neither number can be read off a single delay measurement the way clock-to-Q delay can. Library characterization instead sweeps the data transition back and forth relative to the clock edge across many trial simulations, and watches what happens to the resulting clock-to-Q delay (Tcq) at the output.

⤢ Click to zoom Characterization sweep: clock-to-Q delay vs. data-to-clock offset data transition time relative to clock edge (Tₑ₊) → clock-to-Q delay (Tₛₜ) 1.10 × Tₛₜ,min (10% degradation line) Tₛₜ,min (flat asymptotic minimum) nominal clock edge (Tₑ₊ = 0) Tₑ₊ = −Tₛ₡ (setup boundary) Tₑ₊ = +Tₕₑ (hold boundary) metastability region — Tₛₜ rises toward an asymptote as data crowds the edge

This is the "bathtub curve." Tcq stays flat at its minimum for most of the sweep, then bends sharply upward as the data transition crowds either side of the clock edge. The industry-standard definition places Tsu and Thd at the offset where Tcq has degraded by a fixed 10% above its minimum — not at the true asymptote, which would technically require the data offset to reach infinity.

Degradation criterion (industry default) Tcq(Tdc) = 1.10 × Tcq,min

Tdc is the data-transition time relative to the clock edge. The two offsets where the curve crosses this 10%-degradation line, one on each side of the edge, are the definitions of −Tsu and +Thd. A tighter or looser percentage shifts both numbers together; some flows instead use a fixed absolute delay adder (e.g. +10ps over minimum) rather than a percentage, especially at low voltage where the curve's minimum region isn't flat enough for a percentage criterion to stay well-behaved.

CriterionDefinitionWhere it's used
Relative degradation (10%)Tcq allowed to rise 10% above its minimumMost common default across standard-cell characterization tools
Fixed absolute adderTcq allowed to rise by a fixed delay (e.g. 5–10ps) above minimumNear-threshold / low-voltage libraries, where the Tcq curve is too nonlinear for a clean percentage point
Pass/fail (functional)The offset closest to the edge that still produces a logically correct, non-metastable output at allConservative reference point; rarely used directly for signoff since it sits right at the edge of the metastability cliff
Why this matters for STA: because Tsu and Thd are themselves defined by an arbitrary (if standardized) degradation threshold rather than a hard physical boundary, the true "keep-out window" around the clock edge is actually a little softer than the two numbers in the library suggest — part of the reason signoff margins exist on top of the nominal setup/hold numbers, not just on top of interconnect and process variation.

Can setup or hold be negative? Yes — and here's the mechanism

Both numbers absolutely can be negative in a real cell library, and it isn't a data error when a timing report shows one. A negative Tsu means data is still safely captured even if it arrives slightly after the external clock edge; a negative Thd means data is allowed to change slightly before the external clock edge and the flop still reliably captures the old value. Both come from exactly the same source: the internal race, inside the flip-flop cell, between the clock buffer chain's delay and the D-pin-to-master-latch data path's delay — the two paths highlighted in the master-slave diagram above.

⤢ Click to zoom Internal clock path slower → setup can go negative data path (D pin → master latch) τₑ short clock path (CP pin → internal edge) τ₊₡ long (extra buffering / long clock route) Result: the real internal sampling instant lands well after the external CP edge — so data arriving a little after the external edge still beats the (delayed) real deadline. Tₛ₡,ext goes negative. Internal data path slower → hold can go negative data path (D pin → master latch) τₑ long (extra input buffering / mux stage on D) clock path (CP pin → internal edge) τ₊₡ short Result: an external data change, even slightly before the CP edge, still takes so long to reach the internal node that the old value is safely long gone from risk. Tₕₑ,ext goes negative.

Same mechanism, opposite regime: whichever internal path (clock or data) is relatively slower "donates" margin to the other check. A cell can't get negative setup and negative hold at the same time from this effect — it's a trade, not a free gift on both sides.

Writing this out: let τclk be the internal delay from the CP pin to the real internal sampling instant, and τd be the internal delay from the D pin to the master latch's input. Deriving the external setup/hold requirement from the internal ones by simply shifting for these two delays gives:

External setup and hold, referenced to internal timing Tsu,ext = Tsu,int + τd − τclk
Thd,ext = Thd,int + τclk − τd

The two equations share the same (τclk − τd) term with opposite sign — whatever this internal race adds to one check, it subtracts from the other. When the clock path dominates (τclk large), Tsu,ext can drop below zero. When the data path dominates (τd large), Thd,ext can drop below zero instead.

Worked example

Suppose a flop's internal setup requirement is Tsu,int = 50ps, its clock buffer chain adds τclk = 180ps, and its D-to-master-latch route adds only τd = 60ps. Then Tsu,ext = 50 + 60 − 180 = −70ps — the datasheet and the .lib model both report a setup time of −70ps, meaning data is still safely captured even 70ps after the external clock edge appears to have already passed.

This shows up directly in signoff: Liberty (.lib) timing arcs carry negative numbers in their setup_rising/hold_rising tables exactly like this, and STA tools consume them with no special-casing — the slack formulas from earlier in this section work correctly whether Tsu/Thd are positive or negative, since slack is still just required-time minus arrival-time. A negative hold time on a library flop is one of the quiet reasons some designs close hold with fewer buffer insertions than a naive by-hand estimate would predict.
Don't treat negative as "no check needed": a negative hold constraint is still a real, actively-enforced check — it just happens to be more lenient than "data must not change before the edge." STA still flags a violation if a path's fastest arrival is faster than even that relaxed, negative deadline; negative just moves the goalpost, it doesn't remove it.
Accuracy Refinement

Clock Uncertainty & Reconvergence Pessimism

Both the launch and capture flip-flops in a reg2reg path get their clock from the same clock tree, which usually means the two clock paths share a common trunk before splitting off toward their respective leaf flops. A naive STA tool would apply the clock tree's latest possible delay to the launch path and its earliest possible delay to the capture path (or vice versa, whichever is pessimistic) — including along the segment both paths physically share, which cannot actually have two different delays at once in real silicon.

⤢ Click to zoom Common clock path pessimism clock root common trunk (shared by both paths) launch FF capture FF naive STA: assumes this segment is fast for launch, slow for capture — impossible in real silicon CRPR removes it The shared trunk's delay is identical for both paths by physical necessity — whatever pessimism was added for that segment is subtracted back out of the slack calculation, recovering timing margin that never actually existed as risk.

Clock reconvergence pessimism removal (CRPR), also called common clock path pessimism removal (CCPP removal), identifies the shared clock-tree segment between a launch and capture path and cancels the artificial early/late split applied to it.

CRPR matters most on paths where the launch and capture flops are physically close together and share most of their clock path — exactly the kind of path a clock mesh or H-tree topology (see Physical Design → CTS) is designed to produce plenty of. Without CRPR, signoff would report false violations on paths that are actually safe, forcing unnecessary and costly fixes.

Uncertainty componentPresent pre-CTS?Present post-CTS?
Clock jitterYes (estimated)Yes (from clock source / PLL spec)
Skew margin (generic guardband)Yes — large, since no real tree exists yetNo — replaced by actual propagated skew
Reconvergence pessimismN/A — no real clock topology to share pathsPresent, removed by CRPR
Constraint Refinement

Timing Exceptions

Not every structural path in a netlist represents something that can actually happen functionally, and not every path needs to close in a single clock cycle. SDC timing exceptions tell STA to relax or skip specific paths — used carefully, since an incorrect exception silently turns off checking on a path that might actually matter.

False paths

A path that structurally exists in the netlist but can never be sensitized by real functional behavior — for example, two mutually-exclusive control paths that logic guarantees will never both be active, or paths through a synchronizer where only metastability settling time matters, not a specific delay number.

set_false_path -from [get_pins CTRL/mux_sel_reg/Q] \
               -to   [get_pins DATAPATH/mode_reg/D]

Multicycle paths

A path that's allowed more than one clock cycle to settle — common on wide, slow datapaths (large multipliers, deep adder chains) where forcing single-cycle closure would cost prohibitive area or power for no real benefit, as long as the receiving logic knows to wait the extra cycle(s) before sampling.

set_multicycle_path 2 -setup \
    -from [get_pins MUL/a_reg/CP] \
    -to   [get_pins MUL/result_reg/D]
set_multicycle_path 1 -hold \
    -from [get_pins MUL/a_reg/CP] \
    -to   [get_pins MUL/result_reg/D]
Common mistake: a multicycle setup exception almost always needs a matching hold exception one cycle earlier than the default, or the hold check ends up checking against the wrong edge entirely and either masks a real violation or reports a spurious one. False paths declared too broadly (e.g. wildcarding a bus that only sometimes carries don't-care data) are one of the most common sources of silicon timing escapes — every exception should be traceable to a specific, provable functional reason.
Formal verification of exceptions: because a wrong exception can mask a real bug that only shows up in silicon, many signoff flows run a formal tool specifically to prove that declared false paths really are unreachable and that multicycle paths really do get the extra cycles the design assumes — treating the SDC exception list itself as something that needs verification, not just the design it constrains.
Signoff Scale

Corners & MCMM Signoff

A chip has to work correctly across every combination of manufacturing variation, supply voltage, temperature, and functional operating mode it might ever encounter — not just one. Multi-corner multi-mode (MCMM) analysis, sometimes called MMMC, runs the full STA path analysis across every combination simultaneously rather than one at a time, since the worst-case path is rarely the same path in every scenario.

⤢ Click to zoom MCMM scenario matrix (illustrative) modes → Functional Sleep Scan shift JTAG corners → WCS (worst-case slow) BCF (best-case fast) WCL (worst-case leakage) setup setup setup setup setup setup setup setup hold hold hold hold 4 modes × 3 PVT corners × parasitic corners → dozens of scenarios, each independently checked a design signs off only when every path passes in every scenario — the worst scenario per path, not per design, sets the bar

Setup is typically dominant at the slow/worst-case corner (WCS), hold at the fast/best-case corner (BCF) — which is exactly why fixing one type of violation by changing corner assumptions doesn't work; both corners have to pass simultaneously.

DimensionWhat it variesTypical signoff concern
PVT cornerProcess (TT/FF/SS/…), voltage, temperature — see Fabrication → Process CornersSetup dominant at slow corners, hold dominant at fast corners
Parasitic (RC) cornerInterconnect resistance/capacitance extraction extremesCmax/Cmin extraction corners stress setup vs. hold differently than device corners alone
Functional modeNormal operation, low-power/sleep states, DFT scan-shift, JTAG/debugScan-shift mode in particular often has completely different critical paths than functional mode
On-chip variationWithin-die statistical spread — see Fabrication → On-Chip Variation & SigmaApplied as derates or POCV distributions on top of every corner/mode combination
Cross-link: the underlying process corner mechanics (TT/FF/SS/FS/SF, how a fab actually determines a die's corner) and POCV/AOCV on-chip variation modeling are covered in depth on Fabrication rather than repeated here — MCMM is what stacks those per-corner numbers into one signoff decision across every mode a chip can be in.
Statistical Foundations

Sigma & Statistical Guardbanding

"3-sigma" and "2-sigma" show up constantly in timing signoff conversations, and they mean exactly what they mean in any other statistical context: a process parameter like transistor gate length or threshold voltage varies randomly from device to device, that variation is well-approximated by a Gaussian (normal) distribution, and σ is the standard deviation of that distribution. A cell's delay inherits the same randomness — each library arc has a mean delay μ and a characterized spread σ around it, and "signing off at 3σ" means the design has to meet timing even if a given path's delay lands 3 standard deviations into the unfavorable tail of that distribution, not just at the mean.

⤢ Click to zoom Gaussian delay distribution and one-sided sigma guardbands μ (mean delay) +1σ +2σ +3σ slow tail — setup risk most likely delay fast tail — hold risk

Setup cares about the slow (right) tail of the delay distribution; hold cares about the fast (left) tail. A "3σ setup guardband" adds 3× the characterized σ on top of μ when computing the arrival time used in the setup check.

Sigma level (N)One-sided coverageApprox. fraction left in the tail
1σ84.13%≈158,700 ppm (1 in 6)
2σ97.72%≈22,750 ppm (1 in 44)
3σ99.87%≈1,350 ppm (1 in 741) — common signoff default
4σ99.9968%≈31.7 ppm
5σ99.99997%≈0.29 ppm
6σ99.9999999%≈0.001 ppm — automotive/safety-critical territory

Choosing N is a direct trade between design margin and residual risk, and it's the same trade the yield model on Fabrication → Yield makes for defect density — a higher sigma target covers more of the population but costs more area, power, or frequency to guarantee, since every path effectively has to be built to survive a rarer, more pessimistic version of itself. Consumer designs commonly sign off around 3σ; automotive and infrastructure parts, where a field failure is far more costly, often push to 4.5–6σ for the most safety-relevant paths.

Combining sigma along a path

A real timing path passes through many gates and wires, each with its own independent random variation. Naively adding each stage's Nσ guardband together (the old flat-AOCV approach) is far too pessimistic, because it implicitly assumes every gate on the path is simultaneously at its own worst case — astronomically unlikely for genuinely independent random sources. POCV instead combines the per-stage sigmas the way independent random variables actually combine: variances add, standard deviations don't.

Root-sum-square (RSS) combination of independent random variation σpath = √(σ12 + σ22 + … + σn2)

The guardband actually added to the path's nominal delay is N × σpath, not N × (σ1 + σ2 + …). Because RSS grows with the square root of the number of stages rather than linearly, POCV recovers a meaningful amount of the pessimism that made older flat-derate AOCV methodology increasingly unusable as pipelines got deeper at advanced nodes. Systematic (chip-wide, fully-correlated) variation components still add linearly on top of this — only the random, independent component benefits from RSS.

Cross-link: the underlying OCV/AOCV/POCV variation-modeling methodology is introduced on Fabrication → On-Chip Variation & Sigma; this section focuses specifically on what the sigma number itself means statistically and how the signoff target is chosen.
Emerging Practice

Statistical STA (SSTA)

Corner-based STA treats process variation as a small handful of discrete worst-case points (TT/FF/SS/…), each analyzed as if every transistor on the chip were simultaneously at that exact extreme — a convenient simplification, but an increasingly pessimistic one as the number of independent variation sources grows at advanced nodes. Statistical static timing analysis (SSTA) instead models key parameters (gate length, threshold voltage, interconnect thickness) as probability distributions and propagates those distributions through the timing graph, producing a timing distribution for each path rather than a single worst-case number.

Corner-based STASSTA
Variation modelDiscrete worst-case pointsContinuous probability distributions
OutputSingle slack number per path per cornerTiming yield / probability of meeting a target frequency
PessimismHigher — assumes full correlation at each cornerLower — models partial correlation between parameters explicitly
AdoptionUniversal, standard signoff methodologyUsed selectively — complex flow, mostly at the most advanced nodes or for critical blocks

SSTA hasn't replaced corner-based signoff industry-wide — POCV (parameterized on-chip variation, covered on Fabrication) captures much of SSTA's statistical benefit with far less flow complexity by applying statistically-derived derates on top of ordinary corner-based STA, which is why POCV rather than full SSTA is the more common statistical-timing technique in production signoff today.

Lifetime Reliability

Aging & Reliability

A chip that comfortably passes every setup and hold check on the day it's tested doesn't necessarily stay that way. Transistors physically wear out under electrical stress the same way any component does — not by breaking outright, but by slowly drifting. Over months and years of operation, two dominant mechanisms shift each transistor's threshold voltage (Vt) upward, which makes every gate a little slower than it was on day one, which in turn erodes the setup slack that was signed off against a "fresh" library.

Bias Temperature Instability (NBTI / PBTI)

NBTI affects PMOS devices held under negative gate-to-source stress (i.e. a gate held at logic-0 relative to source); PBTI is the NMOS analogue under positive stress. Both are caused by charge traps forming at the gate-oxide interface, which raises Vt and slows the device. A distinctive feature of BTI: it's partly recoverable — some of the trapped charge anneals out when the stress condition is removed (e.g. when a PMOS gate switches back to logic-1), so the damage isn't purely one-directional the way wear usually is. Still, a net permanent component accumulates over years of duty cycling.

Hot Carrier Injection (HCI)

During switching, some carriers gain enough kinetic energy ("hot" carriers) to be injected into and trapped within the gate oxide, again raising Vt and degrading mobility. Unlike BTI, HCI damage is essentially permanent and cumulative — it doesn't anneal out during idle periods. HCI severity scales with switching activity and supply voltage, so it hits high-frequency, high-toggle-rate logic (like clock buffers and heavily-used datapath cells) hardest.

⤢ Click to zoom Delay degradation over chip lifetime operating time → (years) gate delay NBTI/PBTI — fast initial rise, then saturates (partly recoverable under idle/off periods) HCI — steadier, roughly monotonic cumulative rise EOL (e.g. 10–15yr mission profile) EOL guardband

Both mechanisms push delay in the same direction (slower), but with different shapes over time — which is why physics-based aging models, not a single flat percentage, are needed to project an accurate end-of-life (EOL) corner.

How STA accounts for it

ApproachHow it worksTradeoff
Flat aging guardbandMultiply nominal signoff delay by a conservative fixed factor (e.g. 1.03–1.08×) meant to cover worst-case lifetime degradationSimple, fast, but not physically grounded — can under- or over-guard specific paths depending on their actual switching activity and stress profile
Aging-aware STADegradation-aware cell libraries characterized at multiple aging checkpoints (fresh, 1yr, 5yr, EOL) from physics-based NBTI/HCI models fit to accelerated stress-test data; the EOL corner is run through STA like any other MCMM cornerMore accurate and path-specific, but requires reliability-characterized libraries and workload/mission-profile assumptions (voltage, temperature, duty cycle) up front
In-field adaptive compensationRather than guardbanding at design time, track real degradation with on-chip monitors and compensate at runtimeReduces the design-time guardband needed, at the cost of added monitor/control circuitry — see below
Common empirical BTI degradation form ΔVt(t) ≈ A · tn

Reliability models commonly fit BTI-driven threshold-voltage shift to a power law in time, with the exponent n typically in the 0.15–0.25 range (and the prefactor A a strong function of voltage, temperature, and duty cycle) — the diminishing-returns shape visible in the NBTI/PBTI curve above. This is a simplified empirical fit used for guardband projection, not a full physical model; production aging tools calibrate it against measured accelerated-stress data for the specific process.

Mission profile matters enormously: a consumer mobile SoC with a 2–3 year expected replacement cycle and mostly room-temperature operation needs a much smaller aging guardband than an automotive or industrial part rated for 10–15 years at elevated under-hood temperatures — which is exactly why automotive-grade (AEC-Q100) timing signoff is a materially different, more conservative exercise than consumer signoff on the same process node.
Cross-link: aging is one of the slow drifts that in-field adaptive body biasing and DVFS/AVS loops can partially compensate for at runtime, alongside process and temperature — trading some design-time guardband for on-chip monitoring and control complexity rather than eating the full EOL margin as fixed slack given away on day one.

Sources