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.