Half-Cycle Paths & Edge Selection

Timing constraints — clocks, generated clocks, I/O delays, exceptions, OCV and MCMM setup

Half-Cycle Paths & Edge Selection

Timing usually assumes a full cycle. Data launches on one edge and is captured one full period later. But not every path works that way. Some paths launch on one clock edge and are captured on the opposite edge. They get only half a cycle to finish. These are half-cycle paths. Half-cycle paths are common when a design mixes rising-edge and falling-edge flip-flops. A flip-flop is a one-bit memory that updates on a clock edge. Most use the rising edge. Some use the falling edge. When data crosses between the two, only half a period is available. SDC, the timing constraint format that compliant tools read, models this automatically once clocks are defined. We never expand the letters; we say SDC. This chapter explains opposite-edge paths, negative-edge flops, how the tool picks edges, and why half-cycle paths are tight and easy to miss.

Picture one clock. It rises, then falls, then rises again. A normal path launches on a rising edge and is captured on the next rising edge. The gap is one full period. That is the usual setup relationship. Now suppose the launching flip-flop uses the rising edge, but the capturing flip-flop uses the falling edge. The data launches at the rising edge. The next capture happens at the falling edge, which comes only half a period later. The path now has half the time it would normally have. This is the heart of a half-cycle path. The opposite case also exists. A falling-edge launch captured by a rising-edge flop. Again, the next opposite edge is half a period away. Either way, the path is squeezed into half the period instead of the full period. The exact half depends on the duty cycle. Duty cycle is the fraction of the period the clock is high.

Suppose the period is 4.92 ns with a fifty percent duty cycle. The high time and low time are each 2.46 ns. A rising-to-falling path gets just 2.46 ns. That is half the time a normal path enjoys. The logic in that path must be much faster to fit.

Negative-Edge Flip-Flops

A negative-edge flip-flop captures on the falling edge of the clock. The falling edge is when the clock drops from high to low. The common positive-edge flip-flop captures on the rising edge. Designers use negative-edge flops on purpose, often to grab data half a cycle earlier or to balance a path. When a negative-edge flop talks to a positive-edge flop, half-cycle timing appears. Say a positive-edge flop launches data at the rising edge. A negative-edge flop captures it at the very next falling edge. That falling edge is only the high time away, which is half the period at fifty percent duty. So the path is a half-cycle path with only the high time to complete. Negative-edge flops are useful but they demand care. The half-cycle they create is tighter than a normal path. If a designer drops in a negative-edge flop to fix one issue, they may create a hard-tomeet half-cycle path elsewhere. The benefit on one path can become a burden on another.

The waveform in the clock definition matters a lot here. The high time and low time decide how long each half-cycle path really has. If the duty cycle is not fifty percent, the two halves differ. A clock with a 2.95 ns high time and a 1.97 ns low time, for a 4.92 ns period, gives a rising-to-falling path 2.95 ns but a falling-to-rising path only 1.97 ns. The asymmetric clock makes one direction much tighter than the other.

How the Tool Picks Edges

The timing tool does not guess. It picks the launch edge and the capture edge by a clear rule. For setup, it finds the launch edge, then looks for the nearest later capture edge at the destination flop's active edge. Active edge means the edge the destination uses, rising or falling.

So if the destination is a falling-edge flop, the tool looks for the next falling edge after the launch. If that falling edge is only half a period away, the tool times the path to half a period. It does not give a halfcycle path a full cycle by mistake. The edge type of each flop drives the choice automatically. Hold uses a related rule but a different edge. For hold, the tool checks the capture edge against the same launch, making sure fast data does not arrive too early at that opposite edge. The capture edge for hold is usually one edge before the setup capture edge. With half-cycle paths this can land at an awkward spot, which is part of why hold on these paths needs attention.

A worked example shows the pick. The period is 4.92 ns. A positive-edge flop launches at time 0. The destination is a negative-edge flop, so its active edge is falling. The first falling edge after time 0 is at 2.46 ns. The tool sets the setup capture at 2.46 ns. The path therefore has 2.46 ns to complete, not 4.92 ns. The tool reached this purely from the edge types; no special command was needed.

Why You Write No Special Constraint

A surprising point: half-cycle timing needs no special SDC command. You do not declare a half-cycle path the way you declare a multicycle path. The tool figures it out from the flops' edge types and the clock waveform. Define the clock correctly, instance the flops, and the half-cycle relationship falls out. This is different from a multicycle path, which you must declare. A multicycle path is one you allow more cycles than normal. You write that explicitly. A half-cycle path is the reverse: it naturally gets less time, and the tool applies that on its own. The only thing you must supply is an accurate clock, especially its waveform.

# standard SDC — portable across compliant tools
# no half-cycle command exists; correct clock waveform is what matters
create_clock -name dat_clk -period 4.92 -waveform {0 2.95} [get_ports dat_clk]

If the clock waveform is wrong, the half-cycle path is mistimed. Say you write a fifty percent duty when the real clock is sixty percent high. The tool thinks the rising-to-falling path has 2.46 ns when it really has 2.95 ns, or the reverse. The path is checked against the wrong window. So the single most important habit for half-cycle paths is getting the clock waveform right.

Half-cycle paths are tight because they get half the time. The logic between the flops must finish in half a period. If the full-period budget was already comfortable, half of it may not be. A path that easily met a 4.92 ns budget can fail badly against a 2.46 ns budget. So half-cycle paths often dominate the failing list even when the design looks healthy overall. They are easy to miss for two reasons. First, you do not declare them, so there is no line in the SDC to remind you they exist. They hide in the mix of positive and negative edge flops. Unless you look, you may not know a half-cycle path is even there. Second, summary reports can bury them. A worst-case report grouped by clock may show one big violator and hide the half-cycle ones below it. The cure is to look for them on purpose. Ask the tool for paths that launch on one edge and capture on the opposite. Filter the report by rising launch and falling capture, and the reverse. This surfaces the half-cycle paths so you can check each has enough margin. Treat them as a special class to review, not as ordinary paths.

A second worked example shows the trap. A design has a clock at 4.92 ns. One path between two positive-edge flops has 3.80 ns of logic and passes the full-period budget with room. A nearby path runs from a positive-edge flop to a negative-edge flop, with 2.90 ns of logic. Against a full period it would pass easily. But it is a half-cycle path, so its budget is only 2.46 ns. The 2.90 ns of logic overruns by 0.44 ns. It fails, even though it looked faster than the path that passed. Only by filtering for opposite-edge paths would you catch it.

Interview Q&A

opposite edge, so it gets only half a period instead of a full one. It typically appears when a design mixes rising-edge and falling-edge flip-flops, and data crosses between the two edge types.

flip-flop captures on the falling edge instead of the rising edge. When it talks to a positive-edge flop, the next opposite edge is only half a period away, so the path between them is a half-cycle path with just the high time or low time to complete.

edge and finds the nearest later edge that matches the destination flop's active edge. If the destination is a falling-edge flop, the next falling edge may be half a period away, so the path is timed to half a period. The flop edge types drive the choice.

which you must declare, a half-cycle path falls out automatically from the flop edge types and the clock waveform. The only thing you must supply is an accurate clock definition, especially its high and low times.

which decide how long each half-cycle path really has. If the duty cycle in the SDC is wrong, the tool checks the path against the wrong window, so a half-cycle path can be mistimed even though everything else looks correct.

they hide in the mix of positive and negative edge flops. Summary reports can bury them under bigger violators. You catch them by deliberately filtering reports for paths that launch on one edge and capture on the opposite.

Key Takeaways

• A half-cycle path launches on one edge and captures on the opposite, getting only half a period to complete.
• Negative-edge flip-flops create half-cycle paths when they exchange data with positive-edge flops, since the next opposite edge is half a period away.
• The tool picks edges automatically by finding the nearest later edge matching the destination flop's active edge, so half-cycle timing is applied without a command.
• You write no special half-cycle constraint, but the clock waveform must be accurate because its high and low times set each path's real budget.
• Half-cycle paths are tight and easy to miss, so filter reports by opposite-edge launch and capture to surface and review them deliberately.