I suspect you are encountering a zero-delay loop race condition in the code. When the -access option is used, under the hood the result is the turning off of optimizations designed to have the simulator perform as efficiently as possible. When optimizations are enabled/disabled the result can be a reordering of events within the various time slices. In a race-free design this reordering will have no effect on the result of the simulation. If there are races in the design, however this reordering can and often does highlight situations in the code that are dependent on a certain evaluation order to produce the desired simulation effects. Because different simulators use different algorithms to process events, changing from one simulator to another can also highlight code that is dependent on a given evaluation order.
How to find the race? That's really the million dollar question. Unfortunately it's not always easy. One method would be to add "+nclinedebug +gui" to your command line to bring up the simulation in an interactive gui. Bring up the source browser and hit the play button and take note of the increasing time and delta cycles. When you note that time has stopped and only delta cycles are increasing you know that you have encountered the zero-delay loop. Thereafter hit the pause/play button until you can determine the section that code that is getting updated and reupdated during the loop.
Hope that helps.
Hello Jack and Mike,
I am facing the same problem as yours and I am using Synopsys's STIL Direct Pattern Validation flow, which means I am taking the patterns generated by Tetramax and simulating using NCSIM and having that same hanging issue. My problem is that I can not disable access since it is used by PLI routins to force values during simulations. Is there any other way of getting rid of that haning issue other than disabling access?