Why does the same path have different timing in TimeQuest?

[Altera_Forum]

Hello! 

I'm trying to constraint a source-synchronous output on my FPGA but I'm getting some timing numbers I can't quite understand (I feel they should be different). I've read Rysc's pdfs on both TimeQuest and Source-Synch interfaces (which are great, awesome contribution!) and Altera's application note (AN433) and I think I understand how it should work.  My system has 2 SDI transceiver inputs, both recovered clocks are running at a nominal 148.5MHz. This two clocks are then multiplexed through logic, I know ripple clocks are frowned upon but I didn't know how else to do it, I couldn't feed those clocks into a clock control block because they come from channel PLLs (which can't feed ctrl blocks) and there's actually another reason which I'm leaving out to simplify the description of the system.  In any case, since I won't be doing any synchronous transfer between the recovered and the ripple clocks (there's a dc FIFO in between) I don't think it should be a problem. AND to be sure (and drive the source synch output) there a PLL right after the logic MUX. This PLL is the one I'm using to read from the dc FIFO and output data into ALTDDIO registers with clock_0 and a second PLL output (clock_180) shifted by 180 to drive another ALTDDIO register with the output clock. The interface is actually SDR, but I figured having both data and clock go through ALTDDIO registers would help with keeping timing similar between them (I've added a false_path from the falling edge of clock_0).  Now, to my question and the reason why I'm confused. I'm running TimeQuest trying to constraint the output and I keep getting some numbers which I feel should be the same -although I'm not entirely sure- but are quite different. For example, when I generate a report of hold timing on the output (clock_0 to clock_180) I get the following (this would be for one of the clocks being muxed, there's basically two sets of identical constraints one for each SDI recovered clock): https://alteraforum.com/forum/attachment.php?attachmentid=14414&stc=1   I've drawn a blue line where the paths diverge, you can see the required path is using one PLL counter (clock_0) and the arrival path is using the other PLL counter (clock_180). Above this line is the path of the recovered clock all the way from the transceiver's channel PLL. Why is it that the increments are so different between both paths? If everything above the blue line is the same, shouldn't the increments be at least similar? I've highlighted with red two that are remarkably different.  I'm just trying to understand what's going on, this is the first time I've had to constrain something this complex and would like to know what's actually happening inside.  Thank you all!

[Altera_Forum]

TQ has "sub-models" to account for on-die variation. For example, let's say we're at the Slow Hot timing model where TQ gives a worst case delay for something. In reality, that is the worst possible delay but if you look at a bunch of delays they will actually vary and many won't be that bad. This is on the same die at the same voltage and temperature. So within a given timing model, there is a fast and slow sub-model. When doing setup analysis, TQ will use the slow sub-model for Data Arrival and the fast sub-model for Data Required. This gets flipped when you do hold analysis on the same path. 

But how is it possible the same element has two different delays at the same time? It isn't. The entire analysis is done as above, and then something called CCPP(Common Clock Path Pessimism) removal comes in and removes the variation on the clock path that is physically the same in the Data Arrival and Data Required. I don't see it in your screen-shots, but it should add up to the differences you're seeing. (There was an issue for ssync outputs where the CCPP removal only removed up to the PLL output and not past that, but I believe that has been fixed).  This has confused many an engineer, including myself, but is the way it's done.

[Altera_Forum]

That makes sense, now that you mention it I remember you wrote about it in your TimeQuest guide (about common clock path pessimism). I just hadn't yet fully understood this was what you meant. 

The ccpp removal is in the left screenshot, line 35, I just didn't include that column because I thought what I was seeing had something to do with the path and on all the other lines it just included net names so I figured it wasn't relevant.  Thank you for your time! =)