Timequest and PLL jitter

1) Constraints on the external clock(such as clock uncertainty) do not pass through to the lower level clocks. That would be far too pessimistic, as PLLs tend to filter out any noise. (I believe the Fitter Report -> PLL Summary has a Bandwidth value for each PLL, whereby it filters noise out of that bandwidth(I think), so if you do a spectral analysis of your input jitter and find what passes through, you could add it in. To date, I've never seen or heard of anyone doing that.)

2) If you do want to add uncertainty, append -add to your derive_clock_uncertainty, so any specific uncertainties you add will be additive values, rather than overwriting the values calculated by derive_clock_uncertainty.

3) I would be wary of debugging at this level, i.e. looking for broad level things like PLL jitter, board level VCC sag, ground-bounce, I/O spice analysis, etc. You could spend a lot of time and never uncover anything. I would strongly recommend getting your hands dirty and start SignalTapping as much as you can until you capture an failure, and then start diagnosing what could have caused it. Although this can be a very slow process at first, you at least always know you are progressing towards a solution.

4) One other thought is too just look at your slacks. All uncertainty does is take some values off your setup and hold slacks. If you feel it's too close, try shooting for more margin. (This is more straightforward with setup, but trickier with hold. By default, many paths will have very low hold margin, like a register feeding another register in the same LAB. That being said, by the nature of the layout there will be even less clock skew and it would be impossible to get a hold violation, so even though it's close, you shouldn't worry about.)