Clock-to-Q delay: Question bank — Hardware deep dive

Quick symbol reminder so nothing below is used unexplained:

$t_{p c q}$ = propagation clock-to-Q delay — the worst-case (maximum) time until $Q$ is fully valid.
$t_{cc q}$ = contamination clock-to-Q delay — the best-case (minimum) time before $Q$ starts to change.
$t_{p d}$ = combinational logic delay (max version $t_{p d, m a x}$ , min version $t_{p d, m i n}$ ).
$t_{se t u p}$ / $t_{h o l d}$ = how long data must be stable before / after the receiving flip-flop's clock edge. See Setup and Hold Time.
$T_{c}$ = clock period; $f_{ma x} = 1/ T_{c, m i n}$ . See Maximum Clock Frequency.

True or false — justify

True or false:

Q

changes at the exact instant the clock edge arrives.

False.

Q

changes

t_{c q}

after the edge — internal transistor capacitances must charge/discharge, and that takes real physical time.

True or false: A flip-flop with a larger

t_{p c q}

can run at a higher maximum frequency.

False.

f_{ma x} = 1/ (t_{p c q} + t_{p d} + t_{se t u p})

; a bigger

t_{p c q}

enlarges the denominator, so

f_{ma x}

drops. More launch delay steals from the cycle budget.

True or false:

t_{cc q} \leq t_{p c q}

always holds.

True. Contamination is the earliest

Q

can move; propagation is the latest it settles. The start of a change can't come after its finish, so the minimum never exceeds the maximum.

True or false: Both the setup check and the hold check use the same single

t_{c q}

number.

False. Setup (slow-path, catches the next edge) uses max

t_{p c q}

; hold (fast-path, must not corrupt the current edge) uses min

t_{cc q}

. Mixing them flips your safety margin the wrong way.

True or false: If a design fails setup, you can fix it by making the clock faster.

False. A setup failure means the cycle is already too short; a faster clock shortens

T_{c}

further and makes it worse. You must slow the clock or shorten the logic path.

True or false: The hold constraint

t_{cc q} + t_{p d, m i n} \geq t_{h o l d}

contains no

T_{c}

term, so hold failures don't depend on clock frequency.

True. Hold is a same-edge race between launch and capture — it has no room for a full period. That's why you cannot fix a hold violation by changing the clock speed.

True or false: Adding a buffer (extra delay) to a path is always bad for timing.

False. Adding delay to a short path is the standard fix for a hold violation, and it doesn't touch

f_{ma x}

(which depends on the long path). Delay is a tool, not just a penalty.

True or false:

t_{c q}

is measured from the moment

Q

starts moving to the moment it finishes.

False. It's measured from the clock edge (50% voltage point) to

Q

reaching its own 50% point — clock edge is the reference, not

Q

's own onset.

True or false: In an ideal truth-table view of a flip-flop,

t_{c q} = 0

True in the model, false in silicon. The truth table is a discrete abstraction with no time; real gates always have

t_{c q} > 0

. Trusting the ideal view overestimates

f_{ma x}

Spot the error

Spot the error: "For the setup check I'll use

t_{cc q}

because it's the delay of the launching flip-flop."

The launching flip-flop does set the delay, but setup is a worst-case check, so it needs the maximum launch delay

t_{p c q}

, not the minimum

t_{cc q}

. Using

t_{cc q}

pretends data launches earlier than guaranteed.

Spot the error: "

f_{ma x} = 1/ (t_{p c q} + t_{p d} + t_{se t u p} + t_{h o l d})

t_{h o l d}

does not belong in the period equation — hold is a same-edge constraint with no bearing on cycle length. The setup/frequency budget is

t_{p c q} + t_{p d} + t_{se t u p}

only.

Spot the error: "Since

t_{p d}

is the same block of logic, I'll use

t_{p d, m a x}

in both the setup and the hold equations."

Setup uses

t_{p d, m a x}

(slowest path may miss the next edge); hold uses

t_{p d, m i n}

(fastest path may arrive too early). Same logic block, but the two checks probe opposite extremes.

Spot the error: "Hold violation? Just increase the clock period to give more time."

The clock period never appears in the hold inequality, so lengthening

T_{c}

does nothing. The fix is to add delay to the short combinational path so data arrives after

t_{h o l d}

Spot the error: "

t_{p c q}

measures how long the input

D

takes to reach the flip-flop."

That's the logic/wire delay before the flip-flop.

t_{p c q}

is measured from the clock edge to the output $Q$ — it's an output delay of the flip-flop itself, not an input path.

Spot the error: "We slowed the clock and the setup slack got worse."

Slowing the clock increases

T_{c}

