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)

Okay, quick look at the receive side. First, I'm confused by what you're doing. If you have a PLL in ssync mode, just use "derive_pll_clocks" and don't bother doing the generated clocks. (I dislike that whole vcoph clock in the 28nm PLLs and glad we got rid of it in Arria 10. It just confuses things that don't need to be confusing).

The big thing is you want to say the clock is coming in center-aligned. That can be done by either shifting the external clock 180 degrees or shifting the internal clock 180 degrees. I prefer doing it on the external one, so do:

create_clock -name {sync_data} -period 12.50 -waveform {6.25 12.5}

Then:

create_clock -name {adc_refclk} -period 12.500 -waveform {0.000 6.250} { adc_refclk_in }

Then:

set_input_delay -clock sync_data -max# [get_ports {sync_in}]

set_input_delay -clock sync_data -min# [get_ports {sync_in}]

Let's take the output case where we set them to +/-4.4ns. That means the transmitter skews it by +/-1.85ns. If the board had 0 skew, then we just plug that directly into the set_input_delay:

set_input_delay -clock sync_data -max 1.85 [get_ports {sync_in}]

set_input_delay -clock sync_data -min -1.85 [get_ports {sync_in}]

Now, I'm not accounting for board skew. I'll let you figure that out, but let's say it adds +/-0.6ns. Just increase the set_input_delays by that:

set_input_delay -clock sync_data -max 2.45 [get_ports {sync_in}]

set_input_delay -clock sync_data -min -2.45 [get_ports {sync_in}]

Be sure to run:

report_timing -setup -detail full_path -npaths 50 -to_clock adc_refclk_out -panel_name "setup: ssync out"

report_timing -hold -detail full_path -npaths 50 -to_clock adc_refclk_out -panel_name "hold: ssync out"

report_timing -setup -detail full_path -npaths 50 -from_clock sync_data -panel_name "setup: ssync in"

report_timing -hold -detail full_path -npaths 50 -from_clock sync_data -panel_name "hold: ssync in"

I like to look at the Data Path tab and see how it traces all the delays through the FPGA and uses the clock edges and external delays.

I'm using DDIO blocks to try and minimise any skew between the clock and data - feeding the clock and data out directly would result in big differences as the clock is on the global network and the data has to travel a fair way through the chip to it's IO pin. I basically for the clock have it drive a 0 on the rising edge (so connected to the H input) and 1 on the falling edge (L input). For the data both the H and L inputs of the DDIO block are connected together - essentially forming an SDR interface. I used to use Xilinx FPGAs and this was apparently the optimal way of doing it on those, so I'm applying the same principal here.

I had initially tried with settings of I think about -max of 3 and -min of -3 based on the various examples (and calculating with the figures I have for delays and whatnot). But this failed timing with hold violations of pretty much any number I put in the -min constraint, which is why I was getting very confused. There were no setup violations, just hold.

I was trying to get timequest to spit out information on why the path was failing using the "Report Timing..." option, but I couldn't seem to get it to tell me anything - it kept saying no paths found to each of the searches I tried.

I'm just waiting for a compile to finish now (takes over an hour!), but once that is done I will try your suggestions and see how I go.

Just to clarify (saw your second post after making mine), for the input side I'm not generating the clocks myself, I'm using derive_pll_clocks, I was just including that information in case it was important (the commands were extracted from what had been automatically generated).

Tried the report_timings commands you posted and it did actually give me something useful this time. I see two hold paths, one with a relationship of -6.25ns with 3.84ns of slack (good), but also a second path which has a relationship of 0ns and -2.66ns of slack.

I think I am right in assuming this second path (the one which is violated) is actually a false path, because it seems to relate the falling edge of the launch clock (the clock driving the DDIO block) with the rising edge of the latch clock (adc_refclk_out). So I should probably cut timing paths between the falling edge of the internal one and the rising edge of the external one given that I actually clock the same data out on both rising and falling edges of the launch clock.