Question bank — Critical path identification

False. Critical means largest accumulated delay, not longest length; a short wire through slow, heavily-loaded gates can beat a long wire through fast ones. Delay is what matters, geometry is only a contributor.

False. Ten fast light-load gates can be quicker than three slow high-fanout gates. You must sum the actual per-gate delays, never count nodes — see Propagation Delay and Gate Sizing.

Usually true, but not guaranteed. Since $\text{slack}=(T+t_{skew})-(t_{cq}+t_{logic}+t_{su})$ also depends on the period and skew of that specific path, two paths with different capture-clock skews can have the worst-slack path differ from the max-delay path.

True by definition. Passing means the worst slack (the critical path's) is non-negative, and since it is the minimum, all others are at least that good.

False. Once the old critical path is fixed, the second-slowest path becomes critical and now sets the floor. Timing closure is iterative — you must re-run Static Timing Analysis (STA) after each fix.

False. Skew that delays the capture clock adds $+t_{skew}$ to the budget $T+t_{skew}$, relaxing the setup check. It only hurts setup if it delays the launch clock — and for hold it flips sign (see the hold section). Track Clock Skew and Jitter carefully.

False. It splits one long path into shorter stages so $f_{\max }$ rises, but it costs an extra clock of latency and more registers/area. You trade throughput timing against latency and hardware — see Pipelining.

False. Delay ($t_{logic}$) is time used by the logic; slack is time left over $=\text{RAT}-\text{AT}$. A path can have huge delay yet positive slack if the period is generous.

False. STA is vectorless — it does graph math (arrival/required times over a DAG), independent of stimulus. That is why it covers all paths exhaustively where simulation would miss corner vectors.

False in a proper synchronous design. STA cuts loops at flip-flops, so the timing graph is a Directed Acyclic Graph; an uncut combinational loop is a design error, not a path to analyze.

True. Setup asks "does data arrive before the next edge?" (max delay). Hold asks "does new data arrive too soon after the same edge and corrupt the value being captured?" (min delay) — see Setup and Hold Time.

True (with capture-clock skew on the right). Data must not change until at least $t_h$ after the capture edge, so the fastest path must be slow enough. Notice this check has no $T$ — hold is a same-edge race, independent of clock period.

False. Since $T$ doesn't appear in the hold inequality, changing the period does nothing. Hold violations are fixed by adding delay (buffers) to the too-fast path or reducing skew — the opposite remedy to setup.

False. A late capture clock ($+t_{skew}$) helps setup (bigger budget) but hurts hold (data must stay stable even longer), because $t_{skew}$ moves to the demanding side of the hold inequality. This sign flip is the classic skew trap.

Conceptually yes — slack $=$ available minus required — but the arithmetic differs: hold slack $=(t_{cq}+t_{logic}^{\min })-(t_h+t_{skew})$, i.e. actual arrival minus earliest-allowed. Positive still means it passes.

Wrong — it omits the flip-flop overheads. The correct floor is $T_{\min }=t_{cq}+t_{logic}^{\max }+t_{su}$; the launch clock-to-Q and the capture setup time both eat into the period.

Sign and terms are wrong. Slack $=(T+t_{skew})-(t_{cq}+t_{logic}+t_{su})$ — it is required-minus-arrival, so a positive slack means the path passes, and the flip-flop overheads must be included.

Wrong operation. The output waits for the last input, so $\text{AT}=\max (\text{input arrivals})+t_{gate}$. Summing would grossly over-count and misidentify the critical path.

Wrong direction. AT (Arrival Time, the actual latest signal time) is a forward topological pass from launch points; RAT (Required Arrival Time, the latest allowed time) is a backward pass from endpoints using $T$ and $t_{su}$. Slack $=$ RAT $-$ AT needs both directions.

Incomplete. Fixing the worst path promotes the runner-up to critical. You re-analyze and fix until the worst slack is non-negative across all endpoints.

Wrong scope. A single clock cannot tick faster than its slowest register-to-register path allows, so that one path caps the entire clock domain's frequency — see Maximum Clock Frequency.

Wrong. A multicycle path is deliberately told the tool it has, say, 2 clock periods to settle, so its budget becomes $\approx 2T$ instead of $T$. Applying the single-period constraint would wrongly flag it as critical.

Because a gate's output cannot be valid until its last input has settled; the latest-arriving input gates the output. This max-of-inputs rule is exactly what causes a single slowest path to emerge across the whole graph.

All paths launch on the same clock edge and must finish before the next one. Like a relay race ending only when the slowest runner arrives, you cannot fire the next clock edge until the slowest path is safely captured.

A later capture edge means the deadline arrives later, granting more time: $t_{cq}+t_{logic}+t_{su}\le T+t_{skew}$. The extra $t_{skew}$ is genuine slack donated to that path — but the same lateness subtracts from hold budget.

A graph lets it compute worst-case arrival/required times over all paths in near-linear forward+backward passes, guaranteeing full coverage. Simulation would need an impossible set of vectors to hit every corner path.

Inserting a register splits one long combinational delay into two shorter stage delays, so the largest $t_{logic}$ that the period must cover drops. Smaller $t_{logic}^{\max }$ means smaller $T_{\min }$ hence higher frequency.

Because slack also depends on the period and skew seen by that path's capture register. Different clock skews (or multicycle exceptions) change the budget side, so equal delay does not imply equal slack.

Because the launch and capture clocks are unrelated, there is no fixed period-$T$ deadline for STA to check; the crossing is instead handled by synchronizers and metastability analysis, not by single-path setup slack. STA usually marks such paths as false/excluded.

Both are critical simultaneously — the design has no unique bottleneck, so any fix must improve both together, or one alone leaves the other still capping $f_{\max }$.

The period still cannot go to zero: $T_{\min }=t_{cq}+t_{su}$ remains, set purely by flip-flop overhead. This is the floor no amount of logic optimization can break — only faster flip-flops help.

There is a longest-delay path (input-to-output), but no register-to-register setup critical path exists; timing is expressed as input-to-output delay against an external constraint, not against an internal clock edge.

The path passes with no margin — it meets timing at the boundary. Any added skew jitter, temperature drift, or process variation can push it negative, so zero slack is technically passing but practically risky. See Clock Skew and Jitter.

Yes. A negative $t_{skew}$ subtracts from the budget side, tightening the setup deadline and shrinking every affected path's slack, potentially making a previously comfortable path the new critical one.

With its relaxed budget ($\approx N\cdot T$ for an $N$-cycle path). Ignoring the exception makes the tool over-count its slack deficit and falsely crown it critical; honoring it may reveal the true single-cycle bottleneck elsewhere.