LVDS Sampling Data

create_clock -period 5.952 -name fpga_clk [get_ports fpga_clk]

create_clock -period 5.952 -name ext_clk

derive_pll_clocks ;# (Not doing anything, but I assume you have PLLs doing somethign else)

derive_clock_uncertainty

set_input_delay -clock ext_clk -max 0.5 [get_ports {LVDS_DATA[*]}]

set_input_delay -clock ext_clk -min -0.5 [get_ports {LVDS_DATA[*]}]

set_input_delay -clock ext_clk -max 0.5 [get_ports {LVDS_DATA[*]}] -clock_fall -add_delay

set_input_delay -clock ext_clk -min -0.5 [get_ports {LVDS_DATA[*]}] -clock_fall -add_delay

-----------

That describes what's going on. Note that the launch and latch clock edges are aligned, which means data sent from say, a rising launch edge, will be clocked in by the falling latch edge(i.e. the next edge). So to get the optimal solution, Quartus has to add delays to the data. You may actually want to capture on the same edge, i.e. have the clock delay be longer. This is probably the case, since your clock delay to the I/O registers will be long but the data delay is short. In that case, you need to tell TQ to do different edge transfers then the default. This is done like so:

set_multicycle_path -rise_from [get_clocks ext_clk] -rise_to [get_clocks fpga_clk] -setup 0

set_multicycle_path -fall_from [get_clocks ext_clk] -fall_to [get_clocks fpga_clk] -setup 0

(If you draw out the waveforms and look at the default relationships, this one hopefully makes sense. Be sure to look at how multicycles work on my TQ guide on alterawiki.com.)

Finally, the resource the clock uses will be determined by Quartus, but not by timing constraints. It can use a global, regional or local routing(depending on FPGA). They all have different delays and can make a difference.