set_input_delay constraint

You may just be failing setup altogether. You've got a 15ns round-trip requirement, with ~8ns chewed up externally, leaving 7ns for the FPGA. I would have thought it could make this, but hard to say without the design.

- Note that the fitter tries to meet both setup and hold, so if it can't meet either, it balances the two, i.e. it might be adding delay to get better slack on failing hold, although the setup fails too(e.g. it's better to have hold fail by -2ns and setup by -2ns then to have hold fail by -4ns and setup meet timing.) I doubt this is happening in your case since your hold requirement is 5ns and your min external delay is 6ns, so you've automatically met hold before adding in any FPGA delays. Now that I write it, this should definitely not be a problem. (If I thought it were, I would a) look for hold failures on this path in the fast timing corners, or b) comment out the min delay, so the min is the same as the max, and see if it still fails setup). Again, I don't think this is a problem.

- I don't think you feel comfortable with the constraints. Run the following in TimeQuest:

report_timing -setup -npaths 10 -detail full_path -from [get_ports FLAGD] -panel_name "FLAGD setup" -file "./TQ/FLAGD_setup.txt"

report_timing -hold -npaths 10 -detail full_path -from [get_ports FLAGD] -panel_name "FLAGD hold" -file "./TQ/FLAGD_hold.txt"

The setup is the one to be concerned about, but always good to look at hold. Anyway, look at the Data Path tab. The Data Arrival Path should show the base clock coming into the FPGA, going to the output clock PCLK, then wrapping back into the FLAGD port to the input register. There should be an iExt delay of 8ns(plus brd_dly). Basically this is the clock coming into the FPGA and creating data that wraps around externally to the latch register. The Data Required Path should then be that same clock coming into the FPGA and going to the latch register's .CLK pin. Once you understand that, you can see how the delays are calculated and add up. It may be that it just doesn't meet timing. If you want, attach the FLAGD_setup.txt to this post.

If it just can't meet setup, two thoughts:

- The quick one is to make it launch on the rising edge rather than falling. You would need to change the logic to accomodate this, but you could just do a test run in the .sdc by removing the -invert in the generated clock and compiling. This will make your hold relationship 10ns and setup 20ns. This buys 5ns of delay for setup and it should be able to meet timing. My only concern is now the hold is not a slam dunk, i.e. the relationship is 10ns, the external delay is ~7ns, so the FPGA needs to add at least 3ns. This probably occurs automatically by what it routes through, but if it doesn't the fitter will need to add delay, which makes setup a little tighter.

- Another option if you can't thread this needle is to use a PLL and have separate clocks drive the launch and latch edges. This way you can dial the latch clock exactly where you want it, i.e. it could have a +7ns shift or something like that(with edges, you have to be a multiple of 5ns).