Timequest constrains for async SRAM

If you're registering your I/O, which is always recommended for best performance, than your I/O timing shouldn't really change. Just click on Report Datasheet, get the numbers and make the requirement a little bit looser. You will get an error if one of your I/O suddenly starts failing. The only benefit of a truly correct solution is if one I/O suddenly shifted and started failing, but the I/O on the other side of the transaction also shifted, which is unlikely. Yes, it would be nice if this could be done the right way, but if you do it this other way, you'll probably get the same results and it will always work, and it will give an error if something goes wrong.

Noting your next post, timing analysis is not a "how fast can that run" analysis. It is based on your requirements and is a pass/fail analysis. Now, in the simplest design where there is only one clock domain, you could probably get an accurate "how fast can that run" analysis, but as soon as you start having multiple domains interacting with each other, they don't scale like a single clock domain, for all sorts of reasons.