“When do you use a false path, and when a multicycle path?” The interviewer then asks what proof they would show a reviewer.
The question tests constraint discipline. An exception relaxes a check, so each one needs a reason and a reviewer.
A false-path exception removes ordinary setup/hold analysis from selected paths. Justify it with a mode or functional exclusion, or a separately verified timing/protocol contract such as static configuration established before consumers run. It does not mean the signal has no functional importance. Scope the exception to the paths and views for which that justification holds.
A multicycle path is real but slow by protocol: data launched with an enable that the capture side honours N cycles later. It keeps a check, with a longer budget.
SDC (illustrative, not tool output)
set_false_path -from [get_clocks scan_clk] -to [get_clocks func_clk]
set_multicycle_path -setup 2 -from [get_cells en_reg] -to [get_cells dst_reg]
set_multicycle_path -hold 1 -from [get_cells en_reg] -to [get_cells dst_reg]The lines above show intent only. Exact syntax varies between tools and flows.
Exception | When it applies | Evidence required |
|---|---|---|
False path | Logically impossible paths or excluded modes; static configuration only under a proven initialization/consumption contract | Mode exclusion or startup sequencing/settling proof, scoped endpoints and designer sign-off |
Multicycle (setup N) | Enable-qualified data stable for N cycles | Enable waveform or protocol rule, hold pair set to N − 1 |
Neither | A path that is merely slow | No exception: fix the logic or the clock |
For same-clock rising-edge paths with period T and the usual end-based setup convention, setup N moves capture from T to NT. The companion hold multiplier N−1 restores the original hold edge at 0; it is not an (N−1)-cycle minimum-data-delay requirement. Confirm actual selected edges in the tool report.
Same-clock constraint | Launch | Setup capture | Hold capture for this launch |
|---|---|---|---|
Default | 0 | T | 0 |
setup 3 alone | 0 | 3T | 2T |
setup 3 + hold 2 | 0 | 3T | 0 (original relationship restored) |
Read each row from the launch edge at 0: the orange arrow is where setup is checked and the dark marker is where hold is checked.
Setup 3 alone stretches the setup arrow to 3T but drags the hold check out to 2T.
A hold check at 2T would demand roughly two cycles of minimum data delay, which is rarely intended.
Adding hold 2 pulls the hold check back to 0, the original relationship.
For different periods, phases or waveforms, -start and -end choose which clock's edges the multiplier moves. Derive launch/capture pairs explicitly; do not copy the same-clock N−1 recipe without reviewing those edges. See the canonical edge pairing.
Q: Who signs off an exception? The block designer documents the reason and a reviewer approves it. STA waivers are design waivers, not tool noise.
Q: A slow path is waived as false and silicon still fails. What went wrong? The path was sensitized after all. Every false path needs a sensitization argument, not just a passing run.
Q: The enable is every 4 cycles but jittery. Still multicycle? Only if the protocol guarantees 4 stable cycles in every case. Jitter in the guarantee voids the exception.
“False-path it and move on.” Without the exclusion proof this is timing fraud. The audit trail is the deliverable.
“Set multicycle 2 and skip the hold line.” In the stated same-clock convention the unpaired hold check moves to T, creating an unintended minimum delay requirement. The matching hold 1 restores edge 0. Review actual edges, especially for different waveforms or -start/-end choices.
“Cut the whole synchronizer.” A single-bit async input may have a scoped timing exception to its first stage; keep destination interstage timing for settling/MTBF. Gray buses need physical skew/arrival bounds, and held-data handshakes need data-before-capture timing. Clock groups remove checks and may override those bounds: audit active exception precedence and implementation reports. See crossing-specific constraints.
It restores the original hold relationship at launch edge 0. The 2 is an SDC edge multiplier, not a two-cycle hold budget. Inspect the reported edges and enforce the enable/stability protocol.
No. A consumer could sample the first value too soon or incoherently during initialization. Establish when writes finish, how the value settles or crosses domains, and when consumers are released. A mission-only exception may be justified after that contract is proved, with boot/wake/reconfiguration checked separately. Otherwise retain normal timing, or use an explicitly enforced multicycle/CDC protocol; infrequent updates alone justify neither exception.
The first-use setup/hold budget, reset-release sequencing and any CDC coherency requirement. Holding the value forever afterward does not repair an unsafe first capture.
The SDC lines show intent only; exact syntax varies between tools and flows.