IntermediateQuestion 61 of 112

What is a half-cycle path, and why does it need a multicycle exception?

From PDVerse STA Mentor Guide, part of the pdVerse Mentor Guide

By Tabish Iqbal, who has 9+ years of VLSI Physical Design experience

Last updated: 28 Sept 2026

Short Answer

A half-cycle path launches on one clock edge and is captured on the very next edge of the same clock, so by default the tool gives it only half a clock period instead of a full one. A multicycle exception tells the tool to check it over a full cycle instead, when the design only needs a new result once per cycle.

Waveform showing a rising-edge launch flop and a falling-edge capture flop 2.5ns apart on a 5ns-period clock, with the default half-cycle setup check next to the corrected full-cycle check after set_multicycle_path -setup 2. — Technical Reference DiagramWhat is a half-cycle path, and why does it need a multicycle exception?

Technical Reference DiagramWhat is a half-cycle path, and why does it need a multicycle exception?

Technical Explanation

By default, PrimeTime times every path to the nearest following clock edge, and that assumption is what creates a half-cycle path.

The default is edge-to-edge, not cycle-to-cycle. If a launch flip-flop's clock pin sees a rising edge and the very next active edge on the capture flip-flop is a falling edge half a period later, the tool checks that path in half a period, whether or not the design meant it that way.
This shows up whenever both edges of one clock drive flip-flops — a common pattern in double-data-rate style logic, or any design that reuses the falling edge of an existing clock instead of adding a second clock.
The fix is set_multicycle_path -setup N ... (SDC). Setting -setup 2 moves the checked capture edge one edge further out, effectively granting a full cycle instead of half a cycle.
Moving the setup edge shifts the hold edge too, by default. The tool bases every valid hold relationship on the setup relationship you just changed, so a -hold exception is usually needed alongside -setup to put the hold check back where the design actually needs it.
Why this matters for closure: treating a genuinely one-cycle-per-result path as a half-cycle path forces synthesis and place-and-route to hit a deadline that is twice as tight as necessary, which can cost real area and power for no functional benefit.
The reverse mistake is just as real: applying a multicycle exception to a path that truly does need a new result every half cycle turns a real violation into a silent pass.

State	What it checks	Effect
Default (no exception)	Edge-to-edge: the very next active clock edge, whatever its polarity	Correct for logic that really needs a new result every half cycle; unnecessarily tight otherwise
`set_multicycle_path -setup N`	Moves the checked setup capture edge N cycles further out	Grants more time for setup, but silently shifts the hold check edge too
`set_multicycle_path -hold M`	Pulls the checked hold edge back to where the design actually needs it	Needed alongside `-setup`, or hold is checked against the wrong, usually too-late, edge

Common Mistake

The Trap: assuming every path between flip-flops on the same clock automatically gets a full period, and only discovering the half-cycle default when synthesis reports an unexpectedly tight path.

A designer builds logic that only needs a new value once per full cycle, then is surprised the report shows a half-period requirement because the capture flop happens to use the falling edge.
Chasing that half-cycle deadline with buffering or resizing wastes area and power fixing a constraint the design never actually needed.

Follow-up Question & Model Response

You add set_multicycle_path -setup 2 to grant a half-cycle path a full cycle. Do you need to change anything else, or is the setup fix complete on its own?

Candidate Model Response: The setup fix alone is not complete, because moving the setup capture edge automatically moves the hold check to a new, usually incorrect, edge. I would add a matching set_multicycle_path -hold 1 ... (SDC) on the same path to pull the hold check back to right after the launch edge. Without that second command, the tool checks hold against a capture edge a full cycle later than intended, which can mask a real hold violation. I would confirm the final relationship with report_timing, checking both edges line up with the design's real behavior.

Practical Example

A 200MHz clock (5ns period) drives one flip-flop on its rising edge and a second flip-flop on its falling edge, 2.5ns later. The datapath between them only needs to settle once per full 5ns cycle, so the team applies set_multicycle_path -setup 2 -from [get_cells FF_A] -to [get_cells FF_B] (SDC), granting the full 5ns instead of 2.5ns. They pair it with set_multicycle_path -hold 1 -from [get_cells FF_A] -to [get_cells FF_B] to pull the hold check back to the original launch-adjacent edge, matching PrimeTime's documented rule that hold cycles equal the setup value minus one minus the hold value.

Complete STA Handbook