How to utilize programmable delay chain?

I wasn't able to get the inputs timed with the .zip. But once I've made the change, you're right that the setup fails at the fast corner. Basically the clock is on a global clock tree and is basically a fixed path. The data comes in and the delay chain is set to 0. At the fast corner this still fails setup timing. (The default setup is that the data path needs to be faster than the clock path, which should be easy since the clock is on a global. But once we add in the 900ps of external delay from your timing constraints, we're saying the data path must be more than 900ps faster, and it just isn't.)

I decided to go the other way, and rather than a same-edge capture, do the normal next edge capture. To do this, I commented out the multicycle and false path exceptions on these I/O. After doing this, the setup relationship is 5ns and the hold relationship is 0ns, i.e. the next window after data is launched. (There is also a setup relationship of 10ns and hold of -5ns, which you could false path, but I never do this since it doesn't help anything, since the correct analysis is more restrictive and if you've met that, then you've met these less restrictive ones too). Anyway, after doing that I end up making setup by 2ns but failing hold by -1ns. When I look at the fitter report, the delay chains have been cranked up to their highest value of 6, i.e. the fitter is setting these to meet timing. I was thinking you could hand place the registers further away from the IO to get longer delays, but the problem is if you add ~1ns of delay in the fast corner, that's probably about 2ns of delay in the slow corner, i.e. you're likely to start failing setup.

Your design seems to be falling into a sweet spot(or unsweet spot?) where it just fails on the same-edge capture and the next-edge capture. Yuck. I went back to your original constraints and put a keep on the signal the clock goes through, and this forced it to route through a LUT before getting onto a global, which added enough delay to meet timing. (Hold met with >1ns of slack, while setup had only ~100ps of setup in the fast corner.) THe placer puts the LUT right next to the global, which is a little too fast, so I added a location assignment to pull it a little further away and that balances it a little better, with 382ps of setup slack and ~800ps of hold slack. Note that I am only looking at the lower DQ signals, so you probably need to do this for the H ones.

Code change:

signal s_sl_LDQS_In : std_logic;

attribute keep : boolean;

attribute keep of s_sl_LDQS_In : signal is true;

Location assignment:

set_location_assignment X59_Y6 -to s_sl_LDQS_In