SignalTap sampling issues

[Altera_Forum]

Hi, 

I'm using Quartus II 7.0, and a Cyclone EP1C6F256. I'm trying to use SignalTap to look at some signals in the design. The SignalTap sample clock is the same as my design's clock - the output of a PLL, running at 60MHz.   The problem is that the signals captured by SignalTap do not seem to represent what's actually going on - I put a scope on one of the device output pins and the result doesn't match what I see on the same signal in SignalTap. The SignalTap signals are toggling frequently - it looks like they're very noisy. Even the main global reset signal is showing lots of toggling in SignalTap, and I know this isn't actually happening. Is this a clock synchronisation issue? I often use SignalTap but have never seen anything like this before - what am I missing?  Any advice gratefully received,  Cheers R

[Altera_Forum]

Note that Quartus does run static timing analysis on the SignalTap blocks, so you should get timing failures if there was a problem. (If you sampled the data in SignalTap with a clock that was asynchronous to the clock domain you were sampling from, then you wouldn't get errors because you had told static timing analysis the clocks aren't related and shouldn't be analyzed. But you've already said you're using the same clock.) 

 Another really strange thing is the asynch reset, which I'm guessing should be static through the process, isn't. If there were timing issues, a static signal would still show up static.  I've never heard of internal noise like you're describing. I really don't think that's the issue.  If there were noise on your JTAG lines, which is definitely possible, the symptoms I've seen are failure to communicate, i.e. more robust failures, not bad data. (I have a previous post on JTAG noise that is probably worth reading.)   So to sum it up, I'm kind of at a loss. If you do some more debugging and get more info, please post it.

[Altera_Forum]

When nothing makes sense, check your basics first. Depending on how new the board design is, check: Power supply voltages, reference clock(s) to the part, and the locked signal of the PLL clock you are using for the capture. Check timing closure, and try to focus on sampling registered signals if you can. If you have pulled a bunch of test signals to pins, like it sounds you may have, bring out the capture clock and check it thoroughly on a scope. If the foundations are solid, then it will be a little more tricky / intriguing to straighten out. I love/hate signal tap and use it often as well. Still I always bring out a full MICTOR connector worth of test pins.

[Altera_Forum]

--- Quote Start ---  I always bring out a full MICTOR connector worth of test pins.  --- Quote End ---     There are a couple of additional Quartus features that can be used with test pins. [LIST]SignalProbe lets you bring out internal signals to device pins. You can change which signals are probed with recompiles that are faster than a regular Fitter runtime.[/LIST] [LIST]The Logic Analyzer Interface lets you preselect a large number of internal signals to bring out to a relatively small number of device pins. You can dynamically change which internal signals are currently being monitored on the test pins using a GUI that communicates with the Logic Analyzer Interface by JTAG. [/LIST]  Another JTAG-controlled debugging feature is In-System Sources and Probes.  Information on all these debugging features is in the Quartus handbook, Volume 3, Section V: In-System Design Debugging.

[Altera_Forum]

Thanks for all the suggestions. I discovered a pull-down resistor on the JTAG clock on the target board was missing - only an ac termination was there (RC in series to ground). Fitting the resistor has fixed the problem. I'm puzzled how I managed to program and verify the device, and run SignalTap at all, if there was a problem with the clock, though. 

Cheers, R

[Altera_Forum]

Did you try to sample also on higher clock frequencies ?