Multicycle Path

What are multi cycle paths?

By default, timing paths are single cycle long. Here is what it really means. In digital
circuits, memory elements like flip flops or latches, launch new data at the beginning
of the clock cycle.

During the clock cycle, the actual computation is performed
through the combinational logic and at the end of the clock cycle data is ready and is
captured by the next memory element at the rising edge of the next clock cycle, which
is the same as ending of the current clock cycle.

Following figure illustrates this.

As shown in the figure, the launching flop keeps generating new set of data at the
output pin Q of the launch flop with every rising edge of the clock cycle. Similarly
capture flop keeps sampling input data every rising edge of the clock cycle.

As you can see in the figure the data launched on rising edge ‘1’ (in red) is supposed to be
captured by capture edge ‘1’ (in blue). Similarly capture edge ‘2’ corresponds to
launch edge ‘2’ and so on.
This is called a single cycle timing path.

There is one clock cycle from the launch of the data to the capture of the data. By default, timing tools assume this to be the circuit behavior. Timing tools will perform a setup check with respect to a capture clock edge, which is one clock cycle after the launch clock edge.

But this may not be the case every time. Many times what happens is that the
combinational delay from the launch flop to the capture flop is more than one clock
cycle.

In such cases, one cannot keep launching data at the beginning of every clock cycle and hope to capture correct data at the end of every clock cycle. In such cases data launched at the beginning of a clock cycle will just not reach the capture edge at the end of clock cycle.

When this is the case, the circuit designer has to account for this fact and design of the
circuit.

If the combinational delay from launch flop to the capture flop is more than
one clock cycle, but less than two clock cycles, the circuit designer has to design the
circuit in such a way that data is not launched from the launch flop at every clock
cycle but is launched at every other clock cycle.

And the data launched at the beginning of a clock cycle is captured not after one clock cycle, but two clock cycles.
Following figure depicts this.

As shown in the figure, let’s say that we have a circuit where we know that
combinational delay from launch flop to the capture flop is more than one clock cycle
but quite a bit less than two clock cycles, such that it can meet setup time requirements
comfortably in two clock cycles, but it doesn’t meet setup in one clock cycle.


You can see in the figure the data launched at the launch clock ‘1’, approximately
arrives at the capture flop (Data to be captured (D)) after about one and half clock
cycles.

As it was mentioned earlier, by default timing tools think that all timing paths
are one clock cycle long.

In other words, if the data was launched at launch clock ‘1’, the timing tool will think that it needs to be captured at the capture edge which is one
clock cycle after the launch edge, which is the capture edge shown in the figure with
black rising arrow

Timing tool by default will check setup with respect the capture edge shown in figure
with black rising arrow and will report that input data to the capture flop (Data to be
captured (D)), fails the setup to the capture flop as it arrives later than the capture
edge.

This check is shown in figure with dotted line. In reality we know that this is
false setup check. The capture flop input setup check should be against the capture
edge shown by the blue color.

As stated earlier, our design here is such that we expect
data to be take two clock cycles to travel from launch flop to capture flop and we have
designed our circuit such that launch flop doesn’t launch new data every clock cycle,
but it launches every other clock cycle as shown by the red color launch edges.

In such scenario, we need to provide the timing tool with an exception or an override and we need to tell the timing tool that, it needs to postpone its default setup check by one clock cycle.

In other words, we need to ask timing tool to give the one additional clock cycle time for the setup check. Usually this is achieved by something like following.

set_multi_cycle 2 -from -to Where ‘2’ is the clock cycle count. It instructs timing tool to use 2 clock cycles and not just default ‘1’ for the cases where we want timing tool to use 2 clock cycles.

Leave a Comment

Your email address will not be published. Required fields are marked *

error: Content is protected !!
Scroll to Top