, which increases setup slack (more room in the cycle). If slack got worse, either the clock was made faster or another parameter changed — slowing never hurts setup.

Why questions

Why does clock-to-Q delay exist at all?

Every internal node has capacitance; a transistor must charge or discharge that capacitance to flip the output, and moving charge through finite resistance always takes finite time.

Why do manufacturers publish two clock-to-Q numbers (

t_{cc q}

and

t_{p c q}

Because timing has two opposite worst cases: the slowest response threatens setup/frequency (needs the max,

t_{p c q}

), and the fastest response threatens hold (needs the min,

t_{cc q}

). One number can't cover both extremes.

Why does the setup check use the maximum path delays while the hold check uses the minimum ones?

Setup fails when data arrives too late for the next edge — so we assume everything is as slow as possible. Hold fails when new data arrives too early and corrupts the current capture — so we assume everything is as fast as possible.

Why must

t_{p c q}

be included in the minimum-period inequality instead of assuming

Q

launches instantly?

Assuming instant launch pretends FF1 responds at the edge, which underestimates when data actually leaves. That inflates

f_{ma x}

and hides real timing bugs that appear on the bench.

Why is

t_{cc q}

(a small delay) actually a good thing for hold but a hidden danger?

A large

t_{cc q}

delays the arrival of new data, which helps satisfy hold. A very small

t_{cc q}

means the new value races out early and can clobber the previous capture — so tiny fast delays are precisely what causes hold violations.

Why doesn't fixing a hold violation change the maximum operating frequency?

Hold is fixed by padding the short path, but

f_{ma x}

is set by the long (critical) path. Adding delay to a non-critical path leaves the critical path — and therefore

T_{c}

— untouched.

Why is

t_{c q}

measured to the 50% voltage point of

Q

rather than when

Q

is fully at the rail?

The 50% point is a clean, well-defined crossing that's symmetric for rising and falling edges; waiting for the full rail is fuzzy and depends on the load, so 50% gives a repeatable reference.

Edge cases

Edge case: A wire directly connects FF1's

Q

to FF2's

D

with no logic (

t_{p d, m i n} = 0

). Is hold automatically safe?

Not automatically. The check becomes

t_{cc q} \geq t_{h o l d}

; if the flip-flop's own contamination delay is smaller than its hold requirement, it fails even with zero logic. Directly-connected flip-flops are the classic hold-failure case.

Edge case: What happens to the setup equation if the logic delay

t_{p d} = 0

(two back-to-back flip-flops)?

It reduces to

T_{c} \geq t_{p c q} + t_{se t u p}

— the fastest a flip-flop chain can be clocked, set purely by the flip-flops themselves. This is the floor on the period no logic can beat.

Edge case: If

t_{cc q} = t_{p c q}

(a hypothetical flip-flop with zero spread between min and max), what does that imply?

The output timing is perfectly deterministic —

Q

always settles at exactly one time. Real flip-flops always have

t_{cc q} < t_{p c q}

due to process, voltage, and temperature variation, so this is an idealization.

Edge case: The combinational block has one path of

30

units and another of

300

units. Which drives setup and which drives hold?

The 300 (max) path drives the setup/frequency check (slowest data may miss the edge); the 30 (min) path drives the hold check (fastest data may arrive too early). One block, two extremes. See Timing Analysis.

Edge case: If the clock reaches FF2 later than FF1 (positive clock skew toward the capture flip-flop), does that help or hurt setup?

It helps setup — the later capture edge gives data more time to arrive — but it hurts hold, because the new data now has even more time to race in and corrupt the delayed capture. See Clock Skew.

Edge case: Can

f_{ma x}

ever be limited by

t_{c q}

alone, with no logic and no setup?

No —

t_{se t u p}

is always present in the receiving flip-flop, so the floor is

t_{p c q} + t_{se t u p}

at minimum. You can drive

t_{p d}

to zero but never remove the setup term.

Recall One-line summary of the traps

The single deepest trap: which extreme? Setup = slow world (max $t_{p c q}$ , max $t_{p d}$ ); hold = fast world (min $t_{cc q}$ , min $t_{p d}$ ). Get the extreme wrong and every downstream number points the wrong way.

Connections

Clock-to-Q delay — the parent concept this bank stress-tests.
Setup and Hold Time — the two constraints most of these traps hinge on.
Flip-Flops — the device producing $t_{c q}$ .
Combinational Logic Delay — the $t_{p d}$ min/max split behind the "which extreme" trap.
Maximum Clock Frequency — where the setup budget becomes $f_{ma x}$ .
Timing Analysis — the framework tying min/max paths together.
Clock Skew — modifies the setup/hold balance in the edge-case items.