Multicycle Path

Multicycle paths are another kind of timing exception like false paths. Generally, data launched from one flop reaches the next flop in one clock cycle. But there may be cases where it takes more than one clock cycle to reach the destination flop. Such paths are termed as ‘Multicycle paths’.

This can be due to a large combinational logic in the data path, as shown in Figure 1. The output of such combinational logic takes more than one clock period to be stable.

For example, Assume a design running at 100MHz, which means the clock period is 10ns. But the large combinational delay is taking a long time (i.e. 25 ns) to produce a definitive value. Now, the design has to make sure that the capture flop captures the data after 3 clock cycles giving enough time for data to be stable in the data path. Hence, this will be a path with MCP value ‘3’.

Unlike false paths, timing checks are not completely disabled on these paths.

The multicycle paths can also be seen when clock domain crosses from slower to faster clock and vice versa, here we are discussing multicycle paths in a single clock domain.

Setting Constraints:

For the timing analysis, the tool needs to be informed of the multicycle path through some constraints. There are set_multicycle_path constraints for the same. Please read setup and hold checks for refreshing the concepts.

• Set_multicycle_path 3 -setup -from FF1 to FF2
• This command directs the tool to a new capture edge. The hold check is also shifted as shown by red lines, which makes the analysis wrong. The hold check needs to be done on the same clock edge.

• Set_multicycle_path 2 -hold -from FF1 to FF2
• This moves the hold check as shown by blue lines. This is the complete constraint setting for this multicycle path.