March 12, 2013

Multi-Cycle Paths: Perspective & Intent

Multi-Cycle Paths, as the name suggests, are those paths which need not be timed in one clock cycle. It is easier said than done! Before we discuss further, let's talk about what Multi-cycle paths does not mean!!

Myth 1: All those paths which the STA team is unable to meet at the highest clock frequency, are potential multi-cycle paths.
Reality: Multi-cycle paths are driven by the architectural and design requirements. STA folks merely implement or appropriately said, model the intent in their timing tools! A path can be a multi-cycle path even if the STA team is able to meet timing at the highest clock frequency.

Myth 2: It is by some magic that the design teams conjure up how many cycles it would be appropriate to for a path to function! <Apologies the hyperbole! :)>. And STA team follows the same in their constraints.
Reality: MCPs are driven by the intent. And implementation is governed by that intent which includes but is not limited to the number of run modes a particular SoC should support.

Consider the following scenario:

Normal mode, Low Power Mode and Ultra Low Power Modes can be considered to be the different run modes of the SoC. You can say that the customer can choose at what time which run mode would be better. Example: when performance is not critical, or your device can go to 'hibernate' mode, you (or the software) can allow the non-critical parts of the SoC to go into a Low Power Mode, and hence save power!

Consider the specifications:
  • Normal Mode: Most Critical IP & Not-So Critical IP would work at f MHz. Least Critical IP would work at f/2 MHz. Interaction between any two IPs would be at slower frequency.
  • Low Power ModeMost Critical IP would work at f MHz. Not-So Critical IPLeast Critical IP would work at f/2 MHz. Interaction between any two IPs would be at slower frequency.
  • Ultra Low Power ModeMost Critical IP would work at f MHz. Not-So Critical IP would work at f/2 MHz. And Least Critical IP would work at f/k MHz; (k=> 3-8). Interaction between any two IPs would be at slower frequency.
Consider the Low Power Mode. Any interaction within the Not-So Critical IP would be at slower frequency. However, any paths between the Most Critical IP and Not-So Critical IP would be Multicycle path of 2 in the low power mode. In this case, the clock at the Not-So Critical IP is gated selectively for every alternate clock cycle to implement an MCP. Hence data launched from Most Critical IP now effectively gets two clock cycles (of the faster clock) to reach the Not-So Critical IP. The following figure explains the intent:

This much for the intent! However, as we mentioned that for the Least Critical IP, depending on the mode, would work at f/k MHz => (k=3-8) one might need an MCP of 2, 3, 4.... and so on. This calls for a need of a configurable implementation of multicycle paths. We shall cover it sometime later. Till then, you can assimilate on the intent part. You can also mail me in case you think of any such implementation at my<dot>personal<dot>log<at>gmail<dot>com. Adios!


  1. Nice! I must confess that was really an eye-opener. All this while, I used to think that all those paths which can't be met in single cycle, are potential MCPs!


  2. Hi Danny. Thanks for the kind words of appreciation. :) I am glad you liked the post! :)

  3. Do we need to declare the path as MCP, even if the clock with 'f' freqency and 'f/2' are derived from the same clock source ?

    1. Yes. The timing tools (like ETS and Primetime) would always try to time those paths at the highest frequency, i.e. f. We need to explicitly define in the MCP: the number of MCPs wrt to fast or the slow clock and the through pin (optional).

  4. Another doubt, should we define MCP with respect to the launch clock or the destination clock ? By any chance, will the synthesis tool will help us identify the possible MCP and False paths ?

    1. MCPs could be defined wrt to any clock. See, as I mentioned in the post, MCPs are governed by architecture. The STA folks must understand the intent that's the designer implies and then apply the MCP which could be wrt to fast clock or slow clock; launch clock or the fast clock (or maybe both!).

      Synthesis tools are not cognizant of MCPs or false paths. Although majority of the MCPs are false paths are governed by the design about which only a designer can tell, the synthesis (or for that matter the timing tool itself) cannot even identify some obvious false paths as the one depicted in this problem:

      One must always understand the intent behind MCPs or false paths and then model then accordingly.

      I hope I was able to answer your query! :)


  5. Could you kindly elaborate on 'configurable implementation of multicycle paths'?