Signaltap modify actual circuit when triggered problem.

[Altera_Forum]

Has anyone seen a issue where, when the "Run analysis" on Signaltap is clicked, the operation of the actual design actually changed? 

 I am using signaltap to monitor a ADPLL loop control. I have some of the actual clock and signal being pinned out to be monitored. For example I monitor the VCO output of my ADPLL with external frequency counter.  There is no error during compilation, and when the image is d/l into the FPGA, the loop works, and lock. The reading on all the output pin is correct. The loop stays in clock as can be seen on the counter with a correct freq.  However, when I click the "Run Analysis" on the GUI, the loop immediate lose lock, and the VCO outputs a wrong frequency, as seen on the counter. This means the Signaltap actually MODIFY the way the design works, when triggered. This is un-acceptable, as signaltap should be passive, and surprised me.  I am on 12.0sp2. Anyway seen this too?

[Altera_Forum]

I once had a design that failed because SignalTap traces had crosstalk with another interface. (Ours was somewhat the opposite, where as soon as the other interface started running the JTAG interface died.)

[Altera_Forum]

I would think too it could be a cross talk problem with the JTAG signals, or maybe a power supply decoupling problem? For example on the Cyclone III and IV, the VCCA supplies are used for both the PLLs and the JTAG system, IIRC.

[Altera_Forum]

--- Quote Start ---  I would think too it could be a cross talk problem with the JTAG signals, or maybe a power supply decoupling problem? For example on the Cyclone III and IV, the VCCA supplies are used for both the PLLs and the JTAG system, IIRC.  --- Quote End ---    There is of course such possibility, especially with Rysc's case. where another "external" interface may render the Jtag interface being "choked". However in my case, the internal PLL are all still stable and output a correct frequency. The ADPLL that I am referring to, is purely a logic design, purely LE, and got nothing to do with the PLL inside the cyclone. Even if the clock is de-stablised by the "JTAG noise", it should be able to recover, unless, the logic has been "changed" by the "Run Analysis".

[Altera_Forum]

I don't see how the logic could be "changed" by run analysis. The closest connection between design and the signaltap block is a chain of pipeline registers clocked by the aquisition clock. There are additional registers for signals operating as trigger and a combinational LE for storage quailifiers, but nothing that would be packed with user logic by Quartus.

[Altera_Forum]

One suggestion would be to upgrade to Quartus 12.1, SP1. I've had some funny problems with SignalTap in the latest previous versions. 12.1 SP1 seems to be an improvement. Best, James

[Altera_Forum]

With signaltap in Quartus 12.0SP1,  

I have checkboxes that that are deactivated with no reason. Trigger signal no upedated.

[Altera_Forum]

Well, believe it or not, I did a archive, and reboot the system. Did a re-compile (with the original), and the problem disappeared. Definitely a unstable version in terms of Signaltap, IMHO.

[Altera_Forum]

--- Quote Start ---  I don't see how the logic could be "changed" by run analysis. The closest connection between design and the signaltap block is a chain of pipeline registers clocked by the aquisition clock. There are additional registers for signals operating as trigger and a combinational LE for storage quailifiers, but nothing that would be packed with user logic by Quartus.  --- Quote End ---    Well, I would agree with you, that it shouldn't. Like your inside information suggested, it should not behave like what I have. However, true enough it is behaving this way, and somehow, it recovered, after I rebooted the machine(see my last post). Looks like something is really "wrong" with Signaltap and Quartus II 12.0sp2...and it is behaving beyond the "boundary" of the Signaltap developer.  Is there any improvement to Signaltap in 12.1sp1, in your opinion?

[Altera_Forum]

I've seen some strange bugs with Quartus 11 and over when it tries to reuse parts of the last compilation to save time. Now when I see something strange that I can't explain, my first attempt to sole the problem is to delete the db and incremental_db folders and recompile again ;) I believe that archiving the project and recompile from the archive would produce the same result.