Help with very small hold time violations

[Altera_Forum]

I am getting 50-100 ps negative hold slack on registers using the register feedback into the LUT. The launch and latch clock are the same, and the from and to node are also the same. 

 The clock is 100 MHz. The part is a Cyclone III. I have enabled Optimize hold timing on all paths, as well as multi-corner timing.  From my understanding there is a 0ns hold requirement on these registers. I have attached timing analyzer waveforms of an example failing path, and a passing path that is on the same clock but does not use the feedback path inside the LE.   Is there any reason the fitter isn't adding delay to these paths to meet timing?

[Altera_Forum]

Is clock path pessimism removal enabled? You would see a line item in the Path Summary tab. The clock tree uses a slightly faster sub-model to the source register and a slightly slower sub-model to the destination register, which models On Die Variation. Of course, when it's one clock feeding the same register, there is no On-Die Variation. The Common Clock Path Pessimism Removal is what adds back delay to counter this pessimism. If it's not on, you can turn it on under Assignments -> Settings -> TimeQuest. 

 Note that it's impossible to have a hold failure where the same clock is the source and destination, since the data delay will always be positive, and the clock skew is exactly 0, since it's only a single edge in question.  Also note that I have seen failures like this in some older versions of Quartus with early timing models, so make sure you're up to date.

[Altera_Forum]

You are correct. Enabling Common clock path pessimism removal fixed this timing error. Is there any time where this option should be turned on? It sounds like it is only useful for analyzing signals that cross clock domains. 

 I am using Quartus 9.0 Build 132.

[Altera_Forum]

It should always be enabled. (I think the first release with this option had it disabled for some reason, but all new projects have it on.) It really applies to all domains. Even within a single domain, there will be a point where the clock tree branches, with one path going to the source register and the other branch going to the destination, and those branches will have ODV. But CCPP will add a lot more of this pessimism back in when it's a single clock domain, making the ODV much smaller(as it should be).

[Altera_Forum]

Do these invalid hold violations cause the timing-driven P&R to do things that are unnecessary?

[Altera_Forum]

An invalid hold requirement can cause the fitter to add delays to meet that requirement, which can cause congestion. (Assuming Optimize Hold timing is set to all paths, which is what tells the fitter to add routing delays to meet hold requirements.) If it's small, it's probably not a big deal. Where it can be a problem is if a user adds a multicycle -setup of 2, or something like that, and forgets to add a multicycle -hold of 1, whereby they have a hold requirement that is a whole clock period, and hence the router needs to add a lot of delay to try and meet this.