The first thing to do is figure out what is consuming your simulation time – and that means profiling the code. All simulators provide this capability, and it’s something a lot of verification engineers ignore altogether – or ignore until late in the design cycle. I like profile my simulation env early in test bench bring-up.
Except under rare circumstances, I would expect the vast majority of simulation time should be consumed by the DUT. If that’s not the case, you have a problem, and I would start with the “low hanging fruit” from the profiling results.
Once you have done all you can w/the testbench code, there are tricks you can do w/the RTL. For example, suppose your design in a 16-port Ethernet switch. For some sims, it may be worthwhile to force gate the clocks to some of those – say 12 ports, and restrict your stiumulus to route packets thru the remaining 4 ports. In this way, you can drastically reduce unecessary simulation events and speedup sims.
Finally, ensure that you do not run sims w/waveform dumping enabled unless needed. For regressions, I run all my sims w/out waveform dumping enabled. When I encounter a failure, my regression scripts automatically rerun the failing test/seed w/waveforms enabled. This is the best of both worlds – my sims run as fast as possible when passing (and consume less disk space), and at the same time, I have waveforms ready for debug when needed.
Good Luck –
Dan