Set_input_delay misunderstanding

uncertainty is only applied between clocks, and it is a limitation that it can't be applied on specific paths. That being said, it models things like clock jitter, which occur at the clock source and are not path specific. So when the user takes a clock that goes into the FPGA, and also says it's used externally, the tool can only apply one uncertainty number. In the end, this is the wrong way to do it, but is legal .sdc and so the tool won't error out. But when the user correctly creates a virtual clock, the tools can show that there will be jitter on the internal clock in relation to this external one, which reduces the requirement by 20ps.

(I was looking to see if this was reported by Check Timing, but it doesn't appear so. That being said, there are cases where the clock on an I/O pin is used for external timing. It's when the clock is sent out the FPGA via an output or bidir pin, and is then used in a set_output_delay to latch the data externally, or a set_input_delay to latch the data back into the FPGA, such as a read from an asynchronous RAM. In this case the set_input_delay uses a clock that is inside the FPGA, and the lack of uncertainty is correct.)