LVDS Sampling Data

The FPGA introduces uncertainty in its fabric. That uncertainty can cancel out when both the source and destination is inside the FPGA, so it can be a smaller number. When one clock is outside the FPGA, the uncertainty between that clock and the one in the FPGA is a little higher. To be honest, the time I looked at it, I was using a PLL. I just looked at a small test design I have, and I get the same uncertainty whether using a virtual clock or the FPGA clock. I would still argue it's good practice to do a virtual clock, but not wrong if you don't. (Lots of users don't do the virtual clock and are unaware of it, which is another reason I point it out.)

report_timing -setup -from fpga_clk will work if the only paths from fpga_clk are from the I/O. You will minimally also now see the paths from the input registers, which are clocked by fpga_clk, to registers in another domain. If fpga_clk feeds thousands of registers, then you might get thousands, or tens of thousands, of paths listed before you ever see the I/O. I always recommend creating a .tcl script that analyzes "things of interest", which always includes I/O interfaces. Just having:

report_timing -setup -npaths 200 -detail full_path -from ext_clk -panel_name "LVDS Inputs||setup"

report_timing -hold -npaths 200 -detail full_path -from ext_clk -panel_name "LVDS Inputs||hold"

I don't run it all the time, but just to have it accessible in the project directory if I ever want to look at it again is useful.