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 Mode: Most Critical IP would work at f MHz. Not-So Critical IP & Least Critical IP would work at f/2 MHz. Interaction between any two IPs would be at slower frequency.
- Ultra Low Power Mode: Most 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!
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!
ReplyDeleteThanks!
Hi Danny. Thanks for the kind words of appreciation. :) I am glad you liked the post! :)
ReplyDeleteDo 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 ?
ReplyDeleteYes. 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).
DeleteAnother 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 ?
ReplyDeleteMCPs 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!).
DeleteSynthesis 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: http://vlsi-soc.blogspot.in/2013/02/puzzle-fixing-timing-violation.html
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! :)
Thanks!
Could you kindly elaborate on 'configurable implementation of multicycle paths'?
ReplyDeleteGreat Post !! I have one doubt. While doing Setup check for MCPs we check after every 2 clock cycle (as per above explanation). What about Hold check? Do we check at one clock cycle prior to setup check edge or at the launch edge?
ReplyDeleteIf Ive one or 2 critical paths in the design, can I apply MCP? If not, why? And what are the complications if we apply MCP for these 2 paths.
ReplyDeleteWhat is the difference between Timing MCPs and Functional MCPs?
ReplyDelete