TimeQuest Path Waveform Clock Pessimism

[Altera_Forum]

When looking at a path detail within Timequest (and specifically within the "waveform" tab"), there is a piece named "Clock Pessimism". I was wondering if anyone understood the origin for this pessimism? Just for more info, the launch and latch clocks for this path are the same, and the common clock path pessimism removal is enabled (by default). This is not a finished design so there are some virtual pins. Also, I am using Quartus 9.1. 

Thanks!

[Altera_Forum]

Pessimism should always be enabled. 

Within a timing corner, their are two timing "sub-models", basically a fast and a slow. So when doing setup analysis on a path, it will use the slow sub-model for the source clock and data delay, and the fast sub-model for the destination clock path. For hold analysis on the exact same path, it will do the opposite. If you compare setup and hold analysis on the exact same path, you can visually see different numbers.  Part of this is rise-fall variation, but a large component is for On-Die Variation, which models the fact that different paths may not be at the exact fastest or slower allowed at the same time. This is all a good thing. The problem is that the same clock feeds the source and destination. It's impossible to have on-die variation and rise/fall variation on the exact same signal, so it goes up to the point until the clock tree split, figures out how much pessimism was added because of these two models, and removes it. Again, it makes timing easier and is correct.

[Altera_Forum]

The clock pessimism that you see in the timing report is caused when scaling is applied to the clock path to account for different on-chip variations that are not accounted for the primitive block timing models. The scaling factor is applied to all cells and nets on the launch clock path, data path, and capture clock path. Imagine now that there is a portion at the root of the clock tree where the launch clock and capture clock are the same. There is no need to apply any scaling/pessimism to this portion of the clock tree to account for cross chip process effects because these effects cancel each other out in the path (which makes sense since they are the same cells and nets). Since the this extra pessimism is artificial, it is being removed. This removal is what you see in the line "clock pessimism. 

 The obvious question might be why is the pessimism put on the common portion of the path to start with. I guess it is easier for the timers to remove it after the fact. Maybe doing it this way simplifies the data structures and reduces memory consumption. This is just a guess as to why it is done this way...

[Altera_Forum]

I missed Rysc's reply while I was composing mine. Both explanations are the same...just stated a little differently.

[Altera_Forum]

Thanks you Rysc and BrettFavre for your replies. The thing in my case is that the CCPP removal is enabled so, as you both stated, I would think that the reported "clock pessimism" would be closer to 0 given that the launch and latch are being controlled by the same clock. However, it is not close to 0, and actually it is pretty significant (~10% of the cycle time). Unless I am reading things wrong (in TimeQuest), it definitely looks like the pessimism value is being added to the total path delay and there is nothing that is offsetting it.  

 Any ideas?

[Altera_Forum]

The piece named clock pessimism is named poorly in the timing report. It is actually reporting the pessimism that was removed. So, this item would be 0 of removal was disabled (might not even be listed in the timing report). I would expect the "clock pessimism" line in the timing report to be non-zero when the pessimism removal is enabled.

[Altera_Forum]

Thanks for the fast response! 

 So when I first read your message I completely disagreed with you, but I stared at the TimeQuest window (the waveform and the data path tabs) assuming you were right and everything just came into focus. While the Clock pessimism is in fact "added" to the clock delay, it is added to the data required clock delay, and the larger the data required clock delay, the more time you have in the cycle to do work. Without that clock pessimism added in, the amount of time I would have to do logic would be reduced given that the data required time would be earlier. So yeah, you are totally right and now this whole thing makes sense within the framework of the common clock path pessimism.  Thanks for your help!

[Altera_Forum]

Spot on. You got it.