Common Path Pessimism

Common Path Pessimism is a common source of some extra pessimism in timing analysis. Before we delve further into this, note that pessimism can be of two types: Intended and Unwanted. Intended pessimism could be like adding some extra uncertainty for clock skew before CTS stage, or some uncertainty for noise before SI (Signal Integrity) analysis. It is often prudent to have this pessimism taken upfront in your design because it will avoid any surprises when you move from one stage to another. 

Having said that, which category do you reckon should Common Path Pessimism fall? Let's define it first and then we'll take a look at it objectively.

When any pair of launching and capturing flop have a some portion of clock path as common, the difference between the max and min delay of that common clock segment is referred to as Common Path Pessimism. We discussed the rationale behind the use of timing derates briefly in the post: OCV vs PVT. Note that the entire timing analysis revolves around this intended pessimism where the basic aim is to make the timing paths more critical to avoid seeing any surprises in the silicon. EDA tools, however, themselves have quite a fair amount of pessimism, it is always prudent for the STA engineers to augment some uncertainty/pessimism in their timing analysis.

Convince yourself that:

• Setup check would be most critical when clock reaches the launching flop late and capturing flop early; and the data path takes more delay.
• Hold check would be most critical when clock reaches the launching flop early, capturing flop late and data path takes less delay.

Consider the following example with no common clock path and note that we have just applied the above principle to add pessimism in timing analysis.

So, while doing setup analysis, the clock tree buffers in the launching path would be derated by +5% and in the capturing path would be derated by -5&. The data path would be derated by +5%.
While doing hold analysis, it would be the opposite. The clock tree buffers in the launching path would be derated by -5% and in the capturing path would be derated by +5&. The data path would be derated by -5%.

How would the situation change when there's a common clock path? Let's take a look.

Ideally speaking, for setup analysis, we would like to take the +5% derated value of the delay of these buffers while considering launching path and -5% derated value while considering the capture path. However, here lies the catch! How can the same buffer or set of buffers be derated differently for launch and capture? Recall from the definition of OCV that it is the intra-chip variation in PVT that STA engineers consider them in the first place.

However, now these buffers, they are in the same location. So at a time they would behave in a similar manner. It does not make sense to consider different delays for same buffers. And this is the origin of common path pessimism and in usually unwanted. What we can do is (or rather what EDA tools tend to do is), do the calculation considering common path to be non-existent. And in the slack, add the double derated value of the common buffers, which would be 10% of the three common buffers in this case. This is referred to as Common Path Pessimism Removal.

Combinational Loops

You would often hear backend engineers remonstrating the frontend design folks on the presence of combinational loops in the design. But why do they create such a hue and cry? What possibly could one or maybe few combinational loops do? Well, potentially, they can render the entire functionality of the SoC haywire and not taken care off. And some combinational loops, on the other hand, are indispensable for the evolution of a particular technology. We'll see how and why.

A combo loop is structure which is formed by a signal starting from an input of a combinational gate, after passing through one or more combinational gate, reaches the same combo gate from which it started without encountering any sequential element in between.

Here's what a generalized combo loop looks like:

• Unstable Loops: Let's start with a basic combo loop that you must have studied in your academics or at least heard about it. The reverend Ring Oscillator. It is an inveterate fallacy that a ring oscillator can be used to make a clock generating circuit. Trust me, clock generating or even divider circuits, for that matter, are not as simple as the ring oscillator shown below. 

Of what use could this simple circuit be? Well, if we can control any one input of any of the three inverters shown here, we can know the delay of an inverter which is often the first cell to be characterized in any technology. Moreover, test structures like these also help the foundry guys in determining the manufacturing process of a particular chip whether it was WCS or BCS.

• Stable Loops: Here's an example of a stable loop consisting of an OR gate. Note that, as soon as the free input receives a logic 1, the output goes to 1. And same signal is conveyed back to the another input, and the loop is stable or rather stuck-at-1.

Note that stable loops would not pose problems of copious dynamic power consumption. But such a loops pose headaches to DFT teams. Recall from the post: Two Pillars of DFT: Controllability & Observability, we talked about how stuck-at faults are simulated and detected. If such a loop would be present in the design, any stuck-at faults in the vicinity of this gate cannot be observed, and hence DFT team would lose their stuck-at coverage by a considerable amount!!

STA Concerns: We started this post with a preamble talking about backend engineers repining the frontend engineers. How would a backend engineer be affected by a combo loop? Here's how.

Recall from the post: Factors Affecting Delays of Standard Cells that the delay and output slew of any standard cell depends on the input slew and output load. The below figure shows one such example, where slew can keep on degrading indefinitely, and would ultimately impact the timing and more importantly the power consumption of the SoC.

To sum up, combo loops must be avoided in all SoCs except for special circumstances like ring oscillator circuit can be employed for testing the characteristics of the SoC.