3.4.5 · D5Sequential Circuits
Question bank — Setup and hold time constraints
Before we start, one shared vocabulary reminder so nothing below uses an unexplained symbol:
Everything on this page — setup, hold, skew, metastability — is ultimately a statement about whether some signal edge falls inside that red band. Keep the picture in mind for every trap.
True or false — justify
Setup violations can always be fixed by slowing the clock.
True. Setup is , so raising (slower clock) always helps — the constraint literally contains .
Hold violations can be fixed by slowing the clock.
False. The hold inequality has no term — it is a same-edge race, so the period cancels out. Only adding fast-path delay helps.
A flip-flop with zero combinational logic between it and the next FF can never have a hold problem.
False. Even with a direct wire, might be smaller than ; the fast new data can race into the next FF's own keep-still window. Zero logic often makes hold worse, not safer.
Setup uses the slowest delays and hold uses the fastest delays.
True. Setup fears data arriving too late → worst-case (max) delays. Hold fears data arriving too early → best-case (min) delays. "Setup MAX, Hold MIN."
Positive capture-clock skew is always good because it raises .
False (a classic trap). It relaxes setup () but tightens hold (). Push it too far and you create unfixable-by-frequency hold failures.
Negative capture-clock skew (capture clock arrives early) helps hold.
True. With the hold bound becomes , and a negative lowers the right side — easier to meet. But the same negative skew tightens setup ( loses time), so it is again a trade.
If a design meets setup at some frequency , it also meets setup at any lower frequency.
True. Lowering (fewer ticks per second) raises ; setup only asks to be large enough, so a larger can only help.
If a design meets hold at some frequency, it meets hold at every frequency.
True. Since the hold inequality contains no , its pass/fail status is frequency-independent — it is decided purely by the delays.
A larger is bad for both setup and hold.
False. Larger hurts setup (data leaves later, less margin), but larger actually helps hold (new data leaves later, so it disturbs the next FF later — good).
Metastability can happen even if setup and hold are both perfectly satisfied.
True but rare. Within spec the probability is essentially negligible, yet asynchronous inputs that ignore the keep-still window can still hit it — that's why synchronizers exist.
Spot the error
"Max frequency = ."
Wrong — does not belong in the setup/frequency formula. ; hold is a separate, frequency-free constraint.
"To fix a hold violation, reduce the combinational logic delay."
Backwards. Hold needs the fast path to be longer so data arrives after the window; you add delay (buffers), not remove it. Reducing delay makes hold worse.
"Setup is checked against the current edge, hold against the next edge."
Reversed. Setup is a race across the whole period (this launch edge vs. the next capture edge). Hold is a race within the same edge — data launched by an edge disturbing the value captured on that same edge.
"Since hold has no , hold violations are harmless."
A hold violation means correct data may be overwritten before it's latched → wrong stored value or metastability. It is frequency-proof, which makes it more dangerous, not harmless — you cannot dial it away.
"We subtract from in setup because the flip-flop is slow to react."
The subtraction reserves the last of the period as the capture FF's keep-still window; nothing may still be arriving there. It's about protecting the sampling window, not about the FF being sluggish afterward (that's ).
"Adding buffers to fix hold will also fix setup."
No — buffers lengthen the path. If placed on the critical (max) path they hurt setup. Hold fixes go on the fast (min) path; done carelessly they can eat setup margin, so placement matters.
Why questions
Why does the clock period cancel out of the hold constraint?
Both the launching edge and the disturbing data ride the same clock edge. Any that shifts the launch edge shifts the capture window identically, so it algebraically disappears.
Why does positive capture skew help setup but hurt hold?
A later capture edge gives arriving data more time before it (setup easier) but extends the keep-still window further into the just-launched fast data (hold harder). Same delay, opposite effect on the two edges involved.
Why does negative capture skew flip that trade-off?
An earlier capture edge shrinks the period seen by setup (less time for slow data → setup harder) but pulls the keep-still window away from the fast just-launched data (hold easier). It is the mirror image of positive skew.
Why can't we just use as a single number instead of min and max?
Setup needs the worst-case (max) to guarantee even the slowest data arrives in time; hold needs the best-case (min) to guarantee even the fastest data doesn't arrive too soon. One number can't play both roles.
Why is Pipelining limited by the setup constraint and not hold?
Pipelining raises clock frequency by shortening ; the setup formula caps how small can get. Hold, being frequency-free, doesn't bound the pipeline's speed — it must simply be met independently.
Why does Static Timing Analysis (STA) check setup and hold separately?
They use opposite delay corners (max vs. min) and opposite edges, so they are mathematically distinct inequalities. A tool must evaluate both to certify a design; passing one says nothing about the other.
Edge cases
What happens if and (FF directly feeding FF)?
A hold violation is likely: the fast new data reaches the next FF within its keep-still window. Designers insert delay buffers on this shift-register-like path precisely to survive it.
What if or is negative (real datasheets allow this)?
A negative setup means data may arrive slightly after the edge and still be caught; negative hold means data may change slightly before the edge safely. The inequalities still hold — the negative number just relaxes that constraint.
What if already exceeds any usable period?
The path is unroutable at speed — no clock is slow enough for the target frequency. You must redesign: split the logic (Pipelining), simplify it, or use faster cells.
What if the capture skew is negative and large enough to fail setup on its own?
Even with zero logic delay, can drop below . The early capture edge simply doesn't leave enough of the period for the data to settle — a setup failure caused purely by clock timing. See the left-shifted edge in Figure s02.
What if jitter makes each edge arrive at a random time?
Jitter shrinks the effective margin on both setup and hold, because the worst-case edge timing must be assumed. Unlike fixed skew (which trades one for the other), jitter can only hurt.
What if two FFs share the exact same clock net with zero skew — is hold automatically safe?
No. Zero skew removes the penalty, but hold still requires on its own. A too-fast path fails even with a perfect clock.
Connections
- Setup and hold time constraints — the parent note these traps stress-test.
- Metastability — the failure that a violated keep-still window produces.
- Clock Skew and Jitter — why positive/negative skew trades setup for hold, and jitter hurts both.
- Static Timing Analysis (STA) — the tool that checks both corners automatically.
- Combinational Logic Delay — the paths whose min/max drive these checks.