Timequest - Constrating Centre-Aligned SDR

Looking at the output side first, why is it SDR and not DDR? You say your clock drives two DDIO outputs, one for clock and one for data, which would make your data DDR, right?

Assuming the data output is SDR and changes on the rising edge of clock(either by not having DDIO on the data output, or sending the same data value twice in a row), then you are sending it SDR with the clock center-aligned to the data. For FPGA -> FPGA interfaces, I find it best to constrain the output side first and get it as tight as possible. So for 80Mbps data rate, that is 12.5ns. Since it is center-aligned, TimeQuest setup analysis should show the setup relationship at 6.25ns and the hold relationship at -6.25ns. So do a pass where your external delays chew up all that margin:

set_output_delay -max 6.25 -clock [get_clocks adc_refclk_out] [get_ports sync_out]

set_output_delay -min -6.25 -clock [get_clocks adc_refclk_out] [get_ports sync_out]

With the external delays chewing up all of the margin, this will fail timing because even 1ps of skew between clock and data will show up as negative slack. So let's say after compiling your setup slack is -1.6ns and your hold slack is -1.7ns. That means your clock could come as much as 1.6ns after the clock to 1.7ns before the clock, i.e. that is the skew(ignoring the 180 degree phase-shift). Be sure to check the slacks across timing models to really get the worst. With that, modify your constraints and recompile:

set_output_delay -max 4.65 -clock [get_clocks adc_refclk_out] [get_ports sync_out]

set_output_delay -min -4.55 -clock [get_clocks adc_refclk_out] [get_ports sync_out]

You may want to round them to something that isn't down to the exact ps to meet timing, i.e.:

set_output_delay -max 4.4 -clock [get_clocks adc_refclk_out] [get_ports sync_out]

set_output_delay -min -4.4 -clock [get_clocks adc_refclk_out] [get_ports sync_out]

So now confirm you can recompile and it meets timing. What this constraint says is the data can be skewed by +/-1.85ns compared to the clock and it will still meet timing. Now that the output is constrained about as tight as it can go, you can take that number and plug it into the input side.

Note that this approach is good when timing is tight. Another approach that might work is to just give it a decent amount of room. For example, just plug in:

set_output_delay -max 4.0 -clock [get_clocks adc_refclk_out] [get_ports sync_out]

set_output_delay -min -4.0 -clock [get_clocks adc_refclk_out] [get_ports sync_out]

This is without compiling anything, just saying the data can be skewed by +/-2.25ns and still meet timing. If you compile and meet timing, great. That means the board + receiver can then add in the extra +/-4ns of skew and still meet timing. Those are pretty large windows and it might just all work and have plenty of margin.

(When both transmit and receive are FPGAs and have variable timing, it's gets more complicated because you constrain each one in relation to the other. That's why you either need to lock one side down first, or pick something in the middle that allows for a decent amount of skew on both sides)