Clock Jargon: Important Terms

Clock to an SoC is like blood to a human body. Just the way blood flows to each and every part of the body and regulates metabolism, clock reaches each and every sequential device and controls the digital events inside the SoC. There are many terms which modern designers use in relation to the clock and while building the Clock Tree, the backend team carefully monitors these. Let's have a look at them.

• Clock Latency: Clock Latency is the general term for the delay that the clock signal takes between any two points. It can be from source (PLL) to the sink pin (Clock Pin) of registers or between any two intermediate points. Note that it is a general term and you need to know the context before making any guess about what is exactly meant when someone mentions clock latency.
• Source Insertion Delay: This refers to the clock delay from the clock origin point, which could be the PLL or maybe the IRC (Internal Reference Clock) to the clock definition point.
• Network Insertion Delay: This refers to the clock delay from the clock definition point to the sink pin of the registers.

Consider a hierarchical design where we have multiple people working on multiple partitions or the sub-modules. So, the tool would be oblivious about the "top" or any logic outside the block. The block owner would define a clock at the port of the block (as shown below). And carry out the physical design activities. He would only see the Network Insertion Delay and can only model the Source Insertion Delay for the block.

Having discusses the latency, we have now focus our attention to another important clock parameter: The Skew.

We discusses the concept of skew and it's implication on timing in the post: Clock Skew: Implication on Timing. It would be prudent to go through that post before proceeding further. We shall now take the meaning of terms: Global Skew and Local Skew.

• Local Skew is the skew between any two related flops. By related we mean that the flops exist in the fan-in or fan-out cone of each other.
• Global Skew is the skew between any two non-related flops in the design. By non-related we mean that the two flops do not exist in the fan-out or fan-in cone of each other and hence are in a way mutually exclusive.

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 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.