SignalTap corruption

[Altera_Forum]

I'm having a problem with SignalTap II - the waveform is corrupted - signals that are known to be static toggle, states within a state machine appear to be simultaneously active, and the trigger conditions don't work properly. One clue is that with a smaller number of signals (say 10), the problem seems to go away or perhaps it's much less frequent and I don't notice it. There are no timing errors. To be sure, I added some constraints to the SDC that I found on another post. The clock for it comes out of a PLL which I've confirmed (by other means) is locked. The frequency is 50 MHz and synchronization of course doesn't matter for monitoring a static signal. My target is the DE2-115 board, which I believe has USB Blaster (not Blaster II) on it. I've re-installed the (Windows 7 64-bit) USB driver for that but it made no difference. I'm running Q 13.0 SP1. Ever have this problem? Any help appreciated!

[Altera_Forum]

i've seen conflicting reports about the JTAG constraints either breaking or fixing STP 

 if you area including the JTAG SDC constraints, try removing them. if you don't have them, try adding them. see page 23:  http://www.altera.com/literature/manual/mnl_timequest_cookbook.pdf

[Altera_Forum]

Thanks for your suggestion. I tried compiling it both ways - with and without the constraints listed on p. 22 for JTAG - but still see the problem occur. There are a few static signals that still toggle. Is there a way to test the integrity of the JTAG/USB link? I never seem to have a problem in the download direction with the programming file... 

 Any other suggestions? Thanks again.

[Altera_Forum]

A simple way to distinguish between SignalTap internal acquisition and JTAG signal integrity problems is to press the "Read Data" button and transmit the same acquisition again. If you get arbitrary different waveforms on each re-transmit, it's a signal integrity problem. If the waveform is exactly kept, the garbage is already in the internal stored data. 

 I can't however imagine a way to get toggling data from a (1.) registered and (2.) known static signal, except for an aquisition clock that violates the minimum pulse width specification, e.g. caused by a too high PLL frequency or the PLL falling out of lock.  JTAG signal integrity problems can be easily brought by EMI, particularly power electronic devices switching near by, possibly also by on board cross talk of fast signals. Unfortunately, SignalTap data streams are apparently transmitted without any checksum or CRC.

[Altera_Forum]

So when I press the "Read Data" button several times, I get arbitrary waveforms, which points to link integrity. But I don't know how to fix this yet. I replaced the USB cable with one that has an integrated ferrite core. I also tried a different 12V power brick though I'll now replace that with a linear supply and see what happens. This problem occurs on a DE2-115, which has the Blaster connector an inch away from the DC power connector. Any further suggestions appreciated.

[Altera_Forum]

nice trick FvM. i went through the trouble of making a small System Console environment to test JTAG integrity 

 strange this problem is happening on a devkit. are you using an Altera USB Blaster (with the yellow ribbon connector)?

[Altera_Forum]

Reading the spec of this board, it has On-board USB-Blaster circuitry. Did you use that? Have you tried to create a simple design and see whether the same problem happens as well? 

 There is JTAG Chain Debugger under Tools menu. I don't know whether it does anything useful in your situation. The IDCODE test may be the one to run for a long time.

[Altera_Forum]

I still haven't solved this problem...  

 I suspect my problem has something to do with running a time-limited SOF. I'm using the Altera TSE MAC, and unfortunately, I'm at the stage where if I remove it, then I can't make any progress to test and debug my design. I've learned to keep only a handful of signals in ST - and trust it only part of the time.  Signaltapit, yes, I use the on-board blaster circuit. I tried your suggestion with the debugger tool and it never results in a failure. I set the iterations to 1000 and ran it about 10 times.  I program the chip using the standalone programmer and then run ST after that. Sometimes it works but often I get corrupted and worse, misleading waveforms. Most annoying is that it won't trigger correctly. I've never had this problem before with ST (I've done many designs - though never with a time-limited SOF). Any help appreciated.

[Altera_Forum]

It's been a while. I don't know where you are with this. Thinking that the JTAG Chain Debugger may not be that useful to detect possible signal integrity issue along the JTAG chain, I decided to write one myself. Brushing up my skill of TCL and learning a bit about TK, I finally got something done in a presentable state. Having had a couple of good weekends didn't help either;) After this experience, I am still not fond of TCL/TK at all. I wish one day this EDA industry can get away from it. You can read about and get the script from this page signaltapit.com/jtag-chain-tester/ I believe it is a better way to test JTAG chain. 

 Reading your last post, somehow, I think there is another possible suspect apart from JTAG communication. Have you paid attention to the timing on the acquisition clock domain? Do you have the correct timing constraints set on that clock domain and all timings are met?