Timing analysis basics (static timing): Question bank

Before we begin, one quick re-anchoring of the characters in every timing race, so no symbol appears below undefined:

Definition The cast (tap to refresh)

$T_{c l k}$ — the clock period, the gap between two rising clock edges (the "clicks").
$t_{c q}$ — clock-to-Q: the delay before a flip-flop's output actually changes after its clock edge. It has a range: $t_{c q, ma x}$ (worst, slowest) and $t_{c q, min}$ (best, fastest).
$t_{co mb}$ — the delay of the combinational logic (the gates) between two flip-flops. $t_{co mb, ma x}$ = the slowest such path, $t_{co mb, min}$ = the fastest.
$t_{s u}$ — setup time: how long data must be steady before an edge.
$t_{h}$ — hold time: how long data must be steady after an edge.
$t_{s k e w}$ — clock skew: how much later (or earlier) the capture flip-flop's clock arrives versus the launch flip-flop's, i.e. $t_{s k e w} = t_{c a pt u r e} - t_{l a u n c h}$ .

The setup and hold windows, drawn

Figure — Timing analysis basics (static timing)

Look at the amber forbidden window around the capture edge in Figure 1. Data must be steady for $t_{s u}$ before the edge and $t_{h}$ after it. If the data line wiggles anywhere inside that amber band, the flip-flop can go metastable. Setup is the left wall of the window; hold is the right wall. Everything else on this page is just: "does the data transition land safely outside the amber band?"

Slowest vs fastest path — why the two checks pick opposite extremes

Figure 2 overlays three data-arrival times at FF2 from three different physical paths — a fast one (cyan), a typical one (white), and the slow critical path (amber). Notice:

The setup deadline (dashed line near the next edge) is threatened only by the slow amber arrival — that's why setup uses $t_{co mb, ma x}$ and $t_{c q, ma x}$ .
The hold window (small amber band right at the launch edge) is threatened only by the fast cyan arrival — that's why hold uses $t_{co mb, min}$ and $t_{c q, min}$ .

Building the two inequalities on a timeline, step by step

Figure 3 is the derivation as a picture. Follow the numbered arrows:

Launch edge at $t = 0$ . Data can't move yet.
After $t_{c q}$ the launch flop's output changes (first arrow).
After $+ t_{co mb}$ the signal reaches FF2's input (second arrow) — this is the arrival.
The setup deadline sits $t_{s u}$ before the next edge at $T_{c l k}$ (dashed marker). Arrival must land at or before it → $t_{c q} + t_{co mb} + t_{s u} \leq T_{c l k}$ .
The hold requirement sits $t_{h}$ after the same launch edge (small amber band at the left). The fast arrival must land at or after it → $t_{c q} + t_{co mb, min} \geq t_{h}$ .

See how setup measures against the next edge (so $T_{c l k}$ appears) while hold measures against the same edge (so $T_{c l k}$ never appears)? That single geometric fact is the whole "hold is period-independent" story.

What clock skew does to the window

In Figure 4 the capture clock (top cyan) is slid later by $t_{s k e w}$ relative to the launch clock (bottom cyan). Watch the amber window slide with it:

The setup deadline moves later → more room for slow data → setup relaxes (budget becomes $T_{c l k} + t_{s k e w}$ ).
The hold wall also moves later → the fast data now has to stay clear of a later wall → hold tightens (requirement becomes $t_{h} + t_{s k e w}$ ).

One slide, opposite effects. That is the "skew helps setup, hurts hold" trade-off made visible.

True or false — justify

STA can prove a design meets timing without any input test vectors

True. STA reasons about the structure's worst-case path delays, so it covers all paths at once — that is exactly why it is called "static."

If a design passes simulation, it must pass STA

False. Simulation only exercises the paths your vectors happen to hit; a slow path that no vector triggered can still violate timing. STA is the exhaustive check.

Setup violations can always be fixed by lowering the clock frequency

True. Setup is

t_{c q, ma x} + t_{co mb, ma x} + t_{s u} \leq T_{c l k}

, and only

T_{c l k}

is under your clock control — enlarge the period and the deadline (Figure 3) moves later.

Hold violations can be fixed by lowering the clock frequency

False. The hold inequality

t_{c q, min} + t_{co mb, min} \geq t_{h}

contains no

T_{c l k}

— it is a same-edge race (Figure 3). Slowing the clock does nothing; you must add delay to the short path.

The critical path is the path with the most gates

False (subtly). It is the path with the largest total delay, which usually but not always means most gates — a few slow gates can beat many fast ones.

Setup and hold analysis look at the same physical path

False. Setup fears the longest (slowest) path; hold fears the shortest (fastest) path (Figure 2). They are typically different paths in the same circuit.

Setup and hold use the same clock-to-Q value

False. Setup uses

t_{c q, ma x}

(data leaves late, hardest to arrive in time); hold uses

t_{c q, min}

(data leaves early, most likely to disturb capture). Each check picks the extreme that hurts it.

A circuit with zero combinational logic (

t_{co mb} = 0

) can never have a hold problem

False. Even a direct flop-to-flop wire has

t_{c q, min}

arriving early; if

t_{c q, min} < t_{h}

the hold check

t_{c q, min} + 0 \geq t_{h}

fails, so back-to-back flops can still violate hold.

Positive slack means the path is exactly meeting its deadline

False. Positive slack means it meets the deadline with margin to spare. Exactly meeting is zero slack; missing is negative slack.

f_{ma x}

depends only on the combinational logic delay

False.

f_{ma x} = 1/ (t_{c q, ma x} + t_{co mb, ma x} + t_{s u})

— the flip-flop overhead

t_{c q, ma x} + t_{s u}

is spent every cycle and directly lowers

f_{ma x}

Positive clock skew (capture clock later) is always bad

False. Later capture relaxes setup (more time to arrive) even though it tightens hold (Figure 4). Skew is a trade-off, not a pure penalty.

A path the designer knows can never be logically exercised still limits

f_{ma x}

False. That is a false path — you tell the tool to exclude it, or its (irrelevant) long delay would needlessly cap your frequency. STA is structural and won't know it's impossible unless told.

Spot the error

"To find max frequency I add

t_{c q, min}

t_{co mb, min}

, and

t_{s u}

, then invert."

Error: setup uses the maximum clock-to-Q and the longest logic —

t_{c q, ma x} + t_{co mb, ma x}

. The slowest arrival (amber path, Figure 2) is what limits the clock.

"Hold slack

= T_{c l k} - (t_{c q} + t_{co mb, min})

Error:

T_{c l k}

has no business in hold. Hold slack

= (t_{c q, min} + t_{co mb, min}) - t_{h}

; it is a same-edge race (left amber band, Figure 3), period-independent.

"Setup got tighter, so I'll add buffers to the data path to slow it down."

Backwards for setup. Adding data-path delay pushes the amber arrival even later (Figure 2), worsening setup. Buffers fix hold; for setup you speed up logic or slow the clock.

"Skew of

+ 0.5

ns adds time for both setup and hold."

Error: sliding the capture edge later (Figure 4) adds

t_{s k e w}

to the setup budget but adds it to the requirement on the hold side (

t_{h} + t_{s k e w}

), making hold harder, not easier.

"This register-to-register path takes 2 cycles, so I'll compare its delay against one

T_{c l k}

Error: that's a multi-cycle path. If the design intends 2 clocks for it, its setup deadline is near

2 T_{c l k}

, not

T_{c l k}

— analysing it as single-cycle reports a false violation. You must declare the multi-cycle constraint.

"STA is unnecessary if I know the longest path — I only care about the slowest gate."

Error: you need the slowest path end-to-end for setup and the fastest path for hold (Figure 2). One extreme is not enough; both bounds must be checked.

"A metastable flip-flop settles instantly to a random 0 or 1."

Error: metastability is a hover between 0 and 1 (inside the amber window, Figure 1) that resolves after an unbounded, probabilistic delay — that's why we build in

t_{s u}

margin. See Metastability.

Why questions

Why does setup use the maximum-delay path but hold use the minimum-delay path?

Setup fears data arriving too late (miss the deadline) → worst case is the slowest path (amber, Figure 2). Hold fears data arriving too early (disturb the capture) → worst case is the fastest path (cyan, Figure 2).

Why is

T_{c l k}

present in the setup formula but absent from the hold formula?

Setup compares arrival against the next edge, a full period away — so

T_{c l k}

sets the deadline. Hold compares against the same edge (offset

0

), so no period appears (Figure 3).

Why does STA ignore the actual data values (0s and 1s)?

Because timing failure depends on when a transition can occur, not which value it is. Structural worst-case delay bounds every value, so ignoring values loses nothing while gaining full path coverage.

Why does

t_{c q}

appear in both the setup and the hold equation?

In both cases the data can't leave the launch flop until

t_{c q}

after its edge (first arrow, Figure 3), so it's the common start — but setup uses

t_{c q, ma x}

and hold uses

t_{c q, min}

. See Setup and hold time.

Why can a design that runs fine at low frequency still have hold violations at that same low frequency?

Because hold is frequency-independent — the short-path race (left amber band, Figure 3) happens on every single edge regardless of period. A hold bug is present at any clock speed.

Why is the critical path the one that sets maximum frequency?

f_{ma x}

is limited by the path needing the most time; that longest-delay (critical) path forces the smallest allowable

T_{c l k}

, and everything else has slack to spare. See Critical path and pipelining.

Why do false paths and multi-cycle paths need explicit designer declaration?

STA is purely structural — it can't know a path is logically impossible (false) or intentionally allowed extra cycles (multi-cycle). Without a declaration it over-constrains the design and reports violations that don't really exist.

Edge cases

What happens to hold if

t_{co mb, min} = 0

and

t_{c q, min} < t_{h}

Hold fails:

t_{c q, min} + 0 < t_{h}

. This is the classic zero-logic back-to-back flop hazard — the new data outruns the hold window (Figure 1) even with no gates.

What if setup slack is exactly

0

The path meets timing with no margin. Any process/voltage/temperature variation pushes it negative, so tools usually flag zero slack as risky, not truly safe.

What is a false path and why doesn't it limit timing?

A path that can never be logically activated by any input combination. It may be physically long, but since no real data ever traverses it, you declare it false so STA ignores its delay when computing

f_{ma x}

What is a multi-cycle path and how does it change the setup check?

A path the design intentionally allows

N > 1

clocks to complete. Its setup deadline is near

N T_{c l k}

instead of

T_{c l k}

, so you declare a multi-cycle exception — otherwise STA reports a false setup violation.

What if the launch and capture flip-flops are driven by clocks that never share edges (asynchronous)?

Standard STA doesn't apply cleanly; you need a synchronizer and metastability analysis instead of a single setup/hold check. See Metastability and Clock skew and clock trees.

If skew is negative (capture clock arrives earlier), what happens to each check?

Setup gets harder (deadline moves earlier, budget

T_{c l k} + t_{s k e w}

shrinks) while hold gets easier (requirement

t_{h} + t_{s k e w}

drops) — the mirror image of Figure 4.

Can adding a buffer to fix hold ever break setup?

Yes, if the buffer sits on a path that is also near its setup limit — the extra delay lengthens that path (pushes the amber arrival right, Figure 2) and can eat its setup slack. Add delay only on genuinely short paths.

What limits

f_{ma x}

if every combinational path had zero delay?

The flip-flop overhead itself:

f_{ma x} = 1/ (t_{c q, ma x} + t_{s u})

. You can never clock faster than the flops' own launch-plus-setup dead time.

Connections

#flashcards/hardware