Expected ALTPLL behaviour

I don't see 4.13ns reported directly in the timing analyzer - but when I open chip planner, and look at the connection from the input pin to the PLL, the net is tagged with the 4.13ns delay. The other delays in chip planner tie up fine with the timing analysis reports.

I'm not concerned about absolute delays as such, just surprised, like you, about how big this one is considering the dedicated routing involved - makes me wonder if I'm doing something silly, or missing something obvious.

As for the wider context, I'm basically trying to analyse all the timing uncertainties associated with a QDRII memory interface. The transmit side is classically source synchronous - data sent to the memory with a clock phase shifted by 90deg. The receive side uses a feedback clock (FPGA output--> PCB -->FPGA input) to clock the read data from the memory into FPGA DDR input registers. The PLL in question is in the receive clock path, nominally to deskew the clock (an attempt to reduce timing uncertainties; works for Xilinx devices) and potentially to add a phase shift to improve setup/hold margins for resynchronisation.

Ahhh. I would ignore it, or file a Service Request. If it's not in the timing report, then the Chip Editor must be doing something wrong, or displaying something different than what you expect. The timing report is what really should be used.

You should get the same type of analysis as you get in Xilinx. Note that for source-synchronous you're actually going to miss some uncertainty. For example, at the slow corner you get a worst case data and clock Tco. But on a given piece of silicon, one of the paths might be "less worst case" than the other. You won't see that in SII, and didn't see it in Xilinx. (It should be small, but it's real).

For all 65nm families and beyond(SIII, CIII, etc.), and using TimeQuest, the models have this type of information. So at a corner, say the slow corner, the paths have a fast On-Die Variation nad slow On-Die Variation value. So for a source synchronous output, TQ will use the slow verion for the data and the fast version for the clock going off chip, and vice versa for the external hold analysis. Also, rise/fall times and unateness come into affect, as well as common clock path pessimism removal. This doesn't help you with your current design, but is a plug of things in the newer family models that TimeQuest takes advantage of.