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.