Simulator accuracy

People often get away with using divide-by registers, but always use a PLL if you can. (In fact, if you truly need a combinatorial clock that is based off of a single main clock, I recommend putting everything on the main clock and creating logic to feed the clock enable, i.e. in your case the divide by two output would be used as a clock enable instead of a clock). Using a PLL(or single clock with clock enable) keeps your edges aligned, which allows a lot of the difficulties in timing analysis to be ignored.

For IO timing(i.e. to your ADC), which timing engine are you using, Classic or TimeQuest? If you're just getting starting with timing analysis, I would recommend TimeQuest, since it's the way of the future. I think it's a little harder to get started(i.e. TAN does a lot of stuff behind the scenes for you), but once you've got your basic building blocks(clock constraints and IO constraints) going, it's much more powerful and you'll enjoy using it.

For IO timing, make sure you do all the calculations. The whole point of slow/fast models is that you cover your basis, so once the numbers get tight(say 2ns in your case, but they can be much less than that), you can be sure your device will work in all conditions. What's the clocking scheme? If you're board level clock that feeds the FPGA also feeds the ADC, then you've got a pretty standard analysis. If the board clock is laid out for low clock skew, then you've got a single period for the ADC to get data off chip, across the board, and into the FPGA. If there is skew, you need to account for that. If your ADC sends a clock to the FPGA alongside the data, it gets more complicated. I believe there is a Source-Synchronous App Note for TimeQuest that was put on the web. That's close to being as complicated as it gets, but usually isn't too bad.