How would you debug an issue that goes away when SignalTap is added?

[Altera_Forum]

I consider myself a fairly experienced FPGA engineer, but I've come up against a rather hard problem and I'm hoping someone can provide some tips. 

 How would you debug a problem in your FPGA design if it goes away when you add a SignalTap instance to try and observe it? This is basically what I've encountered. We have a large, complex design that fills almost an entire Cyclone II 2C35 part and it usually works flawlessly, but when it boots it sometimes comes up in an unusable state. Without going into too much detail, it basically has a processing pipeline in a seemingly deadlocked state, so that no data can be passed through it. By using a script to periodically reload the design and verify that it is functional, I observed that the issue occurs approximately once in every 20 or so boots. However, upon adding a SignalTap instance to try and diagnose the problem, it vanished--the design loaded over 150 times with no issues.  This suggests to me that the problem is not caused by a defect in my RTL-level VHDL description for the design. It must be some kind of timing issue which is sensitive to changes in the fitter results (maybe caused by metastability?), or perhaps even is introduced by the synthesis/fitter process. But I don't really know how to proceed with tracking it down. I have already gone through our SDC files with a fine-toothed comb looking for anything that could account for the problem, but I haven't found any likely suspects.  Ideally I would like to be able to compare the design post-mapping with and without SignalTap and look for qualitative differences, but there doesn't appear to be a way to do that with the Technology Map Viewer. If I could export the information to a text file format then I could process it with scripts to do the comparison, but there doesn't seem to even be an option for that ...  So: if it were you, how would you debug an issue that goes away when SignalTap is added?

[Altera_Forum]

Occasional errors are ususally related to timing issues, particularly incorrect processing of asynchronous signals. Hearing about a problem that occurs at system boot let me think either of a problem with asynchronous released reset or with the relation of PLL startup and reset of modules driven by generated clocks. 

 If the problem is known to occur only at startup, it may be easier to add safe state machine logic to the affected modules (if they are regular state machines) or similar user coded means that recover from deadlock.  SignalTap always changes the routing of a design. To debug the original design, gate level analysis with Modelsim can help. It will indicate those logic operations, where the design timing makes the result potentially unpredictable. You are also able to vary the timing of external signal systematically in the testbench.