Speed grades and internal timings

I think timing simulations are most valuable for non-synchronous design. Everything that's synchronous should behave in the timing simulation in an identical manner to the RTL simulation.

One thing people often don't realize is that timing simulations don't fail when you miss an edge. For example, let's say you have data that you expect to be latched into a register 10ns after the data is launched, but for some reason that data is delayed by 2ns, so it actually gets there at 12ns. Your timing simulation will not issue any sort of warning. Instead, your data just gets latched in a clock cycle later. Only if your testbench is able to recognize this as an error will you see a problem, and it will probably show up as a functional error until you trace it back to the data getting there too late.

If you go to a fast timing model, you'll now simulate the other extreme, where the data gets there much faster and is captured by that clock. So now you have two simulations, one with the data getting there on time and one with it getting a cycle late.

But now let's say this is a bus, and the system doesn't really care what cycle it gets there on, as long as it all gets there together. Neither simulations would show an error, since one would have all the data arrive early, and the other shows it all arriving late, while in hardware you could have some of both, which is an error. This is the type of thing static timing analysis catches that timing sims often do not.

The one thing timing sims do catch is a violation of the uTsu and uTh of the register. So if a register captures at time 10ns and the data changes in that small uTsu/uTh window, the register goes unknown and you get a direct warning(I think). But this window is very small, and its usually more of luck that a timing simulation would catch this than due to a rigorous testbench.

That being said, I'm working on a phase-aligning circutry that muxes four phases of the clock together and will actually extend or shorten the capture clock so it matches the incoming data stream. It's a really complicated design from a static timing analysis perspective, and this is the type of thing where a timing simulation might show how it's supposed to work better than an RTL simulation(it's not my design).

As for gating clocks, use a clock enable or use the megafunction altclkctrl(which has a nice synchronous enable for turning on/off the clock) when possible. For going between clock domains, batfink nicely covered that. At the end of the day, the simplest solution is to a) make sure the clocks are synchronized(outputs of the same PLL), or b) use a DCFIFO, which treats them as completely asynchronous. Other solutions take some understanding of what can happen. As batfink said, if it's a single signal crossing domains and you don't care what cycle it arrives on, then just re-registering it a few times should be sufficient